Question

我有一个应用程序，其中有几个线程，每个线程都被设置为MODE_STREAM的单独AudioTrack。在应用程序之间切换工作正常，当应用程序正常关闭时，它似乎正确关闭所有内容。

但是，如果应用程序在外部终止，例如从调试器终止，或者因为我刚刚在旧版本运行时安装了新版本，似乎全局AudioMixer中的某些状态搞砸了，我得到了logcat输出如：

09-16 14:50:38.965   298  7150 W AudioTrack: obtainBuffer timed out (is the CPU pegged?) 0x83c2348 user=00000eb3, server=00000000
09-16 14:50:39.025  7066  7132 W AudioTrack: obtainBuffer timed out (is the CPU pegged?) 0x8249d40 user=00002000, server=00000000
09-16 14:50:40.277   298  7156 W AudioTrack: obtainBuffer timed out (is the CPU pegged?) 0x84cb810 user=00000eb3, server=00000000

并且没有使用AudioTrack的应用程序能够再次播放音频，直到我重新启动设备。在此特定日志片段中，PID 298是system_server，7066是应用程序的新实例。

我认为发生的事情是AudioTrack在作家线程有机会清理之前就消失了。这让我觉得我应该做些什么来清理。我已经捕获了我的Activity onStop和onDestroy并关闭了我的音频线程，但还有另一个地方需要这样做吗？

此外，还有更好的方法来清理AudioTrack吗？看起来Android的这一部分特别脆弱，但是我无法想象每个人都会使用SoundPool和MediaPlayer来处理所有事情，因为这些API非常有限且非常繁琐（而且两者似乎都以不同的方式包装AudioTrack）。

Answer 1

不幸的是，您的应用在被操作系统杀死并被新版本替换之前不会收到警告。您可以使用一个非常简单的Activity来测试它，其中onStause（）onStart（）onStop（）和onDestroy（）方法产生日志消息。如果您安装了新版本的应用程序，则onStop（）和onDestroy（）方法中的消息永远不会生成。

关于AudioTrack问题，这可能是设备的音频驱动程序的错误。 Some people trying to port Android get similar problems due to bad drivers。此外，这个问题的其他答案之一让我也相信这一点。如果这个问题仅限于来自少数制造商而非所有手机的手机的一部分，那么这表明制造商的声音驱动器是坏的。

您是否考虑过使用MediaPlayer API而不是AudioTrack。它没有相同的灵活性，但它可能是一个可行的解决方法。 Here is a nice comparison of the three different audio apis

一个可能的解决方法是将应用程序实际拆分为两个单独的apks以进行调试。一个人什么也不做，只播放音频，并由第二个应用程序控制。这样，无论何时安装更新的控制器，播放音频的二进制文件都不受影响，并且不会遇到突然终止和重新安装。然后，当您准备分发应用程序时，只需将两者合并为一个apk，然后分发即可。

Answer 2

我从我开发的许多摩托罗拉设备中了解到这个特殊问题。你的设备是Droid系列吗？无论如何，我能说的最好的事情是摩托罗拉应该多次被告知这一点，直到他们费心去解决它。

杀死进程会绕过Activity的生命周期，所以你没有做错任何事。

AudioTrack的全球死亡

2 个答案: