Android硬件加速原理與實現(xiàn)簡介
在手機客戶端尤其是Android應(yīng)用的開發(fā)過程中，我們經(jīng)常會接觸到“硬件加速”這個詞。由于操作系統(tǒng)對底層軟硬件封裝非常完善，上層軟件開發(fā)者往往對硬件加速的底層原理了解很少，也不清楚了解底層原理的意義，因此常會有一些誤解，如硬件加速是不是通過特殊算法實現(xiàn)頁面渲染加速，或是通過硬件提高CPU/GPU運算速率實現(xiàn)渲染加速。
本文嘗試從底層硬件原理，一直到上層代碼實現(xiàn)，對硬件加速技術(shù)進行簡單介紹，其中上層實現(xiàn)基于Android 6.0。
了解硬件加速對App開發(fā)的意義
對于App開發(fā)者，簡單了解硬件加速原理及上層API實現(xiàn)，開發(fā)時就可以充分利用硬件加速提高頁面的性能。以Android舉例，實現(xiàn)一個圓角矩形按鈕通常有兩種方案：使用PNG圖片;使用代碼(XML/Java)實現(xiàn)。簡單對比兩種方案如下。
頁面渲染背景知識
- 頁面渲染時，被繪制的元素最終要轉(zhuǎn)換成矩陣像素點(即多維數(shù)組形式，類似安卓中的Bitmap)，才能被顯示器顯示。
- 頁面由各種基本元素組成，例如圓形、圓角矩形、線段、文字、矢量圖(常用貝塞爾曲線組成)、Bitmap等。
- 元素繪制時尤其是動畫繪制過程中，經(jīng)常涉及插值、縮放、旋轉(zhuǎn)、透明度變化、動畫過渡、毛玻璃模糊，甚至包括3D變換、物理運動(例如游戲中常見的拋物線運動)、多媒體文件解碼(主要在桌面機中有應(yīng)用，移動設(shè)備一般不用GPU做解碼)等運算。
- 繪制過程經(jīng)常需要進行邏輯較簡單、但數(shù)據(jù)量龐大的浮點運算。
CPU與GPU結(jié)構(gòu)對比
CPU(Central Processing Unit，中央處理器)是計算機設(shè)備核心器件，用于執(zhí)行程序代碼，軟件開發(fā)者對此都很熟悉;GPU(Graphics Processing Unit，圖形處理器)主要用于處理圖形運算，通常所說“顯卡”的核心部件就是GPU。
下面是CPU和GPU的結(jié)構(gòu)對比圖。其中：
- 黃色的Control為控制器，用于協(xié)調(diào)控制整個CPU的運行，包括取出指令、控制其他模塊的運行等;
- 綠色的ALU(Arithmetic Logic Unit)是算術(shù)邏輯單元，用于進行數(shù)學、邏輯運算;
- 橙色的Cache和DRAM分別為緩存和RAM，用于存儲信息。
- 從結(jié)構(gòu)圖可以看出，CPU的控制器較為復雜，而ALU數(shù)量較少。因此CPU擅長各種復雜的邏輯運算，但不擅長數(shù)學尤其是浮點運算。
- 以8086為例，一百多條匯編指令大部分都是邏輯指令，數(shù)學計算相關(guān)的主要是16位加減乘除和移位運算。一次整型和邏輯運算一般需要1~3個機器周期，而浮點運算要轉(zhuǎn)換成整數(shù)計算，一次運算可能消耗上百個機器周期。
- 更簡單的CPU甚至只有加法指令，減法用補碼加法實現(xiàn)，乘法用累加實現(xiàn)，除法用減法循環(huán)實現(xiàn)。
- 現(xiàn)代CPU一般都帶有硬件浮點運算器(FPU)，但主要適用于數(shù)據(jù)量不大的情況。
- CPU是串行結(jié)構(gòu)。以計算100個數(shù)字為例，對于CPU的一個核，每次只能計算兩個數(shù)的和，結(jié)果逐步累加。
- 和CPU不同的是，GPU就是為實現(xiàn)大量數(shù)學運算設(shè)計的。從結(jié)構(gòu)圖中可以看到，GPU的控制器比較簡單，但包含了大量ALU。GPU中的ALU使用了并行設(shè)計，且具有較多浮點運算單元。
- 硬件加速的主要原理，就是通過底層軟件代碼，將CPU不擅長的圖形計算轉(zhuǎn)換成GPU專用指令，由GPU完成。
擴展：很多計算機中的GPU有自己獨立的顯存;沒有獨立顯存則使用共享內(nèi)存的形式，從內(nèi)存中劃分一塊區(qū)域作為顯存。顯存可以保存GPU指令等信息。
并行結(jié)構(gòu)舉例：級聯(lián)加法器
為了方便理解，這里先從底層電路結(jié)構(gòu)的角度舉一個例子。如下圖為一個加法器，對應(yīng)實際的數(shù)字電路結(jié)構(gòu)。
- A、B為輸入，C為輸出，且A、B、C均為總線，以32位CPU為例，則每根總線實際由32根導線組成，每根導線用不同的電壓表示一個二進制的0或1。
- Clock為時鐘信號線，每個固定的時鐘周期可向其輸入一個特定的電壓信號，每當一個時鐘信號到來時，A和B的和就會輸出到C。
現(xiàn)在我們要計算8個整數(shù)的和。
對于CPU這種串行結(jié)構(gòu)，代碼編寫很簡單，用for循環(huán)把所有數(shù)字逐個相加即可。串行結(jié)構(gòu)只有一個加法器，需要7次求和運算;每次計算完部分和，還要將其再轉(zhuǎn)移到加法器的輸入端，做下一次計算。整個過程至少要消耗十幾個機器周期。
而對于并行結(jié)構(gòu)，一種常見的設(shè)計是級聯(lián)加法器，如下圖，其中所有的clock連在一起。當需要相加的8個數(shù)據(jù)在輸入端A1~B4準備好后，經(jīng)過三個時鐘周期，求和操作就完成了。如果數(shù)據(jù)量更大、級聯(lián)的層級更大，則并行結(jié)構(gòu)的優(yōu)勢更明顯。
由于電路的限制，不容易通過提高時鐘頻率、減小時鐘周期的方式提高運算速度。并行結(jié)構(gòu)通過增加電路規(guī)模、并行處理，來實現(xiàn)更快的運算。但并行結(jié)構(gòu)不容易實現(xiàn)復雜邏輯，因為同時考慮多個支路的輸出結(jié)果，并協(xié)調(diào)同步處理的過程很復雜(有點像多線程編程)。
GPU并行計算舉例
假設(shè)我們有如下圖像處理任務(wù)，給每個像素值加1。GPU并行計算的方式簡單粗暴，在資源允許的情況下，可以為每個像素開一個GPU線程，由其進行加1操作。數(shù)學運算量越大，這種并行方式性能優(yōu)勢越明顯。
Android中的硬件加速
在Android中，大多數(shù)應(yīng)用的界面都是利用常規(guī)的View來構(gòu)建的(除了游戲、視頻、圖像等應(yīng)用可能直接使用OpenGL ES)。下面根據(jù)Android 6.0原生系統(tǒng)的Java層代碼，對View的軟件和硬件加速渲染做一些分析和對比。
DisplayList
DisplayList是一個基本繪制元素，包含元素原始屬性(位置、尺寸、角度、透明度等)，對應(yīng)Canvas的drawXxx()方法(如下圖)。
信息傳遞流程：Canvas(Java API) —> OpenGL(C/C++ Lib) —> 驅(qū)動程序 —> GPU。
在Android 4.1及以上版本，DisplayList支持屬性，如果View的一些屬性發(fā)生變化(比如Scale、Alpha、Translate)，只需把屬性更新給GPU，不需要生成新的DisplayList。
RenderNode
一個RenderNode包含若干個DisplayList，通常一個RenderNode對應(yīng)一個View，包含View自身及其子View的所有DisplayList。
Android繪制流程(Android 6.0)
下面是安卓View完整的繪制流程圖，主要通過閱讀源碼和調(diào)試得出，虛線箭頭表示遞歸調(diào)用。
- 從ViewRootImpl.performTraversals到PhoneWindow.DecroView.drawChild是每次遍歷View樹的固定流程，首先根據(jù)標志位判斷是否需要重新布局并執(zhí)行布局;然后進行Canvas的創(chuàng)建等操作開始繪制。
- 如果硬件加速不支持或者被關(guān)閉，則使用軟件繪制，生成的Canvas即Canvas.class的對象;
- 如果支持硬件加速，則生成的是DisplayListCanvas.class的對象;
- 兩者的isHardwareAccelerated()方法返回的值分別為false、true，View根據(jù)這個值判斷是否使用硬件加速。
- View中的draw(canvas,parent,drawingTime) - draw(canvas) - onDraw - dispachDraw - drawChild這條遞歸路徑(下文簡稱Draw路徑)，調(diào)用了Canvas.drawXxx()方法，在軟件渲染時用于實際繪制;在硬件加速時，用于構(gòu)建DisplayList。
- View中的updateDisplayListIfDirty - dispatchGetDisplayList - recreateChildDisplayList這條遞歸路徑(下文簡稱DisplayList路徑)，僅在硬件加速時會經(jīng)過，用于在遍歷View樹繪制的過程中更新DisplayList屬性，并快速跳過不需要重建DisplayList的View。
Android 6.0中，和DisplayList相關(guān)的API目前仍被標記為“@hide”不可訪問，表示還不成熟，后續(xù)版本可能開放。
- 硬件加速情況下，draw流程執(zhí)行結(jié)束后DisplayList構(gòu)建完成，然后通過ThreadedRenderer.nSyncAndDrawFrame()利用GPU繪制DisplayList到屏幕上。
純軟件繪制 VS 硬件加速(Android 6.0)
下面根據(jù)具體的幾種場景，具體分析一下硬件加速前后的流程與加速效果。
- 場景1中，無論是否加速，遍歷View樹并都會走Draw路徑。硬件加速后Draw路徑不做實際繪制工作，只是構(gòu)建DisplayList，復雜的繪制計算任務(wù)被GPU分擔，已經(jīng)有了較大的加速效果。
- 場景2中，TextView設(shè)置前后尺寸位置不變，不會觸發(fā)重新Layout。
- 軟件繪制時，TextView所在區(qū)域即為臟區(qū)。由于TextView有透明區(qū)域，遍歷View樹的過程中，和臟區(qū)重疊的多數(shù)View都要重繪，包括與之重疊的兄弟節(jié)點和他們的父節(jié)點(詳見后面的介紹)，不需要繪制的View在draw(canvas,parent,drawingTime)方法中判斷直接返回。
- 硬件加速后，也需要遍歷View樹，但只有TextView及其每一層父節(jié)點需要重建DisplayList，走的是Draw路徑，其他View直接走了DisplayList路徑，剩下的工作都交給GPU處理。頁面越復雜，兩者性能差距越明顯。
- 場景3中，軟件繪制每一幀都要做大量繪制工作，很容易導致動畫卡頓。硬件加速后，動畫過程直接走DisplayList路徑更新DisplayList的屬性，動畫流暢度能得到極大提高。
- 場景4中，兩者的性能差距更明顯。簡單修改透明度，軟件繪制仍然要做很多工作;硬件加速后一般直接更新RenderNode的屬性，不需要觸發(fā)invalidate，也不會遍歷View樹(除了少數(shù)View可能要對Alpha做特殊響應(yīng)并在onSetAlpha()返回true，代碼如下)。
- public class View { // ...
- public void setAlpha(@FloatRange(from=0.0, to=1.0) float alpha) {
- ensureTransformationInfo(); if (mTransformationInfo.mAlpha != alpha) {
- mTransformationInfo.mAlpha = alpha; if (onSetAlpha((int) (alpha * 255))) { // ...
- invalidate(true);
- } else { // ...
- mRenderNode.setAlpha(getFinalAlpha()); // ...
- }
- }
- } protected boolean onSetAlpha(int alpha) { return false;
- } // ...}
軟件繪制刷新邏輯簡介
實際閱讀源碼并實驗，得出通常情況下的軟件繪制刷新邏輯：
- 默認情況下，View的clipChildren屬性為true，即每個View繪制區(qū)域不能超出其父View的范圍。如果設(shè)置一個頁面根布局的clipChildren屬性為false，則子View可以超出父View的繪制區(qū)域。
- 當一個View觸發(fā)invalidate，且沒有播放動畫、沒有觸發(fā)layout的情況下：
- clipChildren為true時，臟區(qū)會被轉(zhuǎn)換成ViewRoot中的Rect，刷新時層層向下判斷，當View與臟區(qū)有重疊則重繪。如果一個View超出父View范圍且與臟區(qū)重疊，但其父View不與臟區(qū)重疊，這個子View不會重繪。
- clipChildren為false時，ViewGroup.invalidateChildInParent()中會把臟區(qū)擴大到自身整個區(qū)域，于是與這個區(qū)域重疊的所有View都會重繪。
- 對于全不透明的View，其自身會設(shè)置標志位PFLAG_DIRTY，其父View會設(shè)置標志位PFLAG_DIRTY_OPAQUE。在draw(canvas)方法中，只有這個View自身重繪。
- 對于可能有透明區(qū)域的View，其自身和父View都會設(shè)置標志位PFLAG_DIRTY。
總結(jié)
至此，硬件加速相關(guān)的內(nèi)容就介紹完了，這里做個簡單總結(jié)：
- CPU更擅長復雜邏輯控制，而GPU得益于大量ALU和并行結(jié)構(gòu)設(shè)計，更擅長數(shù)學運算。
- 頁面由各種基礎(chǔ)元素(DisplayList)構(gòu)成，渲染時需要進行大量浮點運算。
- 硬件加速條件下，CPU用于控制復雜繪制邏輯、構(gòu)建或更新DisplayList;GPU用于完成圖形計算、渲染DisplayList。
- 硬件加速條件下，刷新界面尤其是播放動畫時，CPU只重建或更新必要的DisplayList，進一步提高渲染效率。
- 實現(xiàn)同樣效果，應(yīng)盡量使用更簡單的DisplayList，從而達到更好的性能(Shape代替Bitmap等)。
參考資料與擴展閱讀
