Android未捕获异常处理器实现崩溃日志采集与上报

线上跑着的应用,用户点开就闪,后台日志里干干净净,一条堆栈都没有——这种场景做过移动端的都懂。UncaughtExceptionHandler就是用来堵这个窟窿的:它是 Android(本质上是 Java)线程模型里给"未捕获异常"留的最后一道口子,任何线程因为异常而终止之前,都会回调你注册的处理器,你可以在进程咽气之前的这点时间里,把堆栈、机型、页面路径、内存水位这些关键现场信息抓下来落盘,下次启动再传上去。说白了,它决定的是"用户崩溃了,你到底知不知道、知多少"。这篇内容适合三类人看:刚接手线上质量、想知道崩溃采集底层的同学;正在自己搭一套轻量级崩溃监控、不想无缘无故塞一个几 MB 的大 SDK 的同学;以及已经在用现成方案、但总觉得"上报上来的东西不够用"的同学。下面我会把调用链路、实现骨架、踩坑清单一次性铺开,代码都是能直接跑的那种。

1. 线上闪退抓不到日志,这个 Handler 到底补的是哪个洞

1.1 崩溃发生在用户手里,你却在日志里一无所知

先说清楚痛点。开发阶段崩溃不可怕,AS 的 Logcat 窗口一红,堆栈明明白白躺着,复制粘贴去搜一下就定位了。真正要命的是发布之后:用户在某个特定机型、某个特定系统版本、某个特定网络状态下点了一个按钮,App 直接消失。你去后台翻日志,发现那一刻什么记录都没有,因为进程是被"异常终止"的,不是被你自己的 try-catch 捕获后优雅退出的,日志缓冲区里的东西还没来得及刷出去,进程就没了。

很多人第一反应是"加 try-catch 啊"。问题是,一个中等规模的应用,几十上百个 Activity、几百个回调入口、几千个异步任务,你不可能给每一处都包一层 try-catch。而且很多崩溃压根不在你的业务代码里——在 framework 的回调里、在第三方 SDK 的线程里、在某个库的静态初始化块里。这些位置的异常你根本拦不到,只能任由它一路向上抛,直到把线程干掉。

未捕获异常处理器就是为这种"拦不住的异常"设计的一道全局兜底。它不能阻止崩溃发生——这点必须先泼冷水,任何声称能"自动修复崩溃"的方案都有猫腻——但它能在崩溃发生的那一刻,把现场信息完整地抄录下来。这就好比飞机上的黑匣子,它救不了飞机,但它能让下一次不再以同样的方式掉下来。

我做过的项目里,崩溃采集从零搭起大概只需要半天,但收益是长期的:上线第一周就能收到几十条有效堆栈,里面往往藏着两三个必现的低级错误,比如某个空集合直接取下标、某个 Context 被错误持有导致空指针。这些东西在测试环境因为数据量小、路径短,根本暴露不出来。

1.2 这套机制在 Android 的崩溃链路上处于什么位置

Android 的 Java 层崩溃,归根到底是"某个线程抛出了异常,且没有在调用栈的任何一层被 catch 住"。JVM 规范里对这种情况有明确处理流程:线程即将终止之前,会去查这个线程有没有设置专属的处理器(thread.setUncaughtExceptionHandler),没有就查线程组,线程组没有再查全局默认的(Thread.setDefaultUncaughtExceptionHandler)。Android 沿用这套机制,并且在ActivityThread里注册了一个默认实现,负责在崩溃后杀掉进程。

所以链路的顺序是这样:业务代码抛异常 → 一路上抛无人接 → 线程即将终止 → 回调你注册的处理器 → 你处理完(或者不处理) → 回调系统原来的处理器 → 系统杀进程。这里有个关键点:你的处理器不会自动"接管"后续流程,系统默认的那个仍然会被调用,除非你在自己的实现里显式地把原处理器保存下来、决定什么时候转发。这一点在第三节的代码里会体现,很多人写完 Handler 发现"崩了之后进程还赖着不死、界面卡成白板",就是因为没有正确地把控制权交回去。

还要注意区分三层东西,初学者极容易混淆:

把这张表记住,能省掉你日后无数次的自我怀疑。我见过有同学信心满满地接了全局 Handler,结果线上最严重的几个问题全是 ANR 和 native 崩溃,一条都没收到,回头就怀疑人生。不是 Handler 没用,是你用错了工具。

1.3 自研还是引第三方:一个务实的取舍判断

这里得说清楚一个事实:市面上成熟的崩溃采集方案已经很完善了,覆盖 Java、Native、ANR,还能做堆栈聚合和符号还原。那为什么还要自己写?

判断标准其实很简单,看你缺什么。如果你缺的是"从零到一有个兜底、能把堆栈落盘、能自己控制上报时机和字段",自研一套一百来行代码足矣,而且对包体积几乎零影响,隐私合规也完全可控——什么字段该收、什么不该收,你自己说了算。如果你缺的是"符号还原、聚合去重、崩溃率趋势、版本对比、卡顿监控",这些工程量巨大,老老实实用成熟方案。

我个人的做法是两条腿走路:自研一个极简的 Handler 负责把原始现场落盘,作为"最后一道保险",即使第三方 SDK 因为某些原因没初始化成功、或者被降级,我仍然拿得到原始堆栈;第三方方案负责聚合和分析。两套东西互不干扰,数据还能互相印证。这个思路在很多团队里都验证过,成本很低,收益是把"采集失败"这个风险点彻底消掉了。

另外还有一个"不能忽略的场景",就是一些团队会在低端机上做降级,把非核心 SDK 全部关掉以省内存。如果你的崩溃采集整条链路都挂在某个大 SDK 上,降级一开,采集就瞎了。自研的轻量 Handler 就没有这个问题,它只依赖文件读写,几乎不占资源,可以在所有降级路径上都保留。

2. 机制拆解:从线程终止到你的代码被执行,中间发生了什么

2.1 注册时机决定你能捕获到多少崩溃

Thread.setDefaultUncaughtExceptionHandler是静态方法,设置的是全局默认处理器,对所有没有单独设置的线程生效。所以理论上你越早注册越好,最理想的位置是Application.attachBaseContext()的最开头,或者Application.onCreate()的第一行。

为什么强调"越早越好"?因为初始化阶段本身就是崩溃高发区,大概能占到总崩溃量的 10% 到 20%。多进程的初始化、第三方 SDK 的 ContentProvider 自动初始化、资源加载、数据库迁移,这些都是容易出事的环节。如果你的 Handler 注册在某个库初始化之后,那这个库自己崩了,你就什么也收不到。

这里有个容易忽略的点:ContentProvider的onCreate执行时机比Application.onCreate更早。如果你的应用里有多个库通过 ContentProvider 做自动初始化,那么它们任何一家在这个阶段崩溃,你的 Handler 都来不及注册。这种情况下,唯一可行的办法是把 Handler 的注册也做成一个 ContentProvider,并保证它的初始化顺序排在前面,或者干脆用初始化检查工具把这类自动初始化改成手动初始化,把顺序攥在自己手里。

还有一个更极端的场景:如果崩溃发生在你注册 Handler 之前的零点几毫秒,那你确实无能为力。但实践下来,把注册提到最早位置之后,能收到的崩溃比例会有肉眼可见的提升。我做过一次对比,同一个版本,把注册位置从onCreate中部挪到attachBaseContext首行,启动阶段的崩溃捕获量多了将近三成。这个改动只花了两分钟。

2.2 主线程和子线程的差异,比你想的要大

子线程崩溃相对简单:线程挂了,进程还活着,你的 Handler 有充足的时间把东西写下来,甚至还能继续干别的活。这时候你要做的只是记录、上报,然后交给默认处理器。

主线程崩溃就完全是另一回事了。主线程的入口是ActivityThread.main(),里面开了 Looper 之后进了死循环。当某个消息处理过程中抛出异常,异常会穿过消息分发一路抛到Looper.loop()外面,主线程随即终止。注意,主线程终止不等于进程终止。进程里还有 Binder 线程在跑,还有一些系统线程在跑,进程会处于一种"活着但没法响应 UI"的状态。用户看到的现象就是:界面还在,但点什么都没反应,过几秒才彻底消失,或者干脆卡在那儿。

这就是为什么很多人在 Handler 里写了日志、然后什么都不做,会得到"白屏卡死"的反馈。你必须主动把进程干掉,或者交回系统默认处理器由它来干。我强烈建议后者,原因在第四节会展开。

还有个更隐蔽的差异:主线程崩溃时,主线程的 Looper 已经退出了。这意味着你在 Handler 里Handler(Looper.getMainLooper()).post(...)任何东西,都不会被执行。很多同学想在崩溃时弹个 Toast 说"应用即将重启",或者弹个对话框让用户反馈,这在主线程崩溃场景下完全无效,因为消息队列已经没有消费者了。这个坑我踩过,当时调试了半天,以为是 Toast 权限问题。

2.3 Handler 里能做什么、绝对不能做什么

Handler 执行的时候,进程处于一个非常脆弱的状态:内存可能已经错乱,全局变量可能处于半初始化,某些锁可能还被持有。所以这里的原则是"能力范围内做最少的事"。

能做的:读取当前线程名、读取进程名、抓取堆栈、收集设备信息、把这几样东西拼成一个字符串写进文件、然后结束。这些都是同步可完成的操作。

不能做的:发起网络请求(进程随时可能死,而且此时网络库状态未知)、等待异步回调、调用复杂的第三方 SDK 接口、操作 UI、申请大块内存。还有一个反直觉的:不要在 Handler 里再套一层 try-catch 然后吞掉。我见过有人写得很"稳",把所有逻辑包在 try-catch 里,出错就忽略。结果某次他写文件的路径错了,异常被吞,日志一条没落地,线上查了两天才发现。正确做法是:写文件失败就把失败信息打到 Logcat(至少在开发机上能看到),并且用一个备用路径重试一次,再失败就认了,但不能静默。

关于数据收集的量,也要克制。有些人喜欢在崩溃时把 SharedPreferences 全量读出来、把所有缓存目录文件列表读出来,这些操作都可能触发 IO 异常或者耗时过长。我一般的做法是只收集固定的十几个字段,全部来自内存读取或者极轻量的系统调用。

2.4 为什么"防递归"不是一个可选项

Handler 里写的代码本身也可能抛异常,这时候 JVM 会发现当前线程已经在处理未捕获异常了,行为是不确定的,可能直接 abort,可能无限递归直到栈溢出。所以必须有一个布尔标志位做哨兵:进入 Handler 第一件事就是检查标志位,是 false 就置为 true,是 true 就直接返回,把后续交给系统默认处理器。

这个标志位必须是静态的,而且要注意可见性。理论上单线程场景下不需要volatile,但由于多线程可能同时崩溃(虽然罕见),我习惯还是加上。这个细节很小,但在极端情况下能避免一次难以复现的诡异现象。

另外,进程被杀的时候,有些方案的"重启"逻辑会再拉起一个新进程,新进程如果又崩,就会形成"崩溃-重启-崩溃"的死循环,耗电、发热、用户体验极差。所以重启策略一定要带次数限制和冷却时间,这些状态得持久化到磁盘,不能只放内存——因为进程已经被杀了。

3. 一套能直接抄的落地实现

3.1 处理器骨架:Kotlin 版完整代码

先给一个能跑的版本,再逐段解释。核心思路就三步:抓现场、写文件、交回系统。

class CrashCatcher private constructor() : Thread.UncaughtExceptionHandler { private var original: Thread.UncaughtExceptionHandler? = null private val handling = AtomicBoolean(false) companion object { private const val TAG = "CrashCatcher" private const val CRASH_DIR = "crash_logs" private const val MAX_FILES = 10 @Volatile private var instance: CrashCatcher? = null fun install() { if (instance != null) return val catcher = CrashCatcher() catcher.original = Thread.getDefaultUncaughtExceptionHandler() Thread.setDefaultUncaughtExceptionHandler(catcher) instance = catcher } } override fun uncaughtException(t: Thread, e: Throwable) { val first = handling.compareAndSet(false, true) try { if (first) { val report = buildReport(t, e) writeToDisk(report) } } catch (inner: Throwable) { Log.e(TAG, "catch failed: ${inner.message}") } finally { if (first) { original?.uncaughtException(t, e) } } } }

这段代码有几个设计决策值得说清楚。install()用了幂等判断,防止重复注册导致原处理器链被自己包住两层,那会形成递归。original保存了系统原本的处理器,一定要在finally里转发,否则进程不会被正常终止,就会出现前面说的白屏卡死。AtomicBoolean保证只处理一次,即使同一时刻有两个线程崩溃,也只有一个能进去写日志。

很多人会纠结"要不要在主线程崩溃之后继续跑"。我的答案是没有余地:不要。App 的主线程已经死了,后续任何交互都无法处理,你让进程继续活着,只会让用户面对一个点不动的界面,还不如干脆退出,让用户重开。所以finally里的转发是硬要求,不是可选项。有些老文章会说"自己调用android.os.Process.killProcess更干脆",也可以,但那样你就丢掉了系统的一些清理逻辑,长期看反而不如转发。

3.2 现场数据怎么采集才算够用

采集字段的设计直接决定这份日志有没有价值。字段太多,写文件耗时增长,崩溃时更容易失败;字段太少,拿回来一堆堆栈却不知道发生在什么环境。我总结下来,下面这些是"必须有"的:

这里有两个我个人强烈建议加的字段。一个是前台 Activity 名,通过在 Application 里注册registerActivityLifecycleCallbacks,在onActivityResumed里记一个静态变量,崩溃时直接读。它能把"某个崩溃集中发生在某个页面"这个规律挖出来,比单纯看堆栈直观得多。另一个是冷启动至今时长,小于 3 秒的崩溃基本可以归类为启动期问题,排查方向完全不同。

还有一点:如果你的应用里接了内存泄漏检测或者有内存快照能力,崩溃时可以顺手记一下当前的 Java 堆使用量。如果崩溃发生前堆使用率已经贴近上限,那大概率是 OOM 相关的连锁反应,方向就变了。

3.3 落盘策略:写到哪、怎么写、写多少个

写文件这一步是整个链路里最容易出问题的环节。几条硬性要求:

第一,写到应用私有目录,用context.filesDir下面开一个子目录。不要写外部存储,一是权限问题,二是很多设备在崩溃瞬间外部存储可能不可用。私有目录的路径不需要任何运行时权限,可靠性最高。

第二,同步写、写完立即 flush。异步写在这里没有意义,因为进程马上就要被杀,异步任务根本来不及执行。用FileOutputStream加BufferedWriter,写完显式flush()并在finally里close()。

第三,单文件而不是每次新建一个。每次崩溃新建一个文件,如果遇到崩溃风暴,目录会被瞬间塞爆。我的做法是每次把崩溃信息追加到一个当天的文件里,文件名带上日期,启动时扫描目录,超过一定天数或者文件数超限就清理最旧的。这里清理逻辑一定要做,我见过一个项目因为没做清理,用户手机上攒了几百兆崩溃日志,最后被系统当成异常应用处理。

第四,要在下次启动时上传并删除。上传成功后立刻删文件,避免重复上报。上传要做失败重试,但不能无限重试,一般两次就够,失败就留着下次启动再试。同时要注意,上传时不要在主线程做,放一个低优先级的后台线程,而且不要因为上传失败影响启动速度。

private fun writeToDisk(content: String) { val dir = File(AppHolder.context.filesDir, CRASH_DIR) if (!dir.exists()) dir.mkdirs() val today = SimpleDateFormat("yyyyMMdd", Locale.CHINA).format(Date()) val target = File(dir, "crash_$today.log") FileOutputStream(target, true).use { out -> out.write(content.toByteArray(Charsets.UTF_8)) out.write("\n----\n".toByteArray(Charsets.UTF_8)) out.flush() } trimOldFiles(dir) }

trimOldFiles里按文件最后修改时间排序,超过阈值就删。这里还有一个细节:写文件之前先判断可用磁盘空间,如果剩余空间不到几十兆,直接放弃写入,只打 Logcat。原因很简单,你的应用不该成为压垮用户存储的最后一根稻草,而且磁盘满的时候写文件本身也会抛异常。

3.4 崩溃之后怎么收场:三种策略的取舍

第一种,交回系统默认处理器。这是默认推荐,行为确定,系统会正常杀进程,下次冷启动一切正常。缺点是用户看到的就是"闪退",没有任何交代。

第二种,主动拉起一个"崩溃提示页"。实现的思路是在 Handler 里记录一个"上次异常退出"的标记,下次启动时读到这个标记,先展示一个友好的说明页,告诉用户刚才发生了什么、可以点反馈按钮把日志发给你。这个方案体验最好,而且实现成本不高,因为它不是在崩溃瞬间弹窗(做不到),而是在下次启动时补偿。很多成熟应用都是这么干的。

第三种,尝试自动重启到首页。我必须直说,这条路在新版本系统上越来越窄,后台启动 Activity、后台启动 Service 都有各种限制,很多场景下你调了 API 但什么也不会发生。跨进程拉起也不可靠,因为系统对进程启动的管理越来越严格。如果不做充分的兼容测试就上线,很可能得到一个"重启失败 + 白屏"的更差结果。我的建议是:不要把它当主策略,最多作为特定场景下的补充。

无论选哪种,有件事必须做:重启/重开的次数要限制。在私有目录里存一个计数文件,记录最近十分钟内的重启次数,超过三次就不再尝试,直接展示提示页引导用户手动打开。这个逻辑看起来不起眼,但它挡住的是"崩溃风暴把用户手机烧热"这种投诉。

3.5 边界:哪些崩溃这套东西天然收不到

写实现之前先认清边界,比写完再怀疑有效率得多。

ANR 收不到,因为 ANR 不抛异常,系统只是发现主线程太久没响应,弹了个对话框。想监控 ANR,常规做法是用Looper.getMainLooper().setMessageLogging()打点,统计单条消息的耗时,超过阈值就记录堆栈;或者在Activity的onPause/onResume里做超时埋点。要注意的是,高版本系统对 ANR 现场文件的读取有限制,普通应用不一定拿得到。

Native 崩溃收不到,因为那是 C/C++ 层的信号,和 JVM 的异常机制完全无关,得单独用信号处理方案。

进程被系统直接杀掉(内存回收、用户手动强杀)收不到,因为你根本没机会执行任何代码。

跨进程的问题要注意:如果应用有多个进程,Application.onCreate会在每个进程各执行一次,所以 Handler 在每个进程里都会被注册。这通常是好事,子进程的崩溃你也能收到。但上报的时候一定要带进程名,否则你会看到同一时刻两条一模一样的崩溃,以为是两个 bug。

还有一种很隐蔽的情况:某些系统组件在非常早的阶段崩溃,比如Application的构造过程、静态变量的初始化块。这类崩溃发生在你的注册代码执行之前,确实收不到。想覆盖这部分,只能靠系统的崩溃记录,或者靠下次启动时的"异常退出检测"来做兜底推测。

4. 常见问题与排查实录

4.1 问题速查表

这张表是我从多个项目的实际排查记录里汇总的,基本覆盖了自研方案 90% 的翻车点。其中"崩了之后界面卡住"和"重复上报"两个出现频率最高,而且都是很容易在第一次实现时忽略的。

4.2 三个踩过的坑,每个都花了半天以上

第一个坑,Handler 注册了但没生效。当时排查了很久,最后发现是团队里另一个同事在某个初始化工具类里也调了一次setDefaultUncaughtExceptionHandler,把我们的覆盖掉了。这类问题在多人协作的项目里很常见,尤其是引入多个第三方库之后,谁也不知道谁动过这个全局设置。解决思路是让install()具备幂等性,并且在调试构建里加一句日志,打印当前的默认处理器是谁,一眼就能看出来。

第二个坑,日志写了但是上传不上去。查了半天发现,上传逻辑是在Application.onCreate里同步执行的,而某些机型上首次启动的网络初始化很慢,导致启动被卡住,甚至触发了系统的启动超时。后来改成延迟到首页onResume之后再触发,并且加了严格的超时控制,问题消失。这里的原则是:上报永远不能拖慢启动,它是个锦上添花的能力,不能反客为主。

第三个坑,某个版本的崩溃日志里,堆栈全是框架代码,看不到业务代码。原因是被混淆了。这个问题提醒我,崩溃采集的调试构建一定要保留一份不带混淆的映射关系,而且混淆配置里要保留行号信息,否则你拿到的堆栈里连第几行都没有,还原起来极其痛苦。这件事看起来是构建配置的问题,但和崩溃采集是强绑定的,做采集的时候就得顺手确认好。

4.3 上线前怎么验证这套东西真的在工作

最直接的验证办法是埋一个"测试崩溃"入口,只在调试构建或者内部测试包里出现。点一下,主动抛一个 RuntimeException,然后看三件事:日志文件有没有生成、内容是不是完整、下次启动有没有被正确上传并清理。这三步都通了,链路才算打通。

更严格一点的做法,是做一次"崩溃链路演练":在测试环境模拟低存储、模拟网络不通、模拟应用在后台被杀,看看各种极端条件下日志是否还能落地。我的经验是,正常情况下这套逻辑几乎不会出问题,出问题都在极端场景。所以内部测试版本里一定要保留这个入口,每次改动了崩溃相关代码,手动点一遍。

还有一个容易被忽略的验证点:升级安装。用户从旧版本升级到新版本,私有目录里的旧日志还在,如果清理逻辑写得不严谨,可能会出现重复上报或者读到格式不兼容的旧文件。做升级测试的时候顺手看一眼目录,能省掉不少线上问题。

5. 更进一步:崩溃率口径、兜底手段和几件容易忽略的事

5.1 崩溃率怎么算才不是自欺欺人

崩溃数据收到了,接下来绕不开一个问题:怎么算崩溃率。不同团队的口径差异非常大,有的是"崩溃次数 / 启动次数",有的是"崩溃用户数 / 活跃用户数",两个数字能差好几倍。我倾向用双指标:一个看次数,用来衡量技术质量;一个看人数,用来衡量用户感受。只看次数容易被单个用户的崩溃风暴带偏,只看人数则会低估那些反复崩溃的严重问题。

还有一个细节值得强调:启动两秒内的崩溃要不要单独统计。我建议单独拉一条线。启动期崩溃的用户体验极差——用户点开应用,还没看到东西就没了,很可能直接卸载。这类问题在总数里占比可能不高,但杀伤力最强。单独统计之后,你就会发现启动期问题的修复优先级应该排在最前面。

另外,收到崩溃日志之后别忘了做一次"去重归因"。同一个根因在不同机型上可能表现成不同的堆栈,尤其是涉及到厂商定制系统的时候。这时候靠前台页面名、崩溃时间点、用户操作路径这几个维度交叉比对,比单纯看堆栈更有效。

5.2 低端机与降级场景下的兜底思路

低端机的资源紧张是绕不过去的。我的做法是把崩溃采集做成"可降级的核心能力":写文件的目标目录、字段采集的范围、是否附带堆栈的额外信息,都可以通过一个开关控制。在极端低配设备上,只保留最基础的堆栈落盘,其他全部关掉。

关于重启策略在低端机上的表现,我的经验是要更保守。低端机本身的启动就慢,如果再叠加一次崩溃重启,用户的等待时间会被放大好几倍,体感极差。所以针对低内存设备,直接禁用自动重启,改成展示提示页,让用户自己决定要不要重开。这个判断可以通过ActivityManager.isLowRamDevice()来读。

还有一个场景是隐私合规审查越来越严,崩溃日志里可能携带了不该带的信息。比如堆栈里可能带上用户的输入内容、页面参数里的标识符。所以在写盘之前做一次清洗是必要的:把明显的长数字串、邮箱格式、URL 参数做脱敏处理。这个清洗不需要很复杂,几条正则就能挡住绝大部分,但这一步不能省。

5.3 我个人在实际项目里的几条经验

第一条,处理器的实现要尽量"傻"。不要在里面做判断、不要在里面读配置、不要在里面调业务代码。越简单,在崩溃那一刻成功执行的概率越高。我见过有人为了"只在正式环境采集",在 Handler 里读了一次 SharedPreferences,结果那次崩溃恰好是磁盘 IO 相关的,日志一条没写出来。

第二条,日志的格式要固定,不要随版本变化。你后端解析这套日志的时候,格式一变就是一次解析事故。建议用固定的分隔符或者直接写成 JSON 的一行,字段名一旦定下就别改,要加字段就追加在末尾,老字段全部保留。

第三条,别把 Handler 当成 try-catch 的替代品。有些同学想用它来"吃掉"异常,比如在里面不转发、让进程继续跑。这条路上没有好结果,应用状态已经不可信了,继续跑只会出现更难排查的数据错乱。它的定位始终是记录者,不是修复者。

第四条,定时回看。崩溃采集最容易出现的情况是"接了但没人看",日志堆在服务器上没人管。我的习惯是每周固定扫一遍新增的崩溃类型,尤其是那些出现次数不多但集中在新版本上的,往往是新代码引入的问题,早发现早修。

第五条,把"上次是否异常退出"这个标记用起来。除了做崩溃提示页,它还能帮你判断某些启动异常——比如用户反馈"打开就闪退",但日志里什么都没有,这时候如果标记显示上次是非正常退出,至少能确认确实出过问题,再结合系统的应用异常记录去定位,方向会清晰很多。

最后分享一个小技巧:如果你在排查一个偶发崩溃,又拿不到足够信息,可以临时在 Handler 里把当前所有线程的名字和状态 dump 一份出来。虽然会让日志变大,但在定位"某个后台线程死锁导致的连锁崩溃"这类问题时特别管用,能直接看到崩溃瞬间还有哪些线程活着、卡在哪一步。这个方法我在两个项目里用过,都很快就找到了根因,事后记得把这个开关关掉,不然日志体积会失控。