17、Binder 的异常处理：RemoteException、DeadObjectException 的产生原因与处理方式
Binder 通信看着挺美，跨进程调用像本地调用一样方便。但实际用起来，你会发现它并不是银弹。我在项目中就吃过不少亏——客户端调着调着突然崩了，日志里只留下一句 DeadObjectException。嗯，今天我们就来聊聊这些异常到底怎么来的，又该怎么处理。
17.1 异常体系概览
Binder 相关的异常，核心就两个：RemoteException 和 DeadObjectException。它们的关系很简单——DeadObjectException 是 RemoteException 的子类。
核心要点：所有 Binder 调用相关的 checked exception，最终都继承自 android.os.RemoteException。而 DeadObjectException 是最常见、最让人头疼的那个。
我习惯把 Binder 异常分成两类：
- 通信层面的异常——比如服务端进程挂了、Binder 驱动缓冲区满了
- 业务层面的异常——比如服务端抛出了自定义的
SecurityException
前者是框架帮你抛的，后者是你自己代码里抛的。但不管哪种，客户端都得接住。
17.2 RemoteException：Binder 通信的通用异常
RemoteException 是 Binder 通信异常的基类。说白了，只要跨进程调用过程中出了岔子，框架就会抛它或者它的子类。
为什么会抛 RemoteException？常见场景有：
- 服务端进程意外死亡（最常见）
- Binder 驱动内部错误（比如事务太大，超过 1MB 限制）
- 服务端抛出了未检查的异常（RuntimeException 等）
- 网络超时或内核调度问题（少见）
我记得有一次排查线上问题，发现某个接口偶尔抛 RemoteException，但服务端进程明明活着。后来定位到是 Binder 事务缓冲区满了——客户端一次性传了个大 Bitmap，超过了 1MB 的限制。嗯，这个坑后面会细说。
17.3 DeadObjectException：服务端挂了
DeadObjectException 是 RemoteException 的子类。它的含义非常明确：你正在调用的那个 Binder 对象已经死了。
什么情况下会死？
- 服务端进程被 kill（包括系统杀进程、ANR 后被杀、手动 kill）
- 服务端进程 crash（空指针、OOM 等）
- 服务端主动调用了
System.exit()或类似操作 - Binder 驱动检测到服务端无响应，标记为 dead
注意：一旦服务端进程死亡，客户端持有的所有 Binder 代理对象都会变成“死亡状态”。即使服务端重启了，客户端也必须重新获取 Binder 引用，旧的代理对象无法复活。
我刚开始做 Android 系统开发时，就踩过这个坑。服务端进程被系统杀掉了，客户端还在用旧的 Binder 代理发请求，结果 DeadObjectException 满天飞。后来才明白——Binder 代理对象是有生命周期的，服务端挂了，代理就废了。
17.4 异常处理的最佳实践
处理 Binder 异常，说白了就两件事：捕获异常 和 恢复连接。
17.4.1 捕获 RemoteException
所有 Binder 调用都要包在 try-catch 里。这是基本功，但很多人会忘。
// 错误示范：不捕获异常
mService.doSomething(data); // 可能抛 RemoteException！
// 正确示范：必须捕获
try {
mService.doSomething(data);
} catch (RemoteException e) {
// 处理异常
Log.e(TAG, "Binder call failed", e);
handleBinderError();
}你可能会问：为什么是 checked exception？因为 Google 的设计者就是想逼你处理它。跨进程调用不可靠，这是共识。
17.4.2 区分 DeadObjectException
捕获到 RemoteException 后，最好判断一下是不是 DeadObjectException。因为处理方式不同：
try {
mService.doSomething(data);
} catch (RemoteException e) {
if (e instanceof DeadObjectException) {
// 服务端挂了，需要重新绑定
Log.w(TAG, "Service died, rebinding...");
rebindService();
} else {
// 其他通信异常，可以重试
Log.e(TAG, "Transient error, retrying...");
retryWithBackoff();
}
}我个人习惯在基类封装一个 safeBinderCall() 方法，统一处理异常和重试逻辑。这样业务代码里就不用到处写 try-catch 了。
17.4.3 注册死亡通知
除了被动捕获异常，你还可以主动监听服务端死亡。Binder 提供了 linkToDeath() 机制：
// 客户端注册死亡通知
IBinder.DeathRecipient deathRecipient = new IBinder.DeathRecipient() {
@Override
public void binderDied() {
Log.w(TAG, "Binder died, cleaning up...");
// 清理资源，准备重新绑定
mService = null;
rebindService();
}
};
// 在获取到 Binder 代理后注册
mService.asBinder().linkToDeath(deathRecipient, 0);
// 不再需要时解除注册
mService.asBinder().unlinkToDeath(deathRecipient, 0);建议：注册死亡通知后，记得在合适的时机解除注册（比如 Activity 的 onDestroy）。否则可能造成内存泄漏。
我在项目中遇到过一个问题：服务端进程频繁重启，死亡通知回调里做了大量资源清理操作，结果客户端 UI 卡顿严重。后来改成延迟清理 + 批量处理，才解决。
17.5 事务太大导致的 TransactionTooLargeException
这个异常虽然也继承自 RemoteException，但原因很特殊——Binder 事务缓冲区满了。
Android Binder 驱动默认每个事务的缓冲区大小是 1MB（不同版本略有差异）。如果你传的数据超过这个限制，就会抛 TransactionTooLargeException。
| 场景 | 典型数据量 | 是否容易触发 |
|---|---|---|
| 传小字符串、整数 | 几 KB | 不会 |
| 传 Bitmap（1080p） | 几 MB | 容易 |
| 传大文件（内存映射） | 几十 MB | 必然触发 |
我曾经接手过一个项目，日志里全是 TransactionTooLargeException。查了半天发现是某个接口把整个图片列表序列化后传过去了。解决方案很简单：用文件路径代替数据本身，或者用 ContentProvider 共享大文件。
注意：1MB 限制是 Binder 驱动的硬限制，不是应用层能改的。如果你需要传大数据，请走 ContentProvider、Socket 或者共享内存。
17.6 异常处理流程图
下面这张图总结了 Binder 异常处理的完整流程。我建议你把它贴在工位旁边，写代码时对照着看。
17.7 避坑指南
最后，分享几个我踩过的坑，希望能帮你少走弯路。
避坑 1：不要在 Binder 回调里做耗时操作
Binder 回调默认运行在 Binder 线程池中。如果你在回调里做了耗时操作（比如数据库写入），会阻塞其他 Binder 调用。我曾经见过一个案例，回调里做了网络请求，结果整个系统 UI 都卡住了。
避坑 2：不要忽略 RemoteException
有些人觉得 Binder 调用很少出问题，就懒得捕获异常。结果线上出了 DeadObjectException，应用直接崩溃。记住：跨进程调用永远不可靠，必须捕获。
避坑 3：死亡通知回调里不要做 UI 操作
binderDied() 回调运行在 Binder 线程，不是主线程。如果你在里面更新 UI，会抛 CalledFromWrongThreadException。正确的做法是 post 到主线程 Handler。
避坑 4：大文件不要走 Binder
Binder 的 1MB 限制是硬伤。传大文件请用 ContentProvider、FileProvider 或者共享内存。我见过有人传 10MB 的 JSON，结果每次调用都抛 TransactionTooLargeException。
好了，关于 Binder 的异常处理就聊到这里。这些经验都是我用血泪换来的，希望你能记住。下次遇到 DeadObjectException，别慌——先看看服务端进程是不是还活着，再检查一下你的异常处理逻辑。
公众号:蓝海资料掘金营，微信deep3321