本文记录了Android图形性能的分析过程 - 发现，定性和定位图形性能问题以及性能优化方案讨论。
环境：Android Q + MTK + ARM MALI-G72。
分析的性能（以下简称为情况）：打开屏幕记录应用程序并启动背景屏幕，滑动前台应用程序（滑动屏幕）。POOR性能：CPU和GPU负载显着升高，帧降低，帧降低和用户显然被卡住了。帧速率小于30帧。
优化后，在相同的环境和条件下，渲染帧速率在60帧（翻倍）下稳定，平均渲染时间约为8.44ms（优化前消耗的三分之一不到三分之一）。
使用工具统计帧速率和平均时间消耗（同时打印GPU负载）。当背景屏幕录制打开时，屏幕正在下降。平均渲染时间高达约29ms，在60中翻了一番16.67ms.africa。
这是病例性能问题的GFXINFO支柱图。可以看出，红色的柱子和绿色柱非常高，远远超出了平稳的标准。在它们中，绿色柱子的异常扩大表明，两种Vsync之间的耗时显着增加，并且异常的红色肿大变了。列表示显示列表通过加速的应用程序层应用程序或GPU执行指令消耗GPU执行指令而增加的GPU执行指令，该指令由GLES引起的GPU Time Exptument.over.over Time。
首先，我们完成实验（启动和停止背景屏幕并滑动屏幕以触发渲染），观察和记录，并获得FPS，序列时间消耗以及GPU负载（FPS部分中的相关数据）在背景屏幕的开始时，并停止。
开发工具输出的统计数据的计算结果非常直观。一目了然，背景屏幕记录带来了额外的?8次或?8毫秒的时间来带来抽奖阶段，这将带来额外的?2次或?11ms的时间。30帧。
Draw的创建显示清单的时间消耗。如果Android的视图支持硬件加速，则绘图工作由GPU绘制的绘图工作绘制，可以在不额外的时间内进行额外的?8ms或?8次准备准备，即提交的工作。在硬件加速机制下，GPU需要额外的?11ms或?2倍的executeFrameBuffer在消耗缓冲区翻转操作之前和之后的executeFrameBuffer。mm是正常的。case为?29m。主要增加来自绘制和过程。
在上述初步分析和观察之后，可以围绕DRAW和处理进行以下分析。由于Android Draw部分涉及广泛的分析，它包括应用程序渲染线（显示清单），UI线程和图形堆栈，例如SurfaceFlinger和Renderngine。
在这里，可以初步判断一种技术，即时间消耗来自应用程序过程（渲染线程和UI线程）或图形堆栈。如果您可以判断来自应用程序或图形堆栈的时间，则可以减少分析的范围并减少分析工作负载。上述四个阶段的时间耗尽统计分类相对较宽。实际上，时间消耗的阶段更详细。它显示在前面描述的GFX统计信息支柱图上。GFX支柱图将占用蓝色（RGB（66,122,249））来创建和更新显示清单时间-Consuming。时间（蓝色列的大小）很小，可以解释说，额外的抽取时间消耗不是来自该应用程序，并且很可能来自图形堆栈。Besides.besides，结合了过度绘制分析，确定在正常情况下是否有更多额外的绘制和正常情况。
- 根据上述指导，案件的额外抽取时间消耗与应用程序OnDraw无关。额外的显示列表来自该过程以外的其他过程，这可能是诸如SurfaceFlinger之类的图形堆栈。
本节介绍了问题跟踪过程，通过某些方法将耗时的时间定位到每个阶段，并得出结论。案例性能问题的性质。从本节开始，围绕perfetto.perfetto的整体视图发布了此处，我将关键分类为键到顶部的信息。前四行是负责图形的SF线程，并提交给GPU等待完成的工作，VSYNC-APP和VSYNC-SF.TO。
很容易看出，vsync-sf非常不规则。Vsync-SF是一个基于硬件VSync的信号，实际上触发了SurfaceFlinger的合成工作。它与真实的硬件信号（HW_VSYNC）进行了比较（hw_vsync）是常规的偏移（在案例设备上，vsync，vsync，vsync，vsync，-APP和VSYNC-SF配置为8.3ms，也就是说，在达到硬件Vsync之后，虚拟Vsync-App和vsync-sf ExtensionAfter 8.3ms分别发出以触发App Drawing和SurfaceFlinger合成。
该案的Vsync-SF交错，残疾，不一致且不规律。显然，工作条件不好。它将导致SurfaceFlinger将合成帧提交给Framebuffer（翻转后，翻转后的Framebuffer将提交给显示的下一个框架。
如我们所见，Case的Vsync-SF显得严重漂移（请参阅图片，第二行中的Vsync-SF并不统一，无法跟上，丑陋和混乱），这导致了框架的损失。（但是（但是）VSYNC-SF的失控仅表示框架损失之间的相关性，并不直接表示因果关系。）
换句话说，由于功耗或其他原因（例如，时间消耗引起的延长，人们是线程实现的消息队列），SurfaceFleler的SfeventThread可能不会被调用，这会在窗口期间在窗口期间导致VSYNC-SF窗口段插入 - 但不会存在不均匀的情况。在案例的VSYNC信号报告中，Vsync-SF信号异常地提醒您的性能问题 - 它的不规则现象表明VSYNC之间存在异常时间，不是低功耗的时间消费机制已激活或没有屏幕刷新（恢复时案例性能问题一直在最前沿的屏幕应用，并且每16ms每16ms都有图片更新）。
尽管Vsync-SF具有偏差，但它仅与口吃问题有关联（或者是绩效问题的结果），而不是因果关系。向漂移的信号。Vsync-SF信号偏差实质上是指导性的，因为它可以提醒我们，问题出现在底层中比应用程序（以前的分析的结论），并且提交了框架上层的位置与SurfaceFlinger.Synthetic相比，在合成后提交给屏幕双缓冲区）。
通过这种方式，已经确定了病例性能问题的上限和下限，并且问题分析的范围从原始图形堆栈有效地减小到SurfaceFlinger渲染和合成阶段。
阅读perfetto，您还可以看到，除了丑陋的vsync-sf之外，您还可以看到令人眼花the乱的超长时间耗时的抽奖（app ui thread）和耗时的变态dequeuebuffer（app rendering thread）call.com.com正常情况下，Perfetto报告案例的抽奖方法使增长的增长增加了一倍。很容易被误认为时间消耗。“从一开始就消除的应用程序过程”是不可能的。他们是相反的结论，它们必须是错误的。仅通过仔细分析，可以发现抽签方法确实消耗了更多[墙[墙]]时间（但并不意味着要消耗更多的CPU时间，因为等待过程是睡眠的），但是抽奖方法是因为渲染线的消耗正在等待渲染线程。在底部的图形堆栈下。
由于问题范围已缩小到较小的范围，在SurfaceFlinger的刷新过程中，该案例相对较大 - 时间耗尽，几乎完全来自docposition。两个合成（一个是设备的物理屏幕，第一个是由案例的背端屏幕记录工具创建的虚拟屏幕），虚拟屏幕比物理屏幕高得多（超过4次）。
通过查看“ trace的标签”（上方，perfetto中的主线的每个跟踪点是Artrace扮演的标签），结合了Dumpsys SurfaceFlinger，可以直接看到的线索::::::
结合图中的跟踪标签，可以得出结论，因为GPU合成的虚拟屏幕中的GPU合成显着高于物理屏幕HWC合成的合成。如果GPU合成可以尽可能快地作为HWC，或简单地让虚拟屏幕使用HWC合成，那么SurfaceFlinger的合成工作的消耗将大大减少。
本节结合了上述以上三个部分的分析，本节的“定性问题”是下一个结论。
耗时的本质已经通过。HWC不合成筛选工具应用程序，而是由GPU合成的。使界面陷入困境需要很长时间。在一个单词中，案例使用的合成方法不高。
HWC是硬性作曲家。它接收图形数据，类似于桌面（真实桌面，而不是计算机和手机的桌面），也可以在照片和纸张的顶部 - 也就是说，即合成过程。这项作业可以超越几个Windows的Windows在接口上并将其发送到屏幕上以显示。GPU也可以通过GPU完成这项工作，但是HWC合成的作用是纯硬件 - 它的快速，比GPU快几倍。
尽管先前定性问题的原因是合成方法不是有效的，但没有获得原理 - 为什么虚拟屏幕不使用有效的HWC进行合成。本节介绍了HWC的原理，SurfaceFlinger来控制合成方法，，，，，，，，，，，，，控制合成方法，，则介绍了HWC的原理。虚拟屏幕表面特征等。要在图形堆栈中引入合成方法的处理模式。掌握相关管理后，我们将探索一些通用的共同解决方案以实现性能优化。我们将重点放在解决方案上，以解决基本原因的解决方案。多 - 集合优化方案-Mediacodec.MediaFormat为支持HWC合成表面解。
除非它是设计的功耗，否则SurfaceFlinger将始终检查合成是否支持HWC.IN编程的使用，在合成阶段之一的准备过程中，SurfaceFlinger通过与HIDL Service通信与HIDL Service通信与HIDL Service Commenancy commenance consect of the HWC层的创建硬件作曲家（即HWC）。但是，成功的创建并不意味着支持HWC综合。Surfaceflinger不支持HWC不支持HWC合成为HWC。客户端的合成，那么该部分不能由HWC合成，这仅是由GPU -case合成的情况。
结合上述情况，设计实验验证。在它们的情况下，通过物理屏幕上的pop -up窗口添加了LAYS限制以获得HWC层的限制。确认案例无法使用HWC合成不是由hwc合成的问题。层限制，通过比较验证了表面格式的问题。表面是天然层上的缓冲区包。它的类型是宽而复杂的。一一是不现实的。通过比较性能，可以找到类似的实现。AndroidADB提供了一系列工具，例如虚拟辅助屏幕（开发人员模式模拟辅助屏幕）和用于测试双屏幕显示功能的著名远程筛选工具。
测试后，支持HWC合成 - 这是优化目标。首先查看其实现。
在编程中，虚拟辅助屏幕与情况完全相同 - 通过创建图形层的附加综合，通过创建一个额外的屏幕。完成屏幕录制。
从逻辑上读取源代码，它与虚拟辅助屏幕和案例屏幕记录应用程序 - 屏幕录制相同。
最大可能影响HWC合成的可能性来自点3的格式。使该假设的逻辑是HWC是否具有合成能力是由层的格式确定的（层是图形层到图形缓冲区的抽象，表面是应用程序层的抽象。它们的底层是一致的，也就是说，它们都指各自层中的图形缓冲区）。
因此，编写演示并模仿创建表面的方式：ScreenRecord :: PreparenCoder：
我们的情况是一个应用程序层应用程序，因此只需表达Java代码：
使用Java层，相当于OMX。
演示如上所示。在简短的说明下，核心操作是前两行的格式。诸如编解码器和将表面传递到virtualdisplay之类的其他都是“死”的代码（谁写了它，也是代码，也是代码通过案例应用程序实现）.case应用程序之前是在前创建的，并且仅支持GPU合成（特征）。
运行演示并通过Dumpsys SurfaceFlinger查看虚拟显示各种层的合成类型。您可以看到，从原始客户端类型到设备类型。测试使用相同的环境和方法，发现帧速率在预期的期望下从30帧恢复到60帧！它表明我们的解决方案已实现了彻底成功 - 通过此解决方案，它不仅验证了HWC合成是否受表面格式（底部的图形缓冲区）的限制，而且还验证了设备合成的性能优化可行性。
在合成中使用HWC可能会导致口吃帧。HWC合成条件严格（与硬件平台本身和系统的底层有关）。应用程序层应尝试尽可能多地使用HWC条件以确保尽可能多地使用HWC-将表面设置为（）。