29. 错误处理：Binder 通信中的常见错误码（-EAGAIN, -ENOMEM, -EPERM）分析
Binder 通信看着挺美，用起来也挺顺手。但一旦出了问题，返回的错误码往往让人一头雾水。我见过不少同事，看到 -EAGAIN 就以为是重试一下就行，结果死循环了；看到 -ENOMEM 就以为是内存不够，结果查了半天发现是别的问题。
今天咱们就把这三个最常见的错误码掰开揉碎了讲清楚。你想想看，搞懂了它们，Binder 通信的坑至少能避开一半。
错误码的本质：Binder 驱动在告诉你什么？
Binder 驱动是一个内核模块。它返回的错误码，本质上是 Linux 内核错误码的延续。但 Binder 有自己的语义，不能简单套用文件系统的理解。
我个人习惯把 Binder 错误码分成三类：
- 资源类：-EAGAIN、-ENOMEM，表示当前资源紧张
- 权限类：-EPERM、-EACCES，表示你没有资格做这件事
- 状态类：-EBADF、-EINVAL，表示你传的参数或句柄有问题
今天重点讲前两类，因为它们在实际项目中出现的频率最高，也最容易让人迷惑。
核心观点：Binder 错误码不是简单的「成功/失败」二元结果。每个错误码背后都对应着驱动内部的一个状态机分支。理解这个分支，你才能写出健壮的代码。
-EAGAIN：不是让你无脑重试
-EAGAIN 的字面意思是「再试一次」。但什么时候该重试？什么时候不该？
在 Binder 通信中，-EAGAIN 通常出现在以下场景：
- Binder 线程池已满：驱动尝试唤醒一个 Binder 线程来处理你的请求，但所有线程都在忙
- 事务缓冲区不足：驱动内部的
binder_transaction分配临时内存失败，但不是因为系统内存不够，而是因为当前进程的 Binder 缓冲区配额用完了 - 非阻塞模式下无法立即完成：你用了
IPC_NOWAIT标志，但对方还没准备好
我在项目中遇到过一个问题：某个服务频繁返回 -EAGAIN，客户端就不断重试，结果把 CPU 跑满了。后来发现是服务端的 Binder 线程数设置得太少，导致请求排队。重试解决不了问题，反而加重了负载。
避坑指南：我曾经在日志里看到 -EAGAIN 就写了个 while 循环重试，结果线上出了事故。后来我总结了一条铁律：连续重试超过 3 次还是 -EAGAIN，就应该报错而不是继续重试。因为这说明系统已经处于异常状态，重试只会让情况更糟。
正确的处理方式应该是：
// 伪代码：合理的重试策略
int retry_count = 0;
const int MAX_RETRY = 3;
int ret;
do {
ret = binder_transaction(...);
if (ret == -EAGAIN) {
// 每次重试前等待一段时间，避免忙等
usleep(1000 * (1 << retry_count)); // 指数退避
retry_count++;
} else {
break;
}
} while (retry_count < MAX_RETRY);
if (ret == -EAGAIN) {
// 超过最大重试次数，记录详细日志并上报
ALOGE("Binder transaction failed after %d retries", MAX_RETRY);
// 这里应该触发告警，而不是继续重试
}-ENOMEM：不只是内存不够
-ENOMEM 是「内存不足」的意思。但在 Binder 的世界里，它比你想的要复杂。
Binder 驱动在内核中维护了多个内存池：
- 事务缓冲区：每个进程有默认的 1MB Binder 缓冲区（可通过
/proc/self/binder_proc查看） - 内核 slab 缓存：用于分配
binder_transaction、binder_work等结构体 - 文件描述符表：传递
Parcel::writeFileDescriptor时需要
我见过最典型的场景是：某个服务频繁传递大图片（几 MB 的 Bitmap），结果把 Binder 缓冲区撑爆了。返回 -ENOMEM 后，客户端以为是系统内存不够，开始清理自己的内存，但问题根本不在这里。
个人经验：遇到 -ENOMEM，我建议先查两个地方：
/proc/<pid>/binder_proc中的buffer_size和buffer_free，看缓冲区是否耗尽/proc/<pid>/fd中的文件描述符数量，看是否超过了ulimit限制
这两个地方往往能直接定位问题，比瞎猜内存不够要高效得多。
还有一个容易被忽略的点：传递大数据时，Binder 会尝试在内核中分配连续物理内存。如果系统内存碎片化严重，即使总内存还有剩余，也可能返回 -ENOMEM。这种情况在长时间运行的 Android 设备上尤其常见。
-EPERM：权限问题没那么简单
-EPERM 是「操作不被允许」。在 Binder 通信中，它通常意味着：
- SELinux 策略拒绝：最常见的原因。即使你的 UID 相同，SELinux 上下文不匹配也会被拒绝
- 服务未注册或已注销：你试图调用一个不存在的服务
- 跨用户通信限制：Android 多用户模式下，不同用户之间的 Binder 通信受到限制
我记得有一次排查线上问题，某个系统服务总是返回 -EPERM。查了三天，最后发现是 SELinux 策略中少了一条 allow 规则。说白了，就是「你有权限，但 SELinux 不让你过」。
调试技巧：遇到 -EPERM，先看 dmesg 或 logcat -b events 中是否有 SELinux 相关的 avc: denied 日志。如果有，那就是 SELinux 的问题。如果没有，再检查服务是否真的注册了。
另外，-EPERM 还有一个隐藏含义：它可能意味着你的调用方式不对。比如，你试图在 oneway 调用中获取返回值，或者试图在非 Root 进程中调用需要 Root 权限的服务。这些情况都会返回 -EPERM，但原因各不相同。
三个错误码的对比与总结
为了方便记忆，我做了一个对比表：
| 错误码 | 字面含义 | Binder 中的常见原因 | 我的处理建议 |
|---|---|---|---|
| -EAGAIN | 再试一次 | 线程池满、缓冲区配额用完、非阻塞模式 | 有限次重试 + 指数退避，超过阈值就报错 |
| -ENOMEM | 内存不足 | Binder 缓冲区耗尽、内核 slab 分配失败、文件描述符超限 | 检查 binder_proc 和 fd 限制，而非系统总内存 |
| -EPERM | 操作不允许 | SELinux 拒绝、服务未注册、跨用户限制 | 查 avc: denied 日志，确认服务注册状态 |
嗯，这里要注意一点：这三个错误码不是互斥的。同一个 Binder 调用可能因为不同原因返回不同的错误码。比如，缓冲区不足可能返回 -EAGAIN（如果只是暂时不足），也可能返回 -ENOMEM（如果确实耗尽了）。
一张图看懂 Binder 错误处理流程
下面这张 SVG 图展示了 Binder 通信中错误码的产生路径。我把它画成了流程图，方便你理解驱动内部是怎么决定返回哪个错误码的。
从这张图可以看出：错误码的产生是有逻辑链的。驱动先检查资源，再检查权限。资源不足时，根据是否可重试决定返回 -EAGAIN 还是 -ENOMEM。权限不足则直接返回 -EPERM。
理解了这个流程，你就能根据错误码反推出驱动内部发生了什么。说白了，错误码就是驱动在跟你「说话」，你得听懂它在说什么。
最后一个小技巧：我习惯在 Binder 调用的日志中同时记录 errno 和 strerror(errno)。这样既能拿到数字，又能看到人类可读的描述。调试的时候，这两者结合往往能更快定位问题。
公众号:蓝海资料掘金营，微信deep3321