Android系统稳定性-ANR.docxVIP

Android 系统稳定性 - ANR1.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，进程号是127I/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 3I/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: keyDispatchingTimedOutE/ActivityManager( 127): Load: 3.85 / 3.41 / 3.16 //请注意ago，表示ANR发生之前的一段时间内的CPU使用率，并不是某一时刻的值E/ActivityManager( 127): CPU usage from 26835ms to 3662ms ago with 99% awake:E/ActivityManager( 127): 9.4% 98/mediaserver: 9.4% user + 0% kernelE/ActivityManager( 127): 8.9% 127/system_server: 6.9% user + 2% kernel / faults: 1823 minor... ...E/ActivityManager( 127): +0% 5033/com.example.anrdemo: 0% user + 0% kernelE/ActivityManager( 127): 39% TOTAL: 32% user + 6.1% kernel //这里是later，表示ANR发生之后E/ActivityManager( 127): CPU usage from 601ms to 1132ms later with 99% awake:E/ActivityManager( 127): 10% 127/system_server: 1.7% user + 8.9% kernel / fau