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