作者：huangran，图形图像技术专家
应用开发以后无法知道性能瓶颈的根因是什么？滑动卡顿、白块产生的原因是什么？代码写完之后，不知道如何优化让它表现地更好……
我们发现，如今测试人员的需求已经不只是停留在应用层面的测试数据了，而是需要数据背后的根因。但业界的图形栈测试，绝大部分都只提供应用层面的数据，有一部分可以深入系统层分析，但仍无法触及硬件这一层的测试分析。
HarmonyOS图形栈测试技术，不仅可以深入系统层分析，帮助开发测试者得到数据背后的根因，还能触达硬件层的测试分析。那它是如何做到的呢？让我们一起揭秘HarmonyOS图形栈测试技术。
一、HarmonyOS 图形栈全貌
众所周知，图形是操作系统里面非常核心的模块，和内核、编译器等模块一起作为操作系统的底层基座，不仅如此，它还是体现竞争力的关键模块。但因为图形栈非常复杂，所以需要构筑一套完整的测试技术才可以保证其质量和竞争力。
如图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开发框架，对应右边的三层结构，最底层是接口层测试，中间层是组件层测试，最上层是应用层测试。接下来我们会给大家重点介绍负载模型、系统分析案例和应用分析案例。
对于一个新的开发框架，在没有海量生态的应用进来之前我们是如何验证这个平台的测试能力的？
我们最初设想的是构建足够多的场景来覆盖和验证整个ArkUI框架，比如三棵树（Element树、Component树和Render树）、布局/动效、手势、2D渲染引擎。但因为不存在穷举的方式去覆盖所有业务，所以我们提出了负载模型的概念。
2D负载模型到底是什么？
我们选取了Top200的应用，对应用进行基于场景的分类，并提取特征， 然后形成了8大类常见用户场景（图3），如购物类、图库类、视频类等，同时也抽象出6大类负载，比如资源加载、图层叠加、负载布局 。
同时我们还结合了Beta与商用的性能问题单和用户体验反馈，来逆向帮助我们补充可能遗漏的负载，比如系统I/O负载压力。这样构建的负载模型有两个作用，不仅可以测试HarmonyOS图形栈架构，还可以为作为HarmonyOS应用样例，供开发者参考。
由于设备硬件能力的差异性，负载模型实际上是参数可调节的。比如对于IP Camera这类没有GPU的设备，我们无法给它加很强的负载，它的分辨率较小、物理尺寸也较小，如果用手机的分辨率给它渲染这是没有意义的。所以我们将负载模型构建成一个参数可调模型，这样它就会基于测试者的硬件设备来选择不同的资源做测试，非常灵活便捷。
如前文所说，我们的图形栈测试能力不只是停留在应用层，而是要进入到系统层和硬件层。接下来举两个例子让大家了解一下我们在系统和硬件层面上如何做分析。
案例一：系统分析案例
我们先举一个跟硬件相关的例子，比如“多个应用连续页面切换”的场景，这时候可能产生多应用切换的时延、丢帧等问题。
如图4所示，假如我们定义丢帧率的KPI为0.5%，但是经过测试达到了3%，丢帧指标超标，那么我们将进一步对硬件的CPU占用率和I/O压力进行数据统计。拿到统计数据之后，平台还会告诉你具体是哪一个进程产生了CPU和I/O的压力，并给出优化建议。
案例二：应用分析案例
接下来我们举个应用内的性能分析案例，比如图库应用的图片删除场景，也可能产生丢帧和时延问题。
如图5所示，假设我们定义时延指标为100ms，经过测试发现时延达到1048ms，时延超标，然后我们将ArkUI图形栈函数展开，得到耗时占比，发现在系统层面上FlushBuild（）和FlushLayout（）耗时较长，然后平台会基于这些数据进行分析，找到可能原因，并给出优化建议，以帮助开发者明确下一步优化方向和动作。
三、3D图形栈应用
图6是3D图形栈的整体架构，它包括了两部分，一部分是右侧的自研3D引擎，大家可以基于3D自研引擎进行3D应用的开发，比如3D动效、AR应用、3D壁纸等。
图6左边的部分是SDK，我们提供了一系列API，主要是针对大型的3D游戏，因为大型的3D游戏对于系统和SOC的压力较大，这些API可以帮助大型游戏更好地使用系统和硬件，比如GTX、System Cache、画质增强等SDK接口。
接下来我们会为大家重点介绍3D应用分析基础、特性拆分和分析方法和3D壁纸调优案例。
1. 3D应用分析基础
3D应用对于性能功耗的压力会更大，所以更需要底层SOC以及系统的分析能力。其实无论是3D自研引擎，还是SDK，都可以通过将负载进行特性拆分，然后进行细粒度分析。
如图7所示，场景A关键帧就是由渲染特性HDR、Bloom等粒子特效组成，再加上CPU负载就形成一个关键帧，这些关键帧连续起来就是3D场景。通过这些特性进一步调用到硬件逻辑的相关特性，比如ALU、Texture压力，最终通过DDK调用到硬件层执行。
有了以上分析基础后，我们再来看一下特性拆分和分析方法。
2. 特性拆分和分析方法
如图8所示，这帧渲染画面是由Particle、Shadow map、Point light、Bloom等特效组成，如果GPU的负载较重，性能出现瓶颈，如何找到问题的根因呢？我们把这一帧的GLES的指令截取到，并将每一个单特性进行分拆，然后看每一个单特性（如Particle）对硬件造成的压力。特性拆完后再结合GPU counters来帮助我们定位根因。
如何使用GPU counters来定位问题呢？如图9所示，场景C提示fragment cycles比较重，所以要求开发者减少像素渲染。而对于场景A，不仅Fragment cycles很重，而memory R/W以及Vertex cycles都比较重，那么就要针对这几个瓶颈进行优化。
3D壁纸调优案例
我们举一个3D壁纸调优的案例给大家展示如何找到性能瓶颈。
如图10所示，用Blender制作3D壁纸模型，再用我们的自研引擎增加渲染效果，最终形成一个有光照、反射的画面。
我们将3D壁纸画面进行特性剥离，再看特性剥离后每一个单特性对硬件造成的压力，数据如表1所示。发现表面细分（顶点50W）+点光（1术）+反射面的归一化电流达到了1921.33，性能出现较大恶化，如果使用一般的测试工具，就只能到这一步了。
但我们的工具可以帮助大家进一步分析。我们结合表2的Counters来帮助大家定位问题。
在表2的第一、二组数据可以看到，将反射面减少，会发现“shadercycles”从1910降低到1190，这提示开发者“shader”写的过于复杂了。
我们进一步将顶点数从50W减少到5W，会发现“VertexComputeCycles”从459降低到93.2，说明“VertexComputeCycle”就是一个需要优化的瓶颈。
通过这样的分析方式，就可以逐步定位到问题，并找到优化的方向，从而达成性能功耗和画质的平衡。
四、图形栈工具
我们前文介绍的2D和3D图形应用的分析优化的能力都集成于HarmonyOS图形栈的测试平台——DevEco Testing。
如图11所示，DevEco Testing是一个“三端+自动化”的结构，其中三端包括设备端、PC端和云端，而自动化就是可以使2D或3D应用的做到自动化测试，同时还具备以下测试能力：
性能、功耗、热的采集和分析
游戏测试自动化能力
大数据统计和分析
增强型服务：独立APK、帧采集回放、画质检测、多路测试等
在以上测试能力中，有3个增强型服务测试能力是我们的特色：
（1) 独立的APK测试能力
如图12所示，该工具支持脱离PC的方式进行测试，可直接在被测设备上部署工具，并且在进行设备应用操作时，可以实时展示数据。比如出现帧率的巨大下降时，可以直接在屏幕上展示数据并提供测试的报告，非常直观和便捷。
（2) 分布式渲染多路测试
该工具适用于HarmonyOS分布式多设备场景，可以绑定多个设备（如手机+笔记本），并且该工具平台可以把这些设备的测试报告进行绑定，形成完整的测试报告。
（3) 支持单帧或多帧的采集和回放功能
如图13所示，该工具可以采集一帧或多帧API Trace结果，然后进行回放，再结合GPU Counters进行定位（如前文壁纸调优案例所述）。
五、结语
HarmonyOS图形栈是整个HarmonyOS操作系统的基座，包括ArkUI 2D和3D部分。图形栈的测试是一个分层接口，包括应用层、系统层以及硬件层，可以帮助开发测试者从用户体验指标到深入了解系统和硬件发生了什么。这些测试服务能力集成DevEco Testing下的图形图像测试工具，欢迎大家下载使用。
