圖形測試分析毫無頭緒？HarmonyOS圖形棧測試技術幫你解決

HarmonyOS開發者社群發表於2022-01-10

作者：huangran，圖形影像技術專家

應用開發以後無法知道效能瓶頸的根因是什麼？滑動卡頓、白塊產生的原因是什麼？程式碼寫完之後，不知道如何優化讓它表現地更好……

我們發現，如今測試人員的需求已經不只是停留在應用層面的測試資料了，而是需要資料背後的根因。但業界的圖形棧測試，絕大部分都只提供應用層面的資料，有一部分可以深入系統層分析，但仍無法觸及硬體這一層的測試分析。

HarmonyOS圖形棧測試技術，不僅可以深入系統層分析，幫助開發測試者得到資料背後的根因，還能觸達硬體層的測試分析。那它是如何做到的呢？讓我們一起揭祕HarmonyOS圖形棧測試技術。

一、HarmonyOS 圖形棧全貌

眾所周知，圖形是作業系統裡面非常核心的模組，和核心、編譯器等模組一起作為作業系統的底層基座，不僅如此，它還是體現競爭力的關鍵模組。但因為圖形棧非常複雜，所以需要構築一套完整的測試技術才可以保證其質量和競爭力。

圖1 圖形棧整體架構

如圖1所示，左邊部分是HarmonyOS圖形棧的全貌，其中最上面一層是渲染前端，包括2D類應用、3D類應用和重負載的遊戲視訊類應用，這一層與右邊測試部分的應用層對應，包括體驗KPI和負載模型能力。

中間一層則是我們圖形棧作業系統的核心能力，如元件、JS 引擎、ArkUI的三棵樹（Component樹，Element樹和Render樹）、自研2D引擎、自研3D引擎、動效、手勢、佈局等。這一層與右邊測試部分的系統層對應，包括圖形棧關鍵耗時函式解析和圖形棧優化方案可見的能力。

最下面一層則是HarmonyOS 1+8+N裝置需要橫跨的兩個部分：作業系統和硬體裝置，需要對其進行相容支援，這一層與右邊測試部分的硬體層對應，包括跨系統對比測試能力、跨裝置測試能力和硬體SOC分析能力。

我們圖形棧的測試能力不只是停留在應用層的體驗KPI，它可以將體驗KPI指標進一步分解成系統級別的耗時函式、以及硬體級別的SOC分析能力，並最終提供優化方案（後文將舉例說明）。

瞭解完整體架構後，我們再進一從2D圖形棧應用和3D圖形棧應用兩個角度去了解圖形棧測試技術：

二、2D圖形棧應用

圖2 是HarmonyOS ArkUI開發框架，對應右邊的三層結構，最底層是介面層測試，中間層是元件層測試，最上層是應用層測試。接下來我們會給大家重點介紹負載模型、系統分析案例和應用分析案例。

圖2 ArkUI開發框架

對於一個新的開發框架，在沒有海量生態的應用進來之前我們是如何驗證這個平臺的測試能力的？

我們最初設想的是構建足夠多的場景來覆蓋和驗證整個ArkUI框架，比如三棵樹（Element樹、Component樹和Render樹）、佈局/動效、手勢、2D渲染引擎。但因為不存在窮舉的方式去覆蓋所有業務，所以我們提出了負載模型的概念。

2D負載模型到底是什麼？

我們選取了Top200的應用，對應用進行基於場景的分類，並提取特徵，然後形成了8大類常見使用者場景（圖3），如購物類、相簿類、視訊類等，同時也抽象出6大類負載，比如資源載入、圖層疊加、負載佈局。

圖3 負載場景及型別

同時我們還結合了Beta與商用的效能問題單和使用者體驗反饋，來逆向幫助我們補充可能遺漏的負載，比如系統I/O負載壓力。這樣構建的負載模型有兩個作用，不僅可以測試HarmonyOS圖形棧架構，還可以為作為HarmonyOS應用樣例，供開發者參考。

由於裝置硬體能力的差異性，負載模型實際上是引數可調節的。比如對於IP Camera這類沒有GPU的裝置，我們無法給它加很強的負載，它的解析度較小、物理尺寸也較小，如果用手機的解析度給它渲染這是沒有意義的。所以我們將負載模型構建成一個引數可調模型，這樣它就會基於測試者的硬體裝置來選擇不同的資源做測試，非常靈活便捷。

如前文所說，我們的圖形棧測試能力不只是停留在應用層，而是要進入到系統層和硬體層。接下來舉兩個例子讓大家瞭解一下我們在系統和硬體層面上如何做分析。

案例一：系統分析案例

我們先舉一個跟硬體相關的例子，比如“多個應用連續頁面切換”的場景，這時候可能產生多應用切換的時延、丟幀等問題。

如圖4所示，假如我們定義丟幀率的KPI為0.5%，但是經過測試達到了3%，丟幀指標超標，那麼我們將進一步對硬體的CPU佔用率和I/O壓力進行資料統計。拿到統計資料之後，平臺還會告訴你具體是哪一個程式產生了CPU和I/O的壓力，並給出優化建議。

圖4 系統分析和優化建議

案例二：應用分析案例

接下來我們舉個應用內的效能分析案例，比如相簿應用的圖片刪除場景，也可能產生丟幀和時延問題。

如圖5所示，假設我們定義時延指標為100ms，經過測試發現時延達到1048ms，時延超標，然後我們將ArkUI圖形棧函式展開，得到耗時佔比，發現在系統層面上FlushBuild（）和FlushLayout（）耗時較長，然後平臺會基於這些資料進行分析，找到可能原因，並給出優化建議，以幫助開發者明確下一步優化方向和動作。

圖5 應用分析和優化建議

三、3D圖形棧應用

圖6是3D圖形棧的整體架構，它包括了兩部分，一部分是右側的自研3D引擎，大家可以基於3D自研引擎進行3D應用的開發，比如3D動效、AR應用、3D桌布等。

圖6左邊的部分是SDK，我們提供了一系列API，主要是針對大型的3D遊戲，因為大型的3D遊戲對於系統和SOC的壓力較大，這些API可以幫助大型遊戲更好地使用系統和硬體，比如GTX、System Cache、畫質增強等SDK介面。

接下來我們會為大家重點介紹3D應用分析基礎、特性拆分和分析方法和3D桌布調優案例。

圖6 “3D圖形棧”

1. 3D應用分析基礎

3D應用對於效能功耗的壓力會更大，所以更需要底層SOC以及系統的分析能力。其實無論是3D自研引擎，還是SDK，都可以通過將負載進行特性拆分，然後進行細粒度分析。

如圖7所示，場景A關鍵幀就是由渲染特性HDR、Bloom等粒子特效組成，再加上CPU負載就形成一個關鍵幀，這些關鍵幀連續起來就是3D場景。通過這些特性進一步呼叫到硬體邏輯的相關特性，比如ALU、Texture壓力，最終通過DDK呼叫到硬體層執行。

圖7 “3D應用分析基礎”

有了以上分析基礎後，我們再來看一下特性拆分和分析方法。

2. 特性拆分和分析方法

如圖8所示，這幀渲染畫面是由Particle、Shadow map、Point light、Bloom等特效組成，如果GPU的負載較重，效能出現瓶頸，如何找到問題的根因呢？我們把這一幀的GLES的指令擷取到，並將每一個單特性進行分拆，然後看每一個單特性（如Particle）對硬體造成的壓力。特性拆完後再結合GPU counters來幫助我們定位根因。