這篇文章給大家介紹怎么在Android中實現硬件加速，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

站在用戶的角度思考問題，與客戶深入溝通，找到邊壩網站設計與邊壩網站推廣的解決方案，憑借多年的經驗，讓設計與互聯網技術結合，創造個性化、用戶體驗好的作品，建站類型包括：網站制作、網站設計、企業官網、英文網站、手機端網站、網站推廣、域名與空間、虛擬空間、企業郵箱。業務覆蓋邊壩地區。

了解硬件加速對App開發的意義

對于App開發者，簡單了解硬件加速原理及上層API實現，開發時就可以充分利用硬件加速提高頁面的性能。以Android舉例，實現一個圓角矩形按鈕通常有兩種方案：使用PNG圖片；使用代碼（XML/Java）實現。簡單對比兩種方案如下。

方案	原理	特點
使用PNG圖片（BitmapDrawable）	解碼PNG圖片生成Bitmap，傳到底層，由GPU渲染	圖片解碼消耗CPU運算資源，Bitmap占用內存大，繪制慢
使用XML或Java代碼實現（ShapeDrawable）	直接將Shape信息傳到底層，由GPU渲染	消耗CPU資源少，占用內存小，繪制快

頁面渲染背景知識

• 頁面渲染時，被繪制的元素最終要轉換成矩陣像素點（即多維數組形式，類似安卓中的Bitmap），才能被顯示器顯示。

• 頁面由各種基本元素組成，例如圓形、圓角矩形、線段、文字、矢量圖（常用貝塞爾曲線組成）、Bitmap等。

• 元素繪制時尤其是動畫繪制過程中，經常涉及插值、縮放、旋轉、透明度變化、動畫過渡、毛玻璃模糊，甚至包括3D變換、物理運動（例如游戲中常見的拋物線運動）、多媒體文件解碼（主要在桌面機中有應用，移動設備一般不用GPU做解碼）等運算。

• 繪制過程經常需要進行邏輯較簡單、但數據量龐大的浮點運算。

CPU與GPU結構對比

CPU（Central Processing Unit，中央處理器）是計算機設備核心器件，用于執行程序代碼，軟件開發者對此都很熟悉；GPU（Graphics Processing Unit，圖形處理器）主要用于處理圖形運算，通常所說“顯卡”的核心部件就是GPU。

下面是CPU和GPU的結構對比圖。其中：

• 黃色的Control為控制器，用于協調控制整個CPU的運行，包括取出指令、控制其他模塊的運行等；

• 綠色的ALU（Arithmetic Logic Unit）是算術邏輯單元，用于進行數學、邏輯運算；

• 橙色的Cache和DRAM分別為緩存和RAM，用于存儲信息。

從結構圖可以看出，CPU的控制器較為復雜，而ALU數量較少。因此CPU擅長各種復雜的邏輯運算，但不擅長數學尤其是浮點運算。

• 以8086為例，一百多條匯編指令大部分都是邏輯指令，數學計算相關的主要是16位加減乘除和移位運算。一次整型和邏輯運算一般需要1~3個機器周期，而浮點運算要轉換成整數計算，一次運算可能消耗上百個機器周期。

• 更簡單的CPU甚至只有加法指令，減法用補碼加法實現，乘法用累加實現，除法用減法循環實現。

• 現代CPU一般都帶有硬件浮點運算器（FPU），但主要適用于數據量不大的情況。

CPU是串行結構。以計算100個數字為例，對于CPU的一個核，每次只能計算兩個數的和，結果逐步累加。

和CPU不同的是，GPU就是為實現大量數學運算設計的。從結構圖中可以看到，GPU的控制器比較簡單，但包含了大量ALU。GPU中的ALU使用了并行設計，且具有較多浮點運算單元。

硬件加速的主要原理，就是通過底層軟件代碼，將CPU不擅長的圖形計算轉換成GPU專用指令，由GPU完成。

擴展：很多計算機中的GPU有自己獨立的顯存；沒有獨立顯存則使用共享內存的形式，從內存中劃分一塊區域作為顯存。顯存可以保存GPU指令等信息。

并行結構舉例：級聯加法器

為了方便理解，這里先從底層電路結構的角度舉一個例子。如下圖為一個加法器，對應實際的數字電路結構。

A、B為輸入，C為輸出，且A、B、C均為總線，以32位CPU為例，則每根總線實際由32根導線組成，每根導線用不同的電壓表示一個二進制的0或1。

Clock為時鐘信號線，每個固定的時鐘周期可向其輸入一個特定的電壓信號，每當一個時鐘信號到來時，A和B的和就會輸出到C。

現在我們要計算8個整數的和。

對于CPU這種串行結構，代碼編寫很簡單，用for循環把所有數字逐個相加即可。串行結構只有一個加法器，需要7次求和運算；每次計算完部分和，還要將其再轉移到加法器的輸入端，做下一次計算。整個過程至少要消耗十幾個機器周期。

而對于并行結構，一種常見的設計是級聯加法器，如下圖，其中所有的clock連在一起。當需要相加的8個數據在輸入端A1~B4準備好后，經過三個時鐘周期，求和操作就完成了。如果數據量更大、級聯的層級更大，則并行結構的優勢更明顯。

由于電路的限制，不容易通過提高時鐘頻率、減小時鐘周期的方式提高運算速度。并行結構通過增加電路規模、并行處理，來實現更快的運算。但并行結構不容易實現復雜邏輯，因為同時考慮多個支路的輸出結果，并協調同步處理的過程很復雜（有點像多線程編程）。

GPU并行計算舉例

假設我們有如下圖像處理任務，給每個像素值加1。GPU并行計算的方式簡單粗暴，在資源允許的情況下，可以為每個像素開一個GPU線程，由其進行加1操作。數學運算量越大，這種并行方式性能優勢越明顯。

Android中的硬件加速

在Android中，大多數應用的界面都是利用常規的View來構建的（除了游戲、視頻、圖像等應用可能直接使用OpenGL ES）。下面根據Android 6.0原生系統的Java層代碼，對View的軟件和硬件加速渲染做一些分析和對比。

DisplayList

DisplayList是一個基本繪制元素，包含元素原始屬性（位置、尺寸、角度、透明度等），對應Canvas的drawXxx()方法（如下圖）。

信息傳遞流程：Canvas(Java API) —> OpenGL(C/C++ Lib) —> 驅動程序 —> GPU。

在Android 4.1及以上版本，DisplayList支持屬性，如果View的一些屬性發生變化（比如Scale、Alpha、Translate），只需把屬性更新給GPU，不需要生成新的DisplayList。

RenderNode

一個RenderNode包含若干個DisplayList，通常一個RenderNode對應一個View，包含View自身及其子View的所有DisplayList。

Android繪制流程（Android 6.0）

下面是安卓View完整的繪制流程圖，主要通過閱讀源碼和調試得出，虛線箭頭表示遞歸調用。

從ViewRootImpl.performTraversals到PhoneWindow.DecroView.drawChild是每次遍歷View樹的固定流程，首先根據標志位判斷是否需要重新布局并執行布局；然后進行Canvas的創建等操作開始繪制。

• 如果硬件加速不支持或者被關閉，則使用軟件繪制，生成的Canvas即Canvas.class的對象；

• 如果支持硬件加速，則生成的是DisplayListCanvas.class的對象；

• 兩者的isHardwareAccelerated()方法返回的值分別為false、true，View根據這個值判斷是否使用硬件加速。

View中的draw(canvas,parent,drawingTime) - draw(canvas) - onDraw - dispachDraw - drawChild這條遞歸路徑（下文簡稱Draw路徑），調用了Canvas.drawXxx()方法，在軟件渲染時用于實際繪制；在硬件加速時，用于構建DisplayList。

View中的updateDisplayListIfDirty - dispatchGetDisplayList - recreateChildDisplayList這條遞歸路徑（下文簡稱DisplayList路徑），僅在硬件加速時會經過，用于在遍歷View樹繪制的過程中更新DisplayList屬性，并快速跳過不需要重建DisplayList的View。

Android 6.0中，和DisplayList相關的API目前仍被標記為“@hide”不可訪問，表示還不成熟，后續版本可能開放。

硬件加速情況下，draw流程執行結束后DisplayList構建完成，然后通過ThreadedRenderer.nSyncAndDrawFrame()利用GPU繪制DisplayList到屏幕上。

純軟件繪制 VS 硬件加速（Android 6.0）

下面根據具體的幾種場景，具體分析一下硬件加速前后的流程與加速效果。

渲染場景	純軟件繪制	硬件加速	加速效果分析
頁面初始化	繪制所有View	創建所有DisplayList	GPU分擔了復雜計算任務
在一個復雜頁面調用背景透明TextView的setText()，且調用后其尺寸位置不變	重繪臟區所有View	TextView及每一級父View重建DisplayList	重疊的兄弟節點不需CPU重繪，GPU會自行處理
TextView逐幀播放Alpha / Translation / Scale動畫	每幀都要重繪臟區所有View	除第一幀同場景2，之后每幀只更新TextView對應RenderNode的屬性	刷新一幀性能極大提高，動畫流暢度提高
修改TextView透明度	重繪臟區所有View	直接調用RenderNode.setAlpha()更新	加速前需全頁面遍歷，并重繪很多View；加速后只觸發DecorView.updateDisplayListIfDirty，不再往下遍歷，CPU執行時間可忽略不計

場景1中，無論是否加速，遍歷View樹并都會走Draw路徑。硬件加速后Draw路徑不做實際繪制工作，只是構建DisplayList，復雜的繪制計算任務被GPU分擔，已經有了較大的加速效果。

場景2中，TextView設置前后尺寸位置不變，不會觸發重新Layout。

• 軟件繪制時，TextView所在區域即為臟區。由于TextView有透明區域，遍歷View樹的過程中，和臟區重疊的多數View都要重繪，包括與之重疊的兄弟節點和他們的父節點（詳見后面的介紹），不需要繪制的View在draw(canvas,parent,drawingTime)方法中判斷直接返回。

• 硬件加速后，也需要遍歷View樹，但只有TextView及其每一層父節點需要重建DisplayList，走的是Draw路徑，其他View直接走了DisplayList路徑，剩下的工作都交給GPU處理。頁面越復雜，兩者性能差距越明顯。

場景3中，軟件繪制每一幀都要做大量繪制工作，很容易導致動畫卡頓。硬件加速后，動畫過程直接走DisplayList路徑更新DisplayList的屬性，動畫流暢度能得到極大提高。

場景4中，兩者的性能差距更明顯。簡單修改透明度，軟件繪制仍然要做很多工作；硬件加速后一般直接更新RenderNode的屬性，不需要觸發invalidate，也不會遍歷View樹（除了少數View可能要對Alpha做特殊響應并在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繪制區域不能超出其父View的范圍。如果設置一個頁面根布局的clipChildren屬性為false，則子View可以超出父View的繪制區域。

• 當一個View觸發invalidate，且沒有播放動畫、沒有觸發layout的情況下：

• clipChildren為true時，臟區會被轉換成ViewRoot中的Rect，刷新時層層向下判斷，當View與臟區有重疊則重繪。如果一個View超出父View范圍且與臟區重疊，但其父View不與臟區重疊，這個子View不會重繪。

• clipChildren為false時，ViewGroup.invalidateChildInParent()中會把臟區擴大到自身整個區域，于是與這個區域重疊的所有View都會重繪。

• 對于全不透明的View，其自身會設置標志位PFLAG_DIRTY，其父View會設置標志位PFLAG_DIRTY_OPAQUE。在draw(canvas)方法中，只有這個View自身重繪。

• 對于可能有透明區域的View，其自身和父View都會設置標志位PFLAG_DIRTY。

關于怎么在Android中實現硬件加速就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。

網站題目：怎么在Android中實現硬件加速
分享地址：http://vcdvsql.cn/article42/pcdgec.html

成都網站建設公司_創新互聯，為您提供外貿建站、網站制作、定制網站、網站維護、ChatGPT、自適應網站

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯