通过 DDMS 方法分析读取我的跟踪（调试 ANR）

Posted 2023-03-06

【中文标题】通过 DDMS 方法分析读取我的跟踪（调试 ANR）

【英文标题】：Reading my trace through DDMS method-profiling (DEBUGGING ANR's)

【发布时间】：2016-08-02 15:40:52

【问题描述】：

问题

所以我的 android 应用程序在 15 分钟过去后立即冻结/无响应（如果触摸屏幕，我会收到 ANR）。该应用程序旨在保持清醒而不是锁定，因为它被用于想要全天使用它的客户。但是，它会在 15 分钟后停止工作，这是一个非常具体的时间，这使得它非常不寻常。我的内存使用率很好，只使用了设备中大约 3% 的内存，而我的应用程序只使用了 14% 的 CPU 负载。

我研究了 ANR，发现它是由 UI 阻塞引起的，所以我打开 DDMS 并在应用程序运行时开始方法分析。下图就是我看到的。

使用黄色调用的方法，进程管理器（见下文）

我的光标所在的另一个红色方法是 String 方法，但我不知道这是否是一个大问题，因为它只持续大约 1 毫秒。

我的问题

大约每 250 毫秒，跟踪会重复一次，我猜进程管理器方法会阻塞 UI 线程一段时间，并在其执行过程中占用一些垃圾收集器时间。见下图。

我相信这是我的问题，但我不知道进程管理器在哪里执行我的代码行。有什么想法吗？我不熟悉使用此方法分析工具。 我唯一的猜测是它看起来要挂载的外部 SD 卡？请看调试图片！

【参考方案1】：

所以我从调试器视图和跟踪中发现，进程管理器阻塞了 UI 线程。从调试视图来看，主线程 STOPPED 在被我的可运行 CheckExternalSdRunnable 调用后运行，运行时间约为 9 毫秒 EVERY 250 毫秒。我想这会导致性能下降，并且无法处理输入事件。我注释掉了这行调用runnable的代码，果然运行了一天左右。

我重新打开方法分析，果然，在主线程上运行的可运行对象消失了，这几乎没有显示任何 UI 阻塞！这一行代码几乎消除了所有其他在短时间内阻塞 UI 线程的较小进程。

遇到相同问题的其他人应该在查看 DDMS 下的方法分析选项时打开调试器并查找阻塞 UI 的进程，然后使用调试器查看主线程并查看代码被调用导致应用程序显示 ANR