轉載：http://tech.meituan.com/hardware-accelerate.html
在手機客戶端尤其是Android應用的開發(fā)過程中慎冤，我們經(jīng)常會接觸到“硬件加速”這個詞。由于操作系統(tǒng)對底層軟硬件封裝非常完善沧卢，上層軟件開發(fā)者往往對硬件加速的底層原理了解很少蚁堤，也不清楚了解底層原理的意義，因此常會有一些誤解但狭，如硬件加速是不是通過特殊算法實現(xiàn)頁面渲染加速披诗，或是通過硬件提高CPU/GPU運算速率實現(xiàn)渲染加速。
本文嘗試從底層硬件原理立磁，一直到上層代碼實現(xiàn)呈队，對硬件加速技術進行簡單介紹，其中上層實現(xiàn)基于Android 6.0息罗。
了解硬件加速對App開發(fā)的意義
對于App開發(fā)者掂咒，簡單了解硬件加速原理及上層API實現(xiàn)才沧，開發(fā)時就可以充分利用硬件加速提高頁面的性能迈喉。以Android舉例，實現(xiàn)一個圓角矩形按鈕通常有兩種方案：使用PNG圖片温圆；使用代碼（XML/Java）實現(xiàn)挨摸。簡單對比兩種方案如下。
方案原理特點
使用PNG圖片（BitmapDrawable）解碼PNG圖片生成Bitmap岁歉，傳到底層得运，由GPU渲染圖片解碼消耗CPU運算資源膝蜈，Bitmap占用內存大，繪制慢
使用XML或Java代碼實現(xiàn)（ShapeDrawable）直接將Shape信息傳到底層熔掺，由GPU渲染消耗CPU資源少饱搏，占用內存小，繪制快
頁面渲染背景知識
頁面渲染時置逻，被繪制的元素最終要轉換成矩陣像素點（即多維數(shù)組形式推沸，類似安卓中的Bitmap），才能被顯示器顯示券坞。
頁面由各種基本元素組成鬓催，例如圓形、圓角矩形恨锚、線段宇驾、文字、矢量圖（常用貝塞爾曲線組成）猴伶、Bitmap等课舍。
元素繪制時尤其是動畫繪制過程中，經(jīng)常涉及插值他挎、縮放布卡、旋轉、透明度變化雇盖、動畫過渡忿等、毛玻璃模糊，甚至包括3D變換崔挖、物理運動（例如游戲中常見的拋物線運動）贸街、多媒體文件解碼（主要在桌面機中有應用，移動設備一般不用GPU做解碼）等運算狸相。
繪制過程經(jīng)常需要進行邏輯較簡單薛匪、但數(shù)據(jù)量龐大的浮點運算。
CPU與GPU結構對比
CPU（Central Processing Unit脓鹃，中央處理器）是計算機設備核心器件逸尖，用于執(zhí)行程序代碼，軟件開發(fā)者對此都很熟悉瘸右；GPU（Graphics Processing Unit娇跟，圖形處理器）主要用于處理圖形運算，通常所說“顯卡”的核心部件就是GPU太颤。
下面是CPU和GPU的結構對比圖苞俘。其中：
黃色的Control為控制器，用于協(xié)調控制整個CPU的運行龄章，包括取出指令吃谣、控制其他模塊的運行等乞封；
綠色的ALU（Arithmetic Logic Unit）是算術邏輯單元惧浴，用于進行數(shù)學爽锥、邏輯運算；
橙色的Cache和DRAM分別為緩存和RAM欢策，用于存儲信息仔戈。
從結構圖可以看出陷揪，CPU的控制器較為復雜，而ALU數(shù)量較少杂穷。因此CPU擅長各種復雜的邏輯運算悍缠，但不擅長數(shù)學尤其是浮點運算。
以8086為例耐量，一百多條匯編指令大部分都是邏輯指令飞蚓，數(shù)學計算相關的主要是16位加減乘除和移位運算。一次整型和邏輯運算一般需要1~3個機器周期廊蜒，而浮點運算要轉換成整數(shù)計算趴拧，一次運算可能消耗上百個機器周期。
更簡單的CPU甚至只有加法指令山叮，減法用補碼加法實現(xiàn)著榴，乘法用累加實現(xiàn)，除法用減法循環(huán)實現(xiàn)屁倔。
現(xiàn)代CPU一般都帶有硬件浮點運算器（FPU）脑又，但主要適用于數(shù)據(jù)量不大的情況。
CPU是串行結構锐借。以計算100個數(shù)字為例问麸，對于CPU的一個核，每次只能計算兩個數(shù)的和钞翔，結果逐步累加严卖。
和CPU不同的是，GPU就是為實現(xiàn)大量數(shù)學運算設計的布轿。從結構圖中可以看到哮笆，GPU的控制器比較簡單，但包含了大量ALU汰扭。GPU中的ALU使用了并行設計稠肘，且具有較多浮點運算單元。
硬件加速的主要原理东且，就是通過底層軟件代碼启具，將CPU不擅長的圖形計算轉換成GPU專用指令本讥，由GPU完成珊泳。
擴展：很多計算機中的GPU有自己獨立的顯存鲁冯；沒有獨立顯存則使用共享內存的形式，從內存中劃分一塊區(qū)域作為顯存色查。顯存可以保存GPU指令等信息薯演。
并行結構舉例：級聯(lián)加法器
為了方便理解，這里先從底層電路結構的角度舉一個例子秧了。如下圖為一個加法器跨扮，對應實際的數(shù)字電路結構。
A验毡、B為輸入衡创，C為輸出，且A晶通、B璃氢、C均為總線，以32位CPU為例狮辽，則每根總線實際由32根導線組成一也，每根導線用不同的電壓表示一個二進制的0或1。
Clock為時鐘信號線喉脖，每個固定的時鐘周期可向其輸入一個特定的電壓信號椰苟，每當一個時鐘信號到來時，A和B的和就會輸出到C树叽。
現(xiàn)在我們要計算8個整數(shù)的和舆蝴。
對于CPU這種串行結構，代碼編寫很簡單题诵，用for循環(huán)把所有數(shù)字逐個相加即可须误。串行結構只有一個加法器，需要7次求和運算仇轻；每次計算完部分和京痢，還要將其再轉移到加法器的輸入端，做下一次計算篷店。整個過程至少要消耗十幾個機器周期祭椰。
而對于并行結構，一種常見的設計是級聯(lián)加法器疲陕，如下圖方淤，其中所有的clock連在一起。當需要相加的8個數(shù)據(jù)在輸入端A1~B4準備好后蹄殃，經(jīng)過三個時鐘周期携茂，求和操作就完成了。如果數(shù)據(jù)量更大诅岩、級聯(lián)的層級更大讳苦，則并行結構的優(yōu)勢更明顯带膜。
由于電路的限制，不容易通過提高時鐘頻率鸳谜、減小時鐘周期的方式提高運算速度膝藕。并行結構通過增加電路規(guī)模、并行處理咐扭，來實現(xiàn)更快的運算芭挽。但并行結構不容易實現(xiàn)復雜邏輯，因為同時考慮多個支路的輸出結果蝗肪，并協(xié)調同步處理的過程很復雜（有點像多線程編程）袜爪。
GPU并行計算舉例
假設我們有如下圖像處理任務，給每個像素值加1薛闪。GPU并行計算的方式簡單粗暴饿敲，在資源允許的情況下，可以為每個像素開一個GPU線程逛绵，由其進行加1操作怀各。數(shù)學運算量越大，這種并行方式性能優(yōu)勢越明顯术浪。
Android中的硬件加速
在Android中瓢对，大多數(shù)應用的界面都是利用常規(guī)的View來構建的（除了游戲、視頻胰苏、圖像等應用可能直接使用OpenGL ES）硕蛹。下面根據(jù)Android 6.0原生系統(tǒng)的Java層代碼，對View的軟件和硬件加速渲染做一些分析和對比硕并。
DisplayList
DisplayList是一個基本繪制元素法焰，包含元素原始屬性（位置、尺寸倔毙、角度埃仪、透明度等），對應Canvas的drawXxx()方法（如下圖）陕赃。
信息傳遞流程：Canvas(Java API) —> OpenGL(C/C++ Lib) —> 驅動程序 —> GPU卵蛉。
在Android 4.1及以上版本，DisplayList支持屬性么库，如果View的一些屬性發(fā)生變化（比如Scale傻丝、Alpha、Translate）诉儒，只需把屬性更新給GPU葡缰，不需要生成新的DisplayList。
RenderNode
一個RenderNode包含若干個DisplayList，通常一個RenderNode對應一個View泛释，包含View自身及其子View的所有DisplayList滤愕。
Android繪制流程（Android 6.0）
下面是安卓View完整的繪制流程圖，主要通過閱讀源碼和調試得出胁澳，虛線箭頭表示遞歸調用该互。
從ViewRootImpl.performTraversals到PhoneWindow.DecroView.drawChild是每次遍歷View樹的固定流程米者，首先根據(jù)標志位判斷是否需要重新布局并執(zhí)行布局韭畸；然后進行Canvas的創(chuàng)建等操作開始繪制。
如果硬件加速不支持或者被關閉蔓搞，則使用軟件繪制胰丁，生成的Canvas即Canvas.class的對象；
如果支持硬件加速喂分，則生成的是DisplayListCanvas.class的對象锦庸；
兩者的isHardwareAccelerated()方法返回的值分別為false、true蒲祈，View根據(jù)這個值判斷是否使用硬件加速甘萧。
View中的draw(canvas,parent,drawingTime)-draw(canvas)-onDraw-dispachDraw-drawChild這條遞歸路徑（下文簡稱Draw路徑），調用了Canvas.drawXxx()方法梆掸，在軟件渲染時用于實際繪制扬卷；在硬件加速時，用于構建DisplayList酸钦。
View中的updateDisplayListIfDirty-dispatchGetDisplayList-recreateChildDisplayList這條遞歸路徑（下文簡稱DisplayList路徑）怪得，僅在硬件加速時會經(jīng)過，用于在遍歷View樹繪制的過程中更新DisplayList屬性卑硫，并快速跳過不需要重建DisplayList的View徒恋。
Android 6.0中，和DisplayList相關的API目前仍被標記為“@hide”不可訪問欢伏，表示還不成熟入挣，后續(xù)版本可能開放。
硬件加速情況下硝拧，draw流程執(zhí)行結束后DisplayList構建完成财岔，然后通過ThreadedRenderer.nSyncAndDrawFrame()利用GPU繪制DisplayList到屏幕上。
純軟件繪制 VS 硬件加速（Android 6.0）
下面根據(jù)具體的幾種場景河爹，具體分析一下硬件加速前后的流程與加速效果匠璧。
渲染場景純軟件繪制硬件加速加速效果分析
頁面初始化繪制所有View創(chuàng)建所有DisplayListGPU分擔了復雜計算任務
在一個復雜頁面調用背景透明TextView的setText()，且調用后其尺寸位置不變重繪臟區(qū)所有ViewTextView及每一級父View重建DisplayList重疊的兄弟節(jié)點不需CPU重繪咸这，GPU會自行處理
TextView逐幀播放Alpha / Translation / Scale動畫每幀都要重繪臟區(qū)所有View除第一幀同場景2夷恍，之后每幀只更新TextView對應RenderNode的屬性刷新一幀性能極大提高，動畫流暢度提高
修改TextView透明度重繪臟區(qū)所有View直接調用RenderNode.setAlpha()更新加速前需全頁面遍歷，并重繪很多View酿雪；加速后只觸發(fā)DecorView.updateDisplayListIfDirty遏暴，不再往下遍歷，CPU執(zhí)行時間可忽略不計
場景1中指黎，無論是否加速朋凉，遍歷View樹并都會走Draw路徑。硬件加速后Draw路徑不做實際繪制工作醋安，只是構建DisplayList杂彭，復雜的繪制計算任務被GPU分擔，已經(jīng)有了較大的加速效果吓揪。
場景2中亲怠，TextView設置前后尺寸位置不變，不會觸發(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做特殊響應并在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;? ? }// ...}
軟件繪制刷新邏輯簡介
實際閱讀源碼并實驗，得出通常情況下的軟件繪制刷新邏輯：
默認情況下枕磁，View的clipChildren屬性為true渡蜻，即每個View繪制區(qū)域不能超出其父View的范圍。如果設置一個頁面根布局的clipChildren屬性為false计济，則子View可以超出父View的繪制區(qū)域茸苇。
當一個View觸發(fā)invalidate，且沒有播放動畫峭咒、沒有觸發(fā)layout的情況下：
對于全不透明的View税弃，其自身會設置標志位PFLAG_DIRTY纪岁，其父View會設置標志位PFLAG_DIRTY_OPAQUE凑队。在draw(canvas)方法中，只有這個View自身重繪幔翰。
對于可能有透明區(qū)域的View漩氨，其自身和父View都會設置標志位PFLAG_DIRTY。
clipChildren為true時遗增，臟區(qū)會被轉換成ViewRoot中的Rect叫惊，刷新時層層向下判斷，當View與臟區(qū)有重疊則重繪做修。如果一個View超出父View范圍且與臟區(qū)重疊霍狰，但其父View不與臟區(qū)重疊，這個子View不會重繪饰及。
clipChildren為false時蔗坯，ViewGroup.invalidateChildInParent()中會把臟區(qū)擴大到自身整個區(qū)域，于是與這個區(qū)域重疊的所有View都會重繪燎含。
總結
至此宾濒，硬件加速相關的內容就介紹完了，這里做個簡單總結：
CPU更擅長復雜邏輯控制屏箍，而GPU得益于大量ALU和并行結構設計绘梦，更擅長數(shù)學運算。
頁面由各種基礎元素（DisplayList）構成赴魁，渲染時需要進行大量浮點運算卸奉。
硬件加速條件下，CPU用于控制復雜繪制邏輯颖御、構建或更新DisplayList榄棵；GPU用于完成圖形計算、渲染DisplayList。
硬件加速條件下秉继，刷新界面尤其是播放動畫時祈噪，CPU只重建或更新必要的DisplayList，進一步提高渲染效率尚辑。
實現(xiàn)同樣效果辑鲤，應盡量使用更簡單的DisplayList，從而達到更好的性能（Shape代替Bitmap等）杠茬。
參考資料與擴展閱讀
什么是異構多處理系統(tǒng)月褥，為什么需要異構多處理系統(tǒng)
Android應用程序UI硬件加速渲染的Display List構建過程分析
