Android ANR原理分析

最新推荐文章于 2024-09-11 16:47:38 发布
最新推荐文章于 2024-09-11 16:47:38 发布
阅读量655 收藏 1
点赞数 2
分类专栏： debug

一、概述

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

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

  • Service Timeout:服务在20s内未执行完成；
  • BroadcastQueue Timeout：比如前台广播在10s内执行完成
  • ContentProvider Timeout：内容提供者执行超时
  • inputDispatching Timeout: 输入事件分发超时5s，包括按键分发事件的超时。

二、ANR触发时机

2.1 Service Timeout

Service Timeout触发时机，简单说就是AMS中的mHandler收到SERVICE_TIMEOUT_MSG消息时触发。

在前面文章startService流程分析详细介绍Service启动流程，在Service所在进程attach到system_server进程的过程中会调用realStartServiceLocked()方法

2.1.1 realStartServiceLocked

[-> ActiveServices.java]

private final void realStartServiceLocked(ServiceRecord r,
        ProcessRecord app, boolean execInFg) throws RemoteException {
    ...
    //发送delay消息(SERVICE_TIMEOUT_MSG)，【见小节2.1.2】
    bumpServiceExecutingLocked(r, execInFg, "create");
    try {
        ...
        //最终执行服务的onCreate()方法
        app.thread.scheduleCreateService(r, r.serviceInfo,
                mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),
                app.repProcState);

        } catch (DeadObjectException e) {
            ...
    } finally {
        if (!created) {
            //当service启动完毕，则remove SERVICE_TIMEOUT_MSG消息【见小节2.1.3】
            serviceDoneExecutingLocked(r, inDestroying, inDestroying);
            ...
        }
    }
}

2.1.2 bumpServiceExecutingLocked

该方法的主要工作发送delay消息(SERVICE_TIMEOUT_MSG)

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;
    }
    long now = SystemClock.uptimeMillis();
    Message msg = mAm.mHandler.obtainMessage(
            ActivityManagerService.SERVICE_TIMEOUT_MSG);
    msg.obj = proc;
    //当超时后仍没有remove该SERVICE_TIMEOUT_MSG消息，则执行service Timeout流程【见2.1.4】
    mAm.mHandler.sendMessageAtTime(msg,
            proc.execServicesFg ? (now+SERVICE_TIMEOUT) : (now+ SERVICE_BACKGROUND_TIMEOUT));
}
  • 对于前台服务，则超时为SERVICE_TIMEOUT，即timeout=20s；
  • 对于后台服务，则超时为SERVICE_BACKGROUND_TIMEOUT，即timeout=200s；

2.1.3 serviceDoneExecutingLocked

该方法的主要工作是当service启动完成，则移除service Timeout消息。

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);
        ...
    }
    ...
}

2.1.4 SERVICE_TIMEOUT_MSG

到此不难理解，当SERVICE_TIMEOUT_MSG消息成功发送时，则AMS中的mHandler收到该消息则触发调用serviceTimeout。

final class MainHandler extends Handler {
    public void handleMessage(Message msg) {
        switch (msg.what) {
            case SERVICE_TIMEOUT_MSG: {
                ...
                //【见小节2.1.5】
                mServices.serviceTimeout((ProcessRecord)msg.obj);
            } break;
            ...
        }
        ...
    }
}

2.1.5 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.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【见小节3.1】
        mAm.appNotResponding(proc, null, null, false, anrMessage);
    }
}

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

2.2 BroadcastQueue Timeout

BroadcastQueue Timeout触发时机，简单说就是BroadcastQueue中的mHandler收到BROADCAST_TIMEOUT_MSG消息时触发。

在前面文章Android Broadcast广播机制分析详细介绍广播启动流程，在发送广播过程中会执行scheduleBroadcastsLocked方法来处理相关的广播，然后会调用到processNextBroadcast方法来处理下一条广播。

processNextBroadcast执行过程分4步骤：

  • step1. 处理并行广播
  • step2. 处理当前有序广播
  • step3. 获取下条有序广播
  • step4. 处理下条有序广播

2.2.1 processNextBroadcast

[-> BroadcastQueue.java]

final void processNextBroadcast(boolean fromMsg) {
    synchronized(mService) {
        ...
        //step 2: 处理当前有序广播
        do {
            r = mOrderedBroadcasts.get(0);
            //获取所有该广播所有的接收者
            int numReceivers = (r.receivers != null) ? r.receivers.size() : 0;
            if (mService.mProcessesReady && r.dispatchTime > 0) {
                long now = SystemClock.uptimeMillis();
                if ((numReceivers > 0) &&
                        (now > r.dispatchTime + (2*mTimeoutPeriod*numReceivers))) {
                    //当广播处理时间超时，则强制结束这条广播【见小节2.2.5】
                    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;
                }
                //取消BROADCAST_TIMEOUT_MSG消息【见小节2.2.3】
                cancelBroadcastTimeoutLocked();
            }
        } while (r == null);
        ...

        //step 3: 获取下条有序广播
        r.receiverTime = SystemClock.uptimeMillis();
        if (!mPendingBroadcastTimeoutMessage) {
            long timeoutTime = r.receiverTime + mTimeoutPeriod;
            //设置广播超时时间，发送BROADCAST_TIMEOUT_MSG【见小节2.2.2】
            setBroadcastTimeoutLocked(timeoutTime);
        }
        ...
    }
}

对于广播超时处理时机：

  1. 首先在step3的过程中setBroadcastTimeoutLocked(timeoutTime) 设置超时广播消息；
  2. 然后在step2根据广播处理情况来处理：
    • 当广播接收者等待时间过长，则调用broadcastTimeoutLocked(false);
    • 当，cancelBroadcastTimeoutLocked

2.2.2 setBroadcastTimeoutLocked

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

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

  • 对于前台广播，则超时为BROADCAST_FG_TIMEOUT，即timeout=10s；
  • 对于后台广播，则超时为BROADCAST_BG_TIMEOUT，即timeout=60s。

2.2.3 cancelBroadcastTimeoutLocked

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

移除广播超时消息BROADCAST_TIMEOUT_MSG

2.2.4 BROADCAST_TIMEOUT_MSG

到此不难理解，当BROADCAST_TIMEOUT_MSG消息成功发送时，则AMS中的mHandler收到该消息则触发调用serviceTimeout。

private final class BroadcastHandler extends Handler {
    public void handleMessage(Message msg) {
        switch (msg.what) {
            case BROADCAST_TIMEOUT_MSG: {
                synchronized (mService) {
                    //【见小节2.2.5】
                    broadcastTimeoutLocked(true);
                }
            } break;
            ...
        }
        ...
    }
}

2.2.5 broadcastTimeoutLocked

[-> BroadcastRecord.java]

final void broadcastTimeoutLocked(boolean fromMsg) {
    if (fromMsg) {
        mPendingBroadcastTimeoutMessage = false;
    }

    if (mOrderedBroadcasts.size() == 0) {
        return;
    }

    long now = SystemClock.uptimeMillis();
    BroadcastRecord r = mOrderedBroadcasts.get(0);
    if (fromMsg) {
        if (mService.mDidDexOpt) {
            //延迟timeouts直到dexopt结束
            mService.mDidDexOpt = false;
            long timeoutTime = SystemClock.uptimeMillis() + mTimeoutPeriod;
            setBroadcastTimeoutLocked(timeoutTime);
            return;
        }
        if (!mService.mProcessesReady) {
            //当系统还没有准备就绪时，广播处理流程中不存在广播超时
            return;
        }

        long timeoutTime = r.receiverTime + mTimeoutPeriod;
        if (timeoutTime > now) {
            //过早的timeout，重新设置广播超时
            setBroadcastTimeoutLocked(timeoutTime);
            return;
        }
    }

    BroadcastRecord br = mOrderedBroadcasts.get(0);
    if (br.state == BroadcastRecord.WAITING_SERVICES) {
        //广播已经处理完成，但需要等待已启动service执行完成。当等待足够时间，则处理下一条广播。
        br.curComponent = null;
        br.state = BroadcastRecord.IDLE;
        processNextBroadcast(false);
        return;
    }

    r.receiverTime = now;
    //当前BroadcastRecord的anr次数执行加1操作
    r.anrCount++;

    if (r.nextReceiver <= 0) {
        return;
    }

    ProcessRecord app = null;
    String anrMessage = null;

    Object curReceiver = r.receivers.get(r.nextReceiver-1);
    //根据情况记录广播接收者丢弃的EventLog
    logBroadcastReceiverDiscardLocked(r);
    if (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 (anrMessage != null) {
        //【见小节2.2.6】
        mHandler.post(new AppNotResponding(app, anrMessage));
    }
}

2.2.6 AppNotResponding

[-> BroadcastQueue.java]

private final class AppNotResponding implements Runnable {
    ...
    public void run() {
        //【见小节3.1】
        mService.appNotResponding(mApp, null, null, false, mAnnotation);
    }
}

2.3 ContentProvider Timeout

2.3.1 AMS.appNotRespondingViaProvider

public void appNotRespondingViaProvider(IBinder connection) {
    enforceCallingPermission(
            android.Manifest.permission.REMOVE_TASKS, "appNotRespondingViaProvider()");

    final ContentProviderConnection conn = (ContentProviderConnection) connection;
    if (conn == null) {
        return;
    }

    final ProcessRecord host = conn.provider.proc;
    //无法找到provider所处的进程
    if (host == null) {
        return;
    }

    final long token = Binder.clearCallingIdentity();
    try {
        //【见小节3.1】
        appNotResponding(host, null, null, false, "ContentProvider not responding");
    } finally {
        Binder.restoreCallingIdentity(token);
    }
}

Timeout时间20s

调用链：

ContentProviderClient.NotRespondingRunnable.run
    ContextImpl.ApplicationContentResolver.appNotRespondingViaProvider
        ActivityThread.appNotRespondingViaProvider
            AMP.appNotRespondingViaProvider
                AMS.appNotRespondingViaProvider

2.4 inputDispatching Timeout

在native层InputDispatcher.cpp中经过层层调用，此处先省略过程，后续再展开，从native层com_android_server_input_InputManagerService调用到java层InputManagerService。

2.4.1 IMS.notifyANR

[-> InputManagerService.java]

private long notifyANR(InputApplicationHandle inputApplicationHandle,
        InputWindowHandle inputWindowHandle, String reason) {
    //【见小节2.4.2】
    return mWindowManagerCallbacks.notifyANR(
            inputApplicationHandle, inputWindowHandle, reason);
}

mWindowManagerCallbacks为InputMonitor对象

2.4.2 notifyANR

[-> InputMonitor.java]

public long notifyANR(InputApplicationHandle inputApplicationHandle,
        InputWindowHandle inputWindowHandle, String reason) {
    AppWindowToken appWindowToken = null;
    WindowState windowState = null;
    boolean aboveSystem = false;
    synchronized (mService.mWindowMap) {
        if (inputWindowHandle != null) {
            windowState = (WindowState) inputWindowHandle.windowState;
            if (windowState != null) {
                appWindowToken = windowState.mAppToken;
            }
        }
        if (appWindowToken == null && inputApplicationHandle != null) {
            appWindowToken = (AppWindowToken)inputApplicationHandle.appWindowToken;
        }
        //输出input事件分发超时log
        if (windowState != null) {
            Slog.i(WindowManagerService.TAG, "Input event dispatching timed out "
                    + "sending to " + windowState.mAttrs.getTitle()
                    + ".  Reason: " + reason);
            int systemAlertLayer = mService.mPolicy.windowTypeToLayerLw(
                    WindowManager.LayoutParams.TYPE_SYSTEM_ALERT);
            aboveSystem = windowState.mBaseLayer > systemAlertLayer;
        } else if (appWindowToken != null) {
            Slog.i(WindowManagerService.TAG, "Input event dispatching timed out "
                    + "sending to application " + appWindowToken.stringName
                    + ".  Reason: " + reason);
        } else {
            Slog.i(WindowManagerService.TAG, "Input event dispatching timed out "
                    + ".  Reason: " + reason);
        }
        mService.saveANRStateLocked(appWindowToken, windowState, reason);
    }

    if (appWindowToken != null && appWindowToken.appToken != null) {
        //【见小节2.5.1】
        boolean abort = appWindowToken.appToken.keyDispatchingTimedOut(reason);
        if (! abort) {
            return appWindowToken.inputDispatchingTimeoutNanos;
        }
    } else if (windowState != null) {
        //AMP经过binder，最终调用到AMS【见小节2.4.3】
        long timeout = ActivityManagerNative.getDefault().inputDispatchingTimedOut(
                windowState.mSession.mPid, aboveSystem, reason);
        if (timeout >= 0) {
            return timeout * 1000000L; //转化为纳秒
        }
    }
    return 0;
}

2.4.3 AMS.inputDispatchingTimedOut

public long inputDispatchingTimedOut(int pid, final boolean aboveSystem, String reason) {
    ...
    ProcessRecord proc;
    long timeout;
    synchronized (this) {
        synchronized (mPidsSelfLocked) {
            proc = mPidsSelfLocked.get(pid); //根据pid查看进程record
        }
        timeout = getInputDispatchingTimeoutLocked(proc);
    }
    //【见小节2.4.4】
    if (!inputDispatchingTimedOut(proc, null, null, aboveSystem, reason)) {
        return -1;
    }

    return timeout;
}

inputDispatching的超时为KEY_DISPATCHING_TIMEOUT，即timeout = 5s

2.4.4 AMS.inputDispatchingTimedOut

public boolean inputDispatchingTimedOut(final ProcessRecord proc,
        final ActivityRecord activity, final ActivityRecord parent,
        final boolean aboveSystem, String reason) {
    ...
    final String annotation;
    if (reason == null) {
        annotation = "Input dispatching timed out";
    } else {
        annotation = "Input dispatching timed out (" + reason + ")";
    }

    if (proc != null) {
        ...
        mHandler.post(new Runnable() {
            public void run() {
                //【见小节3.1】
                appNotResponding(proc, activity, parent, aboveSystem, annotation);
            }
        });
    }
    return true;
}

调用链：

InputManagerService.notifyANR
    InputMonitor.notifyANR
        AMP.inputDispatchingTimedOut
            AMS.inputDispatchingTimedOut

2.5 keyDispatching Timeout

keyDispatching timout与inputDispatching Timeout流畅基本一致。

调用链：

InputManagerService.notifyANR
    InputMonitor.notifyANR
        ActivityRecord.Token.keyDispatchingTimedOut
            AMS.inputDispatchingTimedOut

Token.keyDispatchingTimedOut

[-> ActivityRecord.java]

final class ActivityRecord {
    static class Token extends IApplicationToken.Stub {
        public boolean keyDispatchingTimedOut(String reason) {
            ActivityRecord r;
            ActivityRecord anrActivity;
            ProcessRecord anrApp;
            synchronized (mService) {
                r = tokenToActivityRecordLocked(this);
                if (r == null) {
                    return false;
                }
                anrActivity = r.getWaitingHistoryRecordLocked();
                anrApp = r != null ? r.app : null;
            }
            return mService.inputDispatchingTimedOut(anrApp, anrActivity, r, false, reason);
        }
        ...
    }
}

对于keyDispatching Timeout的ANR，当触发该类型ANR时，如果不再有输入事件，则不会弹出ANR对话框；只有在下一次input事件产生后5s才弹出ANR提示框。

三、ANR工作

3.1 appNotResponding

[-> ActivityManagerService.java]

final void appNotResponding(ProcessRecord app, ActivityRecord activity,
        ActivityRecord parent, boolean aboveSystem, final String annotation) {
    ArrayList<Integer> firstPids = new ArrayList<Integer>(5);
    SparseArray<Boolean> lastPids = new SparseArray<Boolean>(20);

    if (mController != null) {
        try {
            // 0 == continue, -1 = kill process immediately
            int res = mController.appEarlyNotResponding(app.processName, app.pid, annotation);
            if (res < 0 && app.pid != MY_PID) {
                app.kill("anr", true);
            }
        } catch (RemoteException e) {
            mController = null;
            Watchdog.getInstance().setActivityController(null);
        }
    }

    long anrTime = SystemClock.uptimeMillis();
    if (MONITOR_CPU_USAGE) {
        updateCpuStatsNow();
    }

    synchronized (this) {
        // PowerManager.reboot() 会阻塞很长时间，因此忽略关机时的ANR
        if (mShuttingDown) {
            Slog.i(TAG, "During shutdown skipping ANR: " + app + " " + annotation);
            return;
        } else if (app.notResponding) {
            Slog.i(TAG, "Skipping duplicate ANR: " + app + " " + annotation);
            return;
        } else if (app.crashing) {
            Slog.i(TAG, "Crashing app skipping ANR: " + app + " " + annotation);
            return;
        }

        app.notResponding = true;

        //记录ANR
        EventLog.writeEvent(EventLogTags.AM_ANR, app.userId, app.pid,
                app.processName, app.info.flags, annotation);

        // Dump thread traces as quickly as we can, starting with "interesting" processes.
        firstPids.add(app.pid);

        int parentPid = app.pid;
        if (parent != null && parent.app != null && parent.app.pid > 0) parentPid = parent.app.pid;
        if (parentPid != app.pid) firstPids.add(parentPid);

        if (MY_PID != app.pid && MY_PID != parentPid) firstPids.add(MY_PID);

        for (int i = mLruProcesses.size() - 1; i >= 0; i--) {
            ProcessRecord r = mLruProcesses.get(i);
            if (r != null && r.thread != null) {
                int pid = r.pid;
                if (pid > 0 && pid != app.pid && pid != parentPid && pid != MY_PID) {
                    if (r.persistent) {
                        firstPids.add(pid);
                    } else {
                        lastPids.put(pid, Boolean.TRUE);
                    }
                }
            }
        }
    }

    //输出ANR到main log.
    StringBuilder info = new StringBuilder();
    info.setLength(0);
    info.append("ANR in ").append(app.processName);
    if (activity != null && activity.shortComponentName != null) {
        info.append(" (").append(activity.shortComponentName).append(")");
    }
    info.append("\n");
    info.append("PID: ").append(app.pid).append("\n");
    if (annotation != null) {
        info.append("Reason: ").append(annotation).append("\n");
    }
    if (parent != null && parent != activity) {
        info.append("Parent: ").append(parent.shortComponentName).append("\n");
    }

    final ProcessCpuTracker processCpuTracker = new ProcessCpuTracker(true);
    //dump栈信息
    File tracesFile = dumpStackTraces(true, firstPids, processCpuTracker, lastPids,
            NATIVE_STACKS_OF_INTEREST);

    String cpuInfo = null;
    if (MONITOR_CPU_USAGE) {
        updateCpuStatsNow();
        synchronized (mProcessCpuTracker) {
            //输出各个进程的CPU使用情况
            cpuInfo = mProcessCpuTracker.printCurrentState(anrTime);
        }
        //输出CPU负载
        info.append(processCpuTracker.printCurrentLoad());
        info.append(cpuInfo);
    }

    info.append(processCpuTracker.printCurrentState(anrTime));

    Slog.e(TAG, info.toString());
    if (tracesFile == null) {
        //发送signal 3来dump栈信息
        Process.sendSignal(app.pid, Process.SIGNAL_QUIT);
    }
    //将anr信息添加到dropbox
    addErrorToDropBox("anr", app, app.processName, activity, parent, annotation,
            cpuInfo, tracesFile, null);

    if (mController != null) {
        try {
            // 0 == show dialog, 1 = keep waiting, -1 = kill process immediately
            int res = mController.appNotResponding(app.processName, app.pid, info.toString());
            if (res != 0) {
                if (res < 0 && app.pid != MY_PID) {
                    app.kill("anr", true);
                } else {
                    synchronized (this) {
                        mServices.scheduleServiceTimeoutLocked(app);
                    }
                }
                return;
            }
        } catch (RemoteException e) {
            mController = null;
            Watchdog.getInstance().setActivityController(null);
        }
    }

    boolean showBackground = Settings.Secure.getInt(mContext.getContentResolver(),
            Settings.Secure.ANR_SHOW_BACKGROUND, 0) != 0;

    synchronized (this) {
        mBatteryStatsService.noteProcessAnr(app.processName, app.uid);

        if (!showBackground && !app.isInterestingToUserLocked() && app.pid != MY_PID) {
            app.kill("bg anr", true);
            return;
        }

        // Set the app's notResponding state, and look up the errorReportReceiver
        makeAppNotRespondingLocked(app,
                activity != null ? activity.shortComponentName : null,
                annotation != null ? "ANR " + annotation : "ANR",
                info.toString());

        //弹出ANR对话框
        Message msg = Message.obtain();
        HashMap<String, Object> map = new HashMap<String, Object>();
        msg.what = SHOW_NOT_RESPONDING_MSG;
        msg.obj = map;
        msg.arg1 = aboveSystem ? 1 : 0;
        map.put("app", app);
        if (activity != null) {
            map.put("activity", activity);
        }

        mUiHandler.sendMessage(msg);
    }
}

主要发送ANR， 则会输出

  • 各个进程的CPU使用情况；
  • CPU负载；
  • IOWait；
  • traces文件

四、其他

导致ANR常见情形：

  • I/O阻塞
  • 网络阻塞；
  • onReceiver执行时间超过10s;
  • 多线程死锁

避免ANR:

  • UI线程尽量只做跟UI相关的工作
  • 耗时的工作()比如数据库操作，I/O，网络操作)，采用单独的工作线程处理
  • 用Handler来处理UIthread和工作thread的交互

UI线程，例如：

  • Activity:onCreate(), onResume(), onDestroy(), onKeyDown(), onClick(),etc
  • AsyncTask: onPreExecute(), onProgressUpdate(), onPostExecute(), onCancel,etc
  • Mainthread handler: handleMessage(), post*(runnable r), etc
  • …

ANR分析：需要关注CPU/IO，trace死锁等数据。

蓝白天际线
关注
专栏目录
Android ANR原理代码分析(二)
潇洒一刀的博客
04-19 1718
系统触发ANR机制 如系统显示ANR机制分析，都是通过appNotResponding来触发ANR对话框的显示，我们通过索引搜索可以发现，总共有五个地方可以产生这个调用，这5个调用正是引起ANR的5个原因。 com.android.server.am.ActivityManagerService#appNotRespondingViaProvider : ContentProvider 超时，目前没有使用。 com.android.server.am.ActiveServices#serviceFo
Android ANR机制的原理以及问题分析（一）
wcsbhwy的博客
05-13 2100
文章目录一、前言二、 ANR的类型三、臭名昭著的ANR 一、前言 Android开发人员对ANR应该毫不陌生——Application Not Responding，即应用程序未响应。ANR的核心原理是消息机制的调度和超时处理，它要求主线程在限定时间内做完任务处理，比如：启动Activity/Service、发送广播、ContentProvider查询、Input事件分发等，否则就可能发生ANR引起性能问题。处理超时时，系统会认为当前主线程已经失去响应其他操作的能力。这些耗时操作包括：密集的CPU运算、大量
我的总结--Android之ANR的原理（Input, Service, Broadcast)
08-22
关于ANR原理的透彻总结，简单易懂
ANR原理
最新发布
qq_51598534的博客
09-11 803
即:启动一个App,首先经过App的生命周期变化,在App端完成我on_resumed后,会进行绘制步骤,经过WMS,WMS调用至SurfaceFlinger端,最终由SurfaceFlinger端调用至IrnputDispatcher,保存新的焦点窗口信息。每个WindowState都有一个对应的WindowStateAnimator,主要负责责:计算窗口动画的帧,管理窗口的Surface(一个提供屏幕绘制区域的概念),与SurfaceFlinger交流,以便正确显示窗口的动画。
关于Android中ANR的一些思考
java开发指南博客 【转载】
08-17 144
本人博客原文 以前做Android系统开发，一般很少写程序。现在到一公司做Android互联网应用，程序中不时出现一些ANR。 上峰对ANR非常的关注，期望我能彻底解决该项目的ANR。⊙﹏⊙b汗！ 因此我对ANR进行了些思考，并和刚从腾讯QQ项目组跳槽来公司北京总部的某架构师同事进行了探讨。他也基本认同我的观点。 现将我应对ANR的思路整理如下： 一、在项目之前，应...
Android ANR机制
fenghanfenghan的博客
10-13 706
在该条log之后会有CPU usage的信息，表明了CPU在ANR前后的用量（log会表明截取ANR的时间），从各种CPU Usage信息中大概可以分析如下几点：(1). 如果某些进程的CPU占用百分比较高，几乎占用了所有CPU资源，而发生ANR的进程CPU占用为0%或非常低，则认为CPU资源被占用，进程没有被分配足够的资源，从而发生了ANR。其中的time，是在最开始startServiceLocked函数中判断出前/后台进程，然后装在ServiceRecord中，一路传过来的。
【Android】ANR的设计原理
Misdirection_XG的博客
07-06 271
上述的道理也很容易理解，A和B一定不能在同一个线程，因为如果是同一个线程，B如果陷入死循环，那么C永远都执行不到了，还检测个毛。如果B执行完了，只去通知A清除标记F，而不清除C可以吗，也可以！但是这个时候C还会继续等待，等到T时间后，去检测F，F肯定是不在的，就检测了个寂寞，还不如直接取消。就像上述例子我提前去告诉老师一样，B提前去告诉A结束C。所以，我们可以将ANR更精炼的总结为: 埋雷、拆雷和爆雷三个步骤。了解了基本道理，我们就可以通过代码来验证下，我们来看下四大组件中的Service的ANR检测逻辑。
通过Android trace文件分析死锁ANR实例过程
09-05
本文将通过一个具体的死锁导致的ANR实例，解析如何利用Android trace文件来分析和解决这类问题。 当Android系统检测到ANR发生时，会在/data/anr/目录下自动生成一个trace文件，其中包含了系统运行时的详细信息，如...
android anr定位分析,Android ANR产生的原因以及其定位分析
weixin_42525385的博客
05-26 3785
前言ANR是Android中一个独有的概念，它的全称是Application Not Responding(应用程序无响应)。相信从事Android开发的同学，或多或少都遇到过，对于高质量的代码，ANR在开发者自测过程中可能不会经常遇到，但一旦测试人员进行Monkey测试，ANR出现的概率就比较高了，如何快速分析定位并解决，是开发者的必修课。ANR的直观体验是用户在操作APP的过程中，感觉界面卡顿...
Android ANR原理以及机制
u012845099的博客
04-09 1764
一我们平时遇到的ANR问题大部分是input ANR类型，本文以input ANR为例进行梳理，这块机制并不复杂，受限于篇幅，本文只介绍埋下计时和check超时的代码部分。正常输入事件的分发流程如下findFocusedWindowTargetsLocked这个函数从字面不难猜出其意图: 查找有焦点的window。该函数较长，我们将其拆分开来进行梳理未找到focused的window，也未找到focused的application这种情况下，则drop该事件。
浅谈Android ANR在线监控原理
08-28
主要介绍了浅谈Android ANR在线监控原理,小编觉得挺不错的，现在分享给大家，也给大家做个参考。一起跟随小编过来看看吧
android的ANR原理剖析及图解(基于android9.0)
qq_23081779的博客
09-19 1083
android中如果在主线程执行耗时操作，那么将会弹出系统弹窗ANR，那么framework层是如何实现超时的判定、都有哪些情况会产生ANR呢？ 经过分析framework源码发现，有以下四种场景会引起ANR InputDispatching Timeout: 输入事件分发超时5s，包括按键分发事件的超时 Service Timeout:服务在20s内未执行完成 BroadcastQueue T...
深度刨析Android ANR触发原理
a546036242的博客
03-18 1014
ANR(Application Not responding)，是指应用程序未响应，Android系统对于一些事件需要在一定的时间范围内完成，如果超过预定时间能未能得到有效响应或者响应时间过长，都会造成ANR。一般地，这时往往会弹出一个提示框，告知用户当前xxx未响应，用户可选择继续等待或者Force Close。那么哪些场景会造成ANR呢？Service Timeout:比如前台服务在20s内未执行完成；BroadcastQueue Timeout：比如前台广播在10s内未执行完成。
Android ANR 实现机制详解
话唠扇贝的博客
02-18 1127
ANR(Application Not Responding)，即应用程序无响应，Android 系统指定某些事件需要在规定时间内完成，如果超过预定时间还能未能得到有效响应，就会造成 ANR。具体表现为，应用位于前台时，系统会向用户显示一个对话框，如下图所示。用户可以选择“wait”让程序继续运行，也可以选择“Close app”强制关闭。
Android按键超时的ANR原理小结
wuhengde的专栏
09-22 8797
1) 按键处理主要的功臣是WindowManagerService. mInputManager @WindowManagerService.java mInputManager = new InputManager(context, this);   @InputManager.java      public InputManager(Context context, W
Android ANR详解
Dream It Possible
02-18 3331
然后​InputDispatcher​开始了第一轮的事件分发，此时并没有正在处理的事件，因此​InputDispatcher​从​inBoundQueue​队列头部取出事件，并重置ANR的计时，并检查窗口是否就绪，此时窗口准备就绪，将该事件转移到了​outBoundQueue​队列中，因为应用管道对端连接正常，因此事件从​outBoundQueue​取出，然后放入了​waitQueue​队列，因为​Socket​双向通信已经建立，接下来就是 应用进程 接收到新的事件，然后对其进行分发。
彻底理解Android ANR机制 一篇就够了
a546036242的博客
03-18 3031
不论从事安卓应用开发，还是安卓系统研发，应该都遇到应用无响应（ANR，Application Not Responding）问题，当应用程序一段时间无法及时响应，则会弹出ANR对话框，让用户选择继续等待，还是强制关闭。绝大多数人对ANR的了解仅停留在主线程耗时或CPU繁忙会导致ANR。面试过无数的候选人，几乎没有人能真正从系统级去梳理清晰ANR的来龙去脉，比如有哪些路径会引发ANR?有没有可能主线程不耗时也出现ANR？如何更好的调试ANR?
【Android】Android ANR产生过程与分析方法
devnn的专栏
10-02 3959
Android ANR问题一直是比较难解决的问题，一来它比较难以复现，二来复现后也不太好分析。这篇文件梳理一下ANR问题产生的过程以及出现ANR问题拿到日志文件如何进行定位原因。其实关于ANR线上监控也是比较棘手的，看了这篇文章我们再去看一些ANR端上监控方案(比如微信Matrix)也许思路更多清晰。
Android面试必知：ANR原理与解决策略
5. **错误处理与日志**：面试者可能询问如何处理运行时异常和异常日志，包括使用`Logcat`分析应用崩溃，尤其是检查那些未捕获的异常和可能导致ANR的情况。 6. **组件的声明与注册**： - Activity、Service和...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值