Android系统稳定性-ANR[整理].pdf

实用标准文案 Android 系统稳定性 - ANR 1.2 如何分析 ANR问题 引起 ANR问题的根本原因，总的来说可以归纳为两类： 应用进程自身引起的，例如： 主线程阻塞、挂起、死循环 应用进程的其他线程的 CPU占用率高，使得主线程无法抢占到 CPU时间片 其他进程间接引起的，例如： 当前应用进程进行进程间通信请求其他进程，其他进程的操作长时间没有反馈 其他进程的 CPU占用率高，使得当前应用进程无法抢占到 CPU时间片 分析 ANR问题时， 以上述可能的几种原因为线索， 通过分析各种日志信息， 大多数情况下你 就可以很容易找到问题所在了。 注意： 确实有一些 ANR问题很难调查清楚， 因为整个系统不稳定的因素 很多，例如 Linux Kernel 本身的 bug 引起的内存碎片过多、硬件损坏 等。这类比较底层的原因引起的 ANR问题往往无从查起，并且这根本不 是应用程序的问题， 浪费了应用开发人员很多时间，如果你从事过整个 系统的开发和维护工作的话会深有体会。 所以我不能保证了解了本章的 所有内容后能够解决一切 ANR问题，如果出现了很疑难的 ANR问题，我 建议最好去和做驱动和内核的朋友聊聊， 或者，如果问题只是个十万分 之一的偶然现象，不影响程序的正常运行，我倒是建议不去理它。 1.2.1 分析 ANR的利器 Android 会在 ANR发生时输出很多有用的信息帮助分析问题原因，我们 先来看一下 ANR的异常信息，使用 logcat 命令查看会得到类似如下的 log ： //WindowManager 所在的进程是 system_server ，进程号是 127 I/WindowManager( 127): Input event dispatching timed out sending to com.example.anrdemo/com.example.anrdemo.ANRActivity 精彩文档 实用标准文案 //system_server 进程中的 ActivityManagerService 请求 kernel 向5033进 程发送 SIGNAL_QUIT请求 // 你可以在 shell 中使用命令达到相同的目的： adb shell kill -3 5033 // 和其他的 Java 虚拟机一样， SIGNAL_QUIT也是 Dalvik 内部支持的功能之 一 I/Process ( 127): Sending signal. PID: 5033 SIG: 3 //5033 进程的虚拟机实例接收到 SIGNAL_QUIT信号后会将进程中各个线程的 函数堆栈信息输出到 traces.txt 文件中 // 发生 ANR的进程正常情况下会第一个输出 I/dalvikvm( 5033): threadid=4: reacting to signal 3 I/dalvikvm( 5033): Wrote stack traces to /data/anr/traces.txt ... ...// 另外还有其他一些进程 // 随后会输出 CPU使用情况 E/ActivityManager( 127): ANR in com.example.anrdemo (com.example.anrdemo/.ANRActivity) //Reason 表示导致 ANR问题的直接原因 E/ActivityManager( 127): Reason: keyDispatchingTimedOut E/ActivityManager( 127): Load: 3.85 / 3.41 / 3.16 // 请注意 ago，表示 ANR发生