1. 面試準備與心態(tài)調整為什么Framework面試是道坎又到了一年一度的“金三銀四”對于Android開發(fā)者來說這不僅是跳槽漲薪的黃金窗口更是一次技術實力的全面檢閱。而在這場檢閱中Android Framework無疑是那道最難翻越、也最考驗開發(fā)者內功的“坎”。很多朋友在應用層開發(fā)上得心應手UI、網絡、數據庫信手拈來但一聊到Framework就容易陷入“好像知道但說不清楚”的尷尬境地。這很正常因為Framework層是連接應用與系統(tǒng)的橋梁它抽象、龐大且充滿了設計哲學和性能考量。我經歷過多次面試也作為面試官考察過不少人。我發(fā)現(xiàn)面試官問Framework問題核心目的往往不是讓你背誦源碼而是考察三個維度第一你對Android系統(tǒng)運行機制的理解深度這決定了你解決復雜問題的上限第二你的系統(tǒng)化思維和架構設計能力能否從全局視角看待一個功能模塊第三你的問題排查與性能優(yōu)化實戰(zhàn)經驗遇到卡頓、ANR、內存泄漏時你的排查鏈路是否清晰有效。所以這份匯總不僅僅是題目的羅列我更想結合自己踩過的坑和面試中的高頻追問點幫你梳理出一條清晰的復習路徑。我們不僅要“知道答案”更要理解“為什么這么問”以及“如何舉一反三”。接下來的內容我會圍繞Binder機制、Handler消息循環(huán)、View繪制、AMS/WMS核心服務、性能優(yōu)化與問題排查這幾個核心模塊展開每個模塊都會深入原理并附上我個人的實戰(zhàn)心得和避坑指南。2. Binder機制Android的進程間通信基石幾乎每一場Android高級面試都繞不開Binder。它太重要了是整個Android系統(tǒng)跨進程通信IPC的骨架。但很多人的理解停留在“它是一個驅動”、“用了內存映射”的層面這遠遠不夠。2.1 Binder的核心原理與一次完整IPC流程Binder的本質是什么我的理解是一套基于C/S架構通過內核驅動中轉實現(xiàn)了對象引用跨進程傳遞和遠程方法調用的通信框架。它的核心優(yōu)勢在于性能一次拷貝和安全性內核身份校驗。一次完整的Binder IPC調用比如Activity啟動另一個進程的Service其流程可以拆解為以下步驟代理與樁的生成AIDL編譯器會為我們生成代理類Proxy和樁類Stub。Proxy在客戶端它把方法調用和參數打包成ParcelStub在服務端它負責解包Parcel并調用實際的方法實現(xiàn)。這里有個關鍵點Proxy和Stub都實現(xiàn)了同一個接口但對客戶端來說它持有的只是一個“代理對象”感覺像是在調用本地方法。數據打包與傳輸當客戶端調用代理對象的方法時參數會被序列化marshal到Parcel中。Parcel就像一個高效的數據容器。然后這個調用請求會通過BinderProxy.transact()方法經由Binder驅動發(fā)送到服務端進程?！耙淮慰截悺本桶l(fā)生在這里客戶端將數據拷貝到內核空間的一塊共享內存中服務端可以直接從這塊內存讀取避免了在用戶空間的多余拷貝。驅動中轉與線程池處理Binder驅動在內核中維護了一個所有Binder實體的引用樹。它根據請求中的handle對Binder實體的引用找到目標服務端所在的進程并將請求數據放入該進程的Binder線程池的等待隊列中。服務端執(zhí)行與返回服務端的Binder線程池中的某個線程被喚醒從隊列中取出請求交給對應的Stub.onTransact()方法處理。Stub解包Parcel調用真正的業(yè)務方法。執(zhí)行結果再通過同樣的路徑打包成Parcel經由驅動返回給客戶端。注意很多面試官會追問“為什么用Binder而不用Socket或管道”。你可以從性能拷貝次數少、安全性支持身份標識、易用性面向對象三個維度對比。但更深一層可以提一下Binder對“引用計數”和“生命周期管理”的天然支持這對于系統(tǒng)管理四大組件等“遠程對象”的生命周期至關重要這是Socket難以優(yōu)雅實現(xiàn)的。2.2 Binder通信中的核心對象與“死亡通知”機制理解幾個核心對象的關系至關重要IBinder 所有Binder對象的基接口。它代表了一個可以跨進程引用的對象。Binder 服務端的本地對象基類。我們實現(xiàn)的服務類通常繼承自Binder或Stub。BinderProxy 客戶端持有的代理對象。它是驅動在內核中創(chuàng)建的在客戶端用戶空間的體現(xiàn)。ServiceManager 一個特殊的Binder服務是Android系統(tǒng)的“服務大管家”負責管理系統(tǒng)核心服務如AMS、WMS的注冊與查詢。一個高級問題是關于“Binder死亡通知”。如果服務端進程意外崩潰客戶端持有的BinderProxy就變成了“野指針”再次調用會導致失敗。如何感知可以通過IBinder.linkToDeath()設置一個死亡代理DeathRecipient。當驅動檢測到服務端Binder實體消失時會回調客戶端的DeathRecipient.binderDied()方法。在實際開發(fā)中這對于需要保持長連接或依賴關鍵系統(tǒng)服務的應用來說是保證健壯性的重要手段。我曾在實現(xiàn)一個與獨立守護進程通信的SDK時就依靠這個機制在進程崩潰后嘗試自動重啟連接。2.3 Binder的優(yōu)化與實戰(zhàn)中的“坑”Binder通信雖高效但并非沒有成本。頻繁或傳輸大數據量的Binder調用會成為性能瓶頸。優(yōu)化建議減少調用次數合并多個細粒度調用為一個粗粒度調用。例如不要在一個循環(huán)里每次調用Binder接口獲取一個數據項而應該設計一個接口一次性獲取列表?？刂茢祿勘苊庠贐inder調用中傳遞過大的對象如巨大的Bitmap。Parcel的序列化/反序列化有開銷。對于大數據考慮使用ashmem匿名共享內存或Socket、文件等替代方案。注意線程模型Binder調用在客戶端是同步阻塞的。如果在主線程進行耗時Binder調用會直接導致ANR。務必在子線程中進行。實戰(zhàn)踩坑 有一次排查一個詭異的“間歇性卡頓”最終定位到一個第三方庫在onDraw方法里頻繁進行輕量的Binder調用查詢某個系統(tǒng)狀態(tài)。雖然每次調用很快但在快速滾動的列表項渲染時積少成多嚴重阻塞了UI線程。教訓是即使在看似簡單的操作中也要對Binder調用保持警惕尤其是在性能敏感的路徑上。3. Handler消息機制理解Android的“心臟”Handler、Looper、MessageQueue構成了Android應用線程間通信的經典模式。它不僅是UI更新的基礎更是理解Android異步編程模型的關鍵。3.1 從源碼角度拆解消息循環(huán)的建立與運轉很多人會背“一個線程只有一個Looper和一個MessageQueue”但為什么我們從頭看起。Looper.prepare() 這是初始化動作。它會檢查當前線程的ThreadLocal中是否已存在Looper如果存在則拋出異常這就是“一個線程一個Looper”的保證。然后創(chuàng)建一個新的Looper對象并將其內部的MessageQueue一并創(chuàng)建最后存入當前線程的ThreadLocal中。ThreadLocal是理解這個機制的關鍵它保證了每個線程訪問到的都是自己獨有的Looper副本。Looper.loop() 這是一個死循環(huán)也是Android主線程不會退出的原因。在循環(huán)中它會不斷地調用MessageQueue.next()去取消息。next()方法可能會阻塞當隊列為空或有延遲消息未到執(zhí)行時間時此時線程會釋放CPU進入等待狀態(tài)通過epoll機制監(jiān)聽文件描述符包括用于喚醒的管道的事件。當有新消息入隊或延遲時間到達時nativeWake()會被調用寫入數據到管道喚醒next()方法取出消息。Handler的發(fā)送與處理Handler.sendMessage()最終會將Message放入其關聯(lián)的Looper的MessageQueue中。當Looper.loop()取到這條消息后會調用msg.target.dispatchMessage()這個target就是發(fā)送消息的Handler。最后會執(zhí)行到我們重寫的handleMessage()方法。提示面試官常問“主線程的Looper是什么時候創(chuàng)建的”。答案是ActivityThread.main()方法。在main()函數里在調用Looper.prepareMainLooper()創(chuàng)建主線程Looper后就進入了Looper.loop()所以主線程的消息循環(huán)在應用啟動之初就建立了這也是為什么我們可以在子線程通過MainLooper的Handler向主線程發(fā)消息更新UI。3.2 消息屏障SyncBarrier與異步消息這是Handler機制中一個高級且重要的概念直接關系到UI的流暢性。什么是消息屏障它是一個特殊的Message其target即Handler為null。當MessageQueue.next()在取消息時遇到屏障它會跳過其后所有的同步消息只尋找異步消息執(zhí)行。為什么要用它最典型的場景是垂直同步VSync信號。當VSync信號到來時系統(tǒng)需要優(yōu)先執(zhí)行UI渲染相關的任務如ViewRootImpl發(fā)起的遍歷繪制這些任務被包裝成異步消息。如果此時消息隊列前面排滿了其他同步消息比如一些業(yè)務邏輯就會導致繪制任務被延遲造成掉幀。插入一個消息屏障可以確保繪制異步消息被優(yōu)先執(zhí)行。如何發(fā)送異步消息在創(chuàng)建Handler時通過Handler(looper, callback, async)構造函數并將async設為true或者對Message調用setAsynchronous(true)。但注意普通應用開發(fā)者通常無法直接插入屏障這是系統(tǒng)內部的行為。理解這個概念能幫你更好地分析UI卡頓。例如如果你通過Systrace工具看到Choreographer#doFrame執(zhí)行被延遲很可能就是因為主線程消息隊列中有耗時的同步消息阻塞了異步的繪制消息。3.3 Handler的內存泄漏與最佳實踐Handler內存泄漏是經典面試題但現(xiàn)在已經有了更優(yōu)解。傳統(tǒng)的內存泄漏場景在Activity中創(chuàng)建匿名內部類Handler它會隱式持有外部類Activity的引用。如果這個Handler被發(fā)送了一個延遲消息比如postDelayed而消息還未處理時Activity被銷毀那么由于Message持有Handler引用Handler持有Activity引用導致Activity無法被GC回收。解決方案的演進靜態(tài)內部類 弱引用將Handler聲明為靜態(tài)內部類并通過弱引用持有Activity。這是早期的標準答案。在生命周期結束時清除消息在Activity.onDestroy()中調用handler.removeCallbacksAndMessages(null)移除所有未處理的消息切斷Message對Handler的引用鏈。這是更直接有效的方法。使用AndroidX的Lifecycle這是目前最推薦的方式。使用Lifecycle庫提供的DefaultLifecycleObserver或在ViewModel中處理延時任務。ViewModel的生命周期與Activity解耦且會在Activity真正銷毀時自動清理從根本上避免了泄漏問題。對于需要在生命周期感知的組件中執(zhí)行延時操作viewModelScope.launch配合協(xié)程的delay是更現(xiàn)代和安全的選擇。我的心得在現(xiàn)代Android開發(fā)中應盡量避免直接使用Handler進行跨生命周期的延時任務調度。將異步邏輯遷移到ViewModel或Presenter中利用協(xié)程或RxJava等具有生命周期感知能力的框架是更清晰、更安全的選擇。Handler應更多地被視作理解系統(tǒng)底層機制和進行線程間通信特別是在非UI線程間的工具。4. View的繪制、測量與事件分發(fā)這是應用開發(fā)最常接觸也是面試中問題最密集的部分之一。光知道onMeasure、onLayout、onDraw的調用順序是不夠的。4.1 從setContentView到View繪制的完整鏈路當我們在Activity.onCreate()中調用setContentView(R.layout.xxx)時背后發(fā)生了什么PhoneWindow與DecorViewActivity持有一個PhoneWindow實例。setContentView會創(chuàng)建DecorView頂級View包含標題欄和內容區(qū)域并將我們的布局文件inflate出來作為contentParent的子View。ViewRootImpl與繪制請求在ActivityThread的handleResumeActivity中會創(chuàng)建ViewRootImpl并將DecorView與之關聯(lián)。ViewRootImpl是連接WindowManager和DecorView的紐帶也是整個View繪制的發(fā)起者。它通過Choreographer來接收VSync信號。VSync與遍歷Traversal當VSync信號到來Choreographer會回調注冊的FrameCallbackViewRootImpl開始執(zhí)行performTraversals()。這是繪制的核心方法它依次調用performMeasure(): 從根View開始遞歸調用子View的measure()確定每個View的測量寬高。這里涉及MeasureSpec父View對子View的約束的計算和傳遞。performLayout(): 根據測量出的寬高遞歸調用子View的layout()確定每個View在父容器中的位置四個頂點的坐標。performDraw(): 將繪制過程分為軟件繪制drawSoftware和硬件加速繪制。硬件加速下它會遞歸調用View的draw()方法但實際的繪制命令會被記錄到DisplayList中最終由GPU執(zhí)行。理解這個鏈路就能明白為什么說“UI更新必須在主線程”。因為整個ViewTree的狀態(tài)包括測量、布局、繪制指令都必須在主線程同步地、串行地更新否則會導致狀態(tài)不一致和崩潰。4.2 自定義View的Measure與Layout實戰(zhàn)面試官很喜歡讓手寫一個簡單的自定義ViewGroup比如流式布局FlowLayout。這考察的是對onMeasure和onLayout的掌握。onMeasure的關鍵步驟遍歷所有子View根據父View傳遞的MeasureSpec和自身的布局參數如LayoutParams調用child.measure(childWidthSpec, childHeightSpec)。在測量子View的過程中需要根據你的布局規(guī)則比如流式布局的換行邏輯累加計算當前行已占用的寬度和高度。所有子View測量完畢后根據子View的總尺寸和自身的MeasureSpec通過setMeasuredDimension()確定自己的最終寬高。這里要處理好EXACTLY、AT_MOST和UNSPECIFIED三種模式。onLayout的關鍵步驟遍歷所有子View根據在onMeasure階段計算好的每個子View應處的位置左上角坐標l, t調用child.layout(l, t, l child.getMeasuredWidth(), t child.getMeasuredHeight())。子View的getMeasuredWidth/Height()是測量結果而getWidth/Height()是layout執(zhí)行后right-left和bottom-top的結果兩者在正常情況下應相等。避坑指南在onMeasure中千萬不要直接調用子View的getWidth()或getHeight()因為此時布局尚未完成這兩個值通常是0。必須使用getMeasuredWidth/Height()。另外要處理好padding和子View的margin這是很多初學者容易忽略的地方。4.3 事件分發(fā)機制的深度解析與沖突處理“事件分發(fā)”這個問題能回答到dispatchTouchEvent、onInterceptTouchEvent、onTouchEvent的傳遞順序算是及格。但要拿高分必須理解背后的設計哲學和如何處理滑動沖突。核心邏輯再梳理傳遞Dispatch事件從Activity.dispatchTouchEvent()開始傳遞給Window再傳給頂級ViewDecorView然后自上而下父View到子View傳遞。父View的dispatchTouchEvent負責決定將事件分發(fā)給哪個子View。攔截Intercept在父View的dispatchTouchEvent中會先調用onInterceptTouchEvent()詢問是否攔截。如果攔截則從該View開始事件序列后續(xù)事件將不再向下傳遞直接由該View的onTouchEvent處理。消費Consume子View通過onTouchEvent返回值決定是否消費事件。如果消費返回true則事件流終止向上傳遞如果不消費返回false事件會回溯給父View的onTouchEvent處理?；瑒記_突的經典場景與解決方案內外滑動方向不一致如外層ViewPager橫向內嵌ListView縱向。解決方案重寫外層容器的onInterceptTouchEvent根據滑動距離和方向判斷。當檢測到橫向滑動距離大于閾值時攔截事件自己處理ViewPager翻頁否則不攔截交給內層ListView處理滾動。內外滑動方向一致如外層ScrollView和內層ListView都是縱向滾動。解決方案通常需要根據業(yè)務邏輯指定一個優(yōu)先級?？梢栽趦葘覮istView滾動到頂部繼續(xù)下拉時將事件交給外層ScrollView或者在內層ListView滾動到底部繼續(xù)上推時交給外層。這需要在內層View的onTouchEvent中根據內容位置和滑動方向進行判斷并通過requestDisallowInterceptTouchEvent()方法來動態(tài)請求父View不要攔截。嵌套RecyclerView這是更復雜的情況。除了上述方法更現(xiàn)代的解決方案是使用NestedScrolling機制如NestedScrollView配合RecyclerView。這套機制定義了父子和子父之間協(xié)同滾動的接口能更優(yōu)雅地處理嵌套滾動避免粗暴的攔截邏輯。我的經驗處理滑動沖突一定要在ACTION_DOWN、ACTION_MOVE、ACTION_UP整個事件序列的背景下思考。一個常見的錯誤是只在ACTION_MOVE中做判斷而忽略了在ACTION_DOWN時初始化狀態(tài)或在ACTION_UP時重置狀態(tài)這會導致事件狀態(tài)混亂。使用GestureDetector或ViewConfiguration.getScaledTouchSlop()來獲取系統(tǒng)認定的滑動閾值比硬編碼一個像素值更可靠。5. AMS、WMS核心系統(tǒng)服務探秘ActivityManagerService和WindowManagerService是Android Framework中最核心的兩個系統(tǒng)服務。理解它們才能理解Android應用的生命周期和窗口管理。5.1 AMS應用生命周期的“總導演”AMS負責管理四大組件的生命周期、進程調度、任務棧Task和Back Stack等。Activity啟動流程簡化版應用進程通過Binder調用AMS.startActivity()。AMS進行一系列校驗權限、目標Activity是否存在等并解析Intent的Flag如FLAG_ACTIVITY_NEW_TASK。AMS根據目標Activity的launchMode和當前任務棧情況決定是創(chuàng)建新Activity實例還是復用已有的。AMS如果判斷目標Activity所在應用進程未啟動則通過Zygotefork出新進程。進程創(chuàng)建后AMS通過Binder調用應用進程的ApplicationThread它是ActivityThread的內部類也是一個Binder對象來調度生命周期。ApplicationThread將消息發(fā)送到主線程的Handler最終由ActivityThread的HHandler處理調用到Activity.onCreate()等方法。關鍵數據結構ActivityRecord AMS中代表一個Activity實例。TaskRecord 代表一個任務Task包含一組相關的ActivityRecord。用戶感知的“應用”通常對應一個或多個Task。ActivityStack 管理TaskRecord的棧。通常有主棧Home Stack、全屏棧Fullscreen Stack等用于管理不同顯示區(qū)域的Activity。理解這些就能回答“singleTask和singleInstance的區(qū)別”、“allowTaskReparenting的作用”等問題。例如singleTask的Activity會在一個新的Task根位置創(chuàng)建并且該Task中只能有它一個Activity其他Activity會被放在別的Task里而singleInstance不僅獨占一個Task這個Task還獨占一個ActivityStack。5.2 WMS窗口的“大管家”WMS管理所有窗口Window的添加、刪除、排序、大小、層級Z-order、焦點以及與SurfaceFlinger的交互。Window、View、Surface的關系Window 是一個抽象概念代表一個可繪制的界面單元。PhoneWindow是其具體實現(xiàn)。View 是Window的內容。DecorView是Window的根View。Surface 是一塊畫布由WMS分配由SurfaceFlinger合成并最終顯示到屏幕上。每個Window通常對應一個Surface。View的繪制內容最終都渲染到其Window對應的Surface上。WMS的核心工作窗口管理當ViewRootImpl調用WMS.addWindow()時WMS會為這個Window創(chuàng)建WindowState對象來管理其狀態(tài)。WMS根據窗口類型應用窗口、子窗口、系統(tǒng)窗口、Z-order、焦點等規(guī)則計算每個窗口的最終位置和大小。布局Layout與動畫WMS會定期如每幀執(zhí)行performLayoutAndPlaceSurfacesLocked()計算所有窗口的最終位置并處理窗口動畫如Activity切換動畫。輸入事件路由InputManagerService接收到觸摸事件后會詢問WMS“這個觸摸點落在哪個窗口上” WMS根據窗口的層級和位置信息找到最頂層的、可接收輸入的窗口然后將事件派發(fā)給對應的應用進程。Surface管理WMS與SurfaceFlinger通信分配和釋放Surface并告知SurfaceFlinger如何合成這些Surface它們的Z-order、位置、透明度等。一個常見面試問題“Dialog為什么有時候會報Unable to add window的錯誤” 這通常是因為Dialog需要依附于一個Window即一個Token。這個Token通常由Activity提供。如果你在非Activity的Context如ApplicationContext上彈出Dialog或者Activity已經銷毀onDestroy之后就無法獲得有效的Token。解決方法確保使用Activity的Context并在生命周期結束時dismissDialog。5.3 應用與系統(tǒng)服務的交互AIDL與系統(tǒng)API我們如何與AMS、WMS交互除了通過startActivity這種封裝好的API更深層的交互是通過AIDL接口。例如ActivityManager是一個客戶端封裝類它內部通過IActivityManager這個AIDL接口與AMS通信。WindowManager則通過IWindowManager與WMS通信。理解這一點就能明白很多系統(tǒng)級功能如獲取運行進程列表、動態(tài)改變窗口屬性的原理。在開發(fā)系統(tǒng)級應用或需要特殊權限的應用時有時需要直接調用這些隱藏的AIDL接口通過反射但這需要系統(tǒng)簽名權限普通應用無法使用。對于普通應用開發(fā)者更實際的是理解這些服務提供的標準API如ActivityManager.getRunningAppProcesses()及其背后的限制和原理。6. 性能優(yōu)化與疑難問題排查實戰(zhàn)Framework層面的知識最終要落到解決實際問題上。面試官非常看重你利用Framework知識進行性能優(yōu)化和問題排查的能力。6.1 卡頓Jank與ANR的根因分析與工具鏈卡頓的本質主線程在16.6ms60Hz屏幕內未能完成VSync信號觸發(fā)的繪制任務performTraversals。原因無非是主線程做了太多事。排查工具鏈Systrace這是分析卡頓的“神器”。它能圖形化展示每個線程在時間軸上的狀態(tài)運行、休眠、阻塞等特別是主線程的Choreographer#doFrame周期。通過Systrace你可以清晰地看到CPU調度主線程是否被其他線程搶占CPU鎖等待主線程是否在等待某個鎖顯示為Monitor WaitI/O操作主線程是否在進行文件讀寫或網絡請求耗時方法結合Trace.beginSection()可以標記代碼塊在Systrace中看到其執(zhí)行時長。Perfetto 是Systrace的升級版提供了更強大的Trace分析和可視化能力是現(xiàn)在更主流的工具。Android Studio Profiler 用于分析CPU、內存的實時占用可以抓取方法調用棧定位熱點方法。ANRApplication Not Responding 是卡頓的極端情況。系統(tǒng)監(jiān)控Input事件按鍵、觸摸或BroadcastReceiver、Service的生命周期方法如果在一定時間前臺Activity是5秒BroadcastReceiver是10秒等內未得到處理就會觸發(fā)ANR。分析ANR 發(fā)生ANR后系統(tǒng)會生成/data/anr/traces.txt文件高版本路徑可能不同。這個文件包含了發(fā)生ANR時所有線程的堆棧信息。關鍵看主線程main的堆棧它卡在什么地方是死鎖還是在進行一個非常耗時的同步操作實戰(zhàn)技巧不要只盯著自己的代碼。很多卡頓/ANR是由系統(tǒng)或第三方庫引起的。例如我在項目中遇到過因為初始化一個第三方地圖SDK其初始化在子線程但阻塞了主線程的某個回調導致的啟動ANR。通過分析traces文件發(fā)現(xiàn)主線程在Binder調用上等待。進一步排查發(fā)現(xiàn)是SDK內部的一個同步鎖設計問題。解決辦法是延遲初始化或聯(lián)系SDK提供方修復。6.2 內存泄漏與內存抖動排查內存泄漏在Android中最常見的就是生命周期長的對象如靜態(tài)變量、單例、線程池持有了Activity/Fragment等生命周期短對象的引用。排查工具Android Studio Profiler Memory Heap Dump 可以捕獲當前內存堆的快照查看對象引用關系。重點關注Activity、Fragment、View、Context等對象的實例個數。如果同一個Activity有多個實例存在很可能發(fā)生了泄漏。LeakCanary 集成到開發(fā)環(huán)境中的自動化內存泄漏檢測庫。它會在對象本該被回收時觸發(fā)GC并分析引用鏈以通知的形式告訴你泄漏路徑非常直觀。內存抖動 指在短時間內頻繁地創(chuàng)建和銷毀大量對象導致GC頻繁觸發(fā)尤其是Young GC。雖然單次GC暫停時間短但頻繁發(fā)生會導致UI線程被不斷打斷產生卡頓。排查方法 使用Profiler的Memory視圖觀察內存分配曲線和GC事件。如果看到鋸齒狀的曲線和密集的GC圖標就可能存在內存抖動。進一步使用Allocation Tracking功能記錄一段時間內的所有對象分配找出分配最頻繁的對象類型和分配棧優(yōu)化其創(chuàng)建邏輯如使用對象池。我的經驗 除了常見的Handler、靜態(tài)引用泄漏要特別注意匿名內部類持有外部類引用的場景尤其是在注冊監(jiān)聽器如SensorManager.registerListener、使用回調時如果忘記在生命周期結束時反注冊就會導致泄漏。另外非靜態(tài)內部類默認持有外部類引用在將其傳遞給一個可能長生命周期的對象如線程池任務時要格外小心。6.3 啟動優(yōu)化與布局優(yōu)化啟動優(yōu)化冷啟動、溫啟動、熱啟動 面試常問區(qū)別。冷啟動耗時最長因為它涉及創(chuàng)建進程、加載Application、啟動首頁Activity的全過程。優(yōu)化主要針對冷啟動。優(yōu)化方向減少主線程工作量 將Application.onCreate()和首屏Activity.onCreate()中的耗時操作如初始化第三方SDK、讀取文件、網絡請求放到子線程或延遲加載。避免啟動過程I/O 檢查是否在主線程讀取SharedPreferences、數據庫或Asset文件。優(yōu)化布局 首屏布局避免過度繪制、嵌套過深。使用ViewStub延遲加載不立即顯示的視圖。使用啟動器Starter模式 將初始化任務抽象為Task根據依賴關系構建有向無環(huán)圖并發(fā)執(zhí)行提升整體初始化速度。視覺優(yōu)化 為啟動Activity設置android:windowBackground提供一個與啟動圖類似的背景消除白屏/黑屏的視覺延遲感。布局優(yōu)化工具 使用Android Studio的Layout Inspector和GPU過度繪制調試功能。原則減少層級 使用ConstraintLayout替代多層嵌套的LinearLayout和RelativeLayout。復用布局 使用include標簽。按需加載 使用ViewStub它在inflate之前幾乎不占用資源。使用merge 當根布局與父容器類型相同時使用merge可以消除一層多余的ViewGroup。避免在onDraw中創(chuàng)建對象 這會導致內存抖動。一個高級話題RenderThread與硬件加速。在硬件加速開啟時View.draw()的繪制命令會被記錄到DisplayList中由RenderThread異步提交給GPU。這意味著主線程的draw階段可能很快但真正的渲染耗時在RenderThread。如果GPU負載過高或繪制指令過于復雜如復雜的Path、陰影仍會導致掉幀。這時需要用Trace工具追蹤RenderThread的耗時。Framework的知識體系龐大而深邃一次面試無法覆蓋所有細節(jié)。但只要你掌握了上述核心模塊的原理、聯(lián)系和實戰(zhàn)應用方法就能在面試中展現(xiàn)出扎實的底層功底和解決問題的能力。復習時建議結合Android源碼AOSP閱讀從ActivityThread、ViewRootImpl等關鍵類入手跟蹤幾個核心流程如啟動、繪制、事件理解會深刻得多。最后保持自信將面試官的問題引向你熟悉的、有深入思考的領域進行有深度的討論往往比泛泛而談更能獲得認可。