Android ANR的设计原理

9,456 阅读8分钟

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更精炼的总结为: 埋雷、拆雷和爆雷三个步骤

了解了基本道理,我们就可以通过代码来验证下,我们来看下四大组件中的Service的ANR检测逻辑。

Service的ANR源码分析

埋雷的过程

我们通过context.startService(intent)来启动service最终都会调用到ContextImpl里面去,最终通过AMS来发起一次跨进程通信,最终调用到system_server进程中去启动service,这里不再废话,直接列出流程。

  • 1 A进程中调用 context.startService(intent)
  • 2 最终调用到system_server进程的AMSstartService()中。
  • 3 最后会调用到system_server进程的ActiveServicerealStartServiceLocked()中。

我们就来看这个函数: 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<ServiceRecord> 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.mHandlerpost一个消息,如果是前台服务,则检测时间是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
}

看下面的图更直接:

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.threadIApplicationThread接口,它的实现是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,发现它的处理在我们的老朋友ActivityThreadH中,如下:

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的检测信息很简单,这里再重复下:

  • 1 将要执行的service添加到系统进程的executingServices中。
  • 2 开启检测逻辑,检测将在指定时间后执行,具体时间决定与是前台服务还是后台服务。
  • 3 一旦服务被执行完,就会尝试移除检测逻辑。
  • 4 如果检测逻辑没被移除,就会被执行,然后去检测哪个服务发生了ANR
  • 5 如果发生了ANR,就将构建ANR信息提供给系统,否则就检测并执行下一轮ANR检测。