解读

这道题在国内 Android 面试里属于“Binder 高频三问”之一（另两问是“一次拷贝如何实现”“Client 怎么拿到 Service 代理”）。面试官想确认两点：

1. 你是否真的在 native 层踩过 Binder 的坑，还是只会背“一次拷贝”口号；
2. 遇到 TransactionTooLargeException 时，你能否快速定位是数据量超限还是架构设计缺陷。
   回答时要把“默认大小”“内核限制”“用户态征兆”“线上定位”四个层次一次讲清，体现全栈能力。

知识点

1. 内核常量：
   BINDER_VM_SIZE 定义在 drivers/android/binder.c，用户态 mmap 的虚拟区大小为 1 MB（1024 KB）。
2. 单次事务限制：
   同一时刻一个线程在 binder_transaction 结构里可申请的物理内存 ≤ 1 MB，但内核会预留 20% 安全水位，因此 App 层实测阈值约 900 KB；若跨进程传递 Ashmem（匿名共享内存）则不计入 1 MB。
3. 超出后的行为：
   • 同步调用：驱动返回 -ENOMEM，Framework 抛 TransactionTooLargeException（API 15+ 统一异常码）。
   • 异步调用（oneway）：驱动直接丢弃事务，返回 -EAGAIN，应用侧无异常但收不到回调，表现为“功能偶发失效”。
4. 国内厂商改动：
   部分深度定制 ROM 把 BINDER_VM_SIZE 扩到 2 MB 或 4 MB，但出于兼容性考虑仍保持 1 MB 上报，因此不能依赖“扩大缓冲区”解决业务问题。
5. 线上监控：
   通过 adb shell cat /d/binder/stats 查看 max_async_space 与 active_async_space；在 App 内可 hook BinderInternal.setBinderProxyCountEnabled 记录异常堆栈，结合 logcat | grep -i "binder.*failed" 复现。

答案

默认事务缓冲区大小为 1 MB，内核侧预留 20% 安全水位后，应用层可安全使用的上限约 900 KB。
一旦单次事务超过该阈值：

• 同步调用会触发 TransactionTooLargeException；
• 异步调用会被驱动丢弃，导致回调丢失且不会抛异常。
  国内部分定制 ROM 虽把缓冲区扩到 2～4 MB，但官方 CTS 仍按 1 MB 验收，因此业务层必须保证单条 Binder 数据 < 500 KB，复杂对象应改用 Ashmem、文件或 ContentProvider 分块传输。

拓展思考

1. 大型列表分页传输：
   把 10 k 条 Cursor 数据一次性通过 AIDL 回传，必炸 1 MB 上限；正确姿势是返回 ContentProvider URI，让对端按页 ContentResolver.openFileDescriptor 自读，或使用 SharedMemory + ParcelFileDescriptor。
2. 多图上传场景：
   把 Bitmap 数组直接塞进 Intent extra，同样触发 TransactionTooLarge；应先在 Service 端建立 Ashmem，再把 ParcelFileDescriptor 通过 Binder 回传客户端，实现“0 拷贝”共享。
3. 崩溃率治理：
   国内厂商后台（如华为 AppGallery Connect、OPPO 移动服务平台）已把 TransactionTooLargeException 归为“强感知崩溃”，权重等同于空指针；治理时除了缩减数据量，还要检查 Intent 是否携带 Serializable 大对象、Bundle 是否被 PictureInPicture 或 Recents 自动序列化。
4. 未来趋势：
   Android 14 引入 BinderRpc（基于 virtio-binder），把缓冲区改为动态流控，上限不再固定 1 MB，但国内终端升级节奏慢，未来 3 年仍需兼容老驱动，面试时可主动提及“做好版本回退”体现前瞻性。