【Android】ANR 原理解析(Service)

前言

ANR,Application Not responding,也就是应用程序未响应。

Android 系统对于一些事件需要在一定的时间范围内完成,如果超过预定时间不能得到响应或者响应时间过长,都会造成ANR。

所有与 ANR 相关的消息,都会经过系统进程 system_server 来调度,然后派发到应用进程完成对消息的实际处理, 一旦应用程序处理消息超时,系统就会收集一些系统状态,如 CPU/IO 使用情况、进程函数调用栈,并且报告用户有进程出现 ANR 了,同时会弹出 ANR 的对话框。

ANR机制可以分为两部分:

  • 监测机制:针对不同的 ANR 类型如 Broadcast、Service、InputEvent 都有一套监测机制
  • 报告机制:在监测到ANR以后,需要显示ANR对话框、输出日志

Service ANR 原理

Android 是通过 Handler 机制设置定时消息来实现检测 Service 超时的。

Service 运行在应用程序的主线程,如果在前台进程中执行 Service ,时间超过 20 秒,则会引发ANR,如果在后台进程中执行 Service ,时间超过 200 秒,则会引发ANR。

如何检测 Service 的 ANR 问题,分为两步:

  • 当发生 Service ANR 时,一般可以先排查一下在 Service 的生命周期函数中有没有做耗时操作
  • 若应用层代码逻辑查不出问题,就需要检查当前系统的状态,如 CPU 使用情况、系统服务的状态等,判断当时发生 ANR 的进程是否受到系统运行异常的影响

那么 Service 发生 ANR 的原理是怎样的呢,下面我们将从源码角度上进行分析。

Android Serviced 启动流程

下面我们先分析 Service 的启动流程。

// 点击按钮 - 启动服务
fun clickToBindService(view: View) {
    Intent(this, MyNewService::class.java).also {
        startService(it)
    }
}

点击按钮启动服务的方法中,调用了 startService 方法来启动一个 Service,跟踪该方法,会调用到 ContextImpl.startService 中:

// ContextImpl.java
@Override
public ComponentName startService(Intent service) {
    warnIfCallingFromSystemProcess();
    return startServiceCommon(service, false, mUser);
}

进而继续执行 ContextImpl.startServiceCommon 方法:

// ContextImpl.java
private ComponentName startServiceCommon(Intent service, boolean requireForeground,
        UserHandle user) {
// …………………………………………………………………………………………………………………………………………………………………………………………
        ComponentName cn = ActivityManager.getService().startService(
                mMainThread.getApplicationThread(), service,
                service.resolveTypeIfNeeded(getContentResolver()), requireForeground,
                getOpPackageName(), getAttributionTag(), user.getIdentifier());
// …………………………………………………………………………………………………………………………………………………………………………………………
}

ContextImpl.startServiceCommon 方法中可以看到,执行了 ActivityManagerService,即 AMSstartService 方法,跟踪该方法:

// ActivityManagerService.java
@Override
public ComponentName startService(IApplicationThread caller, Intent service,
        String resolvedType, boolean requireForeground, String callingPackage,
        String callingFeatureId, int userId)
        throws TransactionTooLargeException {
         UserHandle user) {
// …………………………………………………………………………………………………………………………………………………………………………………………
            res = mServices.startServiceLocked(caller, service,
                    resolvedType, callingPid, callingUid,
                    requireForeground, callingPackage, callingFeatureId, userId);
        UserHandle user) {
// …………………………………………………………………………………………………………………………………………………………………………………………
        return res;
    }
}

可见,调用了 mServices.startServiceLocked 方法,而这个 mServices 则是一个 ActiveServices 对象,因此,代码继续执行 ActiveServices.startServiceLocked 方法:

// ActivityService.java
ComponentName startServiceLocked(IApplicationThread caller, Intent service, String resolvedType,
        int callingPid, int callingUid, boolean fgRequired, String callingPackage,
        @Nullable String callingFeatureId, final int userId)
        throws TransactionTooLargeException {
    return startServiceLocked(caller, service, resolvedType, callingPid, callingUid, fgRequired,
            callingPackage, callingFeatureId, userId, false, null);
}

在 ActivityService 中,经过一系列的调用,会执行到 ActivityService.realStartServiceLocked 方法

private void realStartServiceLocked(ServiceRecord r, ProcessRecord app,
        IApplicationThread thread, int pid, UidRecord uidRecord, boolean execInFg,
        boolean enqueueOomAdj) throws RemoteException {
    // ............................................................
    // 设置ANR超时,可见在正式启动 Service之前,会开始 ANR 的监测
    bumpServiceExecutingLocked(r, execInFg, "create", null /* oomAdjReason */);
    // ............................................................
    // 启动 Service 
    thread.scheduleCreateService(r, r.serviceInfo,
                mAm.compatibilityInfoForPackage(r.serviceInfo.applicationInfo),
                app.mState.getReportedProcState());
    // ............................................................  
    // 调动 Service 的其他方法,如 onStartCommand
    sendServiceArgsLocked(r, execInFg, true);
}

在 realStartServiceLocked 方法中,执行到了 ApplicationThread.scheduleCreateService 方法(这里就不看了),最终又会执行到 ActivityThread.scheduleCreateService 方法,如下:

// ActivityThread.java
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 发送创建 Service 的消息
    sendMessage(H.CREATE_SERVICE, s);
}

ActivityThread.scheduleCreateService 方法中,会通过 handler 发送一个创建 Service 的消息:CREATE_SERVICE,当接收到这个消息时,会执行 ActivityThread.handleCreateService 方法,最终会执行到 service.onCreate() 方法,进而执行 Service 的声明周期,如下所示:

// ActivityThread.java
public void handleMessage(Message msg) {
    if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));
    switch (msg.what) {
        // ..........................................
        case CREATE_SERVICE:
            handleCreateService((CreateServiceData)msg.obj);
            break;
    }
    // ..........................................
}

// 最终执行到这里,调用 service.onCreate() 方法
private void handleCreateService(CreateServiceData data) {
// ..........................................
            service.onCreate();
// ..........................................
    }

以上就是 Service 的启动流程了,整体还是比较清晰的。

Service 超时监测

Service 超时监测机制可以从 Service 启动流程中找到。

在上述 Service 启动流程中,我们跟踪执行到了 ActivityService.realStartServiceLocked 方法,在该方法中,通过调用 bumpServiceExecutingLocked 方法来开始监测 ANR,代码如下:

// ActivityService.java:
private boolean bumpServiceExecutingLocked(ServiceRecord r, boolean fg, String why,
        @Nullable String oomAdjReason) {
// ..........................................
    scheduleServiceTimeoutLocked(r.app);
// ..........................................
}

bumpServiceExecutingLocked 方法会继续调用到 scheduleServiceTimeoutLocked 方法:

void scheduleServiceTimeoutLocked(ProcessRecord proc) {
    if (proc.mServices.numberOfExecutingServices() == 0 || proc.getThread() == null) {
        return;
    }
    Message msg = mAm.mHandler.obtainMessage(
            ActivityManagerService.SERVICE_TIMEOUT_MSG);
    msg.obj = proc;
    // 延时指定时间后,发送消息:SERVICE_TIMEOUT_MSG
    // 前台进程中执行 Service,SERVICE_TIMEOUT = 20s
    // 后台进程中执行 Service,SERVICE_BACKGROUND_TIMEOUT = 200s
    mAm.mHandler.sendMessageDelayed(msg, proc.mServices.shouldExecServicesFg()
            ? SERVICE_TIMEOUT : SERVICE_BACKGROUND_TIMEOUT);
}

如果在指定的时间内没有将 SERVICE_TIMEOUT_MSG 这个消息 remove 掉,则该消息会在 ActivityManagerService 中处理:

// ActivityManagerService.java:
final class MainHandler extends Handler {
    // ..........................................
    @Override
    public void handleMessage(Message msg) {
        switch (msg.what) {
        // ..........................................
        case SERVICE_TIMEOUT_MSG: {
            mServices.serviceTimeout((ProcessRecord) msg.obj);
        } break;
        case SERVICE_FOREGROUND_TIMEOUT_MSG: {
            mServices.serviceForegroundTimeout((ServiceRecord) msg.obj);
        } break;
        // ..........................................
    }
}

这里我们看到,会调用 mServices.serviceTimeout() 方法,而 mServices 指的是 ActivityService,因此我们进入 ActivityService.serviceTimeout 方法中:

// ActivityService.java:
void serviceTimeout(ProcessRecord proc) {
        String anrMessage = null;
        synchronized(mAm) {
            if (proc.isDebugging()) {
                // 应用程序正在调试,忽略超时
                return;
            }
            final ProcessServiceRecord psr = proc.mServices;
            if (psr.numberOfExecutingServices() == 0 || proc.getThread() == null) {
                return;
            }
            final long now = SystemClock.uptimeMillis();
            final long maxTime =  now -
                    (psr.shouldExecServicesFg() ? SERVICE_TIMEOUT : SERVICE_BACKGROUND_TIMEOUT);
            ServiceRecord timeout = null;
            long nextTime = 0;
            // 遍历所有正在执行的服务,寻找运行超时的 Service
            for (int i = psr.numberOfExecutingServices() - 1; i >= 0; i--) {
                ServiceRecord sr = psr.getExecutingServiceAt(i);
                if (sr.executingStart < maxTime) {
                    timeout = sr;
                    break;
                }
                if (sr.executingStart > nextTime) {
                    nextTime = sr.executingStart;
                }
            }
            // 判断执行 Service 超时的进程是否在最近运行进程列表,如果不在,则忽略这个ANR
            if (timeout != null && mAm.mProcessList.isInLruListLOSP(proc)) {
                Slog.w(TAG, "Timeout executing service: " + timeout);
                StringWriter sw = new StringWriter();
                PrintWriter pw = new FastPrintWriter(sw, false, 1024);
                pw.println(timeout);
                timeout.dump(pw, "    ");
                pw.close();
                mLastAnrDump = sw.toString();
                mAm.mHandler.removeCallbacks(mLastAnrDumpClearer);
                mAm.mHandler.postDelayed(mLastAnrDumpClearer, LAST_ANR_LIFETIME_DURATION_MSECS);
                anrMessage = "executing service " + timeout.shortInstanceName;
            } else {
                Message msg = mAm.mHandler.obtainMessage(
                        ActivityManagerService.SERVICE_TIMEOUT_MSG);
                msg.obj = proc;
                mAm.mHandler.sendMessageAtTime(msg, psr.shouldExecServicesFg()
                        ? (nextTime+SERVICE_TIMEOUT) : (nextTime + SERVICE_BACKGROUND_TIMEOUT));
            }
        }
		// 当存在timeout的service,则执行appNotResponding,报告ANR
        if (anrMessage != null) {
            mAm.mAnrHelper.appNotResponding(proc, anrMessage);
        }
    }

可见,在该方法的最后,如果存在 ANR,则会执行到 AnrHelper.appNotResponding 方法来报告一个 ANR。

以上就是本文的所有内容,下一篇文章将会继续从源码的角度上探究 输入事件处理超时 引入的 ANR 原理。

你可能感兴趣的:(Android基础知识,android,kotlin,java)