這套卷三是我整理校招筆試題時印象最深的一套。原因倒不是它有多難而是它的出題邏輯特別“實(shí)”——幾乎每一道題都能在真實(shí)的Android開發(fā)場景里找到對應(yīng)位置沒有那種背八股就能拿分的純記憶題。小紅書作為內(nèi)容社區(qū)類App對候選人的考察明顯偏向信息流場景下的性能、穩(wěn)定性和架構(gòu)能力這一點(diǎn)從卷三的題目分布上能看得很清楚。這篇復(fù)盤我會按照卷面結(jié)構(gòu)逐題拆開把每道題背后的考點(diǎn)、破題思路、常見錯誤都過一遍。如果你正在準(zhǔn)備Android校招或者工作兩三年想查漏補(bǔ)缺這篇應(yīng)該能幫你在刷題時少走不少彎路。1. 卷三的定位與整體復(fù)盤這套卷子到底在考什么先說結(jié)論小紅書的校招筆試并不是單一難度階梯而是“基礎(chǔ)層 進(jìn)階層 業(yè)務(wù)開放層”三段式結(jié)構(gòu)。卷一、卷二通常用來篩掉基本功不扎實(shí)的候選人到了卷三出題人開始考察你有沒有形成自己的工程判斷力——也就是說答案本身不是最重要的重要的是你選擇方案時的理由。1.1 卷三在整套筆試中的位置根據(jù)那幾年校招筆試的普遍規(guī)律卷一、卷二以Java基礎(chǔ)、Android四大組件、網(wǎng)絡(luò)協(xié)議這些“題庫型”題目為主靠刷題可以拿高分。但卷三明顯換了風(fēng)格純選擇題比例降低簡答題和場景設(shè)計(jì)題占比上升還出現(xiàn)了一些需要結(jié)合實(shí)際開發(fā)經(jīng)驗(yàn)才能答好的開放題。這說明什么說明到了卷三這個環(huán)節(jié)面試官默認(rèn)你已經(jīng)具備基本知識儲備開始考察你的技術(shù)決策能力——同樣一個功能你用方案A不用方案B理由是什么你踩過什么坑這些坑能不能總結(jié)成方法論1.2 知識點(diǎn)分布與難度梯隊(duì)我按記憶把卷三的知識點(diǎn)分布做了個整理大概是這個比例知識模塊占比主要考察方向Java/Kotlin基礎(chǔ)15%集合、字符串、并發(fā)、內(nèi)存模型Android核心機(jī)制30%Handler、生命周期、Binder、AMSView體系與交互20%測量、繪制、事件分發(fā)、滑動沖突性能優(yōu)化與穩(wěn)定性20%ANR、內(nèi)存泄漏、啟動速度、包體積架構(gòu)與業(yè)務(wù)設(shè)計(jì)15%MVP/MVVM、組件化、信息流場景整體難度是遞增的。前面基礎(chǔ)題只要復(fù)習(xí)過都能答但從View體系開始沒真正寫過自定義View、沒處理過線上問題的候選人會明顯感到吃力。開放題更是如此不是靠背題能解決的。1.3 答題時間與策略參考那場筆試的時長大概是120分鐘我個人建議的分配是選擇題20分鐘內(nèi)搞定不要猶豫簡答題控制在70分鐘每題先寫核心要點(diǎn)再補(bǔ)細(xì)節(jié)開放題留30分鐘以上因?yàn)檫@類題最拉分很多人最后沒時間寫非?？上А＿€有一個特別重要的技巧寧愿字跡潦草寫完整也不要字跡工整寫一半。面試官看的是你的思路完整性不是你的書法。簡答題如果實(shí)在不會把能想到的關(guān)鍵詞、公式、流程都寫上去多少能拿點(diǎn)分。2. Java與Android基礎(chǔ)層程序員的“肌肉記憶”題這一部分對科班出身的人來說屬于送分題但對于跨專業(yè)或者基礎(chǔ)不牢的候選人反而是丟分重災(zāi)區(qū)。原因很樸素這些知識點(diǎn)太平常了平常到很多人用過就忘真讓你說出原理又說不太清楚。2.1 HashMap的線程安全與擴(kuò)容問題卷三出了一道關(guān)于HashMap的簡答題大意是在多線程環(huán)境下往HashMap里put數(shù)據(jù)會發(fā)生什么如何解決這道題的考點(diǎn)有三個層級。第一層是知道HashMap不是線程安全的第二層是能說清楚為什么不安全——resize擴(kuò)容時如果多個線程同時檢測到需要擴(kuò)容會各自創(chuàng)建新的數(shù)組然后互相覆蓋甚至在高并發(fā)下形成循環(huán)鏈表get時死循環(huán)第三層是能給出解決方案。解決方案本身不復(fù)雜用ConcurrentHashMap替代或者用Collections.synchronizedMap包裝。但這里有個容易踩坑的點(diǎn)很多人只知道ConcurrentHashMap線程安全卻說不清它的實(shí)現(xiàn)機(jī)制。面試官順著問下去如果連volatile和CAS都說不出來那就露餡了。正確的答題姿勢是這樣的先說明HashMap底層是數(shù)組鏈表紅黑樹JDK 1.8之后再提擴(kuò)容閾值是負(fù)載因子0.75然后說清多線程覆蓋和死循環(huán)的成因最后落到ConcurrentHashMap的鎖分段或CASsynchronized實(shí)現(xiàn)。這樣一條線下來既展示了知識廣度也展示了深度。2.2 字符串拼接的性能與內(nèi)存陷阱這道題很經(jīng)典在循環(huán)里用拼接字符串和用StringBuilder性能差距有多大答案當(dāng)然是StringBuilder快得多但關(guān)鍵在于你得說清楚為什么。String是不可變對象每次用拼接都會創(chuàng)建一個新的String對象這個過程中還會產(chǎn)生中間狀態(tài)的char數(shù)組副本。循環(huán)次數(shù)越多臨時對象越多GC壓力越大。如果是在主線程拼接大量日志字符串甚至?xí)鸬魩?。但這里有個細(xì)節(jié)很多人不知道現(xiàn)代Java編譯器會在編譯期對做優(yōu)化——如果拼接表達(dá)式是常量編譯期就會完成如果是在循環(huán)里動態(tài)拼接編譯器會把轉(zhuǎn)成StringBuilder.append調(diào)用。所以嚴(yán)格來說單次拼接和循環(huán)內(nèi)拼接的情況不一樣。不過筆試階段不需要摳這么細(xì)重點(diǎn)還是答出String不可變、頻繁創(chuàng)建對象、StringBuilder可變緩沖區(qū)這三個要點(diǎn)。2.3 Activity生命周期與Fragment重疊問題生命周期是Android面試的常青樹卷三當(dāng)然不會放過。它考的角度比較刁屏幕旋轉(zhuǎn)時Activity和Fragment分別經(jīng)歷了哪些生命周期回調(diào)為什么會出現(xiàn)Fragment重疊怎么解決先說生命周期。屏幕旋轉(zhuǎn)時Activity會經(jīng)歷onPause - onStop - onDestroy - onCreate - onStart - onResume注意是重建不是簡單的暫停恢復(fù)。Fragment的生命周期會跟隨宿主Activity變化而且在這個重建過程中Fragment會被保存然后重新創(chuàng)建。Fragment重疊這個坑我當(dāng)年幫人排查過很多次。典型場景是異步請求回來后add了一個Fragment結(jié)果屏幕一旋轉(zhuǎn)出現(xiàn)了兩個一樣的Fragment。原因在于系統(tǒng)重建Activity時會自動恢復(fù)FragmentManager里保存的Fragment實(shí)例如果你在onCreate里又無條件地add一次就疊加了。解決方案很統(tǒng)一加一個判空條件if (savedInstanceState null)才執(zhí)行add。這個簡單判斷背后是對Activity重建機(jī)制的深入理解也是面試官希望看到的答題思路。2.4 Handler消息機(jī)制主線程為什么不會卡死這道題幾乎是Android面試的必考題卷三也有一道相關(guān)的簡答題主線程的Looper是一個死循環(huán)為什么不會導(dǎo)致App卡死ANR又是怎么觸發(fā)的想拿到這道題的分?jǐn)?shù)要讓面試官感受到你是真懂而不是背了標(biāo)準(zhǔn)答案。用大白話拆解一下Handler的本質(zhì)是向MessageQueue里投遞消息Looper負(fù)責(zé)從隊(duì)列里取出消息并分發(fā)給target處理。主線程Looper確實(shí)是一個for(;;)死循環(huán)但阻塞點(diǎn)在MessageQueue.next()里的nativePollOnce。這個native方法使用的是Linux的epoll機(jī)制——沒有消息時線程會休眠不占CPU有新消息時通過pipe管道喚醒線程。所以“死循環(huán)”實(shí)際上是一個有事件才工作、沒事件就掛起的消息泵它不會耗盡CPU更不會讓App無響應(yīng)。真正的ANR是什么是某個消息在主線程處理時間超過閾值——輸入事件5秒、廣播10秒、前臺Service 20秒。主線程被一個耗時操作卡住了隊(duì)列后面的消息處理不了才會觸發(fā)系統(tǒng)彈ANR。答這道題其實(shí)還有一個加分項(xiàng)說出IdleHandler。它是在消息隊(duì)列空閑時執(zhí)行的回調(diào)可以用來做啟動優(yōu)化時懶加載非核心操作。這能說明你不僅懂原理還知道怎么利用原理優(yōu)化性能是很打動面試官的一個點(diǎn)。2.5 Service兩種啟動方式與后臺限制下的選擇談Service的題在現(xiàn)在的校招筆試題里越來越偏實(shí)際了。卷三問的是startService和bindService的區(qū)別是什么如果應(yīng)用處于后臺還能隨便起Service嗎這兩種啟動方式的核心區(qū)別可以列個表對比項(xiàng)startServicebindService生命周期獨(dú)立start后與調(diào)用者無關(guān)與綁定方綁定解綁則銷毀通信方式通過Intent傳參單向通過IBinder接口雙向調(diào)用典型場景下載、播放音樂音樂播放時UI控制、獲取數(shù)據(jù)銷毀方式stopService 或 stopSelfunbindService關(guān)于后臺限制這是個很現(xiàn)實(shí)的坑。從Android 8.0開始后臺應(yīng)用不能隨意創(chuàng)建后臺Service強(qiáng)行創(chuàng)建會拋IllegalStateException。Android 12又進(jìn)一步限制了前臺Service的啟動。所以現(xiàn)在做長任務(wù)的標(biāo)準(zhǔn)方案是WorkManager它內(nèi)部會選擇合適的時機(jī)執(zhí)行任務(wù)并遵守系統(tǒng)的節(jié)能策略。筆試如果遇到這類題目我建議先答基礎(chǔ)區(qū)別再帶一句“現(xiàn)在的Android版本對后臺Service做了嚴(yán)格限制實(shí)際開發(fā)中會優(yōu)先考慮WorkManager或Foreground Service”這樣能體現(xiàn)出你關(guān)注系統(tǒng)版本演進(jìn)而不是只會背教科書。3. 繪制與交互自定義View是校招的“分水嶺”這一部分是卷三拉開分?jǐn)?shù)差距的地方。說實(shí)話很多候選人在準(zhǔn)備校招時把精力都放在背面試題上了但View體系這東西真的背不出來——你只有親手寫過自定義View處理過測量和事件沖突才能在筆試中寫出讓人信服的答案。3.1 MeasureSpec三種模式與wrap_content經(jīng)典坑卷三這題很穩(wěn)MeasureSpec由哪兩部分組成三種模式分別對應(yīng)什么場景自定義View時wrap_content有什么坑MeasureSpec是一個32位的int值高2位代表Mode低30位代表Size。三種模式分別是EXACTLY父View已經(jīng)確定了子View的精確大小通常對應(yīng)match_parent和wrap_content之外的明確尺寸或者match_parent。AT_MOST子View最大不得超過某個值通常對應(yīng)wrap_content。UNSPECIFIED父View對子View沒有限制可以隨便多大一般出現(xiàn)在ScrollView、RecyclerView的items測量中。而最經(jīng)典的坑是自定義View如果重寫了onMeasure當(dāng)XML里設(shè)置wrap_content時默認(rèn)的resolveSize不會生效View會被當(dāng)成match_parent處理占滿整個父布局。這是個非常隱蔽的bug——很常見的自查邏輯就是“為什么我這自定義控件設(shè)置了wrap_content還是撐滿了”。解決方案是在onMeasure里手動處理Override protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { int widthMode MeasureSpec.getMode(widthMeasureSpec); int widthSize MeasureSpec.getSize(widthMeasureSpec); int resultWidth 0; switch (widthMode) { case MeasureSpec.EXACTLY: resultWidth widthSize; break; case MeasureSpec.AT_MOST: // 計(jì)算內(nèi)容實(shí)際需要的寬度取兩者最小值 resultWidth Math.min(measuredContentWidth(), widthSize); break; case MeasureSpec.UNSPECIFIED: resultWidth measuredContentWidth(); break; } setMeasuredDimension(resultWidth, ...); }筆試時不需要寫完整代碼但一定要把這個坑和解決思路說出來。3.2 事件分發(fā)的完整鏈路與滑動沖突事件分發(fā)這道題卷三至少占了10分。考點(diǎn)是一次點(diǎn)擊事件從產(chǎn)生到最終被消費(fèi)經(jīng)過了哪些方法父View和子View如何協(xié)同決定誰處理標(biāo)準(zhǔn)的鏈路是dispatchTouchEvent - onInterceptTouchEvent - onTouchEvent。當(dāng)手指按下時事件從Activity的dispatchTouchEvent開始一路傳遞到ViewGroup的dispatchTouchEvent這里會先詢問onInterceptTouchEvent要不要攔截不攔截就傳給子View子View處理不了就拋回父View的onTouchEvent。這里面最?？嫉目邮腔瑒記_突。典型場景一個橫向滑動的ViewPager嵌套了一個縱向滑動的RecyclerView或者一個下拉刷新容器里套了一個列表。處理方案有兩個方向外部攔截法在父View的onInterceptTouchEvent里判斷——如果父View需要滑動就攔截否則不攔截。內(nèi)部攔截法子View通過requestDisallowInterceptTouchEvent(true)阻止父View攔截事件結(jié)合父View的onInterceptTouchEvent里判斷!disallowIntercept。筆試答這個題時建議配合手勢判定水平方向位移大于垂直位移就判定為橫向滑動讓ViewPager處理反之讓RecyclerView處理。這個“滑動方向判定”的思路比空談攔截方法更有說服力因?yàn)樗钦鎸?shí)的處理策略。3.3 Canvas狀態(tài)管理與硬件加速細(xì)節(jié)這道題相對偏門但確實(shí)有出現(xiàn)。問的是Canvas.save()和Canvas.restore()的作用是什么在硬件加速下要注意什么Canvas的save/restore跟我們理解的事務(wù)很像。save會保存當(dāng)前畫布的所有狀態(tài)包括坐標(biāo)系、裁剪區(qū)域、變換矩陣restore會恢復(fù)到最后一次save的狀態(tài)。這兩個方法必須成對出現(xiàn)如果只save不restore代碼很隱蔽——后續(xù)所有繪制的坐標(biāo)系偏移會累積導(dǎo)致繪制錯位。硬件加速方面2013年之后Android的View繪制默認(rèn)走了硬件加速Canvas的API大部分都支持但有少數(shù)操作比如clipPath和某些drawText的復(fù)雜操作在硬件加速下行為不一致。另外硬件加速下Canvas的saveLayer性能開銷很大因?yàn)樗鼤?chuàng)建離屏緩沖區(qū)如果頻繁調(diào)用會造成掉幀。這是性能優(yōu)化的一個重要突破點(diǎn)。我在實(shí)際項(xiàng)目里遇到過一個問題自定義折線圖在低端機(jī)上滑動卡頓查了半天發(fā)現(xiàn)是onDraw里頻繁創(chuàng)建Paint對象和調(diào)用saveLayer。改成在初始化時創(chuàng)建并復(fù)用Paint、去掉不必要的離屏繪制之后幀率直接翻倍。這類實(shí)戰(zhàn)細(xì)節(jié)在筆試?yán)锶绻軐懗鰜斫^對是大加分項(xiàng)。4. 性能優(yōu)化與穩(wěn)定性從“能用”到“好用”卷三后半部分的性能題擺明了是在問你觀察過一個App的運(yùn)行狀態(tài)嗎出題人想要的是有線上問題排查經(jīng)驗(yàn)的候選人而不是只會寫功能邏輯的開發(fā)。這部分也是我在帶團(tuán)隊(duì)時最看重的能力項(xiàng)。4.1 ANR的根因分析與監(jiān)控方案這道題問得很大線上App產(chǎn)生了ANR你會怎么排查標(biāo)準(zhǔn)的排查思路是用/data/anr/traces.txt文件看主線程的堆棧找到卡死的調(diào)用點(diǎn)。但線上環(huán)境復(fù)雜不是每個用戶都能輕松拿到trace文件所以現(xiàn)在主流方案是在自家App里內(nèi)置一個輕量級的ANR監(jiān)控模塊。我常用的做法是在Application初始化時手動創(chuàng)建一個HandlerThread里面放一個5秒的延遲任務(wù)。主線程的Looper空閑時會執(zhí)行IdleHandler每次執(zhí)行就刷新這個5秒計(jì)時器。如果5秒后計(jì)時器沒有被刷新說明主線程被阻塞了此時主動抓取主線程堆棧并上報。這個方案不需要root也不需要用戶提供文件線上排查效率很高。筆試答這個題時關(guān)鍵是展現(xiàn)出“從線上問題到定位到修復(fù)”的完整閉環(huán)監(jiān)控抓取 - 堆棧分析 - 定位到具體代碼 - 優(yōu)化方案 - 驗(yàn)證。只寫“看traces文件”是拿不全分的。4.2 內(nèi)存泄漏的常見姿勢與LeakCanary原理內(nèi)存泄漏題幾乎是每次必考。卷三給了一個具體場景一個Activity被銷毀了但LeakCanary仍然檢測到了泄漏可能是什么原因常見的泄漏原因我列一下也是答題時的排查清單非靜態(tài)內(nèi)部類持有外部類引用比如Activity里的Handler、Runnable如果任務(wù)還沒執(zhí)行完Activity就被銷毀了內(nèi)部類對象會一直持有Activity引用。單例持有ActivityContext全局單例里存了Activity的ContextActivity銷毀了但單例還在。靜態(tài)變量持有View靜態(tài)View會持有Activity的Context所以View也不能隨便用靜態(tài)存。資源未關(guān)閉BroadcastReceiver沒解綁、Cursor沒關(guān)閉、IO流沒關(guān)閉、動畫還在循環(huán)等。然后LeakCanary的原理也要能口述它通過WeakReference監(jiān)聽Activity配合ReferenceQueue。GC后如果WeakReference被加入ReferenceQueue說明對象可以被回收如果遲遲沒有被加入說明存在強(qiáng)引用路徑LeakCanary會主動觸發(fā)一次GC再確認(rèn)最后dump出內(nèi)存快照通過LeakCanary自帶的LeakTrace分析出泄漏鏈。這道題的答題技巧是從表象到原理再到實(shí)踐。先說你的判斷思路再解釋工具工作原理最后落到一個具體的修復(fù)案例上。這樣面試官會覺得你既理解原理又真的處理過問題。4.3 APK體積優(yōu)化R8混淆與資源治理卷三關(guān)于包體積的題目切入點(diǎn)很落地的一個APK達(dá)到80MB有哪些手段能把它的體積壓下來先答混淆。從Android Gradle Plugin 8.0開始R8已經(jīng)成為默認(rèn)的混淆和壓縮工具它不只是刪掉無用的代碼和重命名類還內(nèi)置了資源壓縮、內(nèi)聯(lián)等優(yōu)化能力。在build.gradle里開啟minifyEnabled true和shrinkResources true可以同時裁剪代碼和資源。注意R8和ProGuard的區(qū)別——R8是ProGuard的替代品既能壓縮代碼也能做優(yōu)化使用方式卻簡單不少。再答資源的治理。最見效的手段是按優(yōu)先級排列圖片轉(zhuǎn)WebP壓縮率比PNG高20%-40%既有損也無損模式可選刪除無用的資源配合shrinkResources自動移除未引用的對so庫做ABI拆分比如只保留arm64-v8a可以直接砍掉一半體積啟用App Bundle發(fā)布按設(shè)備動態(tài)分發(fā)資源大圖改成運(yùn)行時加載或者用矢量圖替代部分小尺寸PNG。這道題最容易丟分的地方是只答混淆不答資源。要知道對于一個內(nèi)容社區(qū)App來說圖片資源占的權(quán)重遠(yuǎn)大于代碼體積不答資源優(yōu)化等于答了半個題。4.4 啟動優(yōu)化從冷啟動到首幀的拆解啟動優(yōu)化是性能題里的壓軸大題。卷三問的是冷啟動時App做了哪些事如果你想優(yōu)化啟動速度從哪些方向入手冷啟動的流程可以拆成這樣系統(tǒng)創(chuàng)建進(jìn)程加載Application類執(zhí)行attachBaseContext、onCreate創(chuàng)建主Activity執(zhí)行onCreate、onStart、onResume首幀繪制完成用戶看到界面所以啟動耗時的優(yōu)化空間主要在Application和首屏Activity的初始化里。常見的優(yōu)化手段包括異步初始化非必需組件放到子線程但要有初始化順序的管控避免出現(xiàn)子線程和主線程競爭同一資源的競態(tài)。延遲初始化把非首屏必需的初始化放到IdleHandler里等主線程空閑再執(zhí)行。按需加載ContentProvider的初始化時機(jī)比Application還要早這個坑很多人不知道。第三方SDK為了自動初始化會使用ContentProvider每個App啟動時都要加載它們數(shù)量多了非常影響啟動速度。所以選第三方庫時優(yōu)先挑那些支持手動初始化、不搞ContentProvider的。啟動器框架Google的Jetpack啟動庫或者字節(jié)的Alpha框架可以構(gòu)建有依賴關(guān)系的異步任務(wù)執(zhí)行圖把可以并行的任務(wù)并行化串行任務(wù)按依賴順序執(zhí)行。啟動優(yōu)化在筆試?yán)锖茈y靠死記硬背拿高分關(guān)鍵是能不能按“主線程在啟動階段到底做了什么”這個邏輯線來串聯(lián)思路?？脊傧肟吹牟皇且粋€知識點(diǎn)而是一整套分析框架。5. 存儲、網(wǎng)絡(luò)與圖片信息流應(yīng)用的三板斧到了這一塊題目開始向小紅書的業(yè)務(wù)場景靠攏了。內(nèi)容社區(qū)App最核心的幾條鏈路圖片加載、網(wǎng)絡(luò)請求、本地緩存。這三塊不一定都考但考到基本就是大題。5.1 Glide緩存機(jī)制與圖片加載優(yōu)化圖像加載是在內(nèi)容App中極其重要的問題卷三出了一道開放性的看圖題——給出一張圖片列表的頁面問如何保證滑動流暢。這道題實(shí)際的考察點(diǎn)是圖片緩存的三級架構(gòu)。Glide默認(rèn)實(shí)現(xiàn)了比較完善的三層緩存活動資源ActiveResources正在被View引用的圖片存在一個弱引用的HashMap里內(nèi)存緩存LruCache最近使用過的圖片LRU淘汰磁盤緩存Glide還分了兩種——原始數(shù)據(jù)緩存和轉(zhuǎn)換后的圖片緩存默認(rèn)情況下Glide會緩存轉(zhuǎn)換后比如壓縮過、裁剪過的資源。為什么這么設(shè)計(jì)原因很樸素內(nèi)存緩存訪問速度快但容量有限磁盤緩存容量大但訪問慢。如果滑動時每張圖都要從磁盤讀還是會有IO卡頓。所以磁盤緩存之上還要有一層內(nèi)存緩存而正在被使用的圖要單獨(dú)存一份防止剛顯示就被LRU淘汰出去造成“抖動”。此外圖片加載的優(yōu)化還有幾個點(diǎn)縮略圖預(yù)覽、長圖采樣壓縮、WebP格式切換、預(yù)加載機(jī)制。在RecyclerView滑動場景中可以在onBindViewHolder時對下一屏的圖片做preload。這套組合拳打下來滑動流暢度能有肉眼可見的提升。5.2 HTTPDNS與弱網(wǎng)優(yōu)化網(wǎng)絡(luò)相關(guān)的題考察點(diǎn)比較分散。卷三問過一個比較實(shí)際的問題弱網(wǎng)環(huán)境下圖片加載失敗率和速度都不理想怎么優(yōu)化常見且有效的弱網(wǎng)優(yōu)化手段有這些超時設(shè)置有講究連接超時和讀取超時要區(qū)分開不能一個超時時間走到底。弱網(wǎng)環(huán)境下過短的連接超時會導(dǎo)致頻繁重試過長的讀取超時會讓用戶等太久。重試策略不可以在用戶點(diǎn)擊后無限自動重試要限制次數(shù)和間隔。HTTPDNS繞過運(yùn)營商DNS的解析從HTTPDNS服務(wù)器獲取IP避免DNS劫持和調(diào)度不準(zhǔn)的問題。預(yù)連接在列表滑動即將發(fā)生網(wǎng)絡(luò)請求前提前建立連接。數(shù)據(jù)壓縮開啟gzip壓縮圖片用WebP等更高效的格式。很多候選人答這道題只想到“加大緩存、提升服務(wù)器性能”這其實(shí)是沒答到點(diǎn)子上。真正的弱網(wǎng)優(yōu)化是在客戶端側(cè)把每個環(huán)節(jié)都做到容錯、可降級。5.3 數(shù)據(jù)庫升級與ORM選型數(shù)據(jù)庫這題在卷三的權(quán)重不大但出現(xiàn)過數(shù)據(jù)庫版本升級時如果新版需要新增表、新增字段你會怎么寫升級邏輯最簡單的做法是在SQLiteOpenHelper.onUpgrade里按舊版本號做switch分支Override public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) { switch (oldVersion) { case 1: db.execSQL(ALTER TABLE user ADD COLUMN age INTEGER); case 2: db.execSQL(CREATE TABLE new_table (...)); } }注意switch里沒有break這是故意的——如果用戶從版本1直接升到版本3v1的分支執(zhí)行完會繼續(xù)執(zhí)行v2的分支保證升級路徑被完整走一遍。這里有一個特別容易踩的坑不能直接刪除舊表重建。用戶數(shù)據(jù)是無價的刪表等于丟數(shù)據(jù)這在線上是要出大事的。如果表結(jié)構(gòu)變更比較復(fù)雜可以考慮建新表、遷移數(shù)據(jù)、刪舊表的三步策略。答這道題還有個加分項(xiàng)提一下當(dāng)前主流ORM。Room在編譯期做了SQL驗(yàn)證能暴露SQL語法錯誤GreenDAO性能好但注解處理繁瑣。筆試如果能對比一下選型理由說明你確實(shí)在項(xiàng)目里思考過工具選型而不是只會用。6. 架構(gòu)設(shè)計(jì)與開放題校招筆試的“最后一公里”最后這部分是最難的因?yàn)樗鼪]有標(biāo)準(zhǔn)答案。但它也是最容易拉開差距的——為什么因?yàn)槟艽鸬竭@里的候選人已經(jīng)不只是會寫代碼而是開始有架構(gòu)意識和業(yè)務(wù)思維了。6.1 MVC/MVP/MVVM的選擇邏輯架構(gòu)題在卷三出現(xiàn)的概率很高。題目大概是你在項(xiàng)目中使用過MVP還是MVVM優(yōu)缺點(diǎn)是什么你更推薦哪個不要只回答“MVVM更好”要給出選擇邏輯。先看三者的本質(zhì)區(qū)別MVCModel層和View層可以直接交互Controller難以控制代碼容易亂成一團(tuán)。MVPPresenter作為中間人View和Model完全隔離職責(zé)清晰但是接口數(shù)量爆炸每個頁面要寫大量contract類。MVVM用ViewModel和LiveData/Flow替代了Presenter的部分職責(zé)通過Jetpack生態(tài)把數(shù)據(jù)驅(qū)動做得更徹底。ViewModel還能在配置變更時保留狀態(tài)這是MVP做不到的。筆試如果真的讓你選比較穩(wěn)妥的答法是推薦MVVM理由不是因?yàn)樗露且驗(yàn)镴etpack的ViewModelLiveDataDataBinding這套組合解決了MVP的痛點(diǎn)——View與數(shù)據(jù)的關(guān)系由觀察者模式管理狀態(tài)恢復(fù)由ViewModel內(nèi)部機(jī)制處理配合協(xié)程做異步任務(wù)也很干凈。但也要補(bǔ)充一句架構(gòu)不是越新越好中小項(xiàng)目直接用MVC反而更輕量大項(xiàng)目才需要MVVM這種強(qiáng)約束。能說出這種權(quán)衡比無腦推崇MVVM高出一個段位。6.2 組件化與模塊解耦組件化是很多中大型Android項(xiàng)目里的常規(guī)操作卷三用了一道簡答題來問為什么要組件化它解決了什么問題組件化的核心動力是工程效率。當(dāng)項(xiàng)目有幾十個模塊、幾十人協(xié)作時每次編譯一次全量工程要花很長時間業(yè)務(wù)代碼之間也容易互相依賴、改一個地方崩一片。組件化把App拆分成獨(dú)立的模塊每個模塊可以單獨(dú)編譯、單獨(dú)交付測試模塊之間只通過約定好的接口通信。具體到Android工程里一般會拆成app殼工程負(fù)責(zé)整體組裝基礎(chǔ)庫組件網(wǎng)絡(luò)、圖片、日志等業(yè)務(wù)組件首頁、搜索、發(fā)布、個人中心等模塊間的通信方案現(xiàn)在常用的是ARouter這種路由框架通過注解生成路由表用URL或者路徑來跳轉(zhuǎn)頁面、調(diào)用服務(wù)。路由的好處是解耦徹底模塊之間不需要直接依賴。但組件化有一個坑值得提醒不要為組件化而組件化。中小型項(xiàng)目人數(shù)不多強(qiáng)行拆組件反而會降低開發(fā)效率。判斷標(biāo)準(zhǔn)很簡單——編譯時間是否已經(jīng)嚴(yán)重影響開發(fā)效率模塊間是否已經(jīng)出現(xiàn)了明顯的耦合如果都沒有說明還不需要組件化。這道題能答出“什么時候不該做組件化”比單純吹組件化的好處更容易讓考官眼前一亮。6.3 開放題如何設(shè)計(jì)一個首頁信息流這是卷三壓軸級別的題目場景感很強(qiáng)如果讓你設(shè)計(jì)小紅書首頁的信息流頁面你會怎么考慮技術(shù)和體驗(yàn)方面的設(shè)計(jì)這類開放題沒有標(biāo)準(zhǔn)答案但好的回答會從這五個維度逐一展開數(shù)據(jù)層面用分頁加載還是增量更新下拉刷新和上拉加載如何銜接緩存策略是LRU還是時間過期圖片層面信息流以圖片為主必須做壓縮、采樣、預(yù)加載保證滑動流暢。內(nèi)存層面列表頁滑動時如何避免圖片占用過多內(nèi)存回收策略是Glide的trimMemory機(jī)制還是手動管理長列表的Item復(fù)用怎么做體驗(yàn)層面占位圖設(shè)計(jì)、加載失敗的重試機(jī)制、弱網(wǎng)下的降級方案比如先顯示模糊圖再加載高清圖。性能監(jiān)控頁面FPS、卡頓率、啟動耗時、內(nèi)存占用這些指標(biāo)如何采集和上報卡頓時如何定位到具體模塊我最推薦的答題框架是先定目標(biāo)用戶首屏能快速看到內(nèi)容、滑動不掉幀、弱網(wǎng)可降級再拆方案數(shù)據(jù)流、圖片流、緩存、監(jiān)控最后做權(quán)衡緩存太多會占存儲預(yù)加載太多會耗流量。這種從目標(biāo)到方案的層層推導(dǎo)是面試官最愿意看到的思考方式。如果能在回答里加一兩個真實(shí)項(xiàng)目中的優(yōu)化案例——比如“我之前接手一個列表頁卡頓是因?yàn)槊看位瑒佣加|發(fā)了一次網(wǎng)絡(luò)請求后來加了預(yù)加載和緩存才解決”——那就完美了。這比任何華麗的術(shù)語都更有說服力。7. 復(fù)盤與建議踩過的坑希望大家繞開說回這套卷子本身。我接觸過的刷這套題的候選人不少總結(jié)一下高頻丟分點(diǎn)希望大家別在同一個地方摔兩次。7.1 最容易丟分的三個地方第一只答結(jié)果不答過程。比如問Handler機(jī)制直接回答“主線程Looper是死循環(huán)但不會卡死”卻不解釋epoll、不解釋消息隊(duì)列、不解釋ANR閾值。這種答案只能拿基礎(chǔ)分拿不到高分。第二不會結(jié)合實(shí)際項(xiàng)目。卷三的題很多都在問“你怎么做”如果只答教科書層面的知識沒有個人實(shí)踐的細(xì)節(jié)支撐面試官很難相信你真的做過。哪怕是一個很小的優(yōu)化案例只要真實(shí)都能給答案加分。第三開放題寫太短。很多人在做完前面的題之后時間不夠了開放題只寫了幾行字。其實(shí)開放題的分值往往是最高的寫完整比寫完美重要。實(shí)在沒時間也要把能想到的點(diǎn)用“關(guān)鍵詞一句話”的方式列出來讓考官知道你是有思路的。7.2 給我的刷題建議根據(jù)卷三的出題風(fēng)格給正在準(zhǔn)備校招的朋友提幾條實(shí)際建議刷題不能只刷概念題。每學(xué)一個知識點(diǎn)都主動問自己一句這個知識點(diǎn)在我實(shí)際的App開發(fā)里有什么用如果沒用它為什么被面試官反復(fù)考動手寫項(xiàng)目。沒有真實(shí)項(xiàng)目的支撐很多題目你就是答不深。哪怕是模仿一個開源項(xiàng)目把網(wǎng)絡(luò)、圖片、列表這幾個核心鏈路跑通都比背100道題更有用。多做復(fù)盤。每一道做錯的題不要只看一遍答案要弄清楚背后的原理。筆試中同一道題換個角度再考概率很高。我自己帶項(xiàng)目的體會是校招筆試其實(shí)不是在考你會不會做某道題而是在考你的思維方式——你能不能把一個復(fù)雜問題拆解成小步驟能不能從原理推導(dǎo)到實(shí)踐能不能在開放場景中給出有邏輯的方案。卷三這套題本質(zhì)上就是把這些能力拆成了一個個可以量化的得分點(diǎn)。把每一道題背后的思考邏輯琢磨透比背熟任何一份答案都重要得多。