图形测试分析毫无头绪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来帮助我们定位根因。