是否有adb命令dumpsys SurfaceFlinger的输出？

在我特别想了解什么是HWC或GLES层类型，又是什么numHwLayers意思？

下面是dumpsys SurfaceFlinger的，我说的是部分：

  mDebugForceFakeVSync = 0
  显示[0]：768x1280，xdpi = 319.790009，ydpi = 318.744995，刷新= 16666667
  numHwLayers = 5，旗帜= 00000000
    键入|办理|提示|旗帜| TR |混合|格式|源作物|框架名
------------+----------+----------+----------+----+-------+----------+---------------------------+--------------------------------
       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]导航栏
  FB目标| b7dd3ab0 | 00000000 | 00000000 | 00 | 00105 | 00000001 | [0，0，768，1280] | [0，0，768，1280] HWC_FRAMEBUFFER_TARGET
 

解决方案

好吧，我有足够的想通了，回答我的问题，但如果任何人有任何其他的输入，请留下他们的意见。有遇到了一些额外的东西，我会注意到下面仍然是不明确的。

首先，下面的链接有助于解释如何图像渲染及合成发生通过SurfaceFlinger几件事情： http://source.android.com/devices/graphics.html

如果你在链接注意到，有两种方式图像被发送到显示。一个是将它们发送到显示之前处理与GPU的图像，而另一种是使用在显示器的硬件覆盖绕过GPU和直接图像发送到显示器。后一种方法的性能会更好，但你被限制为一定数量的层/覆盖（通常为4）。如果您有更多的层，事情已经得到由GPU进行处理。

这是在我的问题的中心dumpsys SurfaceFlinger的一部分，显示你有多少层有目前dumpsys叫，如果这些层是由硬件作曲（HWC）或者GPU（GLES）正在处理。这说明了什么HWC和GLES意思。此外，numHwLayers是多少重叠显示屏支持（通常为4个）。

此外，还有源作物和框架的坐标。源作物是将要显示的图像的部分。例如，如果它是一个壁纸跨越多个显示屏幕（想想你在主屏幕上看到当您在屏幕上滑动），然后在一个给定的时刻，你只需要一个更大的墙纸图像显示的分段。这意味着，源作物只是告诉你，你是目前使用整体形象的什么部分。它的框架部分是其中源图像的该部分将要实际上是显示在屏幕上。

在code本节dumpsys SurfaceFlinger命令就设在这里： \框架\本地\ SERVICES \ surfaceflinger \ DisplayHardware \ HWComposer.cpp

这是在一个名为HWComposer ::转储功能

以上回答我原来的问题，但下面是我发现一些额外的东西：

它看起来像有比HWC和GLES更多种组合类型。在code上面提到的，我看到一个背景和FB目标的复合型。 FB目标似乎永远是present当您在亚行输入dumpsys SurfaceFlinger。我认为FB目标简直是帧缓冲区完整的图像将被写入（有人请确认这一点）。即使设备处于睡眠状态，你看到这个FB目标。我不明白的是，这是什么背景类型？我甚至不能采取一个猜测。请发表评论，如果你知道这是什么。

谢谢！

Is there any documentation on the output of the adb command "dumpsys SurfaceFlinger"?

In particular, I'd like to understand what is the difference between an HWC or GLES layer type, and what does numHwLayers mean?

Here is the section of dumpsys SurfaceFlinger I'm talking about:

  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

Ok, I have enough figured out to answer my own question, but if anyone has any additional input, please leave them in the comments. There's some additional stuff encountered which I'll note below that still isn't clear.

First, the link below helps explain a few things about how image rendering and compositing happens through SurfaceFlinger: http://source.android.com/devices/graphics.html

If you noticed in the link, there are two ways images are sent to the display. One is to process images with the GPU before sending them to the display, and the other is to use hardware overlays of the display to bypass the GPU and send images directly to the display. The latter method performs better, but you are limited to a certain number of layers/overlays (usually 4). If you have more layers, things have to get processed by the GPU.

The part of dumpsys SurfaceFlinger which was at the center of my question shows you how many layers there are at the moment dumpsys was called, and if those layers are being handled by the Hardware Composer (HWC) or the GPU (GLES). This explains what HWC and GLES mean. Also, numHwLayers is how many overlays the display supports (usually 4).

Also, there are "source crop" and "frame" coordinates. The source crop is the section of an image that will be displayed. For example, if it's a wallpaper that spans multiple display screens (think about what you see on the home screen when you swipe across screens), then at a given moment you will only need a subsection of that larger wallpaper image to display. This means that source crop is just telling you what section of that overall image you are using at the moment. The frame part of it is where that section of the source image is going to actually be display on the screen.

The code for this section of the dumpsys SurfaceFlinger command is located here: \frameworks\native\services\surfaceflinger\DisplayHardware\HWComposer.cpp

It's in a function called "HWComposer::dump"

The above answers my original question, but below are some additional things I noticed:

It looks like there are more composition types than HWC and GLES. In the code noted above, I see a "BACKGROUND" and a "FB TARGET" composite type. FB TARGET seems to always be present when you type "dumpsys SurfaceFlinger" in adb. I think FB Target is simply the frame buffer the complete image will be written to (someone please confirm this). Even if the device is asleep you see this FB TARGET. What I don't understand is, what is this BACKGROUND type? I can't even take a guess on that one. Please leave a comment if you know what this is.

Thanks!