子线程崩溃导致应用无响应，因其静默退出使依赖状态未更新、回调未发出、资源未释放；setUncaughtExceptionHandler仅对调用它的线程实例生效，须在start()前设置，且不可捕获主线程异常。
线程崩溃时为什么应用会无响应
主线程（UI 线程）崩溃会直接导致 Activity 重建或进程终止，但子线程崩溃默认不抛给主线程，也不会触发 Application.onCreate() 或 Activity.onDestroy()。问题在于：若子线程在执行关键逻辑（如网络回调后更新 UI、处理传感器数据、轮询任务），它静默退出后，依赖它的状态没更新、回调没发出、资源没释放，外部看起来就像“卡住”了——比如进度条一直转、按钮点击无反应、定时器停摆。
setUncaughtExceptionHandler 的作用范围和生效时机
这个方法只对**调用它的那个 Thread 实例**生效，且必须在该线程启动前或运行中设置（但要在异常发生前）。它不会自动继承到新创建的线程，也不能捕获已终止线程的历史异常。
-
Thread.setDefaultUncaughtExceptionHandler()可设全局兜底，但仅对未显式设置 handler 的线程生效；主线程的默认 handler 已被 Android 框架接管，修改它需谨慎 - Android 中，主线程崩溃由
ActivityThread捕获并触发ANR或进程杀掉，setUncaughtExceptionHandler()对主线程基本无效 - 常见误用：在
new Thread(() -> {...}).start()后才调用setUncaughtExceptionHandler()—— 此时线程可能已执行完或正在执行，handler 来不及注册
正确设置 handler 的实操方式
核心原则：**在 start() 前绑定 handler，并确保能安全上报/恢复状态**。以下是可靠写法：
Thread worker = new Thread(() -> {
// 可能抛异常的逻辑，如 JSON 解析、IO、空指针操作
JSONObject obj = new JSONObject(response);
updateUi(obj); // 这里可能因 View 已销毁而 NPE
});
worker.setUncaughtExceptionHandler((t, e) -> {
Log.e("Worker", "Crashed in " + t.getName(), e);
// 关键：避免在子线程里直接操作 UI，改用 Handler / runOnUiThread / LiveData
new Handler(Looper.getMainLooper()).post(() -> {
Toast.makeText(context, "后台任务异常：" + e.getMessage(), Toast.LENGTH_SHORT).show();
// 清理关联状态，例如重置 loading flag、关闭 dialog
isLoading.set(false);
});
});
worker.start();
- 不要在 handler 里做耗时操作（如网络请求、磁盘写入），否则阻塞该线程的异常处理流程
- 若使用
ExecutorService，需包装Runnable或继承ThreadPoolExecutor并重写afterExecute()，因为线程池复用线程，setUncaughtExceptionHandler()对 pool 内线程不适用 - 对于 Kotlin 协程，应使用
CoroutineExceptionHandler，而非 Thread handler —— 它们不在同一抽象层
容易被忽略的兼容性与副作用
Android 8.0+ 对后台线程异常更敏感，某些系统级异常（如 TransactionTooLargeException）即使被捕获，也可能已触发 Binder 队列阻塞，后续 IPC 调用（包括 Toast、Handler 发送）会延迟甚至失败。
- 部分 ROM（如 MIUI、EMUI）会拦截或丢弃非主线程的
Toast和Log，建议同时写入本地日志文件供事后分析 - 如果 handler 中调用了
System.exit()或android.os.Process.killProcess()，会导致整个进程退出，用户感知就是“闪退”，而非“无响应”——这反而掩盖了真实问题 - 频繁崩溃+ handler 中重复弹 Toast，可能触发系统 ANR 检测（因主线程被大量 post 占用），形成负向循环
真正防止无响应，靠的不是“抓住异常”，而是“不让关键路径依赖单一线程存活”。比如用 WorkManager 替代长期后台线程，用 LiveData 或 StateFlow 解耦 UI 更新时机，把可能失败的操作设计成幂等、可重试、带超时的单元。
