当Traceview方法概要分析正在运行时，MediaCodec不会返回缓冲区

Question

启用Traceview方法分析时，MediaCodec似乎不返回输入或输出缓冲区。重现的步骤：

1. 在Eclipse中，运行Grafika。
2. 在Grafika中，选择“播放视频（TextureView）”并点按“开始”。
3. 在Eclipse DDMS中，单击“启动方法概要分析”并保持对话框处于打开状态。
4. 在Grafika中，点击“播放”并快速返回Eclipse并单击“确定”。单击“确定”后，Grafika将显示为挂起（它不会再绘制任何帧）。

Grafika详细日志显示，在停止方法分析之前，MediaCodec没有输入或输出缓冲区。

我的猜测是MediaCodec做了一些Looper的东西，可能与Traceview的实现方式有冲突，但这只是猜测。

这是一个已知问题吗？有没有办法解决它并使用MediaCodec配置应用程序？

Answer 1

糟糕。

从dalvik/vm/Thread.cpp（第2105行）：

/*
 * If we're doing method trace profiling, we don't want threads to exit,
 * because if they do we'll end up reusing thread IDs.  This complicates
 * analysis and makes it impossible to have reasonable output in the
 * "threads" section of the "key" file.

通常情况下这很好 - 如果线程正在退出，它就没有什么可做的了，所以如果我们将它保持更长时间并不重要。 Thread#join()的信号已经发生，所以没有什么可做的了。

但在这种情况下，线程暂时通过提供ACodec回调的本地onFrameAvailable()线程附加到VM。所以这个纯原生线程想要将自己附加到VM，调用回调，分离自己，然后重新开始工作。但是因为方法分析是活动的，所以线程分离会停止，直到方法分析完成...但是在代码执行恢复之前，方法分析将不会完成。所以我们陷入僵局。

所以这里有两个问题：

1. Dalvik不应该保持线程活着。它会使方法分析变得更复杂，因为它丢失了方便的唯一线程ID，但这只是一个内务管理问题。
2. 每次想要发送“可用帧”消息时，libstagefright都不应该附加和分离。这是一个相对昂贵的操作，需要分配一个Thread对象，阻止尝试运行无分配。

我没有看到通过更改应用程序解决此问题的简洁方法 - 您必须在没有框架可用通知的情况下进行操作。最好的办法是放弃TraceView分析，改为使用systrace。