简介
ANR对于每一个Android开发这来说都不陌生，当然大家都知道，ANR产生的原因是在主线程执行耗时任务导致的，比如在广播，服务，UI主线程都不会有不同的超时限制，执行时间超过这个时间限制就会出现ANR。
疑问
- 为什么广播，服务，UI主线超时时间不同，系统是怎么设置的呢？
- ANR实现原理是什么？
- ANR后，系统有做了写什么？
- 为什么在Activity的onCreate里面执行耗时任务，不会出现ANR呢？
ANR和SNR
- 属于应用程序的范畴，这不同于SNR(System Not Respoding)，SNR反映的问题是系统进程(system_server)失去了响应能力，而ANR明确将 问题圈定在应用程序。
- SNR由Watchdog机制保证;ANR由消息处理机制保证，Android在系统层实现了一套精密的机制来发现ANR，核心原理是消息调度和超时处理。
- ANR机制主体实现在系统层。所有与ANR相关的消息，都会经过系统进程(system_server)调度，然后派发到应用进程完成对消息的实际处理 ，同时，系统进程设计了不同的超时限制来跟踪消息的处理。 一旦应用程序处理消息不当，超时限制就起作用了，它收集一些系统状态， 譬如CPU/IO使用情况、进程函数调用栈，并且报告用户有进程无响应了(ANR对话框)。
- ANR问题本质是一个性能问题。ANR机制实际上对应用程序主线程的限制，要求主线程在限定的时间内处理完一些最常见的操作(启动服务、 处理广播、处理输入)， 如果处理超时，则认为主线程已经失去了响应其他操作的能力。主线程中的耗时操作，譬如密集CPU运算、大量IO、 复杂界面布局等，都会降低应用程序的响应能力。
ANR机制模型
Handler发送延时消息，当Activity，Service，Broadcast生命周期执行完后会将消息移除，执行时间超过了限制，那么就会执行Handler消息，抛出ANR，暂停程序的运行，收集ANR日志，比如Activity：
系统在执行onCreate方法后会发出一个延时的Handler消息，当onResume执行过程中，已经达到超时限制，那么将执行Handler消息，抛出ANR。
Service中的ANR
- Service启动流程请查看：
Service启动流程源码分析 - 简单实现流程
编写中，请关注博客更新
Activity中的ANR
- Activity启动流程请查看：
编写中，请关注博客更新 - 简单实现流程
编写中，请关注博客更新
Broadcast中的ANR
- Broadcast启动流程请查看：
编写中，请关注博客更新 - 简单实现流程
编写中，请关注博客更新
InputEvent中的ANR
- InputEvent启动流程请查看：
编写中，请关注博客更新 - 简单实现流程
编写中，请关注博客更新
ANR后怎么处理的
- ANR发生后系统处理流程源码分析
博客规划中 - ANR收集系统源码分析
博客规划中
