怎么使用Android ANR分析trace文件的产生流程
这篇文章主要介绍“怎么使用Android ANR分析trace文件的产生流程”,在日常操作中,相信很多人在怎么使用Android ANR分析trace文件的产生流程问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”怎么使用Android ANR分析trace文件的产生流程”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
前言
首先收集需要dump trace的进程并给对应进程发送dump trace的信号
当一些带有超时机制的系统消息(如:Service的创建)判定超时后,会调用系统服务AMS接口,收集ANR相关信息并存档(data/anr/trace, data/system/dropbox)
进入到AMS中,AppError会先进行筛选(1.当前进程正在进行dump流程 2.已经发生crash 3. 已经被系统kill 4.系统是否正在关机等情况),如果都不符合,则认为当前进程发生了anr。
接下来系统在判断当前ANR进程对用户是否可感知,然后开始统计与该进程由关联的进程,或者一些系统核心服务进程的信息(例如与应用交互的SurfaceFligner,System Server等系统进程),如果这些系统服务进程在响应时被阻塞,那么将导致应用进程IPC通信过程被卡死。接着获取其他系统核心进程,因为这些服务进程是init进程直接创建的,并不在SystemServer或Zygote进程管理范围。 >firstPids队列:第一个是ANR进程,第二个是system_server,剩余是所有persistent进程; Native队列:是指/system/bin/目录的mediaserver,sdcard 以及surfaceflinger进程; lastPids队列: 是指mLruProcesses中的不属于firstPids的所有进程。
在收集完第一步信息后,接下来便开始统计各进程本地的更多信息,如虚拟机信息,java线程状态及堆栈。首先会弹出一个ANR的对话框,然后向UI线程发送SHOW_NOT_RESPONDING_MSG消息
5.当UI线程收到该消息后,会调用dumpStackTraces函数:
最重要的一点:向目标进程发送SINAL_QUIT(进程中的Signal Catcher会进行阻塞检测收集信息后面讲),firstPids列表中的进程, 两个进程之间会休眠200ms, 可见persistent进程越多,则时间越长. top 5进程的traces过程中, 同样是间隔200ms, 另外进程使用情况的收集也是比较耗时.
总结;
>将am_anr信息输出到EventLog(分析anr问题时先看该log) 获取重要进程的信息,java进程的,和native的进程 将ANR的Reason和CPU使用的情况输出到main_log 在将CPU使用情况和进程的trace文件信息,在保存到drpobox文件下 向收集到的进程发送SINAL_QUIT信号。
接着分析最后一步向收集到的进程发送信号
(Android5.0之前是dump用的SuspendAll线程,收集信息之后用ResumeAll恢复。在5.0之后采用的是checkPoint进行dump信息)
发生ANR时,systemServer进程会执行dumpStackTraces函数,在该函数中发SIGQUIT信号给对应的进程(上面有分析到) 处于安全考虑,进程之间是相互隔离的,即使系统进程也无法获取其他进程的信息,所以要借助于IPC通信,将指令发送到目标进程,目标进程接收到消息后,协助完成自身进程Dump信息并发送给系统进程。Android P 流程:
一个进程接收到了SIGQIUT信号的时候,SingaCatcher线程的WaitForSignal函数会返回接着会调用到HandlerSigQuit()函数。
2.hindleSigQuit()函数为:
3.DumpForSigQuit()函数:
这是读取的信息,但是什么时候去读取呢(什么时候才能保证获取到的却是是需要的东西,例如GC信息,当前分配了多少对象,这些打印一般都需要在suspend当前进程里面的所有的线程),接下来先分析这个suspend过程:
这个挂起SupendAll实在Thread_list.cc中实现的,他的作用就是用来suspend当前进程里面所有其他的线程(一般发生在GC,DumpForSigQuit等过程中)。SuspendAll过程实现最重要的就是ModifySupendCount(self,+1,false)这段语句他会修改对应Thread对象的suspend引用计数:
因为传入的delta值是+1所以会先执行AtmoicSetFlag()利用原子操作设置了KSuspendRequest标志位,代表当前这个线程有挂起请求。什么时候会进行检测这个标志位呢?这里涉及到了checkPoint的知识点最后讲解(在线程运行中进行上下文切换(例如java线程转换为Native线程)时就会运行CheckSuspend函数,这个函数才是真正的把当前线程suspend:
可以看到检测到了KSuspendRequest标记就会执行FullSuspend函数,KSuspendRequest标志位是用来dump线程的堆栈的,分析完了SuspendAll之后,再继续分析FullSuspendCheck函数:
调用TransitionFromRunnableToSuspend()这个函数后,线程就进入了KSuspended状态,然后在调用TransitionFromSuspendedToRunnablecpm函数从Suspend状态切换到Runnable状态的时候会阻塞在一个条件变量上,除非调用SuspendAll的线程接着又调用了ResumeAll()函数,要不然这些线程就会一直被阻塞住。 4.现在就把SuspendAll的流程分析完了,但是dump线程堆栈的时候并不是在设置了挂起标志位(KSuspendRequest)后执行的,与他相关的是另外一个标志位KCheckpointRequest,接下来看一下Thread_list的Dump函数,这个函数会在Thread_list的DumpForSigQuit中会被调用到,也就是在Signal Cathcer线程处理SIGQUIT信号的过程中。
这个函数先创建了一个叫DumpCheckPoint对象checkpoint,然后调用了RunCheckpoint将这个对象传入,这个函数会返回现在处于Runnable状态的线程个数,接着 调用了WaitForThreadsToRunThroughCheckpoint()等待这些处于Runnable的线程都执行完DumpCheckpoint的Run函数,如果等待超时就会报错。
接着分析RunCheckPoint函数,先看前一部分:
对于处于Runnable状态的线程执行它的RequestCheckpoint函数会返回true,其他状态的线程则会返回false。对于这些非Runnable状态的线程就会像SuspendAll一样会设置KSuspendRequest标志位,后面状态切换的时候就会检查这个标志位挂起。同事RunCheckPoint函数会把这些线程统计到suspend_count_modified_threads这个Vector变量中,在这个变量中的线程,Singal Catcher线程会主动触发他们的dump堆栈过程。接下来再看看这个RequestCheckpoint函数
最后一行设置kCheckpointRequest标志位,在刚才线程切换运行状态时会执行CheckSuspend函数在检测kCheckpointRequest标志位的时候会执行RunCheckpointFunction函数,接着会执行这个checkpoints里面元素的run函数:
(这个存储的其实就是Thread中的RequestCheckpoint在这里不仅设置了标志位还把参数设置为元素的值,这个参数就是Dump里面调用RunCheckpoint传过来的,其实就是DumpCheckpoint)。 ,所以也就是执行DumpCheckpoint的run函数:
其实就是调用了Thread的Dump函数,线程的java堆栈,Native堆栈和Kernel堆栈就是在这里打印的,刚才说对于处于Runnable状态的线程是通过调用他们的RequestCkeckPoint函数,然后它们自己去dump当前堆栈的,而那些不处于Runnable状态的线程则是添加到了一个Vector的变量中,接着就分析RunCheckPoint函数的第二部分:
对于这些不是Runnable状态的线程,他们可能不会主动去调用Run函数,所以只能有Signal Catcher线程去帮他们Dump,至于DumpCheckpoint的Run函数的功能和Runnable状态的线程是一样的,都是打印线程堆栈,并且最后修改引用计数让这些线程在切换状态时继续运行。
总结:
>1.SingalCatcher线程接收到信号后,首先Dump当前虚拟机有关信息(内存状态。对象,加载class,GC等相关信息) 2.接下来会设置每个线程的标记为(check_point),和请求线程状态(suspend)。当线程运行过程中进行上下文切换时,会检查该标记。如果发现有挂起请求,会将自己主动挂起。等到所有线程都挂起之后,SingalCatcher线程开始遍历Dump各个线程的堆栈和线程数据后再唤醒线程。如果某个线程一直无法挂起导致超时,那么本次Dump流程失败抛出异常.
大致流程(Android5.0之前):
checkPoint:
先讲解safePoint,对于ART编译的代码,可以定期轮询当前Runtime来确认是否需要执行某些特定代码;可以认为这些轮询时的点,就是safepoint;safepoint可以用来实现暂定一个java线程,也可以用来实现Checkpoint机制; 例: 当正在执行java代码的线程A执行到safepoint时,会执行CheckSuspend函数,在发现当前线程有 checkpoint request时, 会在这个点执行线程的CheckPoint函数;如果发现当前线程有suspend request时,会进行SuspendCheck,使得线程进入Suspend状态(暂停); 所以说,ART CheckPoint应该是safepoint的一个功能实现;
到此,关于“怎么使用Android ANR分析trace文件的产生流程”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注编程网网站,小编会继续努力为大家带来更多实用的文章!
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341