Android ANR 无响应原理解读

a60cd32b8160d6d986a2ab74249f3497.gif

和你一起终身学习,这里是程序员Android

经典好文推荐,通过阅读本文,您将收获以下知识点:

一 概述

ANR (Application Not responding),是指应用程序未响应,Android 系统对于一些事件需要在一定的时间范围内完成,如果超过预定时间能未能得到有效响应或者响应时间过长,都会造成 ANR。一般地,这时往往会弹出一个提示框,告知用户当前 xxx 未响应,用户可选择继续等待或者Force Close。

那么哪些场景会造成 ANR 呢?

  • Service Timeout:前台服务在 20s 内未执行完成

  • BroadcastQueue Timeout:前台广播在 10s 内未执行完成

  • ContentProvider Timeout:内容提供者,超时 10s

  • InputDispatching Timeout:输入事件分发超时 5s,包括按键和触摸事件

触发 ANR 的过程可分为三个步骤:埋炸弹,拆炸弹,引爆炸弹

二 Service

Service Timeout 是位于 ”ActivityManager” 线程中的 AMS.MainHandler 收到 SERVICE_TIMEOUT_MSG 消息时触发。

对于 Service 有两类:

  • 对于前台服务,则超时为 SERVICE_TIMEOUT = 20s

  • 对于后台服务,则超时为 SERVICE_BACKGROUND_TIMEOUT = 200s

由变量 ProcessRecord.execServicesFg 来决定是否前台启动

2.1 埋炸弹

文章Android四大组件系列4 Service启动流程详细介绍了 Service 的启动流程。其中在 Service 进程 attach 到 system_server 进程的过程中会调用 realStartServiceLocked() 方法来埋下炸弹。

2.1.1 ActiveServices.realStartServiceLocked

ActiveServices.java

private final void realStartServiceLocked(ServiceRecord r,
    ProcessRecord app, boolean execInFg) throws RemoteException {
    ......
    //发送delay消息(SERVICE_TIMEOUT_MSG)
    bumpServiceExecutingLocked(r, execInFg, "create");
    try {
        ......
        //最终执行服务的onCreate()方法
        app.thread.scheduleCreateService(r, r.serviceInfo,
                mAm.compatibilityInfoForPackageLocked(
                r.serviceInfo.applicationInfo),
                app.repProcState);
    } catch (DeadObjectException e) {
        ......
    } finally {
        ......
    }
    ......
}
  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10

  • 11

  • 12

  • 13

  • 14

  • 15

  • 16

  • 17

  • 18

  • 19

2.1.2 ActiveServices.bumpServiceExecutingLocked

ActiveServices.java

private final void bumpServiceExecutingLocked(ServiceRecord r,
    boolean fg, String why) {
    ......
    scheduleServiceTimeoutLocked(r.app);
    ......
}

void scheduleServiceTimeoutLocked(ProcessRecord proc) {
    if (proc.executingServices.size() == 0 || proc.thread == null) {
        return;
    }
    Message msg = mAm.mHandler.obtainMessage(
            ActivityManagerService.SERVICE_TIMEOUT_MSG);
    msg.obj = proc;    
    //当超时后仍没有remove该SERVICE_TIMEOUT_MSG消息,则执行service Timeout流程
    mAm.mHandler.sendMessageDelayed(msg,
        proc.execServicesFg ? (now+SERVICE_TIMEOUT) :
        (now+ SERVICE_BACKGROUND_TIMEOUT));
}
  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10

  • 11

  • 12

  • 13

  • 14

  • 15

  • 16

  • 17

  • 18

  • 19

该方法的主要工作是发送 delay 消息 (SERVICE_TIMEOUT_MSG)。炸弹已埋下,我们并不希望炸弹被引爆,那么就需要在炸弹爆炸之前拆除炸弹。

2.2 拆炸弹

在 system_server 进程 ActiveServices.realStartServiceLocked() 调用的过程会埋下一颗炸弹,超时没有启动完成则会爆炸。那么什么时候会拆除这颗炸弹的引线呢?我们来看经过 Binder 等进程间通信层层调用进入目标进程的主线程 handleCreateService() 函数。

2.2.1 ActivityThread.handleCreateService

ActivityThread.java

private void handleCreateService(CreateServiceData data) {
    ......
    java.lang.ClassLoader cl = packageInfo.getClassLoader();
    Service service = packageInfo.getAppFactory()
          .instantiateService(cl, data.info.name, data.intent);
    ......
    try {
        //创建ContextImpl对象
        ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
        context.setOuterContext(service);
        //创建Application对象
        Application app = packageInfo.makeApplication(false, mInstrumentation);
        service.attach(context, this, data.info.name, data.token, app,
                ActivityManagerNative.getDefault());
        //调用服务onCreate()方法 
        service.onCreate();
        mServices.put(data.token, service);
            
        //拆除炸弹引线
        ActivityManager.getService().serviceDoneExecuting(
                data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
    } catch (Exception e) {
        ......
    }
}
  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10

  • 11

  • 12

  • 13

  • 14

  • 15

  • 16

  • 17

  • 18

  • 19

  • 20

  • 21

  • 22

  • 23

  • 24

  • 25

在这个过程会创建目标服务对象,并回调其 onCreate() 方法,紧接着再次经过 IPC 调用回到 system_server 来执行 serviceDoneExecuting。

2.2.2 ActiveServices.serviceDoneExecutingLocked

ActiveServices.java

private void serviceDoneExecutingLocked(ServiceRecord r,
    boolean inDestroying, boolean finishing) {
    ......
    if (r.executeNesting <= 0) {
        if (r.app != null) {
            r.app.execServicesFg = false;
            r.app.executingServices.remove(r);
            if (r.app.executingServices.size() == 0) {
                //当前服务所在进程中没有正在执行的service
                mAm.mHandler.removeMessages(
                ActivityManagerService.SERVICE_TIMEOUT_MSG, r.app);
        ......
    }
    ......
}
  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10

  • 11

  • 12

  • 13

  • 14

  • 15

该方法的主要工作是当 service 启动完成,则移除服务超时消息 SERVICE_TIMEOUT_MSG。

2.3 引爆炸弹

前面介绍了埋炸弹和拆炸弹的过程,如果在炸弹倒计时结束之前成功拆卸炸弹,那么就没有爆炸的机会,但是世事难料,总有些极端情况下无法即时拆除炸弹,导致炸弹爆炸,其结果就是 App 发生 ANR。接下来,分析下炸弹爆炸的现场。

在 system_server 进程中有一个 Handler 线程,名叫 ”ActivityManager”。当倒计时结束便会向该 Handler 线程发送一条消息 SERVICE_TIMEOUT_MSG。

2.3.1 MainHandler.handleMessage

ActivityManagerService.java ::MainHandler

final class MainHandler extends Handler {
    ......
    public void handleMessage(Message msg) {
        switch (msg.what) {
            case SERVICE_TIMEOUT_MSG: {
                ......
                mServices.serviceTimeout((ProcessRecord)msg.obj);
            } break;
            ......
        }
        ......
    }
}
  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10

  • 11

  • 12

  • 13

2.3.2 ActiveServices.serviceTimeout

ActiveServices.java

void serviceTimeout(ProcessRecord proc) {
    String anrMessage = null;
    synchronized(mAm) {
        if (proc.executingServices.size() == 0 || proc.thread == null) {
            return;
        }
        final long now = SystemClock.uptimeMillis();
        final long maxTime =  now -
                (proc.execServicesFg ? SERVICE_TIMEOUT :
                SERVICE_BACKGROUND_TIMEOUT);
        ServiceRecord timeout = null;
        long nextTime = 0;
        for (int i=proc.executingServices.size()-1; i>=0; i--) {
            ServiceRecord sr = proc.executingServices.valueAt(i);
            if (sr.executingStart < maxTime) {
                timeout = sr;
                break;
            }
            if (sr.executingStart > nextTime) {
                nextTime = sr.executingStart;
            }
        }
        if (timeout != null &&
                mAm.mProcessList.mLruProcesses.contains(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.shortName;
        }
    }

    if (anrMessage != null) {
        //当存在timeout的service,则执行appNotResponding
        proc.appNotResponding(null, null, null, null, false, anrMessage);
    }
}
  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10

  • 11

  • 12

  • 13

  • 14

  • 15

  • 16

  • 17

  • 18

  • 19

  • 20

  • 21

  • 22

  • 23

  • 24

  • 25

  • 26

  • 27

  • 28

  • 29

  • 30

  • 31

  • 32

  • 33

  • 34

  • 35

  • 36

  • 37

  • 38

  • 39

  • 40

  • 41

  • 42

  • 43

其中 anrMessage 的内容为 ”executing service [发送超时 serviceRecord 信息]”。

三 BroadcastReceiver

BroadcastReceiver Timeout 是位于 ”ActivityManager” 线程中的 BroadcastQueue.BroadcastHandler 收到 BROADCAST_TIMEOUT_MSG 消息时触发。

对于广播队列在 AMS 中有两个:mFgBroadcastQueue 队列和 mBgBroadcastQueue 队列:

  • 对于前台广播,则超时为 BROADCAST_FG_TIMEOUT = 10s

  • 对于后台广播,则超时为 BROADCAST_BG_TIMEOUT = 60s

3.1 埋炸弹

我们之前已经分析过广播的注册和发送流程,通过调用 processNextBroadcast 来处理广播。其流程为先处理并行广播,再处理当前有序广播,最后获取并处理下条有序广播。

3.1.1 processNextBroadcast

final void processNextBroadcast(boolean fromMsg) {
        synchronized (mService) {
            processNextBroadcastLocked(fromMsg, false);
        }
}


final void processNextBroadcastLocked(boolean fromMsg, boolean skipOomAdj) {
        BroadcastRecord r;
        ......
        //part 2: 处理当前有序广播
        do {
            final long now = SystemClock.uptimeMillis();
            r = mDispatcher.getNextBroadcastLocked(now);
            ......
            //获取所有该广播所有的接收者
            int numReceivers =
                (r.receivers != null) ? r.receivers.size() : 0;
            if (mService.mProcessesReady && !r.timeoutExempt &&
                r.dispatchTime > 0) {
                long now = SystemClock.uptimeMillis();
                if ((numReceivers > 0) &&
                (now > r.dispatchTime + (2*mConstants.TIMEOUT*numReceivers))) {
                    //当广播处理时间超时,则强制结束这条广播
                    broadcastTimeoutLocked(false);
                    ......
                }
            }
            if (r.receivers == null || r.nextReceiver >= numReceivers
                    || r.resultAbort || forceReceive) {
                if (r.resultTo != null) {
                    //处理广播消息消息
                    performReceiveLocked(r.callerApp, r.resultTo,
                        new Intent(r.intent), r.resultCode,
                        r.resultData, r.resultExtras, false, false, r.userId);
                    r.resultTo = null;
                }
                //拆炸弹
                cancelBroadcastTimeoutLocked();
            }
        } while (r == null);
        ......
        //part 3: 获取下条有序广播
        r.receiverTime = SystemClock.uptimeMillis();
        if (!mPendingBroadcastTimeoutMessage) {
            long timeoutTime = r.receiverTime + mConstants.TIMEOUT;
            //埋炸弹
            setBroadcastTimeoutLocked(timeoutTime);
        }
        ......
}
  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10

  • 11

  • 12

  • 13

  • 14

  • 15

  • 16

  • 17

  • 18

  • 19

  • 20

  • 21

  • 22

  • 23

  • 24

  • 25

  • 26

  • 27

  • 28

  • 29

  • 30

  • 31

  • 32

  • 33

  • 34

  • 35

  • 36

  • 37

  • 38

  • 39

  • 40

  • 41

  • 42

  • 43

  • 44

  • 45

  • 46

  • 47

  • 48

  • 49

  • 50

  • 51

对于广播超时处理时机:

1.首先在 part3 的过程中 setBroadcastTimeoutLocked(timeoutTime) 设置超时广播消息
2.然后在 part2 根据广播处理情况来处理:

  • 当广播接收者等待时间过长,则调用 broadcastTimeoutLocked(false)

  • 当执行完广播,则调用 cancelBroadcastTimeoutLocked

3.1.2 setBroadcastTimeoutLocked

final void setBroadcastTimeoutLocked(long timeoutTime) {
        if (!mPendingBroadcastTimeoutMessage) {
            Message msg =
                mHandler.obtainMessage(BROADCAST_TIMEOUT_MSG, this);
            mHandler.sendMessageAtTime(msg, timeoutTime);
            mPendingBroadcastTimeoutMessage = true;
        }
}
  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

设置定时广播 BROADCAST_TIMEOUT_MSG,即当前往后推 mTimeout 时间广播还没处理完毕,则进入广播超时流程。

3.2 拆炸弹

broadcast 跟 service 超时机制大体上相同,但有一个非常隐蔽的技能点,那就是通过静态注册的广播超时会受 SharedPreferences 的影响。

3.2.1 sendFinished

关于广播是否考虑 SP 的情况取决于如下代码:

BroadcastReceiver.PendingResult.finish

public final void finish() {
    if (mType == TYPE_COMPONENT) {
        final IActivityManager mgr = ActivityManager.getService();
        if (QueuedWork.hasPendingWork()) {
        //当SP有未同步到磁盘的工作,则需等待其完成,才告知系统已完成该广播
            QueuedWork.queue(new Runnable() {
                @Override public void run() {
                 if (ActivityThread.DEBUG_BROADCAST) Slog.i(ActivityThread.TAG,
                       "Finishing broadcast after work to component " + mToken);
                    sendFinished(mgr);
                }
            }, false);
        } else {
            if (ActivityThread.DEBUG_BROADCAST) Slog.i(ActivityThread.TAG,
                    "Finishing broadcast to component " + mToken);
            sendFinished(mgr);
        }
    } else if (mOrderedHint && mType != TYPE_UNREGISTERED) {
        if (ActivityThread.DEBUG_BROADCAST) Slog.i(ActivityThread.TAG,
                "Finishing broadcast to " + mToken);
        final IActivityManager mgr = ActivityManager.getService();
        sendFinished(mgr);
    }
}
  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10

  • 11

  • 12

  • 13

  • 14

  • 15

  • 16

  • 17

  • 18

  • 19

  • 20

  • 21

  • 22

  • 23

  • 24

可见,只有 XML 静态注册的广播超时检测过程会考虑是否有 SP 尚未完成,动态广播并不受其影响。

3.2.2 cancelBroadcastTimeoutLocked

final void cancelBroadcastTimeoutLocked() {
        if (mPendingBroadcastTimeoutMessage) {
            mHandler.removeMessages(BROADCAST_TIMEOUT_MSG, this);
            mPendingBroadcastTimeoutMessage = false;
        }
}
  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

移除广播超时消息 BROADCAST_TIMEOUT_MSG。

3.3 引爆炸弹

3.3.1 BroadcastHandler.handleMessage

BroadcastQueue.java ::BroadcastHandler

private final class BroadcastHandler extends Handler {
    public void handleMessage(Message msg) {
        switch (msg.what) {
            case BROADCAST_INTENT_MSG: {
                    if (DEBUG_BROADCAST) Slog.v(
                            TAG_BROADCAST, "Received BROADCAST_INTENT_MSG ["
                            + mQueueName + "]");
                    processNextBroadcast(true);
            } break;
            case BROADCAST_TIMEOUT_MSG: {
                    synchronized (mService) {
                        broadcastTimeoutLocked(true);
                    }
            } break;
        }
    }
}
  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10

  • 11

  • 12

  • 13

  • 14

  • 15

  • 16

  • 17

3.3.2 broadcastTimeoutLocked

BroadcastQueue.java

final void broadcastTimeoutLocked(boolean fromMsg) {
    if (fromMsg) {//fromMsg = true
        mPendingBroadcastTimeoutMessage = false;
    }
    if (mDispatcher.isEmpty() || mDispatcher.getActiveBroadcastLocked()
         == null) {
       return;
   }
   long now = SystemClock.uptimeMillis();
   BroadcastRecord r = mDispatcher.getActiveBroadcastLocked();
   if (fromMsg) {
   //当系统还没有准备就绪时,广播处理流程中不存在广播超时
        if (!mService.mProcessesReady) {
           return;
       }
        ......
       long timeoutTime = r.receiverTime + mConstants.TIMEOUT;
       if (timeoutTime > now) {
      //如果当前正在执行的receiver没有超时,则重新设置广播超时      
           setBroadcastTimeoutLocked(timeoutTime);
           return;
    }
  }
  if (r.state == BroadcastRecord.WAITING_SERVICES) {
  //广播已经处理完成,但需要等待已启动service执行完成。当等待足够时间,则处理下一条广播。
            r.curComponent = null;
            r.state = BroadcastRecord.IDLE;
            processNextBroadcast(false);
            return;
   }
   r.receiverTime = now;
   if (!debugging) {
       r.anrCount++;//当前BroadcastRecord的anr次数执行加1操作
   }
   Object curReceiver;
   if (r.nextReceiver > 0) {
      curReceiver = r.receivers.get(r.nextReceiver-1);
      r.delivery[r.nextReceiver-1] = BroadcastRecord.DELIVERY_TIMEOUT;
   } else {
      curReceiver = r.curReceiver;
   }
   //查询App进程
   if (curReceiver != null && curReceiver instanceof BroadcastFilter) {
        BroadcastFilter bf = (BroadcastFilter)curReceiver;
        if (bf.receiverList.pid != 0
                && bf.receiverList.pid != ActivityManagerService.MY_PID) {
            synchronized (mService.mPidsSelfLocked) {
                app = mService.mPidsSelfLocked.get(
                        bf.receiverList.pid);
            }
        }
   } else {
        app = r.curApp;
   }
   if (app != null) {
        anrMessage = "Broadcast of " + r.intent.toString();
    }

    if (mPendingBroadcast == r) {
        mPendingBroadcast = null;
    }
    //继续移动到下一个广播接收者
    finishReceiverLocked(r, r.resultCode, r.resultData,
            r.resultExtras, r.resultAbort, false);
    scheduleBroadcastsLocked();

    if (!debugging && anrMessage != null) {
        mHandler.post(new AppNotResponding(app, anrMessage));
    }
}
  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10

  • 11

  • 12

  • 13

  • 14

  • 15

  • 16

  • 17

  • 18

  • 19

  • 20

  • 21

  • 22

  • 23

  • 24

  • 25

  • 26

  • 27

  • 28

  • 29

  • 30

  • 31

  • 32

  • 33

  • 34

  • 35

  • 36

  • 37

  • 38

  • 39

  • 40

  • 41

  • 42

  • 43

  • 44

  • 45

  • 46

  • 47

  • 48

  • 49

  • 50

  • 51

  • 52

  • 53

  • 54

  • 55

  • 56

  • 57

  • 58

  • 59

  • 60

  • 61

  • 62

  • 63

  • 64

  • 65

  • 66

  • 67

  • 68

  • 69

  • 70

3.3.3 AppNotResponding

BroadcastQueue.java

private final class AppNotResponding implements Runnable {
        private final ProcessRecord mApp;
        private final String mAnnotation;

        public AppNotResponding(ProcessRecord app, String annotation) {
            mApp = app;
            mAnnotation = annotation;
        }

        @Override
        public void run() {
            // 进入ANR处理流程
            mApp.appNotResponding(null, null, null, null, false, mAnnotation);
        }
    }
  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10

  • 11

  • 12

  • 13

  • 14

  • 15

四 ContentProvider

ContentProvider Timeout 是位于 ”ActivityManager” 线程中的 AMS.MainHandler 收到 CONTENT_PROVIDER_PUBLISH_TIMEOUT_MSG 消息时触发。

ContentProvider 超时为 CONTENT_PROVIDER_PUBLISH_TIMEOUT = 10s。这个跟前面的 Service 和 BroadcastQueue 完全不同,由 Provider 进程启动过程相关。

4.1 埋炸弹

我们之前详细介绍了 Provider 启动流程。埋炸弹的过程其实是在进程创建的过程,进程创建后会调用 attachApplicationLocked() 进入 system_server 进程。

4.1.1 AMS.attachApplicationLocked

private boolean attachApplicationLocked(@NonNull IApplicationThread thread,
            int pid, int callingUid, long startSeq) {
    ProcessRecord app;
    long startTime = SystemClock.uptimeMillis();
    long bindApplicationTimeMillis;
    if (pid != MY_PID && pid >= 0) {
        synchronized (mPidsSelfLocked) {
            app = mPidsSelfLocked.get(pid); // 根据pid获取ProcessRecord
        }
    } 
    ......    
    //系统处于ready状态或者该app为FLAG_PERSISTENT进程则为true
    boolean normalMode = mProcessesReady || isAllowedWhileBooting(app.info);
    List<ProviderInfo> providers = normalMode ?
        generateApplicationProvidersLocked(app) : null;

    //app进程存在正在启动中的provider
    // 则超时10s后发送CONTENT_PROVIDER_PUBLISH_TIMEOUT_MSG消息
    if (providers != null && checkAppInLaunchingProvidersLocked(app)) {
        Message msg = mHandler.obtainMessage(
            CONTENT_PROVIDER_PUBLISH_TIMEOUT_MSG);
        msg.obj = app;
        mHandler.sendMessageDelayed(msg, CONTENT_PROVIDER_PUBLISH_TIMEOUT);
    }
    ......
}
  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10

  • 11

  • 12

  • 13

  • 14

  • 15

  • 16

  • 17

  • 18

  • 19

  • 20

  • 21

  • 22

  • 23

  • 24

  • 25

  • 26

4.2 拆炸弹

当 provider 成功 publish 之后,便会拆除该炸弹。

4.2.1 AMS.publishContentProviders

public final void publishContentProviders(IApplicationThread caller,
    List<ContentProviderHolder> providers) {
   ......   
   synchronized (this) {
       final ProcessRecord r = getRecordForAppLocked(caller);
       
       final int N = providers.size();
       for (int i = 0; i < N; i++) {
           ContentProviderHolder src = providers.get(i);
           ......
           ContentProviderRecord dst = r.pubProviders.get(src.info.name);
           if (dst != null) {
               ComponentName comp =
               new ComponentName(dst.info.packageName, dst.info.name);
               //将该provider添加到mProviderMap
               mProviderMap.putProviderByClass(comp, dst); 
               String names[] = dst.info.authority.split(";");
               for (int j = 0; j < names.length; j++) {
                   mProviderMap.putProviderByName(names[j], dst);
               }

               int launchingCount = mLaunchingProviders.size();
               int j;
               boolean wasInLaunchingProviders = false;
               for (j = 0; j < launchingCount; j++) {
                   if (mLaunchingProviders.get(j) == dst) {
                       //将该provider移除mLaunchingProviders队列
                       mLaunchingProviders.remove(j);
                       wasInLaunchingProviders = true;
                       j--;
                       launchingCount--;
                   }
               }
               //成功pubish则移除该消息
               if (wasInLaunchingProviders) {
                   mHandler.removeMessages(
                   CONTENT_PROVIDER_PUBLISH_TIMEOUT_MSG, r);
               }
               synchronized (dst) {
                   dst.provider = src.provider;
                   dst.proc = r;
                   //唤醒客户端的wait等待方法
                   dst.notifyAll();
               }
               ......
           }
       }
   }    
}
  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10

  • 11

  • 12

  • 13

  • 14

  • 15

  • 16

  • 17

  • 18

  • 19

  • 20

  • 21

  • 22

  • 23

  • 24

  • 25

  • 26

  • 27

  • 28

  • 29

  • 30

  • 31

  • 32

  • 33

  • 34

  • 35

  • 36

  • 37

  • 38

  • 39

  • 40

  • 41

  • 42

  • 43

  • 44

  • 45

  • 46

  • 47

  • 48

  • 49

4.3 引爆炸弹

在 system_server 进程中有一个 Handler 线程, 名 叫”ActivityManager”。当倒计时结束便会向该 Handler 线程发送 一条信息 CONTENT_PROVIDER_PUBLISH_TIMEOUT_MSG

4.3.1 MainHandler.handleMessage

ActivityManagerService.java ::MainHandler

final class MainHandler extends Handler {
    public void handleMessage(Message msg) {
        switch (msg.what) {
        ......
            case CONTENT_PROVIDER_PUBLISH_TIMEOUT_MSG: {
                ProcessRecord app = (ProcessRecord)msg.obj;
                synchronized (ActivityManagerService.this) {
                    processContentProviderPublishTimedOutLocked(app);
                }
            } break;
            ......
        }
        ......
    }
}
  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10

  • 11

  • 12

  • 13

  • 14

  • 15

4.3.2 AMS.processContentProviderPublishTimedOutLocked

private final void processContentProviderPublishTimedOutLocked(
    ProcessRecord app) {
        cleanupAppInLaunchingProvidersLocked(app, true);
        mProcessList.removeProcessLocked(app, false, true,
        "timeout publishing content providers");
}
  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

4.3.3 AMS.cleanupAppInLaunchingProvidersLocked

boolean cleanupAppInLaunchingProvidersLocked(
    ProcessRecord app, boolean alwaysBad) {
        boolean restart = false;
        for (int i = mLaunchingProviders.size() - 1; i >= 0; i--) {
            ContentProviderRecord cpr = mLaunchingProviders.get(i);
            if (cpr.launchingApp == app) {
                if (!alwaysBad && !app.bad && cpr.hasConnectionOrHandle()) {
                    restart = true;
                } else {
                    //移除死亡的provider
                    removeDyingProviderLocked(app, cpr, true);
                }
            }
        }
        return restart;
    }
  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10

  • 11

  • 12

  • 13

  • 14

  • 15

  • 16

removeDyingProviderLocked() 的功能跟进程的存活息息相关

  • 对于 stable 类型的 provider (即 conn.stableCount > 0),则会杀掉所有跟该 provider 建立 stable 连接的非persistent 进程

  • 对于 unstable 类的 provider (即 conn.unstableCount > 0),并不会导致 client 进程被级联所杀

4.3.4 ProcessList.removeProcessLocked

boolean removeProcessLocked(ProcessRecord app,
        boolean callerWillRestart, boolean allowRestart, String reason) {
        final String name = app.processName;
        final int uid = app.uid;
        ......
        //移除mProcessNames中的相应对象
        removeProcessNameLocked(name, uid);
        mService.mAtmInternal.clearHeavyWeightProcessIfEquals(
            app.getWindowProcessController());

        boolean needRestart = false;
        if ((app.pid > 0 && app.pid != ActivityManagerService.MY_PID) ||
             (app.pid == 0 && app.pendingStart)) {
            int pid = app.pid;
            if (pid > 0) {
                ......
            }
            boolean willRestart = false;
            if (app.isPersistent() && !app.isolated) {
                if (!callerWillRestart) {
                    willRestart = true;
                } else {
                    needRestart = true;
                }
            }
            app.kill(reason, true);//杀进程
            mService.handleAppDiedLocked(app, willRestart, allowRestart);
            if (willRestart) {
                removeLruProcessLocked(app);
                mService.addAppLocked(app.info, null, false, null /* ABI override */);
            }
        } else {
            mRemovedProcesses.add(app);
        }

        return needRestart;
    }
  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10

  • 11

  • 12

  • 13

  • 14

  • 15

  • 16

  • 17

  • 18

  • 19

  • 20

  • 21

  • 22

  • 23

  • 24

  • 25

  • 26

  • 27

  • 28

  • 29

  • 30

  • 31

  • 32

  • 33

  • 34

  • 35

  • 36

  • 37

五 总结

当出现 ANR 时,都是调用到 AMS.appNotResponding() 方法,详细过程见文章理解Android ANR的信息收集过程. 当然这里介绍的 provider 例外。

5.1 Timeout时长

  • 对于前台服务,则超时为 SERVICE_TIMEOUT = 20s

  • 对于后台服务,则超时为 SERVICE_BACKGROUND_TIMEOUT = 200s

  • 对于前台广播,则超时为 BROADCAST_FG_TIMEOUT = 10s

  • 对于后台广播,则超时为 BROADCAST_BG_TIMEOUT = 60s

  • ContentProvider 超时为 CONTENT_PROVIDER_PUBLISH_TIMEOUT = 10s

5.2 超时检测

Service 超时检测机制:

  • 超过一定时间没有执行完相应操作来触发移除延时消息,则会触发 anr

BroadcastReceiver 超时检测机制:

  • 有序广播的总执行时间超过 2* receiver 个数 * timeout 时长,则会触发 anr

  • 有序广播的某一个 receiver 执行过程超过 timeout 时长,则会触发 anr

另外:

  • 对于 Service,Broadcast,Input 发生 ANR 之后,最终都会调用 AMS.appNotResponding

  • 对于 provider,在其进程启动时 publish 过程可能会出现 ANR,则会直接杀进程以及清理相应信息,而不会弹出 ANR 的对话框。appNotRespondingViaProvider() 过程会走 appNotResponding(),这个就不介绍了,很少使用,由用户自定义超时时间.

 原文链接:

https://blog.csdn.net/liuwg1226/article/details/11383483

至此,本篇已结束。转载网络的文章,小编觉得很优秀,欢迎点击阅读原文,支持原创作者,如有侵权,恳请联系小编删除,欢迎您的建议与指正。同时期待您的关注,感谢您的阅读,谢谢!

aef0bd79021814fcb0d1da62aff05493.jpeg

点个在看,方便您使用时快速查找!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值