1. 從“卡頓”到“絲滑”為什么我們需要硬件加速如果你在Android開發(fā)或者日常使用中稍微留意一下就會發(fā)現(xiàn)一個有趣的現(xiàn)象同樣是滑動一個列表在幾年前的老舊手機(jī)上可能卡頓掉幀而在如今的設(shè)備上卻異常流暢。這背后除了CPU性能的飛躍一個至關(guān)重要的技術(shù)就是“硬件加速”。簡單來說硬件加速就是把原本由CPU負(fù)責(zé)的、繁重的圖形計算任務(wù)交給一個更專業(yè)的“打工人”——GPU圖形處理器去處理。為什么需要這么做你可以把CPU想象成一個博學(xué)但“雜活”很多的大學(xué)教授他既要處理邏輯運(yùn)算比如計算購物車總價又要負(fù)責(zé)內(nèi)存管理偶爾還得畫兩筆圖形渲染。而GPU則像是一個專門負(fù)責(zé)畫畫的藝術(shù)家他可能不擅長復(fù)雜的邏輯但在處理大量、重復(fù)的圖形繪制任務(wù)比如填充像素、變換頂點(diǎn)時效率是CPU的數(shù)十甚至上百倍。當(dāng)應(yīng)用界面需要頻繁重繪特別是涉及復(fù)雜動畫、陰影、圓角、濾鏡時如果全部讓CPU來“畫畫”它很快就會不堪重負(fù)導(dǎo)致界面渲染跟不上屏幕刷新通常是60Hz即16.67毫秒一幀用戶就會感知到卡頓、掉幀。Android系統(tǒng)從早期的版本就開始逐步引入和深化硬件加速。對于開發(fā)者而言理解硬件加速不僅僅是知道一個概念更是優(yōu)化應(yīng)用性能、解決UI卡頓問題的關(guān)鍵鑰匙。它決定了你的View是如何被繪制到屏幕上的為什么有些自定義View異常流暢而有些卻“吃”性能。接下來我們就深入這個“幕后英雄”的世界看看它是如何工作的以及我們?nèi)绾斡煤盟?. 核心架構(gòu)Android圖形系統(tǒng)的“三層樓”要理解硬件加速的實(shí)現(xiàn)我們必須先俯瞰整個Android圖形系統(tǒng)的架構(gòu)。你可以把它想象成一棟三層小樓每一層都有明確的職責(zé)分工數(shù)據(jù)自頂向下流動最終呈現(xiàn)在屏幕上。2.1 應(yīng)用層Skia與繪制命令的生成我們開發(fā)者最常打交道的是這一層。當(dāng)你在onDraw(Canvas)方法中調(diào)用canvas.drawCircle()、canvas.drawText()時你并不是直接在操作屏幕像素。你是在向一個“繪制命令列表”中添加指令。在Android中這個關(guān)鍵的圖形庫就是Skia。Skia是一個由Google維護(hù)的開源2D圖形庫它提供了豐富的API來繪制形狀、文字、圖像和路徑。在未開啟硬件加速的情況下軟件渲染模式Skia庫會使用CPU來光柵化這些繪制命令生成最終的位圖Bitmap。這個過程是同步的并且完全在CPU上完成效率較低。當(dāng)在應(yīng)用或View層級開啟硬件加速后故事就變了。此時Canvas對象背后關(guān)聯(lián)的不再是一個簡單的位圖緩沖區(qū)而是一個Display List顯示列表。你所有的drawXXX操作不再被立即執(zhí)行而是被記錄、轉(zhuǎn)換成一系列的繪制操作對象Op并存儲在這個Display List中。這就像從“邊讀菜譜邊炒菜”變成了“先把所有烹飪步驟寫好再交給大廚GPU批量處理”。這個轉(zhuǎn)換過程是由Skia的硬件加速后端如OpenGL或Vulkan完成的。2.2 系統(tǒng)層SurfaceFlinger與合成引擎Display List準(zhǔn)備好后就需要交給系統(tǒng)去管理和合成。這里的關(guān)鍵角色是SurfaceFlinger它是Android圖形系統(tǒng)的核心服務(wù)。每個窗口如Activity、Dialog、狀態(tài)欄在屏幕上都有一個對應(yīng)的Surface。你可以把Surface理解為一塊畫布。應(yīng)用層將自己的Display List提交給對應(yīng)的Surface。SurfaceFlinger的職責(zé)就是管理所有這些Surface并根據(jù)它們的Z-order層級順序、位置、透明度等信息決定如何將它們合成為最終的一幀圖像。在硬件加速架構(gòu)下每個Surface的內(nèi)容通常由應(yīng)用側(cè)的RenderThread渲染線程負(fù)責(zé)渲染。RenderThread會使用GPU通過OpenGL ES或Vulkan API來執(zhí)行Display List中的繪制命令將矢量指令光柵化結(jié)果直接存入一塊圖形緩沖區(qū)GraphicBuffer中。這塊緩沖區(qū)可以被GPU高效地讀寫。SurfaceFlinger則扮演合成器的角色。它獲取各個Surface已經(jīng)渲染好的GraphicBuffer通過GPU使用OpenGL ES或?qū)ｉT的硬件合成器如Overlay進(jìn)行疊加、混合等操作生成最終屏幕所需的幀數(shù)據(jù)。這個“合成”動作本身也是硬件加速的效率極高。2.3 驅(qū)動與硬件層GPU與顯示控制器這是最底層的一樓。GPU接收來自上層RenderThread或SurfaceFlinger通過圖形APIOpenGL ES/Vulkan發(fā)出的指令驅(qū)動其內(nèi)部的眾多核心并行執(zhí)行頂點(diǎn)著色、片段著色等計算完成真正的光柵化工作。生成的圖像數(shù)據(jù)被放入幀緩沖區(qū)Frame Buffer。最終顯示控制器Display Controller以固定的刷新率例如60Hz從幀緩沖區(qū)中讀取數(shù)據(jù)轉(zhuǎn)換為顯示器能識別的信號輸出到屏幕上形成我們看到的畫面。這三層架構(gòu)的精妙之處在于異步化和并行化。UI線程主線程只負(fù)責(zé)構(gòu)建和更新Display List輕量級操作繁重的渲染工作交給了獨(dú)立的RenderThread和GPU合成工作又交給了SurfaceFlinger和GPU。這使得UI線程能夠快速響應(yīng)交互避免因渲染任務(wù)繁重而阻塞從而保障了應(yīng)用的流暢性。3. 實(shí)現(xiàn)揭秘從View到像素的硬件加速流水線了解了宏觀架構(gòu)我們深入到單個View的繪制流程中看看硬件加速是如何具體介入的。3.1 構(gòu)建階段Display List的錄制當(dāng)View需要繪制時無論是否開啟硬件加速都會調(diào)用draw(Canvas)方法。關(guān)鍵在于傳入的Canvas是什么。軟件渲染Canvas背后是一個Bitmap或Picture繪制命令被立即執(zhí)行修改Bitmap的像素。硬件加速Canvas背后是一個DisplayListCanvas。它是一個“錄制器”。在硬件加速模式下View.draw(Canvas)的過程實(shí)際上是在“錄制”// 偽代碼示意 Override protected void onDraw(Canvas canvas) { // 在硬件加速下canvas是DisplayListCanvas canvas.save(); // 被記錄為一個SaveOp操作對象 canvas.clipRect(dirtyRect); // 被記錄為一個ClipRectOp canvas.drawCircle(centerX, centerY, radius, paint); // 被記錄為一個DrawCircleOp canvas.restore(); // 被記錄為一個RestoreOp // ... 沒有任何像素在此刻被改變 }所有這些save,clipRect,drawCircle調(diào)用都被轉(zhuǎn)換為對應(yīng)的RenderNode渲染節(jié)點(diǎn)中的操作對象Op。一個復(fù)雜的View層級結(jié)構(gòu)最終會對應(yīng)一棵由RenderNode構(gòu)成的樹每個RenderNode內(nèi)部包含了自己的Display List。這個階段的性能開銷很小因?yàn)樗粍?chuàng)建了一些輕量的Java對象來描述繪制操作而不是計算像素。3.2 渲染階段RenderThread與GPU執(zhí)行當(dāng)Display List構(gòu)建完成并且View樹發(fā)生了需要重繪的變更時例如調(diào)用了invalidate()系統(tǒng)不會立即重繪。它會安排一個Vsync垂直同步信號到來時再開始處理。在Vsync信號到來后UI線程執(zhí)行performTraversals()更新視圖層級和Display List。如果只是屬性動畫如平移、旋轉(zhuǎn)、透明度變化UI線程可能只更新RenderNode的屬性如平移矩陣而無需重新錄制Display List這稱為“屬性動畫硬件加速”效率極高。同步到渲染線程更新后的RenderNode樹信息被同步到獨(dú)立的RenderThread。RenderThread驅(qū)動GPURenderThread使用OpenGL ES或Vulkan API將Display List中的操作命令翻譯成GPU能理解的指令流。GPU并行執(zhí)行這些指令完成幾何變換、光柵化、紋理填充、混合等所有操作將最終結(jié)果輸出到當(dāng)前Surface的GraphicBuffer中。這個渲染過程是完全異步于UI線程的。UI線程在完成同步后就可以繼續(xù)處理下一個觸摸事件或動畫幀了不會等待渲染完成。3.3 合成與上屏SurfaceFlinger的舞臺每個窗口的Surface都有自己的GraphicBuffer。當(dāng)應(yīng)用渲染完一幀后它會通過eglSwapBuffers或Vulkan的類似機(jī)制將準(zhǔn)備好的緩沖區(qū)“提交”或“排隊(duì)”。SurfaceFlinger在下一個Vsync信號到來時被喚醒它收集所有已經(jīng)準(zhǔn)備好新幀的Surface。然后它使用GPU或?qū)Ｓ玫腛verlay硬件按照正確的Z-order將這些緩沖區(qū)合成到一起。例如一個半透明的Dialog需要覆蓋在Activity之上這個混合計算就由SurfaceFlinger來完成。最終合成的圖像被送入顯示控制器的幀緩沖區(qū)在下一個屏幕刷新周期顯示出來。注意過度繪制Overdraw問題在硬件加速下依然存在甚至可能更隱蔽。因?yàn)镚PU雖然擅長填充像素但過度繪制意味著GPU做了大量不必要的片段著色計算依然會浪費(fèi)功耗和性能。開發(fā)者工具中的“調(diào)試GPU過度繪制”功能就是幫助我們可視化并優(yōu)化這一問題。4. 開發(fā)者實(shí)踐啟用、控制與優(yōu)化硬件加速理解了原理我們來看看在開發(fā)中如何具體操作和優(yōu)化。4.1 如何啟用與配置硬件加速硬件加速在Android中通常是默認(rèn)開啟的但它是分層級的應(yīng)用級別在AndroidManifest.xml的application標(biāo)簽中設(shè)置。application android:hardwareAcceleratedtrue ...這是默認(rèn)值從Android 3.0/API 11開始。除非有特殊兼容性問題否則保持開啟。Activity級別在activity標(biāo)簽中單獨(dú)設(shè)置。activity android:hardwareAcceleratedfalse /你可能需要為某些使用了不兼容硬件加速的第三方庫或自定義View的Activity關(guān)閉它。Window級別在代碼中動態(tài)設(shè)置。getWindow().setFlags( WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED, WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED );View級別這是最細(xì)粒度的控制。myView.setLayerType(View.LAYER_TYPE_HARDWARE, null); // 強(qiáng)制此View使用硬件層 myView.setLayerType(View.LAYER_TYPE_SOFTWARE, null); // 強(qiáng)制此View使用軟件渲染 // LAYER_TYPE_NONE 表示遵循默認(rèn)設(shè)置4.2setLayerType的妙用與陷阱View.setLayerType是一個強(qiáng)大但需要慎用的工具。它告訴系統(tǒng)為此View分配一個離屏緩沖區(qū)FBO并將其渲染結(jié)果緩存為一張紋理。適用場景復(fù)雜動畫對一個包含復(fù)雜子View的ViewGroup如自定義控件做旋轉(zhuǎn)、縮放、透明度動畫時為其設(shè)置LAYER_TYPE_HARDWARE。這樣動畫期間View只需要被渲染一次到紋理上之后動畫只是對這張紋理進(jìn)行操作避免了每一幀都重新繪制所有子View性能提升巨大。組合效果需要應(yīng)用一些GPU支持而CPU不支持的高效效果時如setRotationX/Y3D旋轉(zhuǎn)或復(fù)雜的Camera變換。臨時提升繪制性能在已知某View需要頻繁重繪但內(nèi)容相對靜態(tài)時可以開啟硬件層緩存。需要避開的陷阱內(nèi)存與性能開銷創(chuàng)建硬件層需要分配額外的圖形內(nèi)存Texture這是一個不小的開銷。頻繁創(chuàng)建和銷毀硬件層例如在列表的每一項(xiàng)中都設(shè)置會導(dǎo)致嚴(yán)重的性能問題。不是“性能萬能藥”如果View的內(nèi)容每一幀都在劇烈變化例如不斷播放視頻或進(jìn)行粒子動畫那么緩存就失去了意義因?yàn)槊恳粠夹枰逻@個紋理反而增加了紋理上傳的開銷。此時使用硬件層可能比不用更差。及時關(guān)閉動畫結(jié)束后務(wù)必記得將layerType設(shè)置回LAYER_TYPE_NONE以釋放紋理資源。一個好的模式是在動畫開始前設(shè)置在動畫監(jiān)聽器的結(jié)束回調(diào)中清除。4.3 自定義View的硬件加速兼容性如果你編寫自定義View需要確保它在硬件加速下能正確工作。絕大多數(shù)Canvas操作在兩種模式下都兼容但存在一些已知的差異裁剪Clip操作硬件加速下對裁剪路徑clipPath的支持是有限的復(fù)雜路徑的裁剪可能被忽略或產(chǎn)生不精確的結(jié)果。通常建議避免在硬件加速下使用復(fù)雜的clipPath或者改用其他方式實(shí)現(xiàn)效果例如使用PorterDuffXfermode進(jìn)行混合但這也需謹(jǐn)慎測試。繪制文本文本測量和渲染在兩種模式下可能存在亞像素級的差異在極端追求像素級一致的場景下需要注意。Xfermode一些高級的PorterDuffXfermode混合模式在硬件加速下可能不被支持或行為不一致。SRC_IN,SRC_OVER,DST_OVER等基本模式通常沒問題但DST_IN,SRC_OUT等復(fù)雜模式需要測試。ShadowLayerPaint.setShadowLayer在硬件加速下效果很好但BlurMaskFilter用于繪制時在硬件加速下會被忽略。檢測與適配你可以在onDraw方法中通過Canvas.isHardwareAccelerated()來判斷當(dāng)前Canvas是否支持硬件加速從而采用不同的繪制策略。但更推薦的做法是讓你的繪制代碼在兩種模式下都能正確工作這通常意味著避免使用那些有差異的特性。4.4 性能分析與調(diào)試工具工欲善其事必先利其器。Android提供了強(qiáng)大的工具來分析和調(diào)試硬件加速相關(guān)的性能問題。開發(fā)者選項(xiàng) - 硬件加速渲染調(diào)試GPU過度繪制用不同顏色顯示屏幕上的過度繪制區(qū)域幫助你定位哪些區(qū)域被繪制了太多次。顯示硬件層更新當(dāng)View的硬件層Texture內(nèi)容更新時該View會閃爍紅色。這是檢查你是否在不必要地更新硬件層的絕佳工具。理想情況下只有動畫開始和結(jié)束時才看到紅色閃爍動畫過程中不應(yīng)閃爍。GPU渲染模式分析Profile HWUI render在屏幕上顯示柱狀圖直觀展示每一幀中各個階段的耗時如UI線程準(zhǔn)備、RenderThread同步、GPU執(zhí)行等幫助你定位是CPU瓶頸還是GPU瓶頸。Systrace這是性能分析的“核武器”。它可以捕捉到系統(tǒng)級別的詳細(xì)時序信息包括UI線程、RenderThread、GPU工作負(fù)載、SurfaceFlinger合成等。通過Systrace你可以清晰地看到一幀的生命周期找到掉幀的具體原因——是UI線程的onDraw太慢是RenderThread的渲染命令太復(fù)雜還是GPU負(fù)載過高Android Studio Profiler其中的CPU和GPU Profiler可以幫助你分析應(yīng)用層的性能熱點(diǎn)查看OpenGL ES調(diào)用等。5. 常見問題與深度優(yōu)化策略在實(shí)際項(xiàng)目中僅僅開啟硬件加速并不總能保證流暢。下面是一些典型問題和進(jìn)階優(yōu)化思路。5.1 內(nèi)存抖動與Display List失效硬件加速的優(yōu)勢在于復(fù)用Display List。但如果你的View在每一幀的onDraw中都創(chuàng)建新的Paint、Path或Bitmap對象會導(dǎo)致大量對象分配和GC引發(fā)內(nèi)存抖動。更嚴(yán)重的是這可能導(dǎo)致RenderNode的Display List無法被有效復(fù)用因?yàn)槠鋬?nèi)部狀態(tài)如Paint屬性一直在變從而觸發(fā)完整的Display List重建和GPU紋理更新嚴(yán)重消耗性能。優(yōu)化策略重用對象將Paint、Path、Matrix等對象作為成員變量初始化在onDraw中只修改其屬性而非重新創(chuàng)建。減少無效區(qū)域精準(zhǔn)調(diào)用invalidate(Rect)而不是無參數(shù)的invalidate()以最小化需要重繪的區(qū)域。使用ViewPropertyAnimator對于屬性動畫優(yōu)先使用View.animate()它直接操作RenderNode的屬性完全避免了onDraw調(diào)用效率最高。5.2 紋理上傳瓶頸當(dāng)Bitmap內(nèi)容發(fā)生變化例如從網(wǎng)絡(luò)加載圖片后設(shè)置給ImageView或者一個硬件層Texture的內(nèi)容需要更新時需要將新的像素數(shù)據(jù)從CPU內(nèi)存上傳到GPU顯存中這個過程稱為紋理上傳。這是一個相對耗時的操作如果在一幀內(nèi)上傳多張大紋理很可能導(dǎo)致掉幀。優(yōu)化策略預(yù)加載與緩存對于已知的圖片資源提前解碼并緩存Bitmap。使用BitmapFactory.Options.inBitmap復(fù)用內(nèi)存減少分配和上傳。控制圖片尺寸確保加載到內(nèi)存的Bitmap尺寸與其顯示的View大小匹配不要加載一張2048x2048的圖只顯示在100x100的ImageView里。可以使用inSampleSize進(jìn)行下采樣。異步加載圖片加載務(wù)必放在后臺線程如使用Glide、Coil等庫避免在UI線程進(jìn)行解碼和上傳。合并更新對于頻繁變化的自定義View如果可能嘗試將多次小的內(nèi)容更新累積起來一次性上傳到紋理。5.3 過度繪制與圖層管理即使GPU很強(qiáng)繪制看不見的像素也是純粹的浪費(fèi)。過度繪制在復(fù)雜UI中非常常見。硬件加速下的過度繪制消耗的是GPU的片段著色器性能Fill Rate。優(yōu)化策略移除不必要的背景很多布局和View的默認(rèn)背景是不需要的將其設(shè)置為null。使用canvas.clipRect()在自定義View的onDraw中在繪制子元素前通過clipRect限制繪制區(qū)域避免繪制到視圖邊界之外。扁平化視圖層級過深的View樹會增加遍歷和Display List構(gòu)建的開銷。使用ConstraintLayout可以有效減少嵌套。理性使用硬件層如前所述不要濫用setLayerType。只在動畫期間為復(fù)雜靜態(tài)視圖開啟并及時關(guān)閉。5.4 低端設(shè)備與兼容性處理在老舊或低端設(shè)備上GPU可能非常弱甚至不支持某些OpenGL ES擴(kuò)展。在這些設(shè)備上不當(dāng)?shù)挠布铀偈褂梅炊鴷蔀樾阅軞⑹帧?shí)踐建議進(jìn)行差異化配置可以考慮為低端設(shè)備通過API等級、內(nèi)存大小或特定屬性判斷在application級別關(guān)閉硬件加速或者關(guān)閉某些特別耗GPU的特性如實(shí)時模糊、復(fù)雜陰影。降級方案對于使用了硬件加速特定效果如setRotationY的界面準(zhǔn)備一個簡單的軟件渲染降級方案在檢測到性能不佳時啟用。嚴(yán)格測試務(wù)必在真實(shí)低端設(shè)備上進(jìn)行性能測試使用“GPU渲染模式分析”工具觀察幀時間確保核心場景流暢。硬件加速是現(xiàn)代Android流暢體驗(yàn)的基石但它并非一個簡單的開關(guān)。深入理解其原理、工作流程和潛在陷阱才能寫出真正高性能的UI代碼。它要求開發(fā)者在享受GPU帶來的并行計算紅利的同時也必須關(guān)注內(nèi)存、紋理、繪制命令的合理管理。從構(gòu)建高效的Display List到明智地使用硬件層再到利用專業(yè)工具進(jìn)行性能剖析每一步都是通往“絲滑”應(yīng)用的必經(jīng)之路。記住最好的優(yōu)化往往來自于對底層機(jī)制的理解以及對數(shù)據(jù)流動的敬畏。