问题标签 [surfaceflinger]

我想计算 FPS 以检测基于现有 Android 分析工具的应用程序的性能问题。

我注意到在 Systrace 上，它可以记录 performTraversals 的长度。据我所知，performTraversals 执行测量、布局和绘制，其中包括更新框架时的大部分工作。那么 performTraversals 能否具有足够的代表性来衡量一个帧是否需要 60 毫秒才能更新？

我还注意到 Systrace 记录了在 SurfaceFlinger 上花费的时间。我知道 SurfaceFlinger 用于渲染目的，但我不知道帧的确切起点和终点。我是否还应该考虑花在 SurfaceFlinger 上的时间和帧速率？（虽然我确实观察到 SurfaceFlinger 比 performTraversals 执行的频率更高，这意味着 SurfaceFlinger 可能不一定遵循 performTraversals。它也会在其他场景中触发。）

PS 我知道 sysdump gfxinfo，但它只能记录 128 帧（~2 秒），而我想要的可能会持续更长时间。

我尝试遵循 Android Jelly bean 4.2 中的 wifi 显示代码。在wifi显示中，PlaybackSession该类将负责获取数据。最后它将从一个名为 的类中获取数据，该类SurfaceMediaSource继承自MediaSource。数据BufferQueue在SurfaceMediaSource. 但我找不到谁负责将数据写入BufferQueue. 我相信SurfaceFlinger应该这样做。但是，我找不到任何特定的代码。有谁知道它是如何工作的？

我最近（使用 Odin）为我的 SGS2 安装了最新的库存 ROM，而没有擦除数据。之后我放了一个根内核并开始使用。

我发现： - 如果我启动手机，让它进入锁定屏幕（第一个出现在三星徽标之后），然后用电源按钮关闭屏幕，一切正常 - 如果我不关闭屏幕，启动过程出错并且全部冻结；我只能强制重新启动它。

我拿了两双靴子的 logcat 并在有故障的靴子中发现了这些错误。注意：我削减了 SIGSEGV 的某些部分以保持在 30000 个字符的限制内。

任何人都可以帮助解决问题吗？

谢谢！！！

[………………]

有人熟悉 LogCat 中的以下错误吗？

10-21 19:45:42.476: E/SurfaceFlinger(155): layer=0x7486e0 is not in the purgatory list

我阅读了“SurfaceFlinger”，它似乎负责 Android 上的图形渲染，但我很难找到任何涵盖炼狱列表的文档。另一个问题提到了类似的错误（但他们没有得到回复）。

我正在尝试用 jellybean 4AJ.2.5P2 启动 blaze 板。当我尝试启动时，出现以下错误。

我使用了以下引导参数：

这些是我得到的日志。

我搜索了很多，我找不到任何有用的东西。

任何帮助将不胜感激！

谢谢！

更新：

我们在内核中改变了很多。现在上面提到的错误已经不复存在了。但是，我面临着表面抛油器的问题。

启动Surface Flinger时发生crash，最后logcat显示“service 'SurfaceFlinger' dead”

我在下面附上了最近的日志。

请帮我调试一下。

任何指导将不胜感激！

很奇怪，在 systrace 工具中，当我看到 Surfaceflinger 执行绘图命令和窗口合成时，这是在 CPU 上运行而不是在 GPU 上运行。但根据 Romain Guy 的谷歌谈话，他们告诉我们绘图命令的这种组合和执行是在 GPU 上执行的。我的设备有 GPU，即使他们使用的是 CPU 内核。我认为如果 CPU 内核是免费的，那么它使用 CPU 内核，否则它使用 GPU。

在浏览 Android Graphics 上在线可用的材料时，我几乎没有与 Android Graphics 相关的查询：

1. 什么是窗口？它与 View 有什么关系？
2. 每个应用程序都有自己的 Window 吗？
3. 一个应用程序可以有多个窗口吗？
4. 当 Surfaceflinger 组成表面时，它是否也组成了窗口？

我也经历了其他问题，但这些问题对我来说仍然不清楚。

在创建 Surface 时，有一个与之关联的缓冲区，用于保存与此 Surface 相关的所有画布数据。并且在 android 应用程序中一次可以创建多个表面。

所以我对此表示怀疑，因为像 3 这样的帧缓冲区数量有限，每个表面的数据如何映射到将被更新的最终帧缓冲区？

我在SO中遇到了关于Adaptive Playback的这个通用问题。Android Kitkat但是，我有一些具体的查询如下：

我能够理解对codec相关框架的影响。但是，有一点我无法完全理解。

在自适应播放的情况下，编解码器metadata在其输出端口上使用一个基本上抽象和打包底层缓冲区句柄（很可能是gralloc句柄）的输出端口。如果分辨率发生变化，我假设直接codec更新gralloc句柄属性并将缓冲区发送回OMX客户端而不更改端口设置。

我的第一个问题是：我的理解和假设是否正确？

如果是这样，Surfaceflinger/如何SurfaceTexture知道传入的有效负载是metadata格式的，它如何从底层实现中检索width和？heightgralloc

您能否指出相关来源，这将有助于我更好地理解这个问题？

提前谢谢了。

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

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

这是我正在谈论的dumpsys SurfaceFlinger部分：