在手機客戶端尤其是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)。簡單對比兩種方案如下。
| 方案 | 原理 | 特點 |
|---|---|---|
| 使用PNG圖片(BitmapDrawable) | 解碼PNG圖片生成Bitmap,傳到底層,由GPU渲染 | 圖片解碼消耗CPU運算資源,Bitmap占用內(nèi)存大,繪制慢 |
| 使用XML或Java代碼實現(xiàn)(ShapeDrawable) | 直接將Shape信息傳到底層,由GPU渲染 | 消耗CPU資源少,占用內(nèi)存小,繪制快 |
頁面渲染背景知識
CPU與GPU結(jié)構(gòu)對比
CPU(Central Processing Unit,中央處理器)是計算機設(shè)備核心器件,用于執(zhí)行程序代碼,軟件開發(fā)者對此都很熟悉;GPU(Graphics Processing Unit,圖形處理器)主要用于處理圖形運算,通常所說“顯卡”的核心部件就是GPU。
下面是CPU和GPU的結(jié)構(gòu)對比圖。其中:

從結(jié)構(gòu)圖可以看出,CPU的控制器較為復(fù)雜,而ALU數(shù)量較少。因此CPU擅長各種復(fù)雜的邏輯運算,但不擅長數(shù)學(xué)尤其是浮點運算。
CPU是串行結(jié)構(gòu)。以計算100個數(shù)字為例,對于CPU的一個核,每次只能計算兩個數(shù)的和,結(jié)果逐步累加。
和CPU不同的是,GPU就是為實現(xiàn)大量數(shù)學(xué)運算設(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根導(dǎo)線組成,每根導(dǎo)線用不同的電壓表示一個二進制的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)復(fù)雜邏輯,因為同時考慮多個支路的輸出結(jié)果,并協(xié)調(diào)同步處理的過程很復(fù)雜(有點像多線程編程)。

GPU并行計算舉例
假設(shè)我們有如下圖像處理任務(wù),給每個像素值加1。GPU并行計算的方式簡單粗暴,在資源允許的情況下,可以為每個像素開一個GPU線程,由其進行加1操作。數(shù)學(xué)運算量越大,這種并行方式性能優(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)建等操作開始繪制。
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ù)具體的幾種場景,具體分析一下硬件加速前后的流程與加速效果。
| 渲染場景 | 純軟件繪制 | 硬件加速 | 加速效果分析 |
|---|---|---|---|
| 頁面初始化 | 繪制所有View | 創(chuàng)建所有DisplayList | GPU分擔了復(fù)雜計算任務(wù) |
| 在一個復(fù)雜頁面調(diào)用背景透明TextView的setText(),且調(diào)用后其尺寸位置不變 | 重繪臟區(qū)所有View | TextView及每一級父View重建DisplayList | 重疊的兄弟節(jié)點不需CPU重繪,GPU會自行處理 |
| TextView逐幀播放Alpha / Translation / Scale動畫 | 每幀都要重繪臟區(qū)所有View | 除第一幀同場景2,之后每幀只更新TextView對應(yīng)RenderNode的屬性 | 刷新一幀性能極大提高,動畫流暢度提高 |
| 修改TextView透明度 | 重繪臟區(qū)所有View | 直接調(diào)用RenderNode.setAlpha()更新 | 加速前需全頁面遍歷,并重繪很多View;加速后只觸發(fā)DecorView.updateDisplayListIfDirty,不再往下遍歷,CPU執(zhí)行時間可忽略不計 |
場景1中,無論是否加速,遍歷View樹并都會走Draw路徑。硬件加速后Draw路徑不做實際繪制工作,只是構(gòu)建DisplayList,復(fù)雜的繪制計算任務(wù)被GPU分擔,已經(jīng)有了較大的加速效果。
場景2中,TextView設(shè)置前后尺寸位置不變,不會觸發(fā)重新Layout。
draw(canvas,parent,drawingTime)方法中判斷直接返回。場景3中,軟件繪制每一幀都要做大量繪制工作,很容易導(dǎo)致動畫卡頓。硬件加速后,動畫過程直接走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; } // ...}軟件繪制刷新邏輯簡介
實際閱讀源碼并實驗,得出通常情況下的軟件繪制刷新邏輯:
PFLAG_DIRTY,其父View會設(shè)置標志位PFLAG_DIRTY_OPAQUE。在draw(canvas)方法中,只有這個View自身重繪。PFLAG_DIRTY。 ViewGroup.invalidateChildInParent()中會把臟區(qū)擴大到自身整個區(qū)域,于是與這個區(qū)域重疊的所有View都會重繪。總結(jié)
至此,硬件加速相關(guān)的內(nèi)容就介紹完了,這里做個簡單總結(jié):
以上就是本文的全部內(nèi)容,希望對大家的學(xué)習(xí)有所幫助,也希望大家多多支持武林網(wǎng)。
新聞熱點
疑難解答