在我的 Android 应用程序的长时间运行 session 中，我遇到了一些 OutOfMemory 错误。为了找到原因，我尝试使用 Android Studio Profiler，但它停止工作并在使用后 10 秒内卡住应用程序。
有一个 Android Studio 屏幕的屏幕截图。它会在第一秒内记录 Activity ，然后卡住应用程序并停止记录任何内容 -> 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 可能不是该任务的合适工具。首先使用 LeakCanary 识别可能的内存泄漏并修复它们，
那么您应该能够使用 Profiler，而不会停止/杀死线程。如果没有提供最少的代码，这可能是最好的答案。
这种行为的原因可能是，ART 杀死了停滞的线程，而 Profiler 一直在等待它们响应，这显然永远不会发生，因为它们不再存在。
错误信息来自ART，见 thread_list.cc .在 Dalvik VM 上，它的行为可能不同(很可能是由于 OOM 而强制关闭，或者它可能会使 VM 崩溃)。那可能值得一试。在进行分析时介入它也可能是一种选择，但它远不如 LeakCanaray 方便。
更新 :Android Studio 3.6.2 发行说明状态:
Improved memory leak detection for your Activities and Fragments when using Profilers.
关于android - 我的应用程序在分析模式下运行时停止响应，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/55592239/