圖形測驗分析毫無頭緒？HarmonyOS圖形堆疊測驗技術幫你解決-有解無憂

作者：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來幫助我們定位根因，