「Android」ANR入门学习笔记

ANR 全称是 Applicatipon Not Response ，Android 设计 ANR 的用意，是零碎通过与之交互的组件以及用户交互进行超时监控，用来判断利用过程是否存在卡死或响应过慢的问题

ANR 的触发起因

应用层导致 ANR 的起因：

  • 函数阻塞：如死循环、主线程 IO、解决大数据
  • 锁出错：主线程期待子线程的锁
  • 内存缓和：零碎调配给一个利用的内存是有下限的，长期处于内存缓和，会导致频繁内存替换，进而导致利用的一些操作超时

零碎导致ANR 的起因：

  • CPU 被抢占：一般来说，前台在玩游戏，可能会导致你的后盾播送被抢占
  • 零碎服务无奈及时响应：比方获取零碎联系人等，零碎的服务都是 Binder 机制，服务能力也是无限的，有可能零碎服务长时间不响应导致 ANR
  • 其余利用占用大量内存

ANR 的触发规范

简略来说，ANR 就是零碎响应超时，Android对于零碎是否响应超时有如下规范：

  • Service 触发ANR Service Timeout：比方前台服务在20s内未执行实现，后盾服务 Timeout 工夫是前台服务的10倍，200s；
  • Broadcast 触发ANR BroadcastQueue Timeout：比方前台播送在10s内未执行实现，后盾60s；
  • Provider 触发ANR ContentProvider Timeout：内容提供者，在 publish 过超时10s；
  • Input 触发ANR InputDispatching Timeout：输出事件散发超时5s，包含按键和触摸事件。
//ActiveServices.java// How long we wait for a service to finish executing.static final int SERVICE_BACKGROUND_TIMEOUT = SERVICE_TIMEOUT * 10;// How long the startForegroundService() grace period is to get around to// calling startForeground() before we ANR + stop it.static final int SERVICE_START_FOREGROUND_TIMEOUT = 10*1000;//ActivityManagerService.java// How long we allow a receiver to run before giving up on it.static final int BROADCAST_FG_TIMEOUT = 10*1000;static final int BROADCAST_BG_TIMEOUT = 60*1000;// How long we wait until we timeout on key dispatching.static final int KEY_DISPATCHING_TIMEOUT = 5*1000;

ANR 的触发流程

对于Service、Broadcast、Provider触发的ANR来说，相似于是一个埋炸弹、拆炸弹、引爆炸弹的过程，例如startService的时候：

惯例场景：埋炸弹 -- 拆炸弹

App->AMS: 启动ServiceApp->Handler: 启动规范工夫20s倒计时（埋炸弹）AMS-->App: 启动实现App->Handler: 勾销倒计时（拆炸弹）

ANR场景：埋炸弹 -- 引爆炸弹

App->AMS: 启动ServiceApp->Handler: 启动规范工夫20s倒计时（埋炸弹）Note right of AMS: 20s内未实现Service启动Note right of Handler: 20s内未勾销Handler->AMS: 触发ANR（引爆炸弹）

对于Input触发的ANR来说，与Service、Broadcast、Provider触发的ANR有所不同，其并非工夫到了就肯定会引爆炸弹（触发ANR），而是在后续的Input事件上报的过程中，才会去被动检测前一个正在解决的事件是否超时。若超时则触发ANR，反之则重置计时器。

ANR 的dump流程

不论 ANR 是怎么产生的，最终逻辑都会调用appNotResponding函数：

graph TDActivityManagerService#inputDispatchingTimedOut--> AnrHelper#appNotResponding--> AnrConsumerThread#run--> AnrRecord#appNotResponding--> ProcessRecord#appNotResponding
//com.android.server.am.ProcessRecord.javavoid appNotResponding(String activityShortComponentName, ApplicationInfo aInfo,        String parentShortComponentName, WindowProcessController parentProcess,        boolean aboveSystem, String annotation, boolean onlyDumpSelf) {    ArrayList<Integer> firstPids = new ArrayList<>(5);    SparseArray<Boolean> lastPids = new SparseArray<>(20);    mWindowProcessController.appEarlyNotResponding(annotation, () -> kill("anr",                ApplicationExitInfo.REASON_ANR, true));    long anrTime = SystemClock.uptimeMillis();    if (isMonitorCpuUsage()) {        mService.updateCpuStatsNow();    }    final boolean isSilentAnr;    synchronized (mService) {        //正文1        // PowerManager.reboot() can block for a long time, so ignore ANRs while shutting down.        //正在重启        if (mService.mAtmInternal.isShuttingDown()) {            Slog.i(TAG, "During shutdown skipping ANR: " + this + " " + annotation);            return;        } else if (isNotResponding()) {            //曾经处于ANR流程中            Slog.i(TAG, "Skipping duplicate ANR: " + this + " " + annotation);            return;        } else if (isCrashing()) {            //正在crash的状态            Slog.i(TAG, "Crashing app skipping ANR: " + this + " " + annotation);            return;        } else if (killedByAm) {            //app曾经被killed            Slog.i(TAG, "App already killed by AM skipping ANR: " + this + " " + annotation);            return;        } else if (killed) {            //app曾经死亡了            Slog.i(TAG, "Skipping died app ANR: " + this + " " + annotation);            return;        }        // In case we come through here for the same app before completing        // this one, mark as anring now so we will bail out.        //做个标记        setNotResponding(true);        // Log the ANR to the event log.        EventLog.writeEvent(EventLogTags.AM_ANR, userId, pid, processName, info.flags,                annotation);        // Dump thread traces as quickly as we can, starting with "interesting" processes.        firstPids.add(pid);        // Don't dump other PIDs if it's a background ANR or is requested to only dump self.        //正文2        //缄默的anr : 这里示意后盾anr        isSilentAnr = isSilentAnr();        if (!isSilentAnr && !onlyDumpSelf) {            int parentPid = pid;            if (parentProcess != null && parentProcess.getPid() > 0) {                parentPid = parentProcess.getPid();            }            if (parentPid != pid) firstPids.add(parentPid);            if (MY_PID != pid && MY_PID != parentPid) firstPids.add(MY_PID);            //抉择须要dump的过程            for (int i = getLruProcessList().size() - 1; i >= 0; i--) {                ProcessRecord r = getLruProcessList().get(i);                if (r != null && r.thread != null) {                    int myPid = r.pid;                    if (myPid > 0 && myPid != pid && myPid != parentPid && myPid != MY_PID) {                        if (r.isPersistent()) {                            firstPids.add(myPid);                            if (DEBUG_ANR) Slog.i(TAG, "Adding persistent proc: " + r);                        } else if (r.treatLikeActivity) {                            firstPids.add(myPid);                            if (DEBUG_ANR) Slog.i(TAG, "Adding likely IME: " + r);                        } else {                            lastPids.put(myPid, Boolean.TRUE);                            if (DEBUG_ANR) Slog.i(TAG, "Adding ANR proc: " + r);                        }                    }                }            }        }    }    ......    int[] pids = nativeProcs == null ? null : Process.getPidsForCommands(nativeProcs);    ArrayList<Integer> nativePids = null;    if (pids != null) {        nativePids = new ArrayList<>(pids.length);        for (int i : pids) {            nativePids.add(i);        }    }    // For background ANRs, don't pass the ProcessCpuTracker to    // avoid spending 1/2 second collecting stats to rank lastPids.    StringWriter tracesFileException = new StringWriter();    // To hold the start and end offset to the ANR trace file respectively.    final long[] offsets = new long[2];    //正文4    File tracesFile = ActivityManagerService.dumpStackTraces(firstPids,            isSilentAnr ? null : processCpuTracker, isSilentAnr ? null : lastPids,            nativePids, tracesFileException, offsets);        ......}

正文1处针对几种非凡状况进行解决：正在重启、曾经处于 ANR 流程中、正在crash、app 曾经被 killed 和 app 曾经死亡了，不必解决 ANR，间接 return。

正文2处 isSilentAnr 是示意以后是否为一个后盾 ANR，前台 ANR 会弹出无响应的 Dialog，后盾 ANR 会间接杀死过程。什么是前台 ANR：产生ANR的过程对用户来说有感知，就是前台 ANR，否则就是后盾 ANR。

正文3处，抉择须要 dump 的过程。产生 ANR 时，为了不便定位问题，会 dump 很多信息到 Trace 文件中。而 Trace 文件里蕴含着与 ANR 相关联的过程的 Trace 信息，因为产生 ANR 的起因有可能是其余的过程抢占了太多资源，或者 IPC 到其余过程的时候卡住导致的。须要被 dump 的过程分为3类：

  • firstPids：firstPids 是须要首先 dump 的重要过程，产生 ANR 的过程无论如何是肯定要被 dump 的，也是首先被 dump 的，所以第一个被加到 firstPids 中。如果是 SilentAnr（即后盾 ANR），不必再退出任何其余的过程。如果不是，须要进一步增加其余的过程：如果产生 ANR 的过程不是 system_server 过程的话，须要增加 system_server 过程；接下来轮询 AMS 保护的一个 LRU 的过程 List，如果最近拜访的过程蕴含了 persistent 的过程，或者带有 BIND_TREAT_LIKE_ACTVITY 标签的过程，都增加到 firstPids 中。
  • extraPids：LRU 过程 List 中的其余过程，都会首先增加到lastPids中，而后lastPids会进一步被选出最近CPU使用率高的过程，进一步组成 extraPids；
  • nativePids：nativePids 最为简略，是一些固定的 native 的零碎过程，定义在 WatchDog.java 中

正文4处，拿到须要 dump 的所有过程的 pid 后，AMS 开始依照 firstPids、 nativePids、extraPids 的程序 dump 这些过程的堆栈：

public static Pair<Long, Long> dumpStackTraces(String tracesFile, ArrayList<Integer> firstPids,        ArrayList<Integer> nativePids, ArrayList<Integer> extraPids) {    // 最多dump 20秒    long remainingTime = 20 * 1000;    // First collect all of the stacks of the most important pids.    if (firstPids != null) {        int num = firstPids.size();        for (int i = 0; i < num; i++) {            final int pid = firstPids.get(i);            final long timeTaken = dumpJavaTracesTombstoned(pid, tracesFile, remainingTime);            remainingTime -= timeTaken;            if (remainingTime <= 0) {                Slog.e(TAG, "Aborting stack trace dump (current firstPid=" + pid                        + "); deadline exceeded.");                return firstPidStart >= 0 ? new Pair<>(firstPidStart, firstPidEnd) : null;            }        }    }    ......}

依据程序取出后面传入的 firstPids、nativePids 、extraPids 的 pid，而后逐个去 dump 这些过程中所有的线程。因为此处有多个过程且每个过程通常有多个线程，所以这里规定了个最长 dump 工夫为20秒，超过则及时返回，这样能够确保ANR弹窗能够及时弹出（或者被 kill 掉）。

接下来的调用链为：

graph TDActivityManagerService#dumpJavaTracesTombstoned--> Debug#dumpJavaBacktraceToFileTimeout--> android_os_Debug#android_os_Debug_dumpJavaBacktraceToFileTimeout--> android_os_Debug#dumpTraces--> debuggerd_client#dump_backtrace_to_file_timeout--> debuggerd_client#debuggerd_trigger_dump
bool debuggerd_trigger_dump(pid_t tid, DebuggerdDumpType dump_type, unsigned int timeout_ms, unique_fd output_fd) {    //pid是从AMS那边传过来的，即须要dump堆栈的过程        pid_t pid = tid;    //......    // Send the signal.        //从android_os_Debug_dumpJavaBacktraceToFileTimeout过去的，dump_type为kDebuggerdJavaBacktrace    const int signal = (dump_type == kDebuggerdJavaBacktrace) ? SIGQUIT : BIONIC_SIGNAL_DEBUGGER;    sigval val = {.sival_int = (dump_type == kDebuggerdNativeBacktrace) ? 1 : 0};        //sigqueue：在队列中向指定过程发送一个信号和数据，胜利返回0    if (sigqueue(pid, signal, val) != 0) {      log_error(output_fd, errno, "failed to send signal to pid %d", pid);      return false;    }    //......    LOG(INFO) << TAG "done dumping process " << pid;    return true;}

除 Zygote 过程外，每个过程都会创立一个 SignalCatcher 守护线程，用于捕捉 SIGQUIT、SIGUSR1 信号，并采取相应的行为。
AMS 过程间接给须要 dump 堆栈那个过程发送了一个 SIGQUIT 信号，过程收到 SIGQUIT 信号之后便开始 dump。也就是说，每当一个过程产生 ANR 时，则会收到 SIGQUIT 信号。换言之，如果能监控到零碎发送的 SIGQUIT 信号，就能监控到产生了 ANR。

总结 ANR 的dump流程：
系统监控到 app 产生 ANR 后，收集了一些相干过程 pid（包含产生 ANR 的过程），筹备让这些过程 dump 堆栈，从而生成 ANR Trace 文件，接着零碎开始向这些过程发送 SIGQUIT 信号，过程收到 SIGQUIT 信号之后开始 dump 堆栈。

ANR 的剖析

获取 ANR 日志的形式：

  • adb pull /data/anr/
  • adb bugreport

trace文件剖析

----- pid 7761 at 2022-11-02 07:02:26 -----Cmd line: com.xfhy.watchsignaldemoBuild fingerprint: 'HUAWEI/LYA-AL00/HWLYA:10/HUAWEILYA-AL00/10.1.0.163C00:user/release-keys'ABI: 'arm64'Build type: optimizedZygote loaded classes=11918 post zygote classes=729Dumping registered class loaders#0 dalvik.system.PathClassLoader: [], parent #1#1 java.lang.BootClassLoader: [], no parent#2 dalvik.system.PathClassLoader: [/system/app/FeatureFramework/FeatureFramework.apk], no parent#3 dalvik.system.PathClassLoader: [/data/app/com.xfhy.watchsignaldemo-4tkKMWojrpHAf-Q3iecaHQ==/base.apk:/data/app/com.xfhy.watchsignaldemo-4tkKMWojrpHAf-Q3iecaHQ==/base.apk!classes2.dex:/data/app/com.xfhy.watchsignaldemo-4tkKMWojrpHAf-Q3iecaHQ==/base.apk!classes4.dex:/data/app/com.xfhy.watchsignaldemo-4tkKMWojrpHAf-Q3iecaHQ==/base.apk!classes3.dex], parent #1Done dumping class loadersIntern table: 44132 strong; 436 weakJNI: CheckJNI is off; globals=681 (plus 67 weak)Libraries: /data/app/com.xfhy.watchsignaldemo-4tkKMWojrpHAf-Q3iecaHQ==/lib/arm64/libwatchsignaldemo.so libandroid.so libcompiler_rt.so libhitrace_jni.so libhiview_jni.so libhwapsimpl_jni.so libiAwareSdk_jni.so libimonitor_jni.so libjavacore.so libjavacrypto.so libjnigraphics.so libmedia_jni.so libopenjdk.so libsoundpool.so libwebviewchromium_loader.so (15)//已调配堆内存大小26M,其中2442kb医用，总调配74512个对象Heap: 90% free, 2442KB/26MB; 74512 objectsTotal number of allocations 120222 //过程创立到当初一共创立了多少对象Total bytes allocated 10MB         //过程创立到当初一共申请了多少内存Total bytes freed 8173KB           //过程创立到当初一共开释了多少内存Free memory 23MB                   //不扩大堆的状况下可用的内存Free memory until GC 23MB          //GC前的可用内存Free memory until OOME 381MB       //OOM之前的可用内存,这个值很小的话，阐明曾经处于内存紧张状态，app可能是占用了过多的内存Total memory 26MB                  //以后总内存（已用+可用）Max memory 384MB                   //过程最多能申请的内存.....//省略GC相干信息//以后过程共17个线程DALVIK THREADS (17)://Signal Catcher线程调用栈"Signal Catcher" daemon prio=5 tid=4 Runnable  | group="system" sCount=0 dsCount=0 flags=0 obj=0x18c84570 self=0x7252417800  | sysTid=7772 nice=0 cgrp=default sched=0/0 handle=0x725354ad50  | state=R schedstat=( 16273959 1085938 5 ) utm=0 stm=1 core=4 HZ=100  | stack=0x7253454000-0x7253456000 stackSize=991KB  | held mutexes= "mutator lock"(shared held)  native: #00 pc 000000000042f8e8  /apex/com.android.runtime/lib64/libart.so (art::DumpNativeStack(std::__1::basic_ostream<char, std::__1::char_traits<char>>&, int, BacktraceMap*, char const*, art::ArtMethod*, void*, bool)+140)  native: #01 pc 0000000000523590  /apex/com.android.runtime/lib64/libart.so (art::Thread::DumpStack(std::__1::basic_ostream<char, std::__1::char_traits<char>>&, bool, BacktraceMap*, bool) const+508)  native: #02 pc 000000000053e75c  /apex/com.android.runtime/lib64/libart.so (art::DumpCheckpoint::Run(art::Thread*)+844)  native: #03 pc 000000000053735c  /apex/com.android.runtime/lib64/libart.so (art::ThreadList::RunCheckpoint(art::Closure*, art::Closure*)+504)  native: #04 pc 0000000000536744  /apex/com.android.runtime/lib64/libart.so (art::ThreadList::Dump(std::__1::basic_ostream<char, std::__1::char_traits<char>>&, bool)+1048)  native: #05 pc 0000000000536228  /apex/com.android.runtime/lib64/libart.so (art::ThreadList::DumpForSigQuit(std::__1::basic_ostream<char, std::__1::char_traits<char>>&)+884)  native: #06 pc 00000000004ee4d8  /apex/com.android.runtime/lib64/libart.so (art::Runtime::DumpForSigQuit(std::__1::basic_ostream<char, std::__1::char_traits<char>>&)+196)  native: #07 pc 000000000050250c  /apex/com.android.runtime/lib64/libart.so (art::SignalCatcher::HandleSigQuit()+1356)  native: #08 pc 0000000000501558  /apex/com.android.runtime/lib64/libart.so (art::SignalCatcher::Run(void*)+268)  native: #09 pc 00000000000cf7c0  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+36)  native: #10 pc 00000000000721a8  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)  (no managed stack frames)"main" prio=5 tid=1 Sleeping  | group="main" sCount=1 dsCount=0 flags=1 obj=0x73907540 self=0x725f010800  | sysTid=7761 nice=-10 cgrp=default sched=1073741825/2 handle=0x72e60080d0  | state=S schedstat=( 281909898 5919799 311 ) utm=20 stm=7 core=4 HZ=100  | stack=0x7fca180000-0x7fca182000 stackSize=8192KB  | held mutexes=  at java.lang.Thread.sleep(Native method)  - sleeping on <0x00f895d9> (a java.lang.Object)  at java.lang.Thread.sleep(Thread.java:443)  - locked <0x00f895d9> (a java.lang.Object)  at java.lang.Thread.sleep(Thread.java:359)  at android.os.SystemClock.sleep(SystemClock.java:131)  at com.xfhy.watchsignaldemo.MainActivity.makeAnr(MainActivity.kt:35)  at java.lang.reflect.Method.invoke(Native method)  at androidx.appcompat.app.AppCompatViewInflater$DeclaredOnClickListener.onClick(AppCompatViewInflater.java:441)  at android.view.View.performClick(View.java:7317)  at com.google.android.material.button.MaterialButton.performClick(MaterialButton.java:1219)  at android.view.View.performClickInternal(View.java:7291)  at android.view.View.access$3600(View.java:838)  at android.view.View$PerformClick.run(View.java:28247)  at android.os.Handler.handleCallback(Handler.java:900)  at android.os.Handler.dispatchMessage(Handler.java:103)  at android.os.Looper.loop(Looper.java:219)  at android.app.ActivityThread.main(ActivityThread.java:8668)  at java.lang.reflect.Method.invoke(Native method)  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:513)  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1109)  ... //此处省略残余的N个线程

trace 参数具体解读：

"Signal Catcher" daemon prio=5 tid=4 Runnable  | group="system" sCount=0 dsCount=0 flags=0 obj=0x18c84570 self=0x7252417800  | sysTid=7772 nice=0 cgrp=default sched=0/0 handle=0x725354ad50  | state=R schedstat=( 16273959 1085938 5 ) utm=0 stm=1 core=4 HZ=100  | stack=0x7253454000-0x7253456000 stackSize=991KB  | held mutexes= "mutator lock"(shared held)

第1行："Signal Catcher" daemon prio=5 tid=4 Runnable

  • “Signal Catcher” daemon：线程名，有 daemon 示意守护线程
  • prio：线程优先级
  • tid：线程外部 id

  • 线程状态：Runnable

    一般来说，main线程处于 BLOCK、WAITING、TIMEWAITING 状态，基本上是函数阻塞导致的 ANR，如果 main 线程无异样，则应该排查 CPU 负载和内存环境。

第2行：| group="system" sCount=0 dsCount=0 flags=0 obj=0x18c84570 self=0x7252417800

  • group：线程所属的线程组
  • sCount：线程挂起次数
  • dsCount：用于调试的线程挂起次数
  • obj：以后线程关联的 Java 线程对象
  • self：以后线程地址

第3行：| sysTid=7772 nice=0 cgrp=default sched=0/0 handle=0x725354ad50

  • sysTid：线程真正意义上的 tid
  • nice：调度优先级，值越小则优先级越高
  • cgrp：过程所属的过程调度组
  • sched：调度策略
  • handle：函数解决地址

第4行：| state=R schedstat=( 16273959 1085938 5 ) utm=0 stm=1 core=4 HZ=100

  • state：线程状态
  • schedstat：CPU调度工夫统计（schedstat 括号中的3个数字顺次是Running、Runable、Switch，Running 工夫：CPU 运行的工夫，单位 ns，Runable 工夫：RQ 队列的等待时间，单位 ns，Switch 次数：CPU 调度切换次数）
  • utm/stm：用户态/内核态的 CPU 工夫
  • core：该线程的最初运行所在核
  • HZ：时钟频率

第5行：| stack=0x7253454000-0x7253456000 stackSize=991KB

  • stack：线程栈的地址区间
  • stackSize：栈的大小

第6行：| held mutexes= "mutator lock"(shared held)

  • mutex：所持有 mutex 类型，有独占锁 exclusive 和共享锁 shared 两类

案例剖析

主线程无卡顿，处于失常状态堆栈
"main" prio=5 tid=1 Native  | group="main" sCount=1 dsCount=0 flags=1 obj=0x74b38080 self=0x7ad9014c00  | sysTid=23081 nice=0 cgrp=default sched=0/0 handle=0x7b5fdc5548  | state=S schedstat=( 284838633 166738594 505 ) utm=21 stm=7 core=1 HZ=100  | stack=0x7fc95da000-0x7fc95dc000 stackSize=8MB  | held mutexes=  kernel: __switch_to+0xb0/0xbc  kernel: SyS_epoll_wait+0x288/0x364  kernel: SyS_epoll_pwait+0xb0/0x124  kernel: cpu_switch_to+0x38c/0x2258  native: #00 pc 000000000007cd8c  /system/lib64/libc.so (__epoll_pwait+8)  native: #01 pc 0000000000014d48  /system/lib64/libutils.so (android::Looper::pollInner(int)+148)  native: #02 pc 0000000000014c18  /system/lib64/libutils.so (android::Looper::pollOnce(int, int*, int*, void**)+60)  native: #03 pc 00000000001275f4  /system/lib64/libandroid_runtime.so (android::android_os_MessageQueue_nativePollOnce(_JNIEnv*, _jobject*, long, int)+44)  at android.os.MessageQueue.nativePollOnce(Native method)  at android.os.MessageQueue.next(MessageQueue.java:330)  at android.os.Looper.loop(Looper.java:169)  at android.app.ActivityThread.main(ActivityThread.java:7073)  at java.lang.reflect.Method.invoke(Native method)  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:536)  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:876)

主线程闲暇，因为它正处于 nativePollOnce，正在期待新音讯。处于这个状态还产生了 ANR，可能有2个起因：

  • dump 堆栈机会太晚了，ANR 曾经产生过了，才去 dump 堆栈，此时主线程曾经恢复正常了
  • CPU 抢占或者内存缓和等其余因素引起

遇到这种状况，要先去剖析 CPU、内存的应用状况。其次能够关注抓取日志的工夫和 ANR 产生的工夫是否相隔太久，工夫太久这个堆栈就没有剖析的意义了。

主线程执行耗时操作
suspend all histogram:    Sum: 206us 99% C.I. 0.098us-46us Avg: 7.629us Max: 46usDALVIK THREADS (16):"main" prio=5 tid=1 Runnable  | group="main" sCount=0 dsCount=0 flags=0 obj=0x73907540 self=0x725f010800  | sysTid=32298 nice=-10 cgrp=default sched=1073741825/2 handle=0x72e60080d0  | state=R schedstat=( 6746757297 5887495 256 ) utm=670 stm=4 core=6 HZ=100  | stack=0x7fca180000-0x7fca182000 stackSize=8192KB  | held mutexes= "mutator lock"(shared held)  at com.xfhy.watchsignaldemo.MainActivity.makeAnr(MainActivity.kt:58)  at java.lang.reflect.Method.invoke(Native method)  at androidx.appcompat.app.AppCompatViewInflater$DeclaredOnClickListener.onClick(AppCompatViewInflater.java:441)  at android.view.View.performClick(View.java:7317)  at com.google.android.material.button.MaterialButton.performClick(MaterialButton.java:1219)  at android.view.View.performClickInternal(View.java:7291)  at android.view.View.access$3600(View.java:838)  at android.view.View$PerformClick.run(View.java:28247)  at android.os.Handler.handleCallback(Handler.java:900)  at android.os.Handler.dispatchMessage(Handler.java:103)  at android.os.Looper.loop(Looper.java:219)  at android.app.ActivityThread.main(ActivityThread.java:8668)  at java.lang.reflect.Method.invoke(Native method)  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:513)  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1109)

主线程处于执行状态，不是闲暇状态，导致 ANR 了，阐明com.xfhy.watchsignaldemo.MainActivity.makeAnr有耗时操作。

主线程被锁阻塞
"main" prio=5 tid=1 Blocked  | group="main" sCount=1 dsCount=0 flags=1 obj=0x73907540 self=0x725f010800  | sysTid=19900 nice=-10 cgrp=default sched=0/0 handle=0x72e60080d0  | state=S schedstat=( 542745832 9516666 182 ) utm=48 stm=5 core=4 HZ=100  | stack=0x7fca180000-0x7fca182000 stackSize=8192KB  | held mutexes=  at com.xfhy.watchsignaldemo.MainActivity.makeAnr(MainActivity.kt:59)  - waiting to lock <0x0c6f8c52> (a java.lang.Object) held by thread 22   //正文1  - locked <0x01abeb23> (a java.lang.Object)  at java.lang.reflect.Method.invoke(Native method)  at androidx.appcompat.app.AppCompatViewInflater$DeclaredOnClickListener.onClick(AppCompatViewInflater.java:441)  at android.view.View.performClick(View.java:7317)  at com.google.android.material.button.MaterialButton.performClick(MaterialButton.java:1219)  at android.view.View.performClickInternal(View.java:7291)  at android.view.View.access$3600(View.java:838)  at android.view.View$PerformClick.run(View.java:28247)  at android.os.Handler.handleCallback(Handler.java:900)  at android.os.Handler.dispatchMessage(Handler.java:103)  at android.os.Looper.loop(Looper.java:219)  at android.app.ActivityThread.main(ActivityThread.java:8668)  at java.lang.reflect.Method.invoke(Native method)  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:513)  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1109)"卧槽" prio=5 tid=22 Blocked  //正文2  | group="main" sCount=1 dsCount=0 flags=1 obj=0x12c8a118 self=0x71d625f800  | sysTid=20611 nice=0 cgrp=default sched=0/0 handle=0x71d4513d50  | state=S schedstat=( 486459 0 3 ) utm=0 stm=0 core=4 HZ=100  | stack=0x71d4411000-0x71d4413000 stackSize=1039KB  | held mutexes=  at com.xfhy.watchsignaldemo.MainActivity$makeAnr$1.invoke(MainActivity.kt:52)  - waiting to lock <0x01abeb23> (a java.lang.Object) held by thread 1  - locked <0x0c6f8c52> (a java.lang.Object)    at com.xfhy.watchsignaldemo.MainActivity$makeAnr$1.invoke(MainActivity.kt:49)  at kotlin.concurrent.ThreadsKt$thread$thread$1.run(Thread.kt:30)......

其中：

"main" prio=5 tid=1 Blocked  - waiting to lock <0x0c6f8c52> (a java.lang.Object) held by thread 22  - locked <0x01abeb23> (a java.lang.Object)"卧槽" prio=5 tid=22 Blocked  - waiting to lock <0x01abeb23> (a java.lang.Object) held by thread 1  - locked <0x0c6f8c52> (a java.lang.Object)

主线程的 tid 是1，线程状态是 Blocked，正在期待0x0c6f8c52这个 Object，而这个 Object 被 thread 22这个线程所持有，主线程以后持有的是0x01abeb23的锁。而卧槽的tid是22，也是 Blocked 状态，它想申请的和已有的锁刚好与主线程相同。这样的话，ANR起因也就找到了。线程22持有了一把锁，并且始终不开释，主线程期待这把锁产生超时。在线上环境，常见因锁而 ANR 的场景是 SharePreference 写入。

CPU被抢占
CPU usage from 0ms to 10625ms later (2020-03-09 14:38:31.633 to 2020-03-09 14:38:42.257):  543% 2045/com.test.demo: 54% user + 89% kernel / faults: 4608 minor 1 major //留神看这里  99% 674/android.hardware.camera.provider@2.4-service: 81% user + 18% kernel / faults: 403 minor  24% 32589/com.wang.test: 22% user + 1.4% kernel / faults: 7432 minor 1 major  ......

该过程占据 CPU 高达543%，抢占了大部分 CPU 资源，因为导致产生 ANR，这种 ANR 通常与 App 无关。

内存缓和导致ANR
10-31 22:37:19.749 20733 20733 E Runtime : onTrimMemory level:80,pid:com.xxx.xxx:Launcher010-31 22:37:33.458 20733 20733 E Runtime : onTrimMemory level:80,pid:com.xxx.xxx:Launcher010-31 22:38:00.153 20733 20733 E Runtime : onTrimMemory level:80,pid:com.xxx.xxx:Launcher010-31 22:38:58.731 20733 20733 E Runtime : onTrimMemory level:80,pid:com.xxx.xxx:Launcher010-31 22:39:02.816 20733 20733 E Runtime : onTrimMemory level:80,pid:com.xxx.xxx:Launcher0

如果一份 ANR 日志的 CPU 和堆栈都很失常，能够思考是内存缓和。看一下 ANR 日志外面的内存相干局部。还能够去日志外面搜一下 onTrimMemory，如果 dump ANR 日志的工夫左近有相干日志，可能是内存比拟缓和了。

零碎服务超时导致ANR
"main" prio=5 tid=1 Native  | group="main" sCount=1 dsCount=0 flags=1 obj=0x727851e8 self=0x78d7060e00  | sysTid=4894 nice=0 cgrp=default sched=0/0 handle=0x795cc1e9a8  | state=S schedstat=( 8292806752 1621087524 7167 ) utm=707 stm=122 core=5 HZ=100  | stack=0x7febb64000-0x7febb66000 stackSize=8MB  | held mutexes=  kernel: __switch_to+0x90/0xc4  kernel: binder_thread_read+0xbd8/0x144c  kernel: binder_ioctl_write_read.constprop.58+0x20c/0x348  kernel: binder_ioctl+0x5d4/0x88c  kernel: do_vfs_ioctl+0xb8/0xb1c  kernel: SyS_ioctl+0x84/0x98  kernel: cpu_switch_to+0x34c/0x22c0  native: #00 pc 000000000007a2ac  /system/lib64/libc.so (__ioctl+4)  native: #01 pc 00000000000276ec  /system/lib64/libc.so (ioctl+132)  native: #02 pc 00000000000557d4  /system/lib64/libbinder.so (android::IPCThreadState::talkWithDriver(bool)+252)  native: #03 pc 0000000000056494  /system/lib64/libbinder.so (android::IPCThreadState::waitForResponse(android::Parcel*, int*)+60)  native: #04 pc 00000000000562d0  /system/lib64/libbinder.so (android::IPCThreadState::transact(int, unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+216)  native: #05 pc 000000000004ce1c  /system/lib64/libbinder.so (android::BpBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+72)  native: #06 pc 00000000001281c8  /system/lib64/libandroid_runtime.so (???)  native: #07 pc 0000000000947ed4  /system/framework/arm64/boot-framework.oat (Java_android_os_BinderProxy_transactNative__ILandroid_os_Parcel_2Landroid_os_Parcel_2I+196)  at android.os.BinderProxy.transactNative(Native method) ————————————————要害行！！！  at android.os.BinderProxy.transact(Binder.java:804)  at android.net.IConnectivityManager$Stub$Proxy.getActiveNetworkInfo(IConnectivityManager.java:1204)—要害行！  at android.net.ConnectivityManager.getActiveNetworkInfo(ConnectivityManager.java:800)  at com.xiaomi.NetworkUtils.getNetworkInfo(NetworkUtils.java:2)  at com.xiaomi.frameworkbase.utils.NetworkUtils.getNetWorkType(NetworkUtils.java:1)  at com.xiaomi.frameworkbase.utils.NetworkUtils.isWifiConnected(NetworkUtils.java:1)

零碎服务超时个别会蕴含 BinderProxy.transactNative 关键字。
从日志堆栈中能够看到是获取网络信息产生了 ANR：getActiveNetworkInfo。零碎的服务都是 Binder 机制（16个线程），服务能力也是无限的，有可能零碎服务长时间不响应导致 ANR。如果其余利用占用了所有 Binder 线程，那么以后利用只能期待。可进一步搜寻 blockUntilThreadAvailable 关键字，at android.os.Binder.blockUntilThreadAvailable(Native method)。
如果有发现某个线程的堆栈，蕴含此字样，可进一步看其堆栈，确定是调用了什么零碎服务。此类ANR也是属于零碎环境的问题，如果某类型手机上频繁产生此问题，应用层能够思考躲避策略。

参考

https://mp.weixin.qq.com/s/qQ...
https://xfhy666.blog.csdn.net...