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