我如何跟踪和解决Android应用程序的BLASTBufferQueue伪造releaseBufferCallback问题？

Question

我最近开始使用Kotlin和Jetpack Compose构建我的第一个应用程序。到目前为止，我在Logcat中没有看到这个错误，并且由于我的经验不足，我感到困惑！我正在清理代码，将函数提取到其他类文件中，清理我制作的Composables之一的UI，现在我正在不断地获得BLASTBufferQueue的Logcat条目，其具有以下条目：

14:03:10.687  E  [VRI[MainActivity]#0](f:0,a:3) Faking releaseBufferCallback from transactionCompleteCallback
14:03:10.687  E  [VRI[MainActivity]#0](f:0,a:3) Faking releaseBufferCallback from transactionCompleteCallback
14:03:10.704  E  [VRI[MainActivity]#0](f:0,a:3) Faking releaseBufferCallback from transactionCompleteCallback
14:03:10.704  E  [VRI[MainActivity]#0](f:0,a:3) Faking releaseBufferCallback from transactionCompleteCallback
14:03:10.722  E  [VRI[MainActivity]#0](f:0,a:3) Faking releaseBufferCallback from transactionCompleteCallback
14:03:10.722  E  [VRI[MainActivity]#0](f:0,a:3) Faking releaseBufferCallback from transactionCompleteCallback
14:03:10.738  E  [VRI[MainActivity]#0](f:0,a:3) Faking releaseBufferCallback from transactionCompleteCallback

这似乎在每次重新组合时发生，但我不知道我改变了什么导致它。

这段代码是否相关？

在使用模拟器时似乎没有问题，目前是可调整大小的 API 33。

但是在使用物理设备 Pixel 7 Pro 时出现了问题。

现在，在物理设备上，自从我上次开发应用程序以来，我已经更新了12月的更新（构建号：TQ1A.221205.011）。更新是否会导致这些 Logcat 条目中的更改？

- Dolanaj

---

我来发布同样的问题。在应用了2022年12月相同的更新后，这些logcat条目开始出现在我的Pixel 7上。我的应用程序已经存在几年了，但仍在积极开发中。它针对API 33，并完全使用Java编写，没有最近的重大更改。很可能是与更新相关的某些内容是如此新颖，以至于还没有得到太多关注。 - mike47

我在 Pixel 6 上也遇到了一百行的这个问题。 - DadNapper

我遇到了同样的问题。不确定它来自哪里，但现在我通过在“package:mine”之后将-tag~:BLASTBufferQueue添加到logcat过滤器输入字段中来隐藏它们。 - Kenneth Saey

从CLI：adb logcat BLASTBufferQueue:S（其中“S”表示静默） - Patrick Decat

Pixel 5 上也有同样的问题，是不是谷歌工程师忘记禁用日志了？ - Alan Lu

Answer 1

以下是我关于这个问题得到的一些发现。

1) 什么是BlastBufferQueue？

我相信这可能发生在Android S及以上版本，而且是在2022年12月更新之后。 BlastBufferQueue是一种消息队列，在应用程序布局窗口的几何形状改变时，将被提交到 Android 平台的表面渲染器。由多个应用程序发送的缓冲区将被同步。

在 Android S 之前，更改将通过 Transaction 发布。在此处，当它们从多个应用进程发送时，缓冲区不会被同步。

这个 BlastBufferQueue 帮助打开来自多个应用程序进程发送的缓冲区之间的连接。

了解更多关于 BBQ 的链接：

https://www.jianshu.com/p/50a30fa6952e

https://www.jianshu.com/p/cdc60627df90

以下是代码，其中 blastbuffer 是从 ViewRootImpl 更新的：

源代码链接

2) 日志的根本原因。

我找到了添加此特定日志的提交。

提交链接

这是一个修复问题的解决方案，在某些情况下，当视图事务得到更新但缓冲区回调未被释放时，将会发生 ANR。因此，当 TransactionCompleteCallback 完成时，此提交是虚拟释放缓冲区回调的解决方法。

在这个提交中，提到了这是一个安全的解决方法。与提交相关联的根本问题是私有的。 这是 Android 团队添加的虚假发布缓冲回调的提交更改。这可能是您收到此日志的原因。

最后，总结一下，可以安全地忽略此日志。

编辑： 我看到一些人由于某些溢出而遭遇致命崩溃。我们必须等待 Greg 提出的 问题 的修复。 暂时，在 Logcat 窗口中可以将日志静音。请参考问题下面的评论。

- Gowtham K K

---

这是关于此主题的有趣信息！上面@ahandyapp的评论之一提到他遇到了崩溃，并且BlastBufferQueue日志条目是他得到的唯一信息，“然而，当应用在带有许多监听器之间的视频流上执行艺术风格转换时，会发生崩溃，除了BLASTBufferQueue消息外，没有其他错误信息-所以它并非完全无害。”不过，根据你的回答，似乎他遇到的崩溃可能与BlastBufferQueue无关。另外，BBQ条目始于Android 13，即2022年12月更新后，而在12月之前它并未启动。 - Dolanaj

感谢您的调查！由于似乎还没有相关问题，我已经为这个日志垃圾文件提交了一个Android问题：https://issuetracker.google.com/issues/271675642 - Greg Price

“可以安全地忽略”除非它以错误级别记录。并且记录了大量副本。这不是正常工作软件的行为方式。 - Jon Watte

哈哈，忽略一堆日志... 那性能呢？！除非Proguard/R8剥离了Log.e()（和本地代码的LOGE()），否则会有显著影响。 - l33t

看起来已经修复了。我的logcat中不再有一堆BlastBufferqueue错误了。可能是四月更新解决了这个问题？ - Martin