1. 項(xiàng)目概述為什么渲染效率是Android開發(fā)的“命門”在Android應(yīng)用開發(fā)中尤其是涉及復(fù)雜UI、動(dòng)畫、游戲或高幀率視頻播放的場(chǎng)景渲染效率直接決定了用戶體驗(yàn)的“天花板”。用戶感知到的卡頓、掉幀、響應(yīng)遲緩其根源往往不在于CPU的計(jì)算能力而在于圖形數(shù)據(jù)從應(yīng)用層到屏幕像素這個(gè)“渲染管道”中的某個(gè)環(huán)節(jié)出現(xiàn)了瓶頸。作為一名常年與性能優(yōu)化打交道的開發(fā)者我見過太多應(yīng)用在功能上無可挑剔卻因?yàn)殇秩拘实拖露陉P(guān)鍵時(shí)刻“掉鏈子”導(dǎo)致用戶流失。因此深入理解并優(yōu)化Android渲染管道不是一項(xiàng)錦上添花的技能而是構(gòu)建高性能、高流暢度應(yīng)用的必修課。Android渲染管道是一個(gè)復(fù)雜的系統(tǒng)它涉及應(yīng)用代碼、系統(tǒng)框架、硬件驅(qū)動(dòng)乃至屏幕本身。簡(jiǎn)單來說它負(fù)責(zé)將你的View層級(jí)結(jié)構(gòu)View Hierarchy和繪制命令Canvas drawing commands轉(zhuǎn)化為屏幕上最終顯示的像素。這個(gè)過程如果效率低下就會(huì)導(dǎo)致幀率FPS下降用戶看到的就是不連貫的動(dòng)畫或靜止的UI。優(yōu)化渲染效率本質(zhì)上就是在為這條管道“疏通堵點(diǎn)”確保每一幀數(shù)據(jù)都能在規(guī)定時(shí)間內(nèi)例如對(duì)于60Hz屏幕就是16.67毫秒順利走完全程。接下來我將從設(shè)計(jì)思路、核心原理、實(shí)操優(yōu)化到問題排查系統(tǒng)地拆解如何提升這條管道的吞吐量。2. 渲染管道核心原理與性能瓶頸剖析要優(yōu)化必須先理解。Android的渲染流程主要可以分為兩個(gè)關(guān)鍵階段測(cè)量/布局Measure/Layout和繪制Draw。這兩個(gè)階段在UI線程主線程執(zhí)行其產(chǎn)出是接下來要討論的渲染管道的“原料”。2.1 從UI線程到SurfaceFlinger渲染管道的全景圖當(dāng)View的invalidate()方法被調(diào)用時(shí)會(huì)觸發(fā)一次視圖樹的遍歷執(zhí)行measure、layout和draw。draw方法執(zhí)行后并不會(huì)直接繪制到屏幕。它的核心工作是記錄繪制命令到一塊稱為顯示列表Display List的緩存中。這個(gè)顯示列表包含了將視圖渲染到屏幕所需的所有OpenGL ES或Vulkan命令。隨后渲染管道真正開始工作同步與構(gòu)建UI線程的工作完成后渲染線程RenderThread被喚醒。它從UI線程同步獲取更新后的顯示列表。記錄與序列化渲染線程遍歷顯示列表將其中的繪制命令如畫矩形、貼紋理、應(yīng)用變換記錄到一個(gè)新的、線程安全的命令緩沖區(qū)中。這一步是多線程渲染的關(guān)鍵它將耗時(shí)的命令準(zhǔn)備工作和實(shí)際的GPU執(zhí)行解耦。提交與合成命令緩沖區(qū)被提交給GPU驅(qū)動(dòng)執(zhí)行。GPU將各個(gè)Surface通常是每個(gè)窗口或SurfaceView渲染到各自的圖形緩沖區(qū)Graphic Buffer中。SurfaceFlinger合成系統(tǒng)服務(wù)SurfaceFlinger收集所有準(zhǔn)備好的圖形緩沖區(qū)根據(jù)它們的Z-order層級(jí)、位置、透明度等信息進(jìn)行合成Compositing最終生成一幀圖像通過硬件合成器Hardware Composer, HWC或GPU合成后提交給顯示控制器Display Controller刷新到屏幕。注意從Android 5.0API 21引入的渲染線程RenderThread是性能提升的關(guān)鍵。它將大部分OpenGL命令的記錄和執(zhí)行從UI線程剝離使得UI線程在觸發(fā)繪制后能更快地響應(yīng)新的輸入事件減少了卡頓。2.2 識(shí)別渲染管道的四大常見瓶頸理解了流程我們就能定位瓶頸。效率低下通常發(fā)生在以下幾個(gè)環(huán)節(jié)UI線程過載這是最常見的瓶頸。如果measure、layout或構(gòu)建顯示列表draw耗時(shí)超過一幀的時(shí)間如16ms就會(huì)直接導(dǎo)致掉幀。復(fù)雜的視圖層級(jí)、頻繁的布局請(qǐng)求requestLayout、在draw中執(zhí)行耗時(shí)操作都是元兇。渲染線程阻塞雖然渲染線程獨(dú)立但它也可能被阻塞。例如上傳巨大的位圖紋理到GPUTexture Upload是一個(gè)非常耗時(shí)的操作會(huì)阻塞渲染線程。此外如果顯示列表過于復(fù)雜例如包含成千上萬個(gè)繪制命令記錄命令本身也會(huì)耗時(shí)。過度繪制Overdraw這是指屏幕上的同一個(gè)像素在單幀內(nèi)被繪制了多次。例如一個(gè)不透明的View完全覆蓋了另一個(gè)View但被覆蓋的View仍然執(zhí)行了繪制命令。過度繪制浪費(fèi)了GPU的填充率Fill Rate是純粹的效能浪費(fèi)。開發(fā)者模式中的“顯示過度繪制區(qū)域”功能可以直觀地看到這個(gè)問題藍(lán)色可接受紅色、深紅色表示過度繪制嚴(yán)重。合成器壓力當(dāng)應(yīng)用使用了很多SurfaceView、TextureView或者半透明疊加層時(shí)SurfaceFlinger和HWC的合成工作會(huì)變得繁重。如果HWC無法處理比如層數(shù)超過了硬件支持的最大值就會(huì)回退到GPU合成后者效率通常較低。3. 實(shí)戰(zhàn)優(yōu)化從代碼到配置的全面策略理論清晰后我們進(jìn)入實(shí)戰(zhàn)環(huán)節(jié)。優(yōu)化必須有的放矢結(jié)合工具定位問題再實(shí)施具體策略。3.1 工具先行性能剖析三板斧在動(dòng)手改代碼前必須用數(shù)據(jù)說話。Systrace這是分析渲染問題的“神器”。它可以給你一個(gè)系統(tǒng)級(jí)的、帶時(shí)間線的性能視圖。重點(diǎn)關(guān)注Choreographer#doFrame的周期看UI線程和渲染線程在每個(gè)幀周期內(nèi)的時(shí)間分布。如果doFrame超過16.67ms就意味著掉幀。在Systrace中你可以清晰地看到measure、layout、draw、sync upload、issue draw commands等階段各自花了多少時(shí)間。Android GPU Inspector這是更現(xiàn)代的GPU性能分析工具。它的“Rendering”標(biāo)簽頁(yè)可以直接顯示每一幀的渲染階段耗時(shí)并能下鉆到具體的OpenGL或Vulkan調(diào)用對(duì)于分析渲染線程瓶頸和GPU負(fù)載極其有效。Layout Inspector ProfilerLayout Inspector可以查看視圖的最終層級(jí)和屬性幫助識(shí)別冗余視圖。Profiler的CPU和內(nèi)存分析器可以幫助定位導(dǎo)致UI線程卡頓的具體方法。3.2 優(yōu)化UI線程減輕主線程負(fù)擔(dān)UI線程的優(yōu)化是立竿見影的。3.2.1 扁平化視圖層級(jí)復(fù)雜的ViewGroup嵌套如RelativeLayout嵌套LinearLayout會(huì)導(dǎo)致測(cè)量和布局的指數(shù)級(jí)復(fù)雜度。優(yōu)先使用ConstraintLayout它可以通過扁平的約束關(guān)系實(shí)現(xiàn)復(fù)雜布局大幅減少層級(jí)。定期使用Layout Inspector檢查布局移除不必要的包裝ViewGroup。3.2.2 優(yōu)化onDraw與避免無效操作Canvas.drawXXX()系列方法在onDraw中被調(diào)用。務(wù)必遵守以下原則絕不分配新對(duì)象避免在onDraw中創(chuàng)建新的Paint、Path、Bitmap等對(duì)象這會(huì)瞬間觸發(fā)GC導(dǎo)致卡頓。所有繪制對(duì)象應(yīng)在初始化時(shí)創(chuàng)建并復(fù)用。使用canvas.clipRect()在繪制多個(gè)元素前通過clipRect告訴系統(tǒng)哪些區(qū)域需要繪制。系統(tǒng)會(huì)跳過裁剪區(qū)域外的繪制命令這對(duì)RecyclerView的Item繪制優(yōu)化尤其有效。謹(jǐn)慎使用canvas.saveLayer()這個(gè)方法會(huì)創(chuàng)建一個(gè)新的離屏緩沖層代價(jià)非常高昂通常用于實(shí)現(xiàn)陰影、模糊等特效。如果非用不可確保其范圍盡可能小。3.2.3 善用View的緩存機(jī)制setWillNotDraw如果一個(gè)自定義View不繪制任何內(nèi)容只是作為容器調(diào)用setWillNotDraw(true)可以跳過該View的onDraw調(diào)用優(yōu)化繪制流程。View的繪制緩存對(duì)于靜態(tài)或很少變化的內(nèi)容可以考慮使用View的繪圖緩存或Bitmap緩存但需權(quán)衡內(nèi)存開銷。在大多數(shù)現(xiàn)代優(yōu)化中顯示列表Display List的自動(dòng)緩存已足夠高效手動(dòng)緩存需謹(jǐn)慎評(píng)估。3.3 優(yōu)化渲染線程與GPU提升管道吞吐量當(dāng)UI線程不再是瓶頸后焦點(diǎn)應(yīng)轉(zhuǎn)向渲染線程和GPU。3.3.1 紋理管理與位圖優(yōu)化紋理上傳是渲染線程的主要阻塞源之一。尺寸適配加載的Bitmap尺寸絕不應(yīng)大于其顯示尺寸。使用BitmapFactory.Options的inSampleSize進(jìn)行下采樣或者使用Glide、Coil等圖片庫(kù)它們會(huì)自動(dòng)處理尺寸適配和緩存。格式選擇如果不需要透明度使用RGB_565格式代替ARGB_8888內(nèi)存占用減半上傳速度也更快。復(fù)用與緩存使用BitmapPool如Glide提供的或LruCache來復(fù)用Bitmap對(duì)象避免重復(fù)解碼和上傳。3.3.2 減少過度繪制這是提升GPU填充率效率的關(guān)鍵。移除不必要的背景很多View的默認(rèn)背景或?yàn)榱嗣烙^添加的漸變背景在最終UI中可能被完全覆蓋。移除這些背景能直接減少一層繪制。使用android:outlineSpotShadowColor和android:outlineAmbientShadowColor對(duì)于Android 5.0以上使用系統(tǒng)自帶的視圖輪廓陰影而非通過繪制疊加層來實(shí)現(xiàn)陰影效果效率更高。自定義View的優(yōu)化在自定義View的onDraw中先繪制大的、不透明的背景再繪制其他內(nèi)容。并利用canvas.quickReject()方法快速判斷繪制區(qū)域是否在臟區(qū)域之外及早跳出。3.3.3 理性使用硬件加速與圖層硬件加速現(xiàn)代Android默認(rèn)開啟。但對(duì)于極簡(jiǎn)單的UI或已知有兼容性問題的特定繪制操作某些Path效果可以嘗試在特定View上通過setLayerType(LAYER_TYPE_SOFTWARE, null)關(guān)閉硬件加速來對(duì)比性能。但這是一個(gè)特例通常硬件加速更快。View.setLayerType將View繪制到離屏緩沖圖層。這適用于制作動(dòng)畫如旋轉(zhuǎn)、縮放整個(gè)View因?yàn)樽儞Q只需應(yīng)用于圖層紋理無需重繪內(nèi)容。但創(chuàng)建和維護(hù)圖層有顯著開銷動(dòng)畫結(jié)束后應(yīng)立即通過setLayerType(LAYER_TYPE_NONE, null)釋放。濫用圖層如給靜態(tài)View設(shè)置會(huì)導(dǎo)致性能下降。3.4 高級(jí)策略與API應(yīng)用對(duì)于追求極致性能的應(yīng)用可以考慮以下方向。3.4.1 使用RenderNode與DisplayListCanvasAPI 29Android 10引入了更底層的RenderNodeAPI。它允許開發(fā)者直接構(gòu)建和更新顯示列表甚至可以在非UI線程上操作需謹(jǐn)慎同步。這對(duì)于需要極高頻更新如自定義圖表、繪圖應(yīng)用的場(chǎng)景有巨大潛力。通過RenderNode的beginRecording()獲取一個(gè)DisplayListCanvas記錄繪制命令最后endRecording()。更新時(shí)可以重用RenderNode只更新變換屬性避免重建整個(gè)顯示列表。3.4.2 擁抱Vulkan對(duì)于圖形密集型應(yīng)用如游戲Vulkan作為新一代底層圖形API相比OpenGL ES能提供更低的驅(qū)動(dòng)開銷和更好的多線程支持。Android NDK支持Vulkan開發(fā)。雖然門檻較高但它能讓你更直接地控制GPU釋放硬件全部潛力。對(duì)于普通應(yīng)用關(guān)注支持Vulkan的圖形庫(kù)如Filament是更可行的路徑。3.4.3 關(guān)注幀率與刷新率同步高刷新率屏幕90Hz, 120Hz已成為主流。應(yīng)用需要感知并適配。Window.setFrameRate()從Android 12開始你可以向系統(tǒng)建議你應(yīng)用的首選幀率。這有助于系統(tǒng)進(jìn)行更好的調(diào)度和節(jié)能。Choreographer通過Choreographer.getInstance().postFrameCallback監(jiān)聽垂直同步信號(hào)VSync在下一幀開始前執(zhí)行你的繪制邏輯可以使動(dòng)畫更平滑。一些高級(jí)動(dòng)畫庫(kù)如Lottie內(nèi)部就使用了此機(jī)制。4. 性能問題診斷與排查實(shí)錄即使遵循了所有最佳實(shí)踐復(fù)雜的應(yīng)用仍可能遇到詭異的性能問題。下面是我在實(shí)踐中總結(jié)的一些排查思路和常見“坑點(diǎn)”。4.1 典型問題場(chǎng)景與解決方案問題現(xiàn)象可能原因排查工具解決方案列表滾動(dòng)卡頓1.onBindViewHolder內(nèi)邏輯太重或創(chuàng)建對(duì)象。2. Item布局層級(jí)過深。3. 圖片加載未優(yōu)化。Systrace, Profiler, Layout Inspector1. 優(yōu)化數(shù)據(jù)綁定復(fù)用對(duì)象。2. 使用ConstraintLayout扁平化Item布局。3. 使用圖片庫(kù)并配置合適尺寸。啟動(dòng)后首屏渲染慢1. 首屏布局太復(fù)雜。2. 冷啟動(dòng)時(shí)加載資源如圖片、字體耗時(shí)。Systrace (關(guān)注應(yīng)用啟動(dòng)階段)1. 簡(jiǎn)化啟動(dòng)Activity布局或使用ViewStub延遲加載非關(guān)鍵部分。2. 預(yù)加載/異步加載資源使用PrecomputedText處理文本。執(zhí)行動(dòng)畫時(shí)卡頓1. 動(dòng)畫導(dǎo)致布局頻繁變化requestLayout。2. 動(dòng)畫View的onDraw復(fù)雜。3. 未使用硬件圖層。Systrace, GPU Inspector1. 使用View的屬性動(dòng)畫translationX,scaleX等它只影響繪制不觸發(fā)布局。2. 優(yōu)化onDraw。3. 對(duì)動(dòng)畫View使用setLayerType(LAYER_TYPE_HARDWARE, null)。靜態(tài)界面也偶爾掉幀1. 后臺(tái)有定時(shí)任務(wù)或消息導(dǎo)致UI線程工作。2. 內(nèi)存抖動(dòng)觸發(fā)GC。3. 其他應(yīng)用或系統(tǒng)服務(wù)占用CPU。Systrace (觀察整個(gè)系統(tǒng)), Profiler Memory View1. 檢查Handler、Timer等。2. 避免在循環(huán)或頻繁調(diào)用的方法中創(chuàng)建小對(duì)象。3. 排查是否為系統(tǒng)級(jí)問題嘗試重啟設(shè)備或更新系統(tǒng)。4.2 調(diào)試技巧與避坑指南Systrace的“魔法標(biāo)簽”在你的關(guān)鍵代碼段前后加上Trace.beginSection(MySection)和Trace.endSection()。這樣在Systrace報(bào)告中你就可以看到自己定義的代碼塊耗時(shí)精準(zhǔn)定位熱點(diǎn)。警惕“Invalidation Cascade”一個(gè)View調(diào)用invalidate()有時(shí)會(huì)導(dǎo)致其父視圖乃至整個(gè)視圖樹無效化。特別是當(dāng)View的邊界可能發(fā)生變化時(shí)調(diào)用了setLeft等會(huì)觸發(fā)requestLayout代價(jià)更高。優(yōu)化時(shí)要審視無效化的范圍是否必要。TextView的性能TextView的測(cè)量和繪制非常復(fù)雜尤其是包含富文本或自定義Span時(shí)。對(duì)于長(zhǎng)列表中的TextView考慮使用PrecomputedText異步計(jì)算文本布局或者對(duì)固定文本使用StaticLayout進(jìn)行緩存。內(nèi)存與性能的權(quán)衡有些優(yōu)化策略會(huì)消耗更多內(nèi)存例如緩存Bitmap或使用硬件圖層。需要在實(shí)際場(chǎng)景中 profiling找到平衡點(diǎn)。Profile GPU Rendering工具中的“綠色橫線”16ms標(biāo)記和“彩色條形圖”是快速判斷每幀負(fù)載的直觀方法。真機(jī)測(cè)試的重要性模擬器和低端真機(jī)的性能表現(xiàn)天差地別。性能測(cè)試和優(yōu)化必須在目標(biāo)用戶群體可能使用的低端設(shè)備上進(jìn)行才能發(fā)現(xiàn)真正的問題。