35. 超时机制：Binder 调用的超时时间设置与超时处理

Binder 调用是跨进程的，说白了就是两个进程之间的一次“握手”。既然是握手，那就可能遇到对方不搭理你、或者手伸到一半卡住了的情况。这时候如果没有超时机制，你的调用线程就会一直挂在那里，像死了一样。嗯，这显然是不能接受的。

我个人习惯把 Binder 的超时机制比作“看门狗”。它不复杂，但一旦出了问题，排查起来特别隐蔽。今天我们就把它彻底讲透。

35.1 超时时间在哪里设置？

Binder 的超时时间，并不是在驱动层写死的。它实际上由 用户空间 的调用方决定。具体来说，是通过 IPCThreadState 中的 mStrictModePolicy 和 mLastTransactionBinderFlags 来间接控制的。

但最直接、最常用的方式，是调用 BinderProxy.transact() 时传入的 flags 参数。这个参数里有一个标志位：FLAG_ONEWAY。你可能会问：“这跟超时有什么关系？” 关系大了。

核心结论： 只有 非 oneway 的 Binder 调用（即同步调用），才会触发超时机制。Oneway 调用本质上是异步的，发送完就返回，不存在超时一说。

那同步调用的超时时间到底是多少？答案是：默认没有超时。你没看错，Binder 驱动本身不强制超时。真正的超时是由 应用层 的 BinderProxy.transact() 内部实现的，它通过 Looper 和 MessageQueue 的 timeout 机制来模拟。

我记得在 Android 4.4 之前，Binder 同步调用确实会一直阻塞。后来 Google 在 BinderProxy 里加了一个默认的 1 秒超时。但这个超时只针对 系统服务 的某些特定调用，并不是全局的。

35.2 超时到底发生在哪一层？

要理解超时，得先搞清楚 Binder 调用的完整链路。我画了一张图，你看完就明白了。

客户端进程 BinderProxy.transact() Binder 驱动 binder_thread_read() 服务端进程 onTransact() BC_TRANSACTION BR_TRANSACTION 超时检测点：客户端等待 BR_REPLY 或 BR_DEAD_REPLY 如果超过 1 秒（默认）未收到回复，触发超时 超时处理：抛出 TransactionTimeoutException 或返回 DEAD_OBJECT 错误码 图：Binder 同步调用超时检测流程

从图上可以看到，超时检测发生在客户端等待回复的阶段。驱动把请求发出去后，客户端线程就进入 waitForResponse() 循环。这个循环内部会调用 Looper.pollOnce()，并传入一个超时时间。

避坑指南： 我曾经在调试一个系统服务时，发现 Binder 调用偶尔会卡死 30 秒以上。后来定位到是因为服务端在处理 onTransact() 时，内部又发起了另一个 Binder 调用，形成了嵌套调用。而客户端的超时时间被服务端的嵌套调用“吃掉”了。解决方案是：在服务端处理耗时逻辑时，一定要开子线程，不要在主线程里做重活。

35.3 超时时间到底是多少？

这个问题其实没有标准答案。不同场景下，超时时间不一样。我整理了一个表格，方便你对照。

场景 超时时间 说明
普通应用 Binder 调用 无默认超时 由应用层自行控制，通常通过 Handler 或 FutureTask 实现
系统服务 Binder 调用 1 秒（部分服务） 在 BinderProxy 内部通过 mDefaultTimeout 控制
ContentProvider 跨进程查询 15 秒 由 AMS 在调用时设置，防止 Provider 死锁
BroadcastReceiver 的 Binder 调用 10 秒 由 ActivityManagerService 控制
自定义 Binder 服务 由开发者自行实现 建议使用 CountDownLatch 或 CompletableFuture 实现超时

你可能会问：“为什么系统服务有 1 秒超时，而普通应用没有？” 原因很简单：系统服务是核心组件，不能因为一个调用卡死就影响整个系统。普通应用嘛，卡死了最多就是 ANR，系统还能接受。

35.4 超时后发生了什么？

超时发生后，Binder 驱动会做两件事：

  1. 清理事务：驱动会把这次未完成的 transaction 从等待队列中移除。
  2. 通知客户端：驱动向客户端发送 BR_DEAD_REPLY 或 BR_FAILED_REPLY 消息。

客户端收到后，waitForResponse() 循环会退出，并返回一个错误码。在 Java 层，这个错误码会被转换成 TransactionTimeoutException 或 DeadObjectException。

但这里有一个坑：服务端可能还在处理。超时只是客户端单方面放弃了等待，服务端并不知道。如果服务端后续完成了处理并返回结果，驱动会发现已经没有人在等了，于是直接丢弃这个回复。

注意： 超时后，服务端仍然会继续执行 onTransact() 中的代码。如果你在服务端做了资源分配或状态修改，超时并不会回滚这些操作。所以，服务端必须保证操作的原子性，或者通过事务机制来处理超时后的回滚。

35.5 如何自定义超时时间？

如果你需要自定义 Binder 调用的超时时间，有几种方式：

方式一：使用 CountDownLatch

// 客户端代码
final CountDownLatch latch = new CountDownLatch(1);
final AtomicReference<Result> resultRef = new AtomicReference<>();

// 在子线程中发起 Binder 调用
new Thread(() -> {
    try {
        Result r = service.doSomething();
        resultRef.set(r);
    } catch (Exception e) {
        // 处理异常
    } finally {
        latch.countDown();
    }
}).start();

// 主线程等待，最多 5 秒
boolean success = latch.await(5, TimeUnit.SECONDS);
if (!success) {
    // 超时处理
    throw new TimeoutException("Binder call timed out");
}

方式二：使用 CompletableFuture（Java 8+）

CompletableFuture<Result> future = CompletableFuture.supplyAsync(() -> {
    return service.doSomething();
});

try {
    Result r = future.get(3, TimeUnit.SECONDS);
} catch (TimeoutException e) {
    // 超时处理
    future.cancel(true); // 尝试中断
}

我个人建议： 如果你在写一个对外提供的 SDK，一定要给调用方提供设置超时时间的接口。不要硬编码超时时间。我曾经接手过一个项目，里面所有 Binder 调用都硬编码了 2 秒超时。结果在低端机上，服务端处理慢一点就疯狂超时，用户体验极差。

35.6 超时问题的排查思路

如果你遇到 Binder 调用超时的问题，可以按这个顺序排查：

  • 第一步：确认是同步还是异步。如果是 oneway 调用，超时就是应用层自己实现的，跟 Binder 驱动无关。
  • 第二步：抓取 trace。用 adb shell dumpsys activity processes 或 adb shell dumpsys binder 查看当前 Binder 线程的状态。
  • 第三步：检查服务端是否死锁。服务端如果也在等另一个 Binder 调用，就可能形成死锁。用 adb shell dumpsys window 或 dumpsys activity 查看线程堆栈。
  • 第四步：检查驱动层是否有积压。用 adb shell cat /sys/kernel/debug/binder/state 查看 Binder 驱动的状态，看是否有大量未完成的 transaction。

嗯，说到排查，我记得有一次线上问题：某个功能在 Android 12 上频繁超时，但在 Android 11 上正常。后来发现是 Android 12 对 Binder 调用增加了新的权限检查，导致服务端处理时间变长。解决方案是优化服务端的处理逻辑，把权限检查提前到调用入口处。

超时机制说白了就是“保底”。它不能解决所有问题，但能防止最坏的情况——整个系统卡死。理解它的工作原理，能让你在遇到问题时少走很多弯路。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →