我正在使用它进行一些信号处理。除了屏幕关闭和显示器旋转时，一切都很好。通常情况下，屏幕关闭只会产生一个"活动"onPause（），但当屏幕旋转时，它会变为：onPause。也就是说，安卓系统似乎先"打开"了屏幕。
不幸的是，这似乎会使AudioRecord以某种未知的方式崩溃或冻结。
我让它全部运行的基本方法是在onResume（）中启动一个新线程，它实例化一个AudioRecord实例，设置它，开始录制，然后进入一个循环：
keepProcessing = true;
while (keepProcessing)
// read a block of data and process
在UI的onPause（）中，线程keepProcessing（一个易失性变量）被清除，然后等待工作线程停止。
if (thread.isAlive()) {
keepProcessing = false;
thread.join();
}
thread = null;
当另一个线程退出keepProcessing循环时，它停止录制，释放AudioRecord资源，丢弃AudioRecord实例并终止。
作为一种通用的启动/停止机制，这一切都很好。使用断点和adb进行检查，一切似乎都按正确的顺序进行。它只是在这个屏幕旋转的场景中不起作用。我只能认为这是因为在旧的"活动"中一切停止后，新的"活动onCreate（）"等非常快速。也就是说，录音机里有些东西仍然很忙。当一个人试图再次打开屏幕时，一切都会冻结。
如果我伪造AudioRecord代码，使其不会真正开始录制，循环只是静止不动，然后再也不会停止录制，那就没问题了。只有当录音机进入录制模式时，它才会出错。
有什么建议吗？
当您旋转设备时，您的活动实际上会停止并被破坏。如果你有后台线程在工作，这完全会让你不知所措。最好的解决方法是告诉Android不要这样做，将android:configChange="orientation"添加到该活动的清单中。是的，这是谷歌做出的一个糟糕的架构决策，令人讨厌，以至于我几乎建议为所有活动添加它。
是的，我能看到，我刚刚发现发生了什么，就这样。
由于初始化keepProcessing标志时出现错误，因此存在竞争条件，当"活动"停止时，后台线程可能仍在运行。
"如果你有后台线程在工作（当活动停止时），这完全会让你不知所措"
你说得很对。确实如此。