Android ANR的设计原理 android

ANR的设计原理定时等待问题
先来看个小故事
老师给我布置了个作业，要求我10分钟内完成，他说10分钟后再来检查。
10分钟后，老师来检查，发现我作业没完成，就把我的名字写在黑板上，来警示其他人。
10分钟后，老师来检查，发现我作业写完了，就接着布置下一个作业了。
但是，这里有个问题，假如我5分钟就写完了作业，是不是可以主动去告诉老师，而不是让他再多等5分钟呢？
当然可以！
这样就可以提前结束本次等待过程，大大节省时间从而提高效率。
上述过程就简单的模拟了ANR的实现原理，更术语的说法如下。
ANR的实现原理简述

1 ANR的检测逻辑有两个参与者: 观测者A和被观测者B，当然，这两者是不在同一个线程中的。
2 A在调用B中的逻辑时，同时在A中保存一个标记F，然后做个延时操作C，延时时间设为T，这一步称为: 埋雷。
3 B中的逻辑如果被执行到，就会通知A去清除标记F，并且通知A解除C，这一步称为: 拆雷。
4 如果C没被拆除，那么在时间T后就会被触发，就会去检测标记F是否还在，如果在，就说明B没有在指定的时间T内完成，那么就提示B发生了ANR，这一步称为: 爆雷。
5 由于A和B是在不同线程中的，所以B即使死循环，也不会影响C的检测过程。

上述的道理也很容易理解，A和B一定不能在同一个线程，因为如果是同一个线程，B如果陷入死循环，那么C永远都执行不到了，还检测个毛。
如果B执行完了，只去通知A清除标记F，而不清除C可以吗，也可以！但是这个时候C还会继续等待，等到T时间后，去检测F，F肯定是不在的，就检测了个寂寞，还不如直接取消。就像上述例子我提前去告诉老师一样，B提前去告诉A结束C。
所以，我们可以将ANR更精炼的总结为: 埋雷、拆雷和爆雷三个步骤。
【Android ANR的设计原理】了解了基本道理，我们就可以通过代码来验证下，我们来看下四大组件中的Service的ANR检测逻辑。
Service的ANR源码分析埋雷的过程
我们通过context.startService(intent)来启动service最终都会调用到ContextImpl里面去，最终通过AMS来发起一次跨进程通信，最终调用到system_server进程中去启动service，这里不再废话，直接列出流程。

1 A进程中调用 context.startService(intent)。
2 最终调用到system_server进程的AMS的startService()中。
3 最后会调用到system_server进程的ActiveService的realStartServiceLocked()中。

我们就来看这个函数: ActiveService.realStartServiceLocked()，这里只贴出核心部分:

private final void realStartServiceLocked(ServiceRecord r, ProcessRecord app, boolean execInFg) throws RemoteException { // 核心函数: 开启ANR检测，也是埋雷和爆雷的地方 bumpServiceExecutingLocked(r, execInFg, "create"); try { // 核心函数: 启动服务，也是拆雷的地方 app.thread.scheduleCreateService(r, r.serviceInfo, mAm.compatibilityInfoForPackage(r.serviceInfo.applicationInfo), app.getReportedProcState()); } catch (DeadObjectException e) { throw e; } finally { } }

核心逻辑有两个： 1 开启ANR检测; 2 启动服务。我们先来看ANR检测函数bumpServiceExecutingLocked():

private final void bumpServiceExecutingLocked(ServiceRecord r, boolean fg, String why) { //... // 将ServiceRecord添加到ProcessRecord的executingServices里面去 r.app.executingServices.add(r); // 开始进行ANR检测 scheduleServiceTimeoutLocked(r.app); //... }

上述代码只贴出核心部分，r.app是一个ProcessRecord，表示当前服务所属的进程，r.app.excutingServices表示当前进程正在执行的服务的集合，如下：

final class ServiceRecord extends Binder implements ComponentName.WithComponentName { // 当前服务所属的进程 ProcessRecord app; }class ProcessRecord implements WindowProcessListener { // 正在执行的服务的集合 final ArraySet executingServices = new ArraySet<>(); }

也就是说，现在我们已经把要启动的Service，添加到进程的executingServices里面了，等价于添加了Flag了。
接着我们看进行ANR检测的方法 scheduleServiceTimeoutLocked，也就是爆雷的过程
爆雷的过程
以下代码位于ActiveService中，这里只贴出核心部分。

void scheduleServiceTimeoutLocked(ProcessRecord proc) { // 如果没有正在执行的服务或者进程已经不再了，就返回 if (proc.executingServices.size() == 0 || proc.thread == null) { return; } // 构建ANR消息，记住这个Flag: SERVICE_TIMEOUT_MSG Message msg = mAm.mHandler.obtainMessage(ActivityManagerService.SERVICE_TIMEOUT_MSG); msg.obj = proc; // 发射delay消息，如果是前台服务，delay时间就是SERVICE_TIMEOUT，否则delay时间就是SERVICE_BACKGROUND_TIMEOUT mAm.mHandler.sendMessageDelayed(msg,proc.execServicesFg ? SERVICE_TIMEOUT : SERVICE_BACKGROUND_TIMEOUT); }// 前台服务ANR的时间是20s static final int SERVICE_TIMEOUT = 20*1000; // 后台服务ANR的时间是200s static final int SERVICE_BACKGROUND_TIMEOUT = SERVICE_TIMEOUT * 10;

这里可以看到，通过mAM.mHandler来post一个消息，如果是前台服务，则检测时间是20s，如果是后台服务，检测时间是200s，那么我们就来看下这个mAm.mHandler里面被执行时候的逻辑吧。
mAm就是ActivityManagerService，以下代码位于ActivityManagerService中，这里只贴出核心部分。

final class MainHandler extends Handler { @Override public void handleMessage(Message msg) { switch (msg.what) { // case到这个Flag了 case SERVICE_TIMEOUT_MSG: { // 进行检测，最后调到了ActiveService.serviceTimeout() mServices.serviceTimeout((ProcessRecord)msg.obj); } break; } } }

我们跟着主线代码ActiveService.serviceTimeout()

void serviceTimeout(ProcessRecord proc) { // anr的消息 String anrMessage = null; synchronized(mAm) { // 如果是debug引起的anr，无视 if (proc.isDebugging()) { return; } // 如果进程已经没有要执行的服务或者进程不在了，就无视 if (proc.executingServices.size() == 0 || proc.thread == null) { return; } // 记录当前时间 final long now = SystemClock.uptimeMillis(); // 计算服务最早的开始时间，如果小于这个时间，就是发生了ANR final long maxTime =now - (proc.execServicesFg ? SERVICE_TIMEOUT : SERVICE_BACKGROUND_TIMEOUT); // 记录超时的服务 ServiceRecord timeout = null; // 如果没有发生ANR，则记录下一条服务的开始时间 long nextTime = 0; // 这里就从前面保存的executingServices列表中开始倒序比较了，还记得我们前面的: r.app.executingServices.add(r)吗 // 遍历寻找发生ANR的Service for (int i=proc.executingServices.size()-1; i>=0; i--) { ServiceRecord sr = proc.executingServices.valueAt(i); // 如果小于最晚开始时间，则发生了ANR if (sr.executingStart < maxTime) { // 记录超时的服务 timeout = sr; break; } // 如果没有发生ANR，就保存下一条服务的开始时间 if (sr.executingStart > nextTime) { nextTime = sr.executingStart; } } // 分支1: 如果发生了ANR，并且进程还在，就提示ANR消息 if (timeout != null && mAm.mProcessList.mLruProcesses.contains(proc)) { StringWriter sw = new StringWriter(); PrintWriter pw = new FastPrintWriter(sw, false, 1024); pw.println(timeout); timeout.dump(pw, ""); pw.close(); // 构建ANR消息 anrMessage = "executing service " + timeout.shortInstanceName; } else { // 分支2: 如果没发生ANR，就进行下一轮观测 Message msg = mAm.mHandler.obtainMessage(ActivityManagerService.SERVICE_TIMEOUT_MSG); msg.obj = proc; // 下一轮观测的时间就是下一条服务的启动时间 + 服务的超时时间 mAm.mHandler.sendMessageAtTime(msg, proc.execServicesFg ? (nextTime+SERVICE_TIMEOUT) : (nextTime + SERVICE_BACKGROUND_TIMEOUT)); } }// 如果anrMessage不为null，也就是发生了ANR消息，就交给系统处理(开启了ANR消息提示就会弹出提示框) if (anrMessage != null) { mAm.mAnrHelper.appNotResponding(proc, anrMessage); } }

这块代码的逻辑是: 遍历正在执行的服务列表，查找发生了ANR的服务，如果找到了，就构建ANR消息并交给系统处理，否则就找到最小的下一条服务的开始执行时间，然后重新计算时间并进行ANR检测。
那么，ANR时间是怎么判断的呢？我们先看下它的相关计算:

// 记录当前时间 final long now = SystemClock.uptimeMillis(); // 计算服务最晚的开始时间，如果小于这个时间，就是发生了ANR final long maxTime =now - (proc.execServicesFg ? SERVICE_TIMEOUT : SERVICE_BACKGROUND_TIMEOUT); if (sr.executingStart < maxTime) { // 发生了ANR }

接着，我们来逐条讲解，我们假设本服务是前台服务:

// 首先，获取当前时间 final long now = SystemClock.uptimeMillis(); // (我们假设是前台服务)，假设服务的开始时间是start，那么如果发生了ANR，就满足: now - start > SERVICE_TIMEOUT // 也就是: now - SERVICE_TIMEOUT > start final long maxTime =now - SERVICE_TIMEOUT; // 也就是: start < maxTime if (sr.executingStart < maxTime) { // 发生了ANR }

看下面的图更直接:

文章图片

接着，我们来看下拆雷的过程。
拆雷的过程
我们先回顾下入口函数: ActiveService.realStartServiceLocked()。

private final void realStartServiceLocked(ServiceRecord r, ProcessRecord app, boolean execInFg) throws RemoteException { // 核心函数: 开启ANR检测，也是埋雷和爆雷的地方 bumpServiceExecutingLocked(r, execInFg, "create"); try { // 核心函数: 启动服务，也是拆雷的地方 app.thread.scheduleCreateService(r, r.serviceInfo, mAm.compatibilityInfoForPackage(r.serviceInfo.applicationInfo), app.getReportedProcState()); } catch (DeadObjectException e) { throw e; } finally { } }

其中，app.thread是IApplicationThread接口，它的实现是ApplicationThread，是ActivityThread的一个内部类。代码如下所示:

private class ApplicationThread extends IApplicationThread.Stub { public final void scheduleCreateService(IBinder token,ServiceInfo info, CompatibilityInfo compatInfo, int processState) { updateProcessState(processState, false); // 创建数据 CreateServiceData s = new CreateServiceData(); s.token = token; s.info = info; s.compatInfo = compatInfo; // 通过handler发射出去，那我们只需要跟这个 H.CREATE_SERVICE 就可以了 sendMessage(H.CREATE_SERVICE, s); } }

我们跟着H.CREATE_SERVICE，发现它的处理在我们的老朋友ActivityThread的H中，如下:

class H extends Handler { case CREATE_SERVICE: // 又是调用了handleXXXXYYYY系列函数 handleCreateService((CreateServiceData)msg.obj); break; }

我们点进去:

private void handleCreateService(CreateServiceData data) { // 暂停GC的处理 unscheduleGcIdler(); LoadedApk packageInfo = getPackageInfoNoCheck(data.info.applicationInfo, data.compatInfo); Service service = null; try {// 通过反射创建Service(记得当初Activity也是这么干的) ContextImpl context = ContextImpl.createAppContext(this, packageInfo); Application app = packageInfo.makeApplication(false, mInstrumentation); java.lang.ClassLoader cl = packageInfo.getClassLoader(); service = packageInfo.getAppFactory().instantiateService(cl, data.info.name, data.intent); context.getResources().addLoaders(app.getResources().getLoaders().toArray(new ResourcesLoader[0])); context.setOuterContext(service); // 调用service.attach(这里保存了context) service.attach(context, this, data.info.name, data.token, app, ActivityManager.getService()); // 回调onCreate()函数 service.onCreate(); mServices.put(data.token, service); try { // 核心函数，也就是拆雷的地方! ActivityManager.getService().serviceDoneExecuting( data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0); } catch (RemoteException e) { throw e.rethrowFromSystemServer(); } } catch (Exception e) { //... } }

上述逻辑: 通过反射创建服务；回调onCreate()；拆雷。我们看拆雷的核心函数serviceDoneExecuting，位于ActivityManagerService中，这里只展示核心函数。

void serviceDoneExecutingLocked(ServiceRecord r, int type, int startId, int res) { boolean inDestroying = mDestroyingServices.contains(r); if (r != null) { // ...// 拆雷的核心函数 serviceDoneExecutingLocked(r, inDestroying, inDestroying); } else { // ... } }

紧跟着:

private void serviceDoneExecutingLocked(ServiceRecord r, boolean inDestroying, boolean finishing) { r.executeNesting--; if (r.executeNesting <= 0) { if (r.app != null) { // 重置前台服务标记 r.app.execServicesFg = false; // 从executingServices中移除 r.app.executingServices中移除.remove(r); if (r.app.executingServices.size() == 0) { // 如果没有正在执行的服务了，也就没必要再进行ANR检测了，就直接移除，也就是拆雷。 mAm.mHandler.removeMessages(ActivityManagerService.SERVICE_TIMEOUT_MSG, r.app); } else if (r.executeFg) { // 处理其他逻辑 } } } }

这就是拆雷的过程，这里有个问题，如果r.app.executingServices.size() == 0不满足呢，就不移除了吗？没错！不移除也没有影响的，因为既然跑到了这里，说明本个服务已经执行完毕了，即使这个检测不移除，等它被执行到了，也检测不到本个服务的ANR，也就是爆雷阶段的分支2，会检测下一轮ANR信息。
当然，移除是最好的，但是为什么不移除呢？这里我也不懂，可能是因为post消息的时候，传递的object参数是r.app，是所有服务共享的进程，而不是单个服务独有的信息，从而导致不能移除，因为一旦移除，就导致所有检测的Message都被移除。如下:

// 检测的时候 Message msg = mAm.mHandler.obtainMessage(ActivityManagerService.SERVICE_TIMEOUT_MSG); msg.obj = proc; // 这里传递的是进程proc，所有的service都用的它 mAm.mHandler.sendMessageDelayed(msg, proc.execServicesFg ? SERVICE_TIMEOUT : SERVICE_BACKGROUND_TIMEOUT); // 移除的时候// 如果这么干了，那么如果service1跑完了，就会导致service2的检测逻辑也会被移除， // 因为service2检测用的msg.obj跟service1一样都是进程proc，所以不能移除，只能等没有服务执行了才全部移除。 mAm.mHandler.removeMessages(ActivityManagerService.SERVICE_TIMEOUT_MSG, r.app);

如果能改成如下，会更好:

// 检测的时候 Message msg = mAm.mHandler.obtainMessage(ActivityManagerService.SERVICE_TIMEOUT_MSG); msg.obj = serviceRecord.xxx; // 传递本服务的独立信息 mAm.mHandler.sendMessageDelayed(msg, proc.execServicesFg ? SERVICE_TIMEOUT : SERVICE_BACKGROUND_TIMEOUT); // 移除的时候 // 直接使用服务独立的信息，不影响其他服务 mAm.mHandler.removeMessages(ActivityManagerService.SERVICE_TIMEOUT_MSG, serviceRecord.xxx);

也可能是我理解的不对！有理解的小伙伴可以在评论区指点迷津。
总结 ANR的检测信息很简单，这里再重复下: