1. 从一次深夜线上事故说起ANR不是玄学是可以被系统性击败的如果你已经写了几年Android大概率遇到过这样的场景凌晨的报警群突然开始刷屏用户反馈应用打开就卡死点哪儿都没反应紧跟着就是系统弹窗XXX 已停止运行或XXX 无响应。你还没来得及打开电脑产品经理已经在群里圈了你三次。我印象最深的一次是某次版本发布后ANR率直接翻了5倍集中在某款低端机上。当时第一反应是是不是系统版本兼容问题翻了一圈代码才发现一个刚上线的组件把一次网络请求放到了主线程而且加了超时重试导致用户在弱网环境下体验到了十几秒的界面冻结。那次之后我把ANR从偶发故障的类别里拎了出来认真研究它的产生机制、卡顿现场还原和线上监控方案。这篇内容就是基于那段时间及后续项目中的实践经验做的系统梳理。ANR的全称是Application Not Responding当主线程在限定时间内没有完成输入事件处理、广播处理或服务执行的关键操作时系统就会判定应用无响应。它本质上是系统在替你给用户一个交代你的应用已经hold不住了。无论你是刚入门Android、正在做性能优化还是负责稳定性治理的技术负责人这篇文章都会给你一套从原因分析、现场排查到修复防复发的完整打法。整篇没有玄学全部是能落地到代码和日志里的硬功夫。2. ANR的系统判定机制先搞清楚系统是怎么生气的2.1 为什么是5秒和10秒这些时间窗口到底是谁定的要理解ANR首先要理解它的判定机制。Android系统对不同类型的组件有着不同的超时阈值这些阈值不是随随便便定的而是基于一个核心假设主线程应该在极短时间内完成一次事件响应。根据安卓系统中ActivityManagerService和InputDispatcher的实现逻辑当前主流的判定阈值大概是这样的场景超时阈值触发条件输入事件Input Dispatching5秒按键、触摸事件等分发给应用后5秒内没有消费完广播BroadcastReceiver前台10秒onReceive执行超时广播BroadcastReceiver后台60秒onReceive执行超时服务Service前台20秒onCreate/onStartCommand等关键生命周期执行超时服务Service后台200秒onCreate/onStartCommand等关键生命周期执行超时ContentProvider10秒较新版本首次启动时Provider初始化超时为什么输入事件是5秒后台服务却可以长达200秒因为系统对用户可感知的敏感度不同。输入事件每延迟一毫秒用户都能感觉到而后台服务的执行对用户来说并不可见所以系统给了更宽裕的时间。这里有个容易被忽略的细节这些阈值在不同Android版本上并不完全一致。从Android 12开始部分厂商定制系统甚至把输入事件的ANR阈值调整为了3.5秒或6秒所以你在真机上测ANR时不同机型触发时机可能不一样排查时不必死扣为什么这个卡了4秒没报ANR那个卡了3秒就报。2.2 ANR判定流程从卡顿到系统弹窗的完整链路系统判定ANR的链路大致可以拆成这么几步第一步事件投递。InputDispatcher把输入事件投递给应用进程的主线程消息队列。投递时会记录一个投递时间戳。第二步超时检查。系统会启动一个超时监控机制如果到时间后事件仍然没有被消费完即应用没有将事件标记为已处理InputDispatcher就会向system_server进程发出ANR通知。第三步进程状态收集。system_server接收到通知后会通过ActivityManager、WindowManager等系统服务收集目标进程的CPU使用率、内存状态、线程堆栈等信息。这个过程会调用Process向目标进程发送SIGQUIT信号触发应用的ANR处理逻辑。第四步生成ANR报告。系统将收集到的CPU占用、主线程堆栈、Binder线程池状态等信息写入/data/anr/目录下的trace文件并弹出无响应对话框。这里有个关键认知ANR本质上不是应用卡了多久的问题而是主线程在系统限定的时间内有没有完成指定任务的问题。换句话说系统只看结果不管你是真的在处理任务还是因为死锁卡住了没完成任务就统一按ANR处理。2.3 主线程消息循环的使命为什么它一堵整个应用就瘫痪要彻底理解ANR你还需要知道主线程UI线程在Android应用里的角色。主线程运行着一个无限的消息循环Looper专门负责处理与UI相关的所有消息——用户输入事件、绘制请求、生命周期回调、广播分发等等。用一个生活化的类比来说主线程就像是餐厅里唯一的大厨兼传菜员。他既要接单处理输入事件又要炒菜执行业务逻辑还要摆盘触发渲染。一旦他在某一桌菜上耗时太多后面所有单子全部积压客人用户的表现就是我叫服务员没人理我。这也解释了为什么规范要求所有耗时任务都不应该放在主线程不是主线程本身很弱而是它的职责太特殊了。一旦主线程被占住即使你在子线程里已经把数据加载好了也没有人负责把数据刷新到界面上——因为刷新UI本身也要通过主线程的消息队列。3. ANR的产生根源四类最常见的主线程灾难现场3.1 主线程上的耗时操作I/O、计算与JSON解析的夺命连环这是ANR产生的最直接原因也是最容易在代码评审中被发现的一类。典型场景包括在主线程执行SharedPreferences的commit()或apply()在高频写入时触发的磁盘I/O阻塞apply()虽然异步写盘但在低版本上有可能导致QueuedWork.waitToFinish()等待在主线程使用BitmapFactory.decodeStream()解码大图尤其是没有设置inSampleSize的情况下一张几MB的图片就能让主线程卡上几百毫秒到几秒在主线程直接做JSON序列化/反序列化服务端返回一个几十万条数据的大列表时Gson.fromJson()可能耗时数秒在主线程用SQLiteDatabase做查询数据库数据量大且没有建索引时一个全表扫描就能轻松突破ANR阈值。很多人会觉得自己项目里没这么严重但请注意一个现实低端机和中端机的CPU性能差距可以达到3-5倍。你在开发机上跑50ms的耗时操作在用户的低端机上可能就是250ms再叠加内存抖动导致的GC暂停、系统后台其他进程的竞争一次输入事件处理时间超出5秒的ANR就出现了。3.2 锁竞争与死锁不是卡住了而是永远等不到相比耗时操作锁竞争和死锁更难排查因为它的卡顿状态是隐藏的——主线程的堆栈可能看起来并没有在做耗时操作而是停在某一个等待位置。举个例子public class DataManager { private static final Object LOCK new Object(); public void updateData() { synchronized (LOCK) { // 耗时写入操作 writeToDatabase(); } } public static void onMainThreadCall() { // 主线程执行 new Thread(() - { synchronized (LOCK) { // 子线程持锁并执行耗时逻辑 SystemClock.sleep(6000); } }).start(); // 主线程也尝试获取锁 synchronized (LOCK) { refreshUI(); } } }上面这段代码的问题非常典型子线程持有了锁并且在锁内执行了6秒的耗时操作主线程在等待锁的过程中无法进行任何UI刷新最终触发ANR。这类问题在并发模型复杂的项目里很常见尤其是使用自己维护的线程池、全局锁或者单例对象时。死锁则是锁竞争的极端形式——两个线程各自持有一把锁同时又在等待对方释放锁。一旦主线程参与其中就是死局。3.3 Binder调用阻塞跨进程通信的隐形杀手如果说锁竞争是程序员自己挖的坑那Binder阻塞更多时候是系统级别的意外。Android应用和系统服务之间的几乎所有通信都是通过Binder完成的比如ActivityManagerService、PackageManagerService、WindowManagerService。一个典型的场景是主线程调用Context.getSystemService()或ActivityManager.getRunningAppProcesses()这些调用需要通过Binder和system_server进程交互。如果系统服务端此时负载过高比如后台大量应用同时启动Binder调用的返回就会变慢主线程阻塞在Binder.transact()上。另一个容易踩坑的案例是主线程调用LocationManager.getLastKnownLocation()或SensorManager的相关接口这些系统服务可能在底层有锁或阻塞逻辑跨进程通信的耗时被放大后主线程就不知不觉地变成了等待状态。3.4 系统级压力与组件异常你的App可能只是受害方最后一种情况是最冤的你的应用代码本身没有明显问题但系统整体负载过高导致ANR。这些场景包括低内存Low Memory情况下系统频繁触发lmkd低内存杀手清理进程应用在等待系统响应时就被判定为ANRCPU被其他应用或系统进程占满主线程虽然在做正常操作但调度不到CPU时间片外部存储I/O异常比如存储卡损坏或文件系统挂起导致所有文件操作都阻塞系统服务自身发生ANR或死锁Binder响应集体超时。这类ANR在线上占了相当大的比例但往往无法通过代码优化彻底解决。这也是为什么只看自身代码的排查思路是有局限性的——你必须把系统当时的负载状态一起纳入分析。4. ANR现场的证据采集第一次拿到手的有效资料4.1 系统在ANR发生时到底生成了什么当ANR发生时Android系统会在设备上生成一份关键证据文件路径一般是/data/anr/文件名类似traces.txt各版本可能有差别有些版本会命名成traces-xx.txt或多个分片文件部分版本还会同时生成/data/system/dropbox/下的ANR事件记录通过dumpsys dropbox命令可以查看到。普通应用无法直接读取/data/anr/目录需要系统权限或开发环境支持。在Android 8.0以后traces.txt的收集机制有了一些变化系统会将堆栈信息写进deadline文件中并结合system_server侧的DropBox记录来判定具体原因。Trace文件的核心内容分为几个部分头部是系统时间、进程信息、ANR发生类型中间是各个进程的CPU使用率汇总最后是目标进程的所有线程堆栈。其中最有价值的就是主线程堆栈和CPU负载汇总。4.2 开发者能拿到的几类日志来源如果你有源码、有测试机ANR复现后可以通过以下方式拿到日志# 导出最新一份ANR trace文件需要root权限或可调试应用 adb shell su -c cat /data/anr/traces.txt traces.txt # 查看DropBox中的ANR记录 adb shell dumpsys dropbox --print | grep -A 100 anr # 查看系统日志中ANR相关的关键行 adb logcat -b system | grep -E ANR|not responding|am_anr # 获取CPU和内存历史状态 adb shell cat /proc/stat adb shell cat /proc/meminfo如果是在线上没有root权限时可以通过第三方监控组件如FCM/友盟/腾讯bugly等自动捕获ANR堆栈不过这些平台捕获的堆栈通常是简化版只包含主线程且没有CPU负载汇总。所以有条件的话我还是建议在测试阶段就手动导出完整trace能够看到的信息量完全不是一个级别。4.3 trace文件里最关键的信息怎么读一份典型的ANR trace最值得关注的是这几个关键区域第一头部信息中的Subject字段它明确写了ANR的类型Subject: Input dispatching timed out (Waiting because the touched window has not finished the previous input event) Subject: Broadcast of Intent { actxxx } timed out Subject: Executing service bind timeout第二CPU负载汇总区域格式类似CPU usage from 16894ms to 0ms ago: 12% 2345/system_server: 8.2% user 3.8% kernel / faults: 123 48% 4567/com.example.app: 41% user 7% kernel / faults: 2345 27% 789/cc1: 15% user 12% kernel这块非常有用——它告诉你在ANR发生的时间窗口内谁在大量消耗CPU。如果你的应用占了48%那大概率是应用内部逻辑确实在执行繁重任务如果应用只占5%而system_server占了12%且某个后台进程占用了40%那可能是系统级问题。第三主线程的堆栈信息通常出现在进程线程列表的第一项线程名为main。如果能看到类似java.lang.Thread.sleep、android.os.MessageQueue.next、Binder.transact()等调用就已经找到一半线索了。5. 从trace还原卡顿现场实战排查链路5.1 第一步先看主线程在做什么排除伪ANR很多人拿到trace文件就直接翻主线程堆栈这个方向是对的但有一个前提需要先排除主线程堆栈如果停在MessageQueue.next()或者epollWait说明主线程其实是在空等并没有在干活。这种情况下ANR的真正原因往往不在主线程本身而在事件没有人处理或窗口状态不对。常见的情况有前一个输入事件被某个耗时的onTouchEvent/onClick卡住了后续事件排队等待Choreographer的帧回调队列被Draw/Render占满渲染管线迟迟没有完成上一帧系统窗口焦点处理异常输入事件被派发到了错误的窗口。遇到这类情况需要往前翻堆栈找到当前待处理事件、前一事件的执行时长再结合CPU负载判断是不是某个过程耗时过长。5.2 第二步用CPU负载区分真忙与假死我排查ANR时有一句口头禅先看CPU再看堆栈最后才动代码。如果你的trace文件中显示应用进程的CPU使用率很高比如超过80%持续很久说明代码大概率在执行密集计算或大量I/O。此时主线程堆栈会显示在某个具体的方法上这个方法的耗时就是ANR根源。如果CPU使用率很低比如不到5%但主线程同样卡住那就偏向三类问题锁等待堆栈上会有synchronized、LockSupport.park、Object.wait等标记并且能看到waiting to lock的引用Binder阻塞堆栈停在BinderProxy.transact()并且长时间没有返回系统进程故障CPU高占用出现在system_server端应用只是被连累。5.3 第三步锁等待类堆栈的实战分析法锁等待的堆栈通常长这样main prio5 tid1 Blocked at com.example.DataManager.updateData(DataManager.java:45) - waiting to lock 0x0465a8c8 (a java.lang.Object) at com.example.MainActivity.onResume(MainActivity.java:88) at android.app.Activity.performResume(Activity.java:8012) ...看到waiting to lock时下一步怎么找持锁线程在同一个trace文件里搜索0x0465a8c8这个对象引用定位哪个线程持有它Thread-3 prio5 tid13 Native at com.example.DataManager.writeToDatabase(DataManager.java:23) - locked 0x0465a8c8 (a java.lang.Object) at com.example.DataManager$1.run(DataManager.java:57)找到了Thread-3持有着这把锁并且卡在了数据库写入操作上。此时你就能判断主线程是在等待子线程的数据库操作完成。顺着这条线继续翻Thread-3的完整调用栈看看具体数据库操作为什么这么慢。这是我个人最推荐的一种trace排查方式——不要在堆栈里凭经验猜而是通过锁对象的地址把整个线程间关系还原出来。5.4 第四步从系统事件链还原整段时间轴trace文件只是一张快照它只记录了ANR判定时刻各线程的状态。但要完整理解问题还需要把事件链串起来。建议收集以下几项数据logcat中ANR发生前10秒的日志看看主线程执行了什么操作am_anr事件在events缓冲区的记录包含进程名、ANR类型、系统时间当前Activity的状态和前后台情况dumpsys activity processes中的进程优先级、LRU列表位置等信息。有了这些时间轴信息你才能回答主线程在卡住前的几秒到底执行了什么这个核心问题。例如某次线上ANR主线程堆栈停在Handler.dispatchMessage但前面的log显示它刚刚收到了一条来自子线程的消息消息里携带了一个超大的Bitmap。如果没有日志辅助这个因果链很难定位。6. 修复与防复发的实际经验从修一次到防一年6.1 针对耗时操作的改造方案卸载主线程最直接的修复方案就是把耗时操作从主线程挪出去。这里分享几个经过项目验证的思路第一对于I/O操作统一收口到一个SingleThreadExecutor或协程的IO调度器中避免各业务线各自开线程导致I/O并发过多反而加剧存储竞争。val ioDispatcher Executors.newFixedThreadPool(2).asCoroutineDispatcher() lifecycleScope.launch(ioDispatcher) { val data database.query() withContext(Dispatchers.Main) { render(data) } }第二对于JSON解析等CPU密集型任务用异步方式执行并充分考虑列表分页或懒加载。如果一个列表几百条数据都包含大量嵌套字段建议服务端做裁剪或者客户端改为分页拉取。第三对于Bitmap加载务必使用Glide或Coil等成熟图片库并设置合理的占位图和尺寸压缩。手写BitmapFactory时也至少要使用inSampleSize。6.2 针对锁冲突的修复策略减少临界区、避免嵌套锁锁冲突的修复并不只是加个锁而是重构锁的使用方式缩小同步块的范围只在需要保护的资源操作内加锁不要在锁内执行I/O使用ReentrantReadWriteLock替换部分读多写少的场景避免持锁调用主线程或者回调到主线程的逻辑对于单例初始化和数据缓存可以使用ConcurrentHashMap#computeIfAbsent或DCL双重检查锁优化。另外强烈建议在代码评审阶段就约定一条纪律主线程上不允许出现synchronized关键字。如果确实需要等待子线程执行结果应该使用回调、协程、LiveData等异步通信方式而不是让主线程去等。6.3 Binder阻塞的规避能不进主线程的IPC就不进规避Binder阻塞的最有效办法就是避免在主线程上直接调用可能会阻塞的Binder方法。一个很好的例子是PACKAGE_MANAGER相关查询PackageManager.getInstalledPackages()在某些版本上会在主线程上做大量包信息收集工作耗时能轻松超过百毫秒多次调用加起来就可能触发ANR。对于必须使用的系统服务调用建议全部包装成异步接口并设置合理的超时重试机制。对线上用户的getSystemService和registerReceiver调用进行监控如果发现主线程Binder调用耗时超过200ms的占比升高就要警惕起来。6.4 线上监控与兜底把ANR从发生后补救变成发生前预警修复只是开始真正的重点是把ANR控制在一个稳定的低水平。我在这块主要做了三件事第一接入ANR监控组件按渠道、版本、进程、机型维度聚合ANR率。自定义的监控组件会通过Looper.getMainLooper().setMessageLogging打印主线程消息的dispatch耗时能捕获到系统ANR之前的慢消息。第二建立ANR前置预警机制——主线程单次消息耗时超过2秒就上报一次卡顿事件。卡顿事件的样本量是ANR的10倍以上能更早暴露风险点。第三在发布V2版本时加一个ANR兜底方案当监控组件检测到主线程连续5条消息都耗时超过500ms时主动触发一次轻量级降级比如关闭动画、暂停一些非核心任务确保用户界面还能响应。6.5 复盘方法论把每一条ANR都变成改进项最后说一个容易被忽略但非常重要的习惯每条ANR都值得一个完整的复盘记录。我的做法是维护一份ANR复盘表格包含以下字段字段说明现象描述用户或测试反馈的直观表现系统日志摘要trace中Subject字段、CPU负载、主线程堆栈根本原因分类耗时操作/锁竞争/Binder阻塞/系统级问题影响版本与机型便于判断是否与适配有关修复方案代码改动点、自测结果线上验证灰度发布后的ANR率变化每当一条ANR被标记为已解决我们还会在代码库中做一个ActionChecklist确保类似的代码模式不会再次被引入。比如主线程禁止做超过100ms的I/O操作这类规则可以通过静态代码扫描或IDE插件在提交前拦截。7. 关于ANR排查说点文档里不会写的实在话每次聊到ANR总能看到有人问有没有什么黑科技能一键定位。说实话我做了这么多年性能治理ANR排查始终是一个工程素养的活儿——它考验的是你对Android系统机制的熟悉程度、对日志的敏感度以及面对复杂并发问题时抽丝剥茧的耐心。几个软性经验分享给大家第一不要太依赖日志平台给的ANR堆栈。很多平台只上传主线程堆栈容易把问题定位到错误的方法上。我见过太多因为平台堆栈指向了某个通用方法导致开发改了一圈代码也没实际解决问题的案例。尽量拿到完整trace和CPU负载。第二低端机测试机不能省。如果条件允许备一台几百元的低端Android机专门用来压测性能。很多高端机永远触发不了的ANR在低端机上就是家常便饭。特别是那些老芯片的设备CPU性能和内存带宽的瓶颈会被放大到无法忽视。第三对系统级ANR要有容忍度。即使你的代码写得很干净线上也一定会有少量ANR是系统自身问题导致的。关键在于你能不能在trace里把责任划分清楚。如果能够在复盘时给出该ANR由system_server高负载导致非应用逻辑问题的结论那比无脑优化代码要有说服力得多。第四ANR修复真正难的不是技术是坚持。一次ANR的修复相对容易难的是在每个需求迭代中保持对主线程健康的敬畏。我见过太多项目性能优化做得不错但新需求一上线又有开发把网络请求直接写进了onClick里然后等线上报警了再来复盘。说到底ANR就是应用性能瓶颈最直观的报警器。它把主线程的每一次失职都变成了系统层面的用户可见投诉。只有把机制搞清楚、日志会用、排查链路跑顺、修复方案跟上你的应用才能在各种机型上真正做到稳定流畅。