從2022年5月中旬開始我一邊在職一邊準(zhǔn)備Android面試白天寫業(yè)務(wù)晚上刷八股文。那段時間我把網(wǎng)上能翻到的Android面試題、大廠面經(jīng)、源碼解析筆記幾乎都過了一遍最后沉淀出一份自己的答題套路?，F(xiàn)在整理出來說說我在準(zhǔn)備Android面試八股文這件事上到底在看什么、背什么、怎么答。先說一個很多人沒想明白的問題八股文為什么值得認(rèn)真準(zhǔn)備因?yàn)槊嬖嚬賳柲愕暮芏囝}目表面是考背書能力實(shí)際是考你有沒有真正理解這套系統(tǒng)是怎么轉(zhuǎn)起來的。Handler、Binder、AMS、事件分發(fā)、四大組件、ANR、內(nèi)存泄漏這些2022年依然是Android面試的硬通貨無論你簡歷上寫的是業(yè)務(wù)開發(fā)還是性能優(yōu)化方向第一輪技術(shù)面大概率就是圍繞這些東西展開。你連消息機(jī)制都講不清楚后面聊項(xiàng)目、聊架構(gòu)、聊協(xié)程面試官很難信服你的基礎(chǔ)扎實(shí)。我這篇八股文篇不是把網(wǎng)上所有題都抄一遍而是按我自己復(fù)習(xí)時的思路重新拆了一遍哪些是必背的哪些是面試官大概率會追著往下問的哪些是答完一句原理之后還能展開加分的內(nèi)容。如果你離面試還有一兩周建議先按后面的節(jié)奏來。1. 為什么2022年7月我還在啃八股文環(huán)境判斷與復(fù)習(xí)節(jié)奏1.1 這個時間節(jié)點(diǎn)面試風(fēng)向2022年年中的Android面試和兩年前相比明顯變了幾個方向。第一Kotlin已經(jīng)完全是主流Co我們寫新項(xiàng)目基本全Kotlin面試時候Java經(jīng)常只被用來問基礎(chǔ)但協(xié)程、Flow、Compose這些新潮內(nèi)容才是加分點(diǎn)。第二大廠對源碼級理解的要求更高了光會說Handler用于線程間通信已經(jīng)不夠面試官會追問Looper在子線程怎么創(chuàng)建、MessageQueue怎么阻塞、為什么不會卡死主線程。第三項(xiàng)目經(jīng)歷之外的軟技能和思考深度被提到了很高的權(quán)重。所以八股文不再只是死記硬背而是要把知識點(diǎn)串成一條完整的鏈路。比如問Activity啟動流程你能不能從Launcher的startActivity一直講到AMS、zygote、ApplicationThread、ActivityThread這整條線。你需要給面試官一種我讀過源碼我懂系統(tǒng)的調(diào)用鏈的感覺而不是碎片化地背幾個名詞。1.2 我的復(fù)習(xí)資料與節(jié)奏安排我當(dāng)時給自己定了兩周的沖刺計(jì)劃資料其實(shí)很固定《Android開發(fā)藝術(shù)探索》和《深入理解Android內(nèi)核設(shè)計(jì)思想》翻重點(diǎn)章節(jié)尤其是消息機(jī)制、View體系、Binder這幾塊。網(wǎng)上能找到的大廠面經(jīng)合集只看近半年內(nèi)的因?yàn)橛行﹩栴}每年會換花樣。自己項(xiàng)目里真實(shí)踩過的坑每個坑都往源碼層面挖一層作為項(xiàng)目里體現(xiàn)基礎(chǔ)的素材。刷題不要貪多我每天只過三個大類系統(tǒng)機(jī)制類、View體系類、性能優(yōu)化類。時間分配上我會用周末兩天把所有核心知識點(diǎn)做成一個腦圖工作日晚上每天攻克一個主題。比如周一看Handler周二看Binder周三看AMS周四看View周五看性能。周六把這一周的問題過一遍周日整理成自己的答題話術(shù)。2. Handler、Binder、AMS這三個機(jī)制幾乎決定了面試的下限2.1 Handler消息機(jī)制從主線程Looper到同步屏障面試官問Handler最常見的開場是你講講Handler機(jī)制。很多人會順口說主線程有LooperLooper從MessageQueue里取消息Handler調(diào)用handleMessage處理。這句話沒有錯但只能拿到基礎(chǔ)分。真正加分的回答應(yīng)該是先指出Looper是ThreadLocal存儲的每個線程只有一個Looper、只有一個MessageQueue。然后說主線程的Looper是在ActivityThread.main方法里通過Looper.prepareMainLooper()創(chuàng)建的它不會退出。接著講Handler的sendMessage最終會調(diào)用enqueueMessage把Message放到MessageQueue插入的時候按when字段做時間排序不是按投遞順序。面試官這時候往往會追一句MessageQueue沒消息的時候主線程在干什么這里才是關(guān)鍵。MessageQueue的next方法是阻塞的它調(diào)用nativePollOnce進(jìn)入epoll機(jī)制的等待讓主線程休眠不占用CPU等有消息進(jìn)來或者有binder事件的時候通過管道/eventfd喚醒。很多只背理論的人會卡在這一步能把native層這一句講出來面試官會覺得你真看過源碼。還有一個容易被追問的點(diǎn)是同步屏障SyncBarrier。正常Message是一串同步消息有需要時可以往MessageQueue插入一個target為null的Message作為同步屏障這個屏障后面的同步消息就不會被執(zhí)行只能執(zhí)行異步消息。View的Choreographer在doFrame時插入VSYNC消息就用了這個機(jī)制。2022年這里有個變種問法Android 12/13之后引入了異步消息以及暢行等等面試官會問你有沒有細(xì)致研究過主線程消息優(yōu)先級你提一下SyncBarrier就夠了。2.2 Binder面試題一次拷貝到底省了什么Binder是Android面試?yán)镒钊菀状痫w的一個點(diǎn)。常見問題就是Android為什么用Binder做跨進(jìn)程通信而不用共享內(nèi)存、Socket、管道先記住結(jié)論性話術(shù)Binder基于C/S架構(gòu)發(fā)送方調(diào)用一次copy_from_user把數(shù)據(jù)從用戶空間拷貝到內(nèi)核空間接收方通過mmap映射直接把內(nèi)核空間那同一份內(nèi)存映射到自己的用戶空間所以是一次拷貝。傳統(tǒng)管道、Socket至少需要兩次拷貝。然后準(zhǔn)備一個類比一次拷貝就像你寄快遞快遞員先到你家里把包裹拿走放到了中轉(zhuǎn)站收件人直接拿著鑰匙開中轉(zhuǎn)站的門把包裹拿走中間不需要再有人把包裹送到收件人手里。而這個中轉(zhuǎn)站就是內(nèi)核對同一塊物理內(nèi)存的映射。Binder面試還會考幾個延伸點(diǎn)Binder線程池是怎么工作的每個進(jìn)程啟動時會創(chuàng)建一個Binder線程池默認(rèn)上限是16個Binder線程執(zhí)行handleMessage等事務(wù)。Binder驅(qū)動在哪個文件核心在kernel層你只要說binder.c 即可。四大組件跨進(jìn)程通信哪些用了BinderAMS、PMS、WMS都是系統(tǒng)服務(wù)Android 10之后一些系統(tǒng)服務(wù)改用AIDL。Binder的死亡代理linkToDeath。oneway和非oneway的呼叫區(qū)別這個很多人在項(xiàng)目中用過AIDL但沒細(xì)想。我復(fù)習(xí)Binder時最大的體會是不要光背一次拷貝要理解mmap為什么能省一次拷貝。因?yàn)榻邮辗酵ㄟ^mmap把內(nèi)核緩沖區(qū)直接映射到用戶態(tài)發(fā)送方復(fù)制到內(nèi)核緩沖區(qū)的數(shù)據(jù)接收方不用再復(fù)制一遍直接讀取即可。2.3 Activity啟動流程把AMS拉進(jìn)回答里Activity啟動流程在2022年依然是高頻題而且面試官普遍希望你在回答中自然冒出AMS、ActivityTaskManager、Zygote、ApplicationThread這些角色。一個標(biāo)準(zhǔn)的回答骨架是這樣Launcher進(jìn)程調(diào)用startActivityActivityManagerShellCommand或者Instrumentation會通過ATMS得到Binder代理。真正執(zhí)行的是AMS.startActivity再由ActivityTaskManager內(nèi)部處理任務(wù)棧。AMS先檢查進(jìn)程是否存在不存在就通過Socket請求Zygote fork新進(jìn)程。Zygote fork出的新進(jìn)程啟動ActivityThread調(diào)用main方法然后scheduleLaunchActivity回到AMS說我準(zhǔn)備好了。最后通過ApplicationThread把LaunchActivity的消息發(fā)回主線程ActivityThread的handleLaunchActivity執(zhí)行真正的生命周期回調(diào)。這個流程里有一個很刁鉆的追問onCreate、onResume與AMS回調(diào)的時序是發(fā)生在什么階段你要是說onCreate在attach之后調(diào)用那是對的但你得說清楚AMS只是負(fù)責(zé)狀態(tài)管理和調(diào)度真正的生命周期執(zhí)行是由ActivityThread在主線程里完成的。還有一道?？嫉难苌}一個App冷啟動的完整過程涉及了哪些系統(tǒng)服務(wù)答案是Zygote、SystemServer、AMS/PMS、ActivityThread、Application還有Launcher。每一個都可以展開說至少一分鐘這就是八股文的厲害之處一環(huán)套一環(huán)。3. View體系問答事件分發(fā)與繪制流程的五連問3.1 事件分發(fā)三兄弟和U型管道View事件分發(fā)是我個人覺得最像考駕照扣分細(xì)則的一個知識點(diǎn)細(xì)節(jié)很多但一旦理解了下發(fā)和回溯的U型管道整個邏輯就順了。先默寫三個方法的職責(zé)dispatchTouchEvent事件分配入口返回true表示事件被消費(fèi)。onInterceptTouchEventViewGroup專屬是否攔截該事件。onTouchEvent自身是否消費(fèi)事件。從ACTION_DOWN開始事件從RootView往下傳到手指所在的View如果中間某個ViewGroup的onInterceptTouchEvent返回true事件就被它攔下來交給它的onTouchEvent。如果一路沒人攔截到了目標(biāo)View它的onTouchEvent如果返回false事件會沿著父容器一層層回溯直到有人消費(fèi)。這就是經(jīng)典的U型管道。面試官喜歡挖的細(xì)節(jié)有三個同一個事件序列中ACTION_DOWN與ACTION_MOVE的關(guān)系如果DOWN沒人消費(fèi)這一整個序列都不會再傳過來如果MOVE被攔截子View會收到ACTION_CANCEL。requestDisallowInterceptTouchEvent(CANCEL)寫在子View里可以禁止父容器攔截。事件分發(fā)和點(diǎn)擊事件的onClick怎么串起來onTouchEvent里有個performClick的調(diào)用點(diǎn)但只有先消費(fèi)了DOWN和UP且事件沒有被打斷才會觸發(fā)performClick。我建議復(fù)習(xí)時用一張腦圖把dispatchTouchEvent的返回值畫出來因?yàn)槊嬖嚂r能準(zhǔn)確說出DOWN返回trueMOVE繼續(xù)分發(fā)給同一目標(biāo)如果MOVE返回false但DOWN是true最終會照樣消費(fèi)掉這種細(xì)節(jié)的人其實(shí)是少數(shù)。3.2 繪制流程measure、layout、draw的邊界和觸發(fā)條件繪制流程的八股經(jīng)常和自定義View一起考。面試官會問自定義View的onMeasure為什么要小心或者layout和draw的觸發(fā)時機(jī)是什么我整理的答題順序是開頭先說入口ViewRootImpl.performTraversals里面依次調(diào)用performMeasure、performLayout、performDraw。然后說MeasureSpec的三種模式EXACTLY確定尺寸、AT_MOST最大限制、UNSPECIFIED無限制。接著說MeasureSpec的值是由父View的MeasureSpec和自身的LayoutParams通過getChildMeasureSpec計(jì)算出來的。最后說layout階段確定View的位置draw階段通過Canvas繪制背景、內(nèi)容、子View、裝飾。最容易踩的坑是onMeasure里不遵守SpecMode。比如ListView/RecyclerView的item高度被設(shè)為wrap_content時如果不處理AT_MOST模式會造成item復(fù)用錯亂或者顯示異常。實(shí)踐里我在onMeasure里拿到AT_MOST模式時會計(jì)算最小高度保證邏輯合理這個細(xì)節(jié)可以作為面試答題時的一個亮點(diǎn)。關(guān)于invalidate和requestLayout的區(qū)別也是必問invalidate會執(zhí)行draw但不會relayoutrequestLayout會重新measurelayoutdraw一般用于尺寸變化。頻繁調(diào)requestLayout容易掉幀這也能串到性能優(yōu)化上。3.3 自定義View衍生題onMeasure的防坑點(diǎn)2022年面試問自定義View已經(jīng)不滿足于你畫過一個圓了。面試官會拿出一套組合拳如果View的寬高不指定會顯示多大 答案是0。你必須自己在onDraw里處理Drawable的自然寬高或者在measure時讓模pact。onDraw里能不能做耗時操作 不能因?yàn)橹骶€程繪制超過16ms就會掉幀。為什么RecyclerView滑出屏幕的item會復(fù)用 因?yàn)閂iewHolder機(jī)制但如果你用wrap_content且onMeasure有問題復(fù)用會出現(xiàn)顯示錯亂。如果在onDraw里postInvalidate會怎樣 會變成每幀都重新繪制性能暴雷。這些衍生題其實(shí)考察的還是你對measure和draw的理解是否透徹。所以我復(fù)習(xí)時把自定義View分成兩條線一條線要求自己畫一個圓形進(jìn)度條并說清onMeasure里如何支持wrap_content另一條線要求自己說清requestLayout的調(diào)用鏈也就是ViewRootImpl.performTraverse如何被觸發(fā)。每一條線都準(zhǔn)備2分鐘左右的口頭講解面試時再臨場演繹。4. 性能優(yōu)化追問鏈ANR、內(nèi)存泄漏與卡頓的底層邏輯4.1 ANR你以為的5秒其實(shí)不是全部ANR的八股題標(biāo)準(zhǔn)答案是Input事件5秒無響應(yīng)、前臺廣播10秒、后臺廣播60秒、前臺Service 20秒、ContentProvider超時。但這些數(shù)值不是重點(diǎn)重點(diǎn)在于ANR是怎么判定的。面試官想聽的回答是系統(tǒng)通過消息機(jī)制檢測超時。比如輸入事件InputDispatcher會設(shè)置一個超時時間如果事件在隊(duì)列里長時間沒有被處理完就會觸發(fā)ANR。所以主線程阻塞才是ANR的真正原因。我當(dāng)時為了準(zhǔn)備ANR特意去看了自己項(xiàng)目里MainLooper現(xiàn)場的日志掌握了兩個關(guān)鍵信息一是日志會有main looper、input dispatching timed out這些關(guān)鍵詞二是要能判斷是死鎖、任務(wù)耗時還是Binder等待。有時候面試官會把ANR和Handler聯(lián)系起來為什么主線程必須有個Looper因?yàn)橐粩嗵幚鞰essageQueue里的待辦事件比如輸入、布局、繪制三大塊。如果某個消息耗時太久后面的所有消息都會排隊(duì)輸入事件超時就被系統(tǒng)判定為ANR。4.2 內(nèi)存泄漏常見場景和LeakCanary原理內(nèi)存泄漏的八股大多數(shù)人都能說出幾個場景靜態(tài)變量持有Activity、Handler持有Activity、匿名內(nèi)部類持有外部類、資源沒關(guān)閉、單例傳入Context。但面試官問為什么Handler持有Activity會造成泄漏很多人就開始含糊。正確答法是Handler在子線程發(fā)了一個延遲消息MessageQueue持有這個MessageMessage.target指向HandlerHandler又持有外部Activity的引用導(dǎo)致Activity無法被回收?；卮餖eakCanary怎么檢測泄漏時不要只說WeakReference要說出關(guān)鍵機(jī)制Activity.onDestroy之后LeakCanary會通過Application.ActivityLifecycleCallbacks拿到這個Activity把它放到一個WeakReference里然后過幾秒主動觸發(fā)一次GC如果WeakReference.get()還是不為null就說明發(fā)生了泄漏再通過ReferenceQueue做確認(rèn)。這里還有一個加分點(diǎn)手動調(diào)用System.gc()并不一定立刻GCLeakCanary會等待IdleHandler空閑時再GC多次檢測后確認(rèn)泄漏。這個細(xì)節(jié)體現(xiàn)你對GC和ART運(yùn)行時有一定理解。4.3 卡頓監(jiān)控從Choreographer到FrameCallback卡頓優(yōu)化題基本會成為你的項(xiàng)目做過什么性能優(yōu)化的引子。我準(zhǔn)備的標(biāo)準(zhǔn)話術(shù)是卡頓的本質(zhì)是掉幀也就是一幀的繪制超過了16.6ms。用Choreographer的FrameCallback可以拿到幀間隔如果兩幀之間的時間差大于16ms就說明有卡頓。但真正要定位是哪兒卡還需要用Systrace/Method Tracing抓主線程耗時。2022年有一些更細(xì)的考法比如為什么說渲染線程的耗時也算進(jìn)掉幀 因?yàn)锳ndroid 5.0之后引入了RenderThreadChoreographer的FrameCallback只管App側(cè)實(shí)際發(fā)到GPU渲染由RenderThread負(fù)責(zé)如果GPU忙不過來即使主線程不卡也會丟幀。性能優(yōu)化的八股里我還準(zhǔn)備了一個非常實(shí)用的模板先用systrace看有沒有binder sync、layout、measure等明顯耗時。再看內(nèi)存抖動頻繁創(chuàng)建對象導(dǎo)致GC頻繁用Memory Profiler抓Allocation。最后用BlockCanary或自研的Looper.getMainLooper().setMessageLogging哪個Message耗時超過閾值就記錄堆棧。這樣答出來會顯得你有完整的方法論而不只是背了一個掉幀概念。5. Jetpack與架構(gòu)設(shè)計(jì)2022年面試的加分區(qū)5.1 MVVM 協(xié)程標(biāo)配回答的完整版本2022年Android面試聊架構(gòu)默認(rèn)大家都會說MVVM。但要是只答數(shù)據(jù)驅(qū)動UIViewModel持有LiveDataView監(jiān)聽LiveData那還是太單薄。一個七八分的回答應(yīng)該是這樣UI層通過Activity/Fragment持有ViewModelViewModel暴露狀態(tài)UI使用觀察者模式監(jiān)聽狀態(tài)變化數(shù)據(jù)的獲取放在Repository層遠(yuǎn)程或本地?cái)?shù)據(jù)源都通過Repository返回給ViewModelViewModel不持有View的引用所以屏幕旋轉(zhuǎn)時不會因?yàn)閂iew重建而重建。再加一點(diǎn)協(xié)程可以替代部分LiveData的場景。LiveData是感知生命周期且自動管理但它在多線程和Flow復(fù)雜轉(zhuǎn)換上不如Kotlin Flow靈活。所以常見架構(gòu)是UI層用LiveDataRepository以上用Flow這個表達(dá)在2022年大廠面試?yán)锓浅３Ｒ姟Ｈ绻阍倌苷f出ViewModel為什么能在Activity重建后保持存活就是加分完成了因?yàn)閂iewModelStore在Activity里Activity被銷毀重建時非配置變更場景下ViewModelStore會保留只有finish時才會clear。5.2 生命周期組件與ViewModel原理被忽略的細(xì)節(jié)面試官有時會專門深挖Lifecycle原理問Lifecycle是怎么感知Activity生命周期的答案是在Activity的onCreate里通過ReportFragment.injectIfNeededIn(activity)注入一個無UI的Fragment利用Fragment的生命周期回調(diào)把Activity的生命周期事件分發(fā)出去?；蛘咴谛掳姹纠顰ctivity通過LifecycleRegistry調(diào)用handleLifecycleEventObserver就會被喚醒。另一個容易被問到的細(xì)節(jié)是onSaveInstanceState和ViewModel的區(qū)別。onSaveInstanceState適合保存臨時性的、可以被序列化的數(shù)據(jù)但如果是大對象或非序列化對象用ViewModel更合適。而且onSaveInstanceState在進(jìn)程被系統(tǒng)殺死后還能恢復(fù)ViewModel在進(jìn)程被殺死后不會存活所以兩者是互補(bǔ)的。準(zhǔn)備這部分時我給自己出的一個驗(yàn)證題是我實(shí)現(xiàn)一個自定義LiveData讓它在多個觀察者不同生命周期下正確分發(fā)事件怎么做 想通這個能應(yīng)對大多數(shù)Lifecycle的追問。5.3 該不該提Compose新技術(shù)的面試尺度2022年7月問Compose大概率是一個印象題。面試官不指望你多精通但想知道你是否關(guān)注了新技術(shù)、有沒有實(shí)踐意識。我的建議是不要主動大篇幅說Compose除非你項(xiàng)目里真的用了。更安全的說法是我了解Compose的聲明式UI思想也看過它的重組機(jī)制但當(dāng)前項(xiàng)目還是以View體系為主團(tuán)隊(duì)還沒有引入Compose。然后可以聊Compose的核心優(yōu)勢狀態(tài)驅(qū)動UI、重組只發(fā)生在State變化處、用Composable函數(shù)描述界面。如果你能補(bǔ)充一兩句副作用API的原理比如remember、LaunchedEffect、DisposableEffect的區(qū)分就更扎實(shí)了。但一定不要生拉硬扯聊到你不熟的地方非常容易露怯。6. 容易漏掉的邊角料考點(diǎn)類加載、混淆、adb與網(wǎng)絡(luò)6.1 Java/Kotlin細(xì)節(jié)泛型擦除與協(xié)程掛起在八股文篇里我把Java/Kotlin基礎(chǔ)單獨(dú)列了一類因?yàn)楹芏嗳嗽跍?zhǔn)備Android題時會忽略語言層的問題但2022年面試官喜歡混合考。Java層最容易考到的是泛型擦除編譯成字節(jié)碼時泛型類型會被擦除運(yùn)行時拿不到真正的泛型類型。面試官會問我能不能通過反射拿到List 的類型參數(shù)答案是不能除非用TypeToken類庫來繞開。Kotlin協(xié)程這塊高頻考點(diǎn)是掛起函數(shù)的原理。掛起函數(shù)本質(zhì)是狀態(tài)機(jī)編譯器會把一個掛起函數(shù)編譯成一個Continuation對象保存當(dāng)前狀態(tài)和局部變量當(dāng)掛起恢復(fù)時再繼續(xù)執(zhí)行。我用一個答題金句掛起不是阻塞是把CPU讓出去等結(jié)果恢復(fù)后在原來的棧上繼續(xù)走而不是新開線程。6.2 R8與APK瘦身混淆規(guī)則的高級問法熱搜詞里出現(xiàn)了android r8和android studio混淆2022年面試也確實(shí)會問App優(yōu)化的相關(guān)。先理解R8是干嘛的它是ProGuard的升級替代品負(fù)責(zé)代碼壓縮、資源壓縮、優(yōu)化和混淆。通過obfuscate階段把類名、方法名改短減少包體積。常見的追問是R8和ProGuard有什么區(qū)別 答案R8把shrink裁剪、optimize優(yōu)化、obfuscate混淆、desugar脫糖四步合并成一個統(tǒng)一的編譯期工具效率比ProGuardDX/D8高很多。APK瘦身的高頻問法包括為什么開啟android:extractNativeLibsfalse可以讓安裝包變小 因?yàn)閴嚎sandAlign庫可以減少占用空間。圖片資源為什么用WebP 同等質(zhì)量下比PNG體積小。為什么可以配置shrinkResources 因?yàn)镽8去掉無效代碼后關(guān)聯(lián)的未使用資源也可以被裁掉。6.3 adb與常用調(diào)試現(xiàn)場排錯的能力題不要小看adb命令面試官在問項(xiàng)目時經(jīng)常順手考你怎么看一個App的當(dāng)前Activity怎么查找ANR日志怎么判斷內(nèi)存占用我整理我必背的一組命令adb shell dumpsys activity top查看當(dāng)前界面Activity。adb shell dumpsys meminfo package查看進(jìn)程內(nèi)存占用。adb pull /data/anr/拉取ANR日志。adb shell kill -3 pid主動觸發(fā)一次ANR日志生成。adb shell am start -n package/activity拉起指定頁面。這些命令的回答要結(jié)合場景不要背菜單。比如你說自己排查過ANR就可以說先用dumpsys看主線程狀態(tài)和堆棧然后從/data/anr/traces里找到線程名和鎖等待關(guān)系。這樣面試官會覺得你確實(shí)干過而不是只會背命令。7. 八股文怎么答才有區(qū)分度從背題到聊體系7.1 面試官問八股的真實(shí)意圖面試官讓你介紹Handler機(jī)制他真實(shí)的目的是什么絕對不是想看你會不會背一遍源碼注釋而是想判斷你是否理解Android系統(tǒng)的消息循環(huán)模型能否應(yīng)對系統(tǒng)為什么這么設(shè)計(jì)。遇到性能或異常問題時能否從機(jī)制層面推測根因。有沒有持續(xù)看源碼和深入思考的習(xí)慣。所以答題的時候不要一口氣把源碼全背出來要像講故事一樣先說模型再說為什么最后配合場景。要留給面試官追問的空間他說不定會接著你的回答問出更多細(xì)節(jié)。我在模擬面試時要求自己回答每個核心題都不超過80秒但在這80秒內(nèi)必須包含一個結(jié)論、一個原理、一個例子。比如Handler結(jié)論是主線程靠LooperMessageQueue循環(huán)處理消息原理是nativePollOnce阻塞、epoll喚醒例子是postDelay不是定時器只是按時間排序插入到時間才從隊(duì)列取出。這樣的回答就比光背流程有區(qū)分度。7.2 被追問時的應(yīng)對不要急著給出所有細(xì)節(jié)面試時最忌諱的是面試官一開口就把我所有知道的都倒出來結(jié)果他沒法再往下問。更自然的策略是先給到七分等追問再給到九分。舉例面試官問你了解AMS嗎你可以先答AMS是系統(tǒng)服務(wù)中管理Activity、Service、BroadcastReceiver生命周期和任務(wù)棧的核心類它在SystemServer進(jìn)程里。如果面試官繼續(xù)問那它怎么和App通信你再展開Binder和ApplicationThread。他如果只問了第一層你就不要直接背到zygote避免顯得像在背課文。遇到不會的問題也要有一套話術(shù)這塊我平時沒有從源碼層面細(xì)看過但是根據(jù)我對xxx的理解我覺得大概和xxx有關(guān)。如果我有機(jī)會深入了解我會xxx。 這句話比硬編胡造強(qiáng)一百倍也比答不上來就沉默強(qiáng)很多。7.3 如果準(zhǔn)備時間只剩兩周的個人建議最后分享一個適合沖刺的實(shí)操方案是我自己用著比較順的第1~3天把Handler、Binder、AMS這三個最硬核的機(jī)制徹底吃透每天拿一臺手機(jī)或者模擬器一邊看源碼一邊畫時序。第4~5天View事件分發(fā)和繪制流程用自己寫過的小Demo驗(yàn)證。第6~7天性能優(yōu)化三件套ANR、內(nèi)存泄漏、卡頓和自己的項(xiàng)目結(jié)合。第8~9天Jetpack全家桶重點(diǎn)看ViewModel、LiveData、Lifecycle。第10~11天過一遍基礎(chǔ)語言題和網(wǎng)絡(luò)題刷一些面經(jīng)。第12~13天模擬面試自己錄音回聽哪里有停頓、哪里表達(dá)不清。第14天查漏補(bǔ)缺把最不熟的三個點(diǎn)再背一遍。每天保證輸出別光看。我會把當(dāng)天復(fù)習(xí)的題目用我自己講給自己聽的方式說一遍經(jīng)常錄音之后發(fā)現(xiàn)真能順暢講三分鐘以上的知識點(diǎn)才算真的學(xué)會了。很多題目隔一天再講一次如果講不順就說明還需要回爐。八股文準(zhǔn)備這件事說白了就是系統(tǒng)梳理 刻意輸出。你能把每個知識點(diǎn)用正常人聽得懂的話講清楚講到自己不覺得卡殼面試時大概率也不會出大問題。2022年7月這個時間點(diǎn)Android面試的要求是在變高但底層的那些機(jī)制沒變把基礎(chǔ)盤扎穩(wěn)了后面聊項(xiàng)目、聊架構(gòu)都會有底氣。