国产探花免费观看_亚洲丰满少妇自慰呻吟_97日韩有码在线_资源在线日韩欧美_一区二区精品毛片,辰东完美世界有声小说,欢乐颂第一季,yy玄幻小说排行榜完本

首頁 > 系統(tǒng) > Android > 正文

淺談Android硬件加速原理與實現(xiàn)簡介

2019-12-12 00:43:17
字體:
供稿:網(wǎng)友

在手機客戶端尤其是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)存小,繪制快

頁面渲染背景知識

  • 頁面渲染時,被繪制的元素最終要轉(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ù)學(xué)、邏輯運算;
  • 橙色的Cache和DRAM分別為緩存和RAM,用于存儲信息。

從結(jié)構(gòu)圖可以看出,CPU的控制器較為復(fù)雜,而ALU數(shù)量較少。因此CPU擅長各種復(fù)雜的邏輯運算,但不擅長數(shù)學(xué)尤其是浮點運算。

  • 以8086為例,一百多條匯編指令大部分都是邏輯指令,數(shù)學(xué)計算相關(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ù)學(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.performTraversalsPhoneWindow.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ù)具體的幾種場景,具體分析一下硬件加速前后的流程與加速效果。

渲染場景 純軟件繪制 硬件加速 加速效果分析
頁面初始化 繪制所有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。

  • 軟件繪制時,TextView所在區(qū)域即為臟區(qū)。由于TextView有透明區(qū)域,遍歷View樹的過程中,和臟區(qū)重疊的多數(shù)View都要重繪,包括與之重疊的兄弟節(jié)點和他們的父節(jié)點(詳見后面的介紹),不需要繪制的View在draw(canvas,parent,drawingTime)方法中判斷直接返回。
  • 硬件加速后,也需要遍歷View樹,但只有TextView及其每一層父節(jié)點需要重建DisplayList,走的是Draw路徑,其他View直接走了DisplayList路徑,剩下的工作都交給GPU處理。頁面越復(fù)雜,兩者性能差距越明顯。

場景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; } // ...}

軟件繪制刷新邏輯簡介

實際閱讀源碼并實驗,得出通常情況下的軟件繪制刷新邏輯:

  • 默認情況下,View的clipChildren屬性為true,即每個View繪制區(qū)域不能超出其父View的范圍。如果設(shè)置一個頁面根布局的clipChildren屬性為false,則子View可以超出父View的繪制區(qū)域。
  • 當一個View觸發(fā)invalidate,且沒有播放動畫、沒有觸發(fā)layout的情況下:
    • 對于全不透明的View,其自身會設(shè)置標志位PFLAG_DIRTY,其父View會設(shè)置標志位PFLAG_DIRTY_OPAQUE。在draw(canvas)方法中,只有這個View自身重繪。
    • 對于可能有透明區(qū)域的View,其自身和父View都會設(shè)置標志位PFLAG_DIRTY
      • clipChildren為true時,臟區(qū)會被轉(zhuǎn)換成ViewRoot中的Rect,刷新時層層向下判斷,當View與臟區(qū)有重疊則重繪。如果一個View超出父View范圍且與臟區(qū)重疊,但其父View不與臟區(qū)重疊,這個子View不會重繪。
      • clipChildren為false時,ViewGroup.invalidateChildInParent()中會把臟區(qū)擴大到自身整個區(qū)域,于是與這個區(qū)域重疊的所有View都會重繪。

總結(jié)

至此,硬件加速相關(guān)的內(nèi)容就介紹完了,這里做個簡單總結(jié):

  • CPU更擅長復(fù)雜邏輯控制,而GPU得益于大量ALU和并行結(jié)構(gòu)設(shè)計,更擅長數(shù)學(xué)運算。
  • 頁面由各種基礎(chǔ)元素(DisplayList)構(gòu)成,渲染時需要進行大量浮點運算。
  • 硬件加速條件下,CPU用于控制復(fù)雜繪制邏輯、構(gòu)建或更新DisplayList;GPU用于完成圖形計算、渲染DisplayList。
  • 硬件加速條件下,刷新界面尤其是播放動畫時,CPU只重建或更新必要的DisplayList,進一步提高渲染效率。
  • 實現(xiàn)同樣效果,應(yīng)盡量使用更簡單的DisplayList,從而達到更好的性能(Shape代替Bitmap等)。

以上就是本文的全部內(nèi)容,希望對大家的學(xué)習(xí)有所幫助,也希望大家多多支持武林網(wǎng)。

發(fā)表評論 共有條評論
用戶名: 密碼:
驗證碼: 匿名發(fā)表
主站蜘蛛池模板: 留坝县| 博爱县| 东乡| 四川省| 沅陵县| 灵丘县| 望都县| 奉新县| 左贡县| 河北区| 宜丰县| 保德县| 大兴区| 贞丰县| 县级市| 商洛市| 晴隆县| 通河县| 曲水县| 文成县| 雅江县| 永定县| 临潭县| 虎林市| 云霄县| 会昌县| 潢川县| 永昌县| 东港市| 庄河市| 锦州市| 琼结县| 枞阳县| 霸州市| 库尔勒市| 卢龙县| 华容县| 元谋县| 广元市| 大城县| 青海省|