如何理解 dumpsys SurfaceFlinger答案

【问题标题】：How to make sense of dumpsys SurfaceFlinger如何理解 dumpsys SurfaceFlinger
【发布时间】：2014-02-08 06:20:36
【问题描述】：

adb 命令“dumpsys SurfaceFlinger”的输出是否有任何文档？

我特别想了解 HWC 或 GLES 层类型之间的区别，numHwLayers 是什么意思？

这里是我说的dumpsys SurfaceFlinger部分：

  mDebugForceFakeVSync=0
  Display[0] : 768x1280, xdpi=319.790009, ydpi=318.744995, refresh=16666667
  numHwLayers=5, flags=00000000
    type    |  handle  |   hints  |   flags  | tr | blend |  format  |       source crop         |           frame           name
------------+----------+----------+----------+----+-------+----------+---------------------------+--------------------------------
       GLES | b7e1c440 | 00000002 | 00000000 | 00 | 00100 | 00000002 | [  334,   56, 1102, 1190] | [    0,   50,  768, 1184] com.android.systemui.ImageWallpaper
       GLES | b7e1d7c8 | 00000002 | 00000000 | 00 | 00105 | 00000001 | [    0,   50,  768, 1184] | [    0,   50,  768, 1184] com.android.launcher/com.android.launcher2.Launcher
       GLES | b7e701e0 | 00000002 | 00000000 | 00 | 00105 | 00000001 | [    0,    0,  768,   50] | [    0,    0,  768,   50] StatusBar
       GLES | b7e1df68 | 00000002 | 00000000 | 00 | 00100 | 00000001 | [    0,    0,  768,   96] | [    0, 1184,  768, 1280] NavigationBar
  FB TARGET | b7dd3ab0 | 00000000 | 00000000 | 00 | 00105 | 00000001 | [    0,    0,  768, 1280] | [    0,    0,  768, 1280] HWC_FRAMEBUFFER_TARGET

【问题讨论】：

读取android.googlesource.com/platform/frameworks/native/+/master/…和android.googlesource.com/platform/frameworks/native/+/master/…的头文件
谢谢！请参阅下面的答案。
另见source.android.com/devices/graphics/architecture.html

标签： android adb surfaceflinger

【解决方案1】：

好的，我有足够的想法来回答我自己的问题，但是如果有人有任何其他意见，请将它们留在 cmets 中。遇到了一些额外的东西，我会在下面指出，但仍然不清楚。

首先，下面的链接有助于解释一些关于如何通过 SurfaceFlinger 进行图像渲染和合成的事情： http://source.android.com/devices/graphics.html

如果您在链接中注意到，有两种方式将图像发送到显示器。一种是在将图像发送到显示器之前先用GPU处理图像，另一种是使用显示器的硬件覆盖绕过GPU，将图像直接发送到显示器。后一种方法效果更好，但您仅限于一定数量的层/叠加层（通常为 4 个）。如果您有更多层，则必须由 GPU 处理。

在我的问题中心的 dumpsys SurfaceFlinger 部分显示了在调用 dumpsys 的那一刻有多少层，以及这些层是由 Hardware Composer (HWC) 还是 GPU (GLES) 处理的.这解释了 HWC 和 GLES 的含义。此外，numHwLayers 是显示器支持的叠加层数（通常为 4 个）。

此外，还有“源裁剪”和“框架”坐标。源裁剪是要显示的图像部分。例如，如果它是跨越多个显示屏幕的壁纸（想想当您在屏幕上滑动时在主屏幕上看到的内容），那么在给定的时刻，您只需要显示该较大壁纸图像的一个子部分。这意味着源裁剪只是告诉您当前正在使用的整体图像的哪个部分。它的框架部分是源图像的该部分将实际显示在屏幕上的位置。

dumpsys SurfaceFlinger 命令这一部分的代码位于此处： \frameworks\native\services\surfaceflinger\DisplayHardware\HWComposer.cpp

它在一个名为“HWComposer::dump”的函数中

以上回答了我最初的问题，但以下是我注意到的一些其他事情：

看起来组合类型比 HWC 和 GLES 多。在上面提到的代码中，我看到了一个“BACKGROUND”和一个“FB TARGET”复合类型。当您在 adb 中键入“dumpsys SurfaceFlinger”时，FB TARGET 似乎总是存在。我认为 FB Target 只是将完整图像写入的帧缓冲区（请有人确认这一点）。即使设备处于睡眠状态，您也会看到此 FB TARGET。我不明白的是，这种背景类型是什么？我什至无法猜测那个。如果您知道这是什么，请发表评论。

谢谢！

【讨论】：

好文章！您对FB TARGET 的看法是正确的。如果所有层与叠加层合成，则没有 GLES 合成，并且帧缓冲区目标层未使用。在空闲系统上（当屏幕上没有任何变化时），HWC 实际上可能会切换到 GLES，因为与以 60fps 叠加合成多个图层相比，合成一次并重复显示 FB 目标图层所需的功率更少。另请参阅stackoverflow.com/questions/20822309（现在这里有一个链接）。忽略背景。
感谢您指出，如果系统处于空闲状态，您可能会看到 FB 目标的所有内容。非常有趣，感谢您的意见。
@fadden 你知道“褪色边缘”（来自可滚动视图）是否会出现在 SurfaceFlinger 的 dumpsys 中？或者它们是在 View 层的渲染器中实现的？
@nmr：将被渲染到图层上。硬件作曲家不这样做。
@fadden 谢谢。我发布了一个后续问题，stackoverflow.com/questions/24297469/why-are-fading-edges-slow 如果您对此感兴趣。

【解决方案2】：

我可以在上面的评论中添加一些内容。在 dumpsys 输出中，我们可以看到图像壁纸、午餐器、状态栏、导航栏的类型是 GLES，这意味着这些层缓冲区由表面抛掷器处理并合成并渲染到 FB 目标中。

谢谢！

【讨论】：