「拿到筆試鏈接的時(shí)候說(shuō)實(shí)話我心里是沒(méi)底的?！?023年秋招我投的是小紅書Android開(kāi)發(fā)崗第一批筆試通知來(lái)得比預(yù)期要早。當(dāng)時(shí)翻遍了?？秃透黝惣夹g(shù)社區(qū)關(guān)于這場(chǎng)筆試的具體內(nèi)容分享非常少大多只有一句「考得比較基礎(chǔ)」這種模糊描述。真正坐到電腦前開(kāi)始答題才發(fā)現(xiàn)這套題和市面上流傳的Android八股文差異比想象中大得多。這篇文章我想把整場(chǎng)筆試從收到郵件到交卷的完整過(guò)程復(fù)盤一遍包括題型結(jié)構(gòu)、每題背后的考察點(diǎn)、考場(chǎng)上踩的坑、以及交卷之后我做了什么。如果你也在準(zhǔn)備小紅書或者同類公司Android崗位的秋招筆試這篇文章應(yīng)該能幫你少走一段彎路。1. 這批筆試的基本盤平臺(tái)、題量與時(shí)間分配1.1 筆試平臺(tái)與考試流程我這場(chǎng)筆試用的是?？途W(wǎng)的在線筆試系統(tǒng)正式考試前半小時(shí)就要進(jìn)入考場(chǎng)調(diào)試攝像頭、麥克風(fēng)和屏幕共享。這里有一個(gè)非?，F(xiàn)實(shí)的提醒?？途W(wǎng)對(duì)切出頁(yè)面、打開(kāi)本地IDE、切后臺(tái)這類行為會(huì)有記錄不同公司對(duì)此的容忍度不一樣。小紅書的規(guī)則是沒(méi)有明確的切屏次數(shù)上限但每一筆違規(guī)記錄都會(huì)留在后臺(tái)后續(xù)是否影響面試篩選誰(shuí)也說(shuō)不準(zhǔn)。所以我全程只在網(wǎng)頁(yè)編輯器里寫題哪怕代碼提示再難用也忍著不切出去。整個(gè)筆試時(shí)長(zhǎng)是120分鐘題量分成四塊單選題、多選題、簡(jiǎn)答題、編程題。題量不算夸張但每道題都飄著一種「我知道你復(fù)習(xí)過(guò)但我要看看你是真懂還是假懂」的氣息。選擇題看似簡(jiǎn)單實(shí)際每個(gè)選項(xiàng)都要細(xì)看簡(jiǎn)答題和編程題則需要留出足夠時(shí)間勉強(qiáng)趕完很容易在最后幾道送分題上寫崩。1.2 四類題型的結(jié)構(gòu)分布我按記憶整理了一個(gè)大概分布每個(gè)批次的題量和分值可能有浮動(dòng)以實(shí)際郵件通知為準(zhǔn)模塊題量分值占比建議用時(shí)單選題約10題25%20分鐘多選題約5題15%15分鐘簡(jiǎn)答題2題20%35分鐘編程題2題40%40分鐘時(shí)間分配上我最失策的地方就是前面對(duì)多選題糾纏太久導(dǎo)致簡(jiǎn)答題后半段寫得很趕。如果重來(lái)一次單選題最多20分鐘多選題最多15分鐘遇到猶豫超過(guò)1分鐘的題直接先標(biāo)記跳過(guò)等所有會(huì)的題做完再回頭。筆試的核心原則永遠(yuǎn)是「先拿穩(wěn)分再啃難題」。1.3 第一批筆試的定位差異小紅書的秋招筆試分批次安排提前批投遞的簡(jiǎn)歷基本都被分在第一批。第一批筆試的題量未必比其他批次大但特殊性在于它處在秋招最早期大家普遍還沒(méi)進(jìn)入刷題狀態(tài)這時(shí)候筆試成績(jī)對(duì)后續(xù)面試安排的參考權(quán)重會(huì)比想象中更高。所以別抱著「試試水」的心態(tài)去考每一場(chǎng)正式筆試都值得當(dāng)面試一樣認(rèn)真對(duì)待。我后來(lái)復(fù)盤時(shí)發(fā)現(xiàn)這場(chǎng)筆試的題目整體難度控制在「基礎(chǔ)扎實(shí)就能過(guò)、基礎(chǔ)不牢就露餡」的水平這也是大廠校招筆試的主流策略。所謂的高難度題其實(shí)并不在于題目有多偏而在于考察鏈路的完整性你只有真正寫過(guò)代碼、看過(guò)源碼、排過(guò)生產(chǎn)環(huán)境的問(wèn)題才能在簡(jiǎn)答題里寫出層次感。2. 選擇與多選基礎(chǔ)知識(shí)的考察邊界到底劃在哪2.1 單選覆蓋的知識(shí)面單選題部分給我的整體印象是不難但非常細(xì)?？键c(diǎn)集中在Java/Kotlin基礎(chǔ)、JVM內(nèi)存布局、并發(fā)與集合、Android四大組件與Handler機(jī)制、View繪制流程以及少量網(wǎng)絡(luò)協(xié)議。幾乎每一題都讓我產(chǎn)生「這題我好像見(jiàn)過(guò)」的既視感但選項(xiàng)里一定會(huì)埋一個(gè)模棱兩可的坑。幾個(gè)我印象比較深的知識(shí)點(diǎn)HashMap在JDK 8里的put流程包括hash擾動(dòng)函數(shù)、插入鏈表還是插入紅黑樹(shù)的判斷條件。很多面試題只背了「鏈表長(zhǎng)度超過(guò)8轉(zhuǎn)紅黑樹(shù)」但真正準(zhǔn)確的答案是鏈表長(zhǎng)度超過(guò)8且數(shù)組長(zhǎng)度不小于64時(shí)才會(huì)樹(shù)化否則優(yōu)先擴(kuò)容。synchronized鎖升級(jí)的偏向鎖、輕量級(jí)鎖、重量級(jí)鎖各自適用的競(jìng)爭(zhēng)場(chǎng)景。這里最容易丟分的是「偏向鎖在JDK 15開(kāi)始默認(rèn)被禁用」這類時(shí)間線細(xì)節(jié)筆試題目可能故意寫成「JDK 8里偏向鎖默認(rèn)開(kāi)啟」來(lái)試探你。String、StringBuilder、StringBuffer的差異以及字符串常量池在拼接時(shí)的行為。比如用final修飾的字符串變量拼接會(huì)被編譯器優(yōu)化進(jìn)常量池沒(méi)用final的引用拼接則走StringBuilder。View的requestLayout和invalidate的區(qū)別。一個(gè)會(huì)觸發(fā)measure和layout一個(gè)只觸發(fā)draw但如果你在子線程里調(diào)invalidate會(huì)得到CalledFromWrongThreadException而requestLayout正常情況下只允許主線程調(diào)用。Handler.postDelayed的消息延遲精度到底受什么因素影響。正確答案是受Looper所在線程的消息隊(duì)列排隊(duì)情況影響系統(tǒng)會(huì)按delay時(shí)間戳排序但前一個(gè)消息如果執(zhí)行太久后面的消息就會(huì)順延。這類題對(duì)工作一兩年的Android開(kāi)發(fā)其實(shí)是送分題因?yàn)槎际且惶斓酵碓谟玫臋C(jī)制。但對(duì)在校同學(xué)來(lái)說(shuō)如果只看過(guò)《Android開(kāi)發(fā)藝術(shù)探索》的章節(jié)標(biāo)題而沒(méi)有真正擼過(guò)源碼很容易被選項(xiàng)里的細(xì)節(jié)坑到。2.2 多選題的邊界陷阱多選題是本場(chǎng)筆試真正考驗(yàn)「知識(shí)邊界感」的部分。它不像單選那樣選一個(gè)正確答案就結(jié)束而是把某一個(gè)知識(shí)點(diǎn)的不同應(yīng)用場(chǎng)景分到四個(gè)選項(xiàng)里問(wèn)你哪些說(shuō)法正確。少選、錯(cuò)選、多選按規(guī)則都不得分。舉一個(gè)方向當(dāng)例子比如ANR的多選題四個(gè)選項(xiàng)分別描述前臺(tái)BroadcastReceiver超時(shí)時(shí)間、后臺(tái)Service超時(shí)時(shí)間、ContentProvider啟動(dòng)超時(shí)是否算ANR、InputDispatching超時(shí)的具體閾值。你不僅要記住「前臺(tái)廣播10秒、后臺(tái)廣播60秒」這種數(shù)字還得知道Service前臺(tái)是20秒、后臺(tái)是200秒更要知道ContentProvider啟動(dòng)超時(shí)在部分版本上也算ANR。一個(gè)數(shù)字記錯(cuò)整道題就沒(méi)了。我在考場(chǎng)上采用的策略是對(duì)沒(méi)有絕對(duì)把握的選項(xiàng)寧可少選。牛客系統(tǒng)的多選評(píng)分規(guī)則通常是選錯(cuò)不得分、少選得部分分所以「選確定項(xiàng)」比「搶分」要穩(wěn)得多。這個(gè)策略在后面的多選模塊幫我至少保住了兩道題的分?jǐn)?shù)。2.3 新特性到底考不考我在考前花了不少時(shí)間準(zhǔn)備Jetpack Compose、Kotlin協(xié)程、Flow這些新東西。結(jié)果選擇題幾乎沒(méi)怎么涉及ComposeKotlin相關(guān)考察也停留在let/apply/run的區(qū)別、協(xié)程的launch/async返回值類型這些層面。不是說(shuō)新特性不重要而是筆試題的視角在告訴你筆試考察的是你「能不能立刻上手干Android的活」而不是「能不能跟上技術(shù)新潮流」。新特性大概率會(huì)放到面試環(huán)節(jié)去聊。這也意味著大家在準(zhǔn)備筆試時(shí)優(yōu)先級(jí)應(yīng)該是Java/Kotlin基礎(chǔ)語(yǔ)法與集合框架、Handler/Looper/MessageQueue機(jī)制、View繪制流程、四大組件生命周期、網(wǎng)絡(luò)協(xié)議基礎(chǔ)這些要占掉七成精力。Compose這類新技術(shù)了解使用方式就夠了不建議花大把時(shí)間死磕。3. 簡(jiǎn)答題Handler內(nèi)存泄漏與ANR層次感決定分差3.1 Handler內(nèi)存泄漏的完整答案鏈路這套筆試有兩道簡(jiǎn)答題第一道就是經(jīng)典中的經(jīng)典Handler導(dǎo)致內(nèi)存泄漏的原因以及處理方案。這個(gè)題在面經(jīng)里被寫爛了但真正能拿高分的答案并不多。如果只寫「用WeakReference包一下」就是送死因?yàn)槊嬖嚬傧肟吹降氖峭暾姆治鲦溌?。我?dāng)時(shí)是按「引用鏈描述 根因定位 解決方案 工程化措施」四層來(lái)寫的第一層引用鏈描述。非靜態(tài)內(nèi)部類或匿名內(nèi)部類默認(rèn)持有外部類的引用這里的典型場(chǎng)景是Activity里new一個(gè)HandlerHandler未處理完的Message被MessageQueue持有Message持有Handler引用Handler持有Activity引用。由于主線程的Looper在App進(jìn)程存活期間不會(huì)退出MessageQueue只要存在這條引用鏈就不會(huì)斷裂GC就無(wú)法回收Activity。第二層根因定位。核心問(wèn)題是Message的生命周期可能比Activity更長(zhǎng)尤其用postDelayed發(fā)出的延遲消息即使Activity已經(jīng)finish它也會(huì)在消息隊(duì)列里躺到延遲時(shí)間到達(dá)。所以內(nèi)存泄漏的根源不是Handler本身而是「延遲消息 長(zhǎng)生命周期Looper 隱式持有Activity」這三個(gè)條件疊加。第三層解決方案。最經(jīng)典的做法是使用靜態(tài)內(nèi)部類WeakReference持有Activity同時(shí)在onDestroy里調(diào)用handler.removeCallbacksAndMessages(null)把消息隊(duì)列里與該Handler相關(guān)的所有消息一并移除。這兩件事必須同時(shí)做只做前者解決不了「消息還在隊(duì)列里占內(nèi)存」的問(wèn)題只做后者沒(méi)法應(yīng)對(duì)Handler可能被其他地方復(fù)用的情況。第四層工程化措施。在Kotlin環(huán)境里可以換用協(xié)程生命周期感知的Scope替代Handler利用Lifecycle框架在onDestroy時(shí)自動(dòng)取消協(xié)程從根上避免這種問(wèn)題。3.2 ANR的定位、分析與解決第二道簡(jiǎn)答圍繞ANR展開(kāi)什么是ANR、如何定位、如何解決。這道題很容易答成「主線程不能做耗時(shí)操作」一句話那就廢了。我用的是「類型判斷-獲取現(xiàn)場(chǎng)-原因分析-修復(fù)思考」這個(gè)流程。類型判斷上ANR有幾種常見(jiàn)形態(tài)InputDispatchingTimeout是5秒前臺(tái)BroadcastReceiver是10秒后臺(tái)BroadcastReceiver是60秒前臺(tái)Service是20秒后臺(tái)Service是200秒ContentProvider啟動(dòng)超時(shí)在部分版本也被視為ANR。不同超時(shí)時(shí)間背后是不同的調(diào)度策略前置知識(shí)不能錯(cuò)。獲取現(xiàn)場(chǎng)方面關(guān)鍵動(dòng)作是從設(shè)備導(dǎo)出 /data/anr/traces.txt或者用 adb pull /data/anr/ 抓取ANR發(fā)生的調(diào)用棧。如果現(xiàn)場(chǎng)正好在Android 10以上設(shè)備可以用perfetto抓取systrace數(shù)據(jù)看主線程執(zhí)行的時(shí)間線。原因分析上常見(jiàn)的主線程阻塞源有主線程直接做磁盤I/O、等待鎖時(shí)發(fā)生鎖競(jìng)爭(zhēng)、Binder調(diào)用主線程同步等待、死鎖、廣播接收器里做耗時(shí)操作、View層級(jí)中的過(guò)度測(cè)量等。答案必須有具體場(chǎng)景而不是「主線程慢」這種空話。解決思路上要把耗時(shí)操作移到子線程或協(xié)程中減少主線程消息隊(duì)列的積壓避免在持有鎖時(shí)做耗時(shí)操作。最關(guān)鍵的一點(diǎn)ANR機(jī)制是Android的自我保護(hù)我們要做的是「讓主線程更快消費(fèi)消息」而不是簡(jiǎn)單地把消息隊(duì)列清掉。3.3 怎么答題才像「有實(shí)戰(zhàn)經(jīng)驗(yàn)的人」簡(jiǎn)答題在全卷里分值不是最高的但它留給面試官的印象是其他題型比不了的。因?yàn)楣P試答卷會(huì)被當(dāng)成面試時(shí)的參考材料面試官會(huì)從你簡(jiǎn)答題的排版和邏輯里判斷這個(gè)人有沒(méi)有debug的習(xí)慣。我當(dāng)時(shí)的寫法是分點(diǎn)加粗每個(gè)層次一段整體用「現(xiàn)象-原因-定位-解決-驗(yàn)證」的結(jié)構(gòu)展開(kāi)。另外提醒一點(diǎn)筆試答題框不是IDE不要在里面寫大段代碼。簡(jiǎn)答題的重點(diǎn)是思路清晰、邏輯完整代碼展示反而會(huì)顯得你表達(dá)不夠凝練。寫上關(guān)鍵API名和偽代碼流程就夠了。4. Activity啟動(dòng)流程與AMS這批題里真正的分水嶺4.1 startActivity到首幀渲染的完整鏈路小紅書這批筆試?yán)镉幸坏雷屛矣∠蠛苌畹念}核心是讓你描述從startActivity到Activity顯示在屏幕上的完整流程。這種題是典型的Framework源碼題單靠背《Android開(kāi)發(fā)藝術(shù)探索》是答不全的。我當(dāng)時(shí)按這條鏈路寫的應(yīng)用進(jìn)程調(diào)用startActivity經(jīng)過(guò)Instrumentation的execStartActivity方法通過(guò)Binder調(diào)用到系統(tǒng)進(jìn)程的AMS也就是ActivityManagerService。這里要注意的是Android 10以后Activity調(diào)度職責(zé)被抽到了ATMS即ActivityTaskManagerServiceAMS更偏向進(jìn)程管理和內(nèi)存管理但整體上我習(xí)慣把它們合稱AMS。ATMS收到請(qǐng)求后會(huì)校驗(yàn)調(diào)用方的權(quán)限、解析Intent、判斷啟動(dòng)模式和任務(wù)棧配置。如果目標(biāo)Activity所在進(jìn)程還沒(méi)啟動(dòng)就需要通過(guò)Socket向Zygote進(jìn)程發(fā)送請(qǐng)求Zygote fork出新的應(yīng)用進(jìn)程。新進(jìn)程啟動(dòng)后會(huì)創(chuàng)建ActivityThread實(shí)例調(diào)用main方法創(chuàng)建主線程Looper然后調(diào)用attach方法把ApplicationThread這個(gè)Binder對(duì)象注冊(cè)給AMS告訴系統(tǒng)「我準(zhǔn)備好了」。接下來(lái)AMS通過(guò)ApplicationThread這個(gè)Binder代理通知ActivityThread去創(chuàng)建Activity。ActivityThread通過(guò)ClassLoader加載目標(biāo)Activity類創(chuàng)建實(shí)例并調(diào)用attachActivity的attach里會(huì)創(chuàng)建PhoneWindow和WindowManager。隨后系統(tǒng)調(diào)度Activity生命周期依次執(zhí)行onCreate、onStart、onResume。在onCreate里我們通過(guò)setContentView設(shè)置布局onResume之后ViewRootImpl接管視圖發(fā)起measure、layout、draw流程最終由SurfaceFlinger合成并上屏。這道題的關(guān)鍵不僅是把流程背下來(lái)還要在每個(gè)節(jié)點(diǎn)標(biāo)注出「這里是Binder跨進(jìn)程調(diào)用」還是「這里是Handler消息驅(qū)動(dòng)」這是能拉開(kāi)差距的層次。4.2 Binder為什么是Android IPC的默認(rèn)選擇和啟動(dòng)流程一起考的還有一個(gè)Binder機(jī)制的簡(jiǎn)答。題目很直白為什么Android選Binder而不是共享內(nèi)存、管道、Socket來(lái)做IPC。我當(dāng)時(shí)的回答包含三個(gè)層面第一性能上Binder只有一次數(shù)據(jù)拷貝。傳統(tǒng)的管道、Socket機(jī)制數(shù)據(jù)從發(fā)送進(jìn)程到接收進(jìn)程至少需要在用戶態(tài)和內(nèi)核態(tài)之間拷貝兩次而B(niǎo)inder通過(guò)內(nèi)核分配的一塊匿名共享內(nèi)存做映射數(shù)據(jù)從發(fā)送進(jìn)程直接拷貝到內(nèi)核緩沖區(qū)再通過(guò)內(nèi)存映射讓接收進(jìn)程直接讀取全程只有一次拷貝。第二安全上Binder具備調(diào)用方身份校驗(yàn)。Binder驅(qū)動(dòng)在內(nèi)核態(tài)就能拿到調(diào)用方進(jìn)程的UID/PID系統(tǒng)服務(wù)可以基于這個(gè)信息做權(quán)限校驗(yàn)偽造調(diào)用方身份比傳統(tǒng)IPC難得多。這套機(jī)制對(duì)整個(gè)Android系統(tǒng)安全模型至關(guān)重要。第三語(yǔ)義上Binder是面向?qū)ο蟮倪h(yuǎn)程過(guò)程調(diào)用?？蛻舳四玫降腂inder代理對(duì)象可以像調(diào)用本地方法一樣調(diào)用遠(yuǎn)程服務(wù)這種設(shè)計(jì)讓系統(tǒng)服務(wù)上百個(gè)接口的管理變得簡(jiǎn)單清晰。如果在回答里能補(bǔ)充「Binder一次拷貝但MMAP依舊會(huì)有一次內(nèi)存同步開(kāi)銷」這種細(xì)節(jié)會(huì)顯得你真的研究過(guò)而不是背框架。4.3 AMS與ATMS的新舊術(shù)語(yǔ)辨析Android 10之后啟動(dòng)流程里最大的變化是Activity的管理職責(zé)從AMS拆分到了ATMS。傳統(tǒng)框架在面試題里經(jīng)常把AMS和Activity管理綁定說(shuō)但新版系統(tǒng)里ActivityTaskManagerService負(fù)責(zé)Activity棧、Task和Window的調(diào)度AMS則聚焦于進(jìn)程、內(nèi)存、廣播隊(duì)列的管理。這道題我沒(méi)等到面試官問(wèn)直接在簡(jiǎn)答題末尾加了一句話「在Android 10以上的版本中Activity調(diào)度被拆分到了ATMS整體架構(gòu)上是AMSATMS協(xié)作完成啟動(dòng)流程?！购竺婷嬖嚨臅r(shí)候面試官確實(shí)對(duì)這句話產(chǎn)生了興趣追問(wèn)我ATMS和AMS的邊界到底怎么劃分。從結(jié)果看這一句補(bǔ)充的性價(jià)比非常高。5. 工程化大題R8、啟動(dòng)優(yōu)化與包體積控制5.1 R8在構(gòu)建流程里干了什么小紅書這套筆試?yán)镉幸坏拦こ袒较虻念}目題干給了一個(gè)和混淆日志相關(guān)的現(xiàn)象問(wèn)應(yīng)該如何配置保留規(guī)則防止指定類被裁剪或混淆。這題背后的知識(shí)點(diǎn)是R8的四個(gè)核心動(dòng)作。R8現(xiàn)在已經(jīng)替代ProGuard成為Android默認(rèn)的代碼壓縮與混淆工具它做四件事壓縮刪除不可達(dá)的類和成員優(yōu)化對(duì)字節(jié)碼做常量折疊、方法內(nèi)聯(lián)等操作混淆把類名方法名改成無(wú)意義短名脫敏適配字符串資源對(duì)類名的引用。實(shí)際配置時(shí)最常踩的坑是被反射調(diào)用的類、被Gson序列化的模型類、被注解處理器生成的代碼在混淆后找不到。最簡(jiǎn)單的處理方式是給這類類加Keep注解或者配置-keep class com.example.model.* { *; }。但更細(xì)致的做法是區(qū)分場(chǎng)景反射類要保留類名Gson模型要保留無(wú)參構(gòu)造器和字段名Keep注解在R8里也會(huì)被正確識(shí)別。如果你在筆試?yán)锬軐懗?keepclassmembers和-keepattributes的區(qū)別說(shuō)明你對(duì)混淆規(guī)則的顆粒度理解到位。前者是「只保留成員規(guī)則不保留類」后者是「保留注解、Signature等元信息」這也是很多線上崩潰的根因。5.2 啟動(dòng)優(yōu)化的完整答題閉環(huán)另一道工程題問(wèn)的是冷啟動(dòng)優(yōu)化策略。這種題沒(méi)有標(biāo)準(zhǔn)答案但答題一定要體現(xiàn)「定位問(wèn)題-確定瓶頸-動(dòng)手優(yōu)化-驗(yàn)證效果」的閉環(huán)而不是堆幾個(gè)「異步化」「懶加載」的術(shù)語(yǔ)。我的回答分三步第一步用Systrace或Perfetto記錄冷啟動(dòng)時(shí)間線區(qū)分Application的onCreate、Activity的onCreate和首幀渲染各占多少時(shí)間。只有數(shù)據(jù)出來(lái)了才知道優(yōu)化精力該投在哪。第二步針對(duì)主線程上的耗時(shí)點(diǎn)逐一處理非核心SDK初始化移到子線程使用有向無(wú)環(huán)圖的任務(wù)調(diào)度框架做并行初始化SharedPreferences讀取拆分并異步化內(nèi)容加載改成懶加載。第三步首幀渲染層面簡(jiǎn)化布局層級(jí)避免過(guò)度繪制減少冷啟動(dòng)階段的主線程磁盤IO。最后加一個(gè)驗(yàn)證手段用adb shell am start -W 包名/.MainActivity查看TotalTime或者用自定義的StartUpTimer埋點(diǎn)統(tǒng)計(jì)。有數(shù)據(jù)對(duì)比才能證明優(yōu)化有效。5.3 包體積優(yōu)化的規(guī)?；桨赴w積的題通常不會(huì)問(wèn)你「一張圖能壓多少」而是問(wèn)「你怎么在團(tuán)隊(duì)里持續(xù)控制包體積增長(zhǎng)」。當(dāng)時(shí)我的回答分資源、代碼和CI三條線資源線上開(kāi)啟shrinkResources配合資源混淆把大圖庫(kù)替換成WebP通過(guò)資源打包配置按需拆分多語(yǔ)言資源。代碼線上R8裁剪無(wú)用的Java代碼按ABI拆分so文件避免全量打包64位和32位兩套庫(kù)必要時(shí)用動(dòng)態(tài)特性模塊化把低頻功能做成遠(yuǎn)程模塊。持續(xù)化建設(shè)上在CI流水線里加上包體積Diff檢查單次PR導(dǎo)致包體積超過(guò)閾值就直接攔截。這個(gè)思路比任何優(yōu)化技巧都重要因?yàn)榘w積問(wèn)題本質(zhì)上是一個(gè)增量的工程管理問(wèn)題不是一次優(yōu)化就能搞定的。我特意在答案里加了「小紅書作為內(nèi)容社區(qū)App啟動(dòng)速度和包體積對(duì)用戶留存非常敏感」這個(gè)場(chǎng)景化表述讓回答更貼近投遞公司的業(yè)務(wù)形態(tài)。6. 編程題兩道題從讀題到提交的完整過(guò)程6.1 第一題字符串按字符頻率降序輸出編程題第一道是字符串處理給定一個(gè)字符串按字符出現(xiàn)頻率降序輸出頻率相同時(shí)按字典序或原順序輸出。這題的核心是HashMap統(tǒng)計(jì)加排序思路很直白難點(diǎn)在代碼的穩(wěn)健性。我的Java解法public String frequencySort(String s) { if (s null || s.isEmpty()) { return ; } MapCharacter, Integer freq new HashMap(); for (char c : s.toCharArray()) { freq.put(c, freq.getOrDefault(c, 0) 1); } ListCharacter chars new ArrayList(freq.keySet()); chars.sort((a, b) - { int cf freq.get(b) - freq.get(a); return cf ! 0 ? cf : a.compareTo(b); }); StringBuilder sb new StringBuilder(); for (char c : chars) { int count freq.get(c); for (int i 0; i count; i) { sb.append(c); } } return sb.toString(); }這道題有四個(gè)容易丟分的地方字符范圍不止字母可能有數(shù)字、下劃線甚至中文所以容器類型必須用Character而不能寫死a到z排序比較的是頻率而不是字母本身空串和單字符的邊界要處理最后拼接字符串的時(shí)候注意用capacity預(yù)估避免StringBuilder反復(fù)擴(kuò)容。6.2 第二題矩陣連通區(qū)域的最大面積第二道是DFS/BFS的圖論基礎(chǔ)題描述是在一個(gè)由0和1組成的二維矩陣中找到相鄰1組成的最大連通區(qū)域面積。核心是DFS每個(gè)格子最多遍歷一次時(shí)間復(fù)雜度O(row*col)。public int maxAreaOfIsland(int[][] grid) { if (grid null || grid.length 0) { return 0; } int rows grid.length; int cols grid[0].length; int max 0; for (int i 0; i rows; i) { for (int j 0; j cols; j) { if (grid[i][j] 1) { max Math.max(max, dfs(grid, i, j, rows, cols)); } } } return max; } private int dfs(int[][] grid, int i, int j, int rows, int cols) { if (i 0 || i rows || j 0 || j cols || grid[i][j] 0) { return 0; } grid[i][j] 0; return 1 dfs(grid, i 1, j, rows, cols) dfs(grid, i - 1, j, rows, cols) dfs(grid, i, j 1, rows, cols) dfs(grid, i, j - 1, rows, cols); }有幾個(gè)細(xì)節(jié)值得注意DFS會(huì)修改原數(shù)組來(lái)標(biāo)記已訪問(wèn)如果題目要求不修改輸入就得額外開(kāi)布爾數(shù)組遞歸方案在大矩陣上可能棧溢出技術(shù)上可以用顯式的循環(huán)棧替代遞歸但筆試環(huán)境里遞歸通常夠用判斷順序上越界檢查必須放在訪問(wèn)數(shù)組元素之前。6.3 考場(chǎng)上的一次翻車與補(bǔ)救實(shí)話說(shuō)第二題我在考場(chǎng)上先寫了一個(gè)BFS版本結(jié)果在出隊(duì)時(shí)的visited標(biāo)記時(shí)機(jī)上卡了幾分鐘。后來(lái)我果斷刪掉BFS代碼退回寫法最樸素的DFS一次通過(guò)。這在筆試?yán)锸呛艹Ｒ?jiàn)的情況不是你不會(huì)而是在時(shí)間壓力下容易把方案想復(fù)雜。我的經(jīng)驗(yàn)是筆試編程題的正確性遠(yuǎn)比代碼優(yōu)雅重要。如果你沒(méi)有十成把握寫出一個(gè)復(fù)雜的解法就選擇最穩(wěn)的解法先拿分。有的同學(xué)在考場(chǎng)上非要寫一個(gè)帶剪枝的優(yōu)化版本結(jié)果邊界條件處理不完反倒連基礎(chǔ)分都沒(méi)拿到。7. 復(fù)盤筆試之后我做的幾件事以及一份備考清單7.1 用錯(cuò)題反向建立知識(shí)樹(shù)交卷之后我沒(méi)有立刻開(kāi)始刷下一家的題而是花了半天把筆試?yán)锼心貌粶?zhǔn)的選擇題記錄下來(lái)按「Java基礎(chǔ)」「Android機(jī)制」「網(wǎng)絡(luò)協(xié)議」「工程化」四類歸到自己的知識(shí)點(diǎn)表格里。筆試?yán)锏腻e(cuò)題是最寶貴的復(fù)習(xí)材料它直接暴露了你的盲區(qū)在哪個(gè)具體分支上比隨機(jī)刷題高效得多。這次筆試之后我把Android崗的準(zhǔn)備重心調(diào)整成了這樣幾塊把《Android開(kāi)發(fā)藝術(shù)探索》里Handler、AMS、View繪制三章重讀一遍在源碼層面畫出startActivity和Binder的整體時(shí)序圖不求背行號(hào)但要能講清楚每一步是誰(shuí)調(diào)用了誰(shuí)每周固定做兩到三道DFS/BFS、字符串處理和鏈表相關(guān)的算法題整理一份「一頁(yè)紙答題模板」凡是遇到原理題就按「背景-機(jī)制-場(chǎng)景-邊界-解決」來(lái)組織文字保證不丟層次。7.2 一份可以直接抄的備考清單結(jié)合這場(chǎng)筆試和我整個(gè)秋招的經(jīng)驗(yàn)整理了一份實(shí)用性優(yōu)先的清單Java/Kotlin基礎(chǔ)集合源碼、HashMap的put流程、鎖機(jī)制與并發(fā)、String不可變性、Kotlin協(xié)程的launch與async差異。Android基礎(chǔ)Handler/Looper/MessageQueue、View測(cè)量布局繪制流程、事件分發(fā)機(jī)制、四大組件生命周期、任務(wù)棧與啟動(dòng)模式。Framework進(jìn)階startActivity完整流程、Binder機(jī)制、Zygote進(jìn)程創(chuàng)建、ANR原理、AMS與ATMS的分工。工程化與性能R8壓縮混淆規(guī)則、冷啟動(dòng)優(yōu)化、包體積控制、內(nèi)存泄漏檢測(cè)、穩(wěn)定性監(jiān)控思路。算法與數(shù)據(jù)結(jié)構(gòu)字符串、哈希表、隊(duì)列與棧、DFS/BFS、鏈表、二叉樹(shù)層序遍歷、雙指針。7.3 非技術(shù)層面的幾個(gè)提醒筆試當(dāng)天提前調(diào)好設(shè)備攝像頭、麥克風(fēng)、網(wǎng)絡(luò)都提前試一遍。答題遇到不會(huì)的選擇題要學(xué)會(huì)戰(zhàn)略性跳過(guò)把時(shí)間留給編程題。我見(jiàn)過(guò)不少人在多選題上死磕結(jié)果后面簡(jiǎn)答題只寫兩行、編程題超時(shí)這種失分是最可惜的。筆試本質(zhì)上考的是「你有沒(méi)有真正做過(guò)Android開(kāi)發(fā)」。寫過(guò)項(xiàng)目和只刷面試題的差距在簡(jiǎn)答題的組織層次和編程題的容錯(cuò)性上會(huì)體現(xiàn)得很明顯。這也是為什么有些同學(xué)看起來(lái)什么都背過(guò)分?jǐn)?shù)卻并不理想。最后說(shuō)一個(gè)我自己的體會(huì)小紅書這批筆試結(jié)束后大概一周內(nèi)收到了面試邀約整體推進(jìn)節(jié)奏比想象中快。如果你筆試感覺(jué)還不錯(cuò)那幾天就開(kāi)始復(fù)盤自己的項(xiàng)目經(jīng)歷不要等面試通知來(lái)了再匆忙準(zhǔn)備那時(shí)候真的會(huì)手忙腳亂。