作者：huangran，圖形圖像技術(shù)專家

應(yīng)用開發(fā)以后無法知道性能瓶頸的根因是什么？滑動卡頓、白塊產(chǎn)生的原因是什么？代碼寫完之后，不知道如何優(yōu)化讓它表現(xiàn)地更好……

我們發(fā)現(xiàn)，如今測試人員的需求已經(jīng)不只是停留在應(yīng)用層面的測試數(shù)據(jù)了，而是需要數(shù)據(jù)背后的根因。但業(yè)界的圖形棧測試，絕大部分都只提供應(yīng)用層面的數(shù)據(jù)，有一部分可以深入系統(tǒng)層分析，但仍無法觸及硬件這一層的測試分析。

HarmonyOS圖形棧測試技術(shù)，不僅可以深入系統(tǒng)層分析，幫助開發(fā)測試者得到數(shù)據(jù)背后的根因，還能觸達硬件層的測試分析。那它是如何做到的呢？讓我們一起揭秘HarmonyOS圖形棧測試技術(shù)。

一、HarmonyOS 圖形棧全貌

眾所周知，圖形是操作系統(tǒng)里面非常核心的模塊，和內(nèi)核、編譯器等模塊一起作為操作系統(tǒng)的底層基座，不僅如此，它還是體現(xiàn)競爭力的關(guān)鍵模塊。但因為圖形棧非常復(fù)雜，所以需要構(gòu)筑一套完整的測試技術(shù)才可以保證其質(zhì)量和競爭力。

圖1 圖形棧整體架構(gòu)

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

中間一層則是我們圖形棧操作系統(tǒng)的核心能力，如組件、JS 引擎、ArkUI的三棵樹（Component樹，Element樹和Render樹）、自研2D引擎、自研3D引擎、動效、手勢、布局等。這一層與右邊測試部分的系統(tǒng)層對應(yīng)，包括圖形棧關(guān)鍵耗時函數(shù)解析和圖形棧優(yōu)化方案可見的能力。

最下面一層則是HarmonyOS 1+8+N設(shè)備需要橫跨的兩個部分：操作系統(tǒng)和硬件設(shè)備，需要對其進行兼容支持，這一層與右邊測試部分的硬件層對應(yīng)，包括跨系統(tǒng)對比測試能力、跨設(shè)備測試能力和硬件SOC分析能力。

我們圖形棧的測試能力不只是停留在應(yīng)用層的體驗KPI，它可以將體驗KPI指標進一步分解成系統(tǒng)級別的耗時函數(shù)、以及硬件級別的SOC分析能力，并最終提供優(yōu)化方案（后文將舉例說明）。

了解完整體架構(gòu)后，我們再進一從2D圖形棧應(yīng)用和3D圖形棧應(yīng)用兩個角度去了解圖形棧測試技術(shù)：

二、2D圖形棧應(yīng)用

圖2 是HarmonyOS ArkUI開發(fā)框架，對應(yīng)右邊的三層結(jié)構(gòu)，最底層是接口層測試，中間層是組件層測試，最上層是應(yīng)用層測試。接下來我們會給大家重點介紹負載模型、系統(tǒng)分析案例和應(yīng)用分析案例。

圖2 ArkUI開發(fā)框架

對于一個新的開發(fā)框架，在沒有海量生態(tài)的應(yīng)用進來之前我們是如何驗證這個平臺的測試能力的？

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

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

我們選取了Top200的應(yīng)用，對應(yīng)用進行基于場景的分類，并提取特征， 然后形成了8大類常見用戶場景（圖3），如購物類、圖庫類、視頻類等，同時也抽象出6大類負載，比如資源加載、圖層疊加、負載布局 。

圖3 負載場景及類型

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

由于設(shè)備硬件能力的差異性，負載模型實際上是參數(shù)可調(diào)節(jié)的。比如對于IP Camera這類沒有GPU的設(shè)備，我們無法給它加很強的負載，它的分辨率較小、物理尺寸也較小，如果用手機的分辨率給它渲染這是沒有意義的。所以我們將負載模型構(gòu)建成一個參數(shù)可調(diào)模型，這樣它就會基于測試者的硬件設(shè)備來選擇不同的資源做測試，非常靈活便捷。

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

案例一：系統(tǒng)分析案例

我們先舉一個跟硬件相關(guān)的例子，比如“多個應(yīng)用連續(xù)頁面切換”的場景，這時候可能產(chǎn)生多應(yīng)用切換的時延、丟幀等問題。

如圖4所示，假如我們定義丟幀率的KPI為0.5%，但是經(jīng)過測試達到了3%，丟幀指標超標，那么我們將進一步對硬件的CPU占用率和I/O壓力進行數(shù)據(jù)統(tǒng)計。拿到統(tǒng)計數(shù)據(jù)之后，平臺還會告訴你具體是哪一個進程產(chǎn)生了CPU和I/O的壓力，并給出優(yōu)化建議。

圖4 系統(tǒng)分析和優(yōu)化建議

案例二：應(yīng)用分析案例

接下來我們舉個應(yīng)用內(nèi)的性能分析案例，比如圖庫應(yīng)用的圖片刪除場景，也可能產(chǎn)生丟幀和時延問題。

如圖5所示，假設(shè)我們定義時延指標為100ms，經(jīng)過測試發(fā)現(xiàn)時延達到1048ms，時延超標，然后我們將ArkUI圖形棧函數(shù)展開，得到耗時占比，發(fā)現(xiàn)在系統(tǒng)層面上FlushBuild（）和FlushLayout（）耗時較長，然后平臺會基于這些數(shù)據(jù)進行分析，找到可能原因，并給出優(yōu)化建議，以幫助開發(fā)者明確下一步優(yōu)化方向和動作。

圖5 應(yīng)用分析和優(yōu)化建議

三、3D圖形棧應(yīng)用

圖6是3D圖形棧的整體架構(gòu)，它包括了兩部分，一部分是右側(cè)的自研3D引擎，大家可以基于3D自研引擎進行3D應(yīng)用的開發(fā)，比如3D動效、ar應(yīng)用、3D壁紙等。

圖6左邊的部分是SDK，我們提供了一系列API，主要是針對大型的3D游戲，因為大型的3D游戲?qū)τ谙到y(tǒng)和SOC的壓力較大，這些API可以幫助大型游戲更好地使用系統(tǒng)和硬件，比如GTX、System Cache、畫質(zhì)增強等SDK接口。

接下來我們會為大家重點介紹3D應(yīng)用分析基礎(chǔ)、特性拆分和分析方法和3D壁紙調(diào)優(yōu)案例。

圖6 “3D圖形棧”

1. 3D應(yīng)用分析基礎(chǔ)

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

如圖7所示，場景A關(guān)鍵幀就是由渲染特性HDR、Bloom等粒子特效組成，再加上CPU負載就形成一個關(guān)鍵幀，這些關(guān)鍵幀連續(xù)起來就是3D場景。通過這些特性進一步調(diào)用到硬件邏輯的相關(guān)特性，比如ALU、Texture壓力，最終通過DDK調(diào)用到硬件層執(zhí)行。

圖7 “3D應(yīng)用分析基礎(chǔ)”

有了以上分析基礎(chǔ)后，我們再來看一下特性拆分和分析方法。

2. 特性拆分和分析方法

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

圖8 特性拆分

如何使用GPU counters來定位問題呢？如圖9所示，場景C提示fragment cycles比較重，所以要求開發(fā)者減少像素渲染。而對于場景A，不僅Fragment cycles很重，而memory R/W以及Vertex cycles都比較重，那么就要針對這幾個瓶頸進行優(yōu)化。

圖9 GPU Counters

3D壁紙調(diào)優(yōu)案例

我們舉一個3D壁紙調(diào)優(yōu)的案例給大家展示如何找到性能瓶頸。

圖10 “3D壁紙調(diào)優(yōu)”

如圖10所示，用Blender制作3D壁紙模型，再用我們的自研引擎增加渲染效果，最終形成一個有光照、反射的畫面。

我們將3D壁紙畫面進行特性剝離，再看特性剝離后每一個單特性對硬件造成的壓力，數(shù)據(jù)如表1所示。發(fā)現(xiàn)表面細分（頂點50W）+點光（1術(shù)）+反射面的歸一化電流達到了1921.33，性能出現(xiàn)較大惡化，如果使用一般的測試工具，就只能到這一步了。

但我們的工具可以幫助大家進一步分析。我們結(jié)合表2的Counters來幫助大家定位問題。

在表2的第一、二組數(shù)據(jù)可以看到，將反射面減少，會發(fā)現(xiàn)“shadercycles”從1910降低到1190，這提示開發(fā)者“shader”寫的過于復(fù)雜了。

我們進一步將頂點數(shù)從50W減少到5W，會發(fā)現(xiàn)“VertexComputeCycles”從459降低到93.2，說明“VertexComputeCycle”就是一個需要優(yōu)化的瓶頸。
通過這樣的分析方式，就可以逐步定位到問題，并找到優(yōu)化的方向，從而達成性能功耗和畫質(zhì)的平衡。

四、圖形棧工具

我們前文介紹的2D和3D圖形應(yīng)用的分析優(yōu)化的能力都集成于HarmonyOS圖形棧的測試平臺——DevEco Testing。

圖11 DevEco Testing-圖形棧測試分析能力

如圖11所示，DevEco Testing是一個“三端+自動化”的結(jié)構(gòu)，其中三端包括設(shè)備端、PC端和云端，而自動化就是可以使2D或3D應(yīng)用的做到自動化測試，同時還具備以下測試能力：

• 性能、功耗、熱的采集和分析
• 游戲測試自動化能力
• 大數(shù)據(jù)統(tǒng)計和分析
• 增強型服務(wù)：獨立APK、幀采集回放、畫質(zhì)檢測、多路測試等
  

在以上測試能力中，有3個增強型服務(wù)測試能力是我們的特色：

（1）獨立的APK測試能力

如圖12所示，該工具支持脫離PC的方式進行測試，可直接在被測設(shè)備上部署工具，并且在進行設(shè)備應(yīng)用操作時，可以實時展示數(shù)據(jù)。比如出現(xiàn)幀率的巨大下降時，可以直接在屏幕上展示數(shù)據(jù)并提供測試的報告，非常直觀和便捷。

圖12靈活的獨立APK測試

（2）分布式渲染多路測試

該工具適用于HarmonyOS分布式多設(shè)備場景，可以綁定多個設(shè)備（如手機+筆記本），并且該工具平臺可以把這些設(shè)備的測試報告進行綁定，形成完整的測試報告。

（3）支持單幀或多幀的采集和回放功能

如圖13所示，該工具可以采集一幀或多幀API Trace結(jié)果，然后進行回放，再結(jié)合GPU Counters進行定位（如前文壁紙調(diào)優(yōu)案例所述）。

圖13 單幀或多幀采集回放

五、結(jié)語

HarmonyOS圖形棧是整個HarmonyOS操作系統(tǒng)的基座，包括ArkUI 2D和3D部分。圖形棧的測試是一個分層接口，包括應(yīng)用層、系統(tǒng)層以及硬件層，可以幫助開發(fā)測試者從用戶體驗指標到深入了解系統(tǒng)和硬件發(fā)生了什么。

這些測試服務(wù)能力集成DevEco Testing下的圖形圖像測試工具，歡迎大家下載使用。