我的 Android 应用程序在长时间运行的会话中遇到一些 OutOfMemory 错误。为了找到原因，我尝试使用 Android Studio Profiler，但它停止工作并在使用后 10 秒内冻结应用程序。
这是 Android Studio 屏幕的屏幕截图。它会在第一秒内记录活动，然后冻结应用程序并停止记录任何内容 ->https://ibb.co/QXLhqnz https://ibb.co/QXLhqnz
我的 logcat 读取的最后几行（随着时间的增加，最后几行不断重复，我更改了包名称）
2019-04-09 08:42:41.151 19728-20399/br.com.xxxxx V/StudioProfiler: Live memory tracking enabled.
2019-04-09 08:42:41.151 19728-20399/br.com.xxxxx V/StudioProfiler: JNIEnv not attached
2019-04-09 08:42:41.483 19728-20399/br.com.xxxxx V/StudioProfiler: Loaded classes: 8894
2019-04-09 08:42:51.688 19728-20399/br.com.xxxxx E/zygote: E[0]:Timed out waiting for threads to suspend(br.com.xxxxx), waited for 10.000s
2019-04-09 08:43:01.689 19728-20399/br.com.xxxxx E/zygote: E[0]:Timed out waiting for threads to suspend(br.com.xxxxx), waited for 20.000s
2019-04-09 08:43:11.689 19728-20399/br.com.xxxxx E/zygote: E[0]:Timed out waiting for threads to suspend(br.com.xxxxx), waited for 30.000s
如有任何帮助，请提前致谢。
Android Studio Profiler 可能不是适合该任务的工具。首先识别可能的内存泄漏金丝雀泄密 https://square.github.io/leakcanary并修复它们，
那么您应该能够使用探查器，而无需停止/终止线程。如果没有提供最少的代码，这可能是最好的答案。
这种行为的原因可能是，ART 杀死停滞的线程，而 Profiler 一直等待它们响应，这显然永远不会发生，因为它们不再存在。
错误信息来自ART，只需查看thread_list.cc https://android.googlesource.com/platform/art/+/master/runtime/thread_list.cc。在 Dalvik VM 上，它的行为可能有所不同（最有可能由于 OOM 强制关闭，或者可能使 VM 崩溃）。这可能值得一试。在分析时介入它也可能是一种选择，但它到目前为止不如 LeakCanaray 那么方便。
Update：Android Studio 3.6.2 发行说明指出：
改进了使用分析器时对活动和片段的内存泄漏检测。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
