Binder架构：Client-Server模型、Service Manager、Binder驱动

聊Binder架构，咱们得从它的核心骨架说起。我当年刚接触Android时，最困惑的就是这玩意儿到底怎么把两个进程串起来的。后来撸了一遍源码才恍然大悟——说白了，它就是个三层结构：Client-Server模型、Service Manager、Binder驱动。这三层各司其职，少了谁都不转。

Client-Server模型——谁请求谁服务

你想象一下：一个进程想用另一个进程的功能（比如系统服务帮你启动Activity），它不能直接跳过去访问内存——进程间是隔离的。所以Android搞了个经典的Client-Server模型。

• Client：发起请求的进程。比如你的App想访问电话服务，它就是Client。
• Server：提供服务的一方。比如TelephonyManager背后的系统服务。
• 请求流程：Client发送一个数据包（Binder事务），Server收到后处理并返回结果。

这里有个坑：Client和Server不是固定的。同一个组件在不同的上下文中可以既当Client又当Server。我见过新手写Binder服务时，把角色定死为“只提供服务”，结果在内部需要调用别的服务时，忘了它也能作为Client发起请求——嗯，这个留神就好。

Service Manager——服务的大管家

那么多Server各提供各的服务，Client怎么知道该找谁？这就需要Service Manager了。你可以把它想象成一个电话簿：所有Server启动后，先把自己的名字（服务名）和一个标识（句柄）注册到Service Manager里。Client要调用某个服务时，先去问Service Manager：“给我activity服务在谁那里？”Service Manager查一下表，告诉Client这个服务的句柄，然后Client就能直接跟Server通信了。

这里有个关键点：Service Manager本身也是一个Binder服务。它的句柄是0（Binder驱动的保留值）。所以Client第一次找Service Manager时，根本不需要查表——驱动直接认识它。

Binder驱动——真正的搬运工

Client和Server之间怎么传数据？进程间不能直接读对方内存，所以Binder驱动就登场了。它是Linux内核里的一个模块，负责三件事：

1. 数据搬运：把Client的请求数据从用户空间复制到内核空间，然后映射到Server进程读取。
2. 线程管理：驱动为每个服务维持一个工作线程池。Client发请求时，驱动唤醒一个空闲的Server线程来处理。
3. 句柄管理：把用户空间能看到的“句柄”和内核里的真实Binder节点对应起来。句柄是一个整数，驱动负责查表映射。

我曾经踩过一个坑：Binder驱动默认每个服务最多16个并发线程。有一次我在一个服务里做了大量CPU密集型计算，结果其它请求因为线程池满了被阻塞。解决方案是调整线程池大小，或者把耗时操作放到别的线程里。

三者如何协作——一次完整调用

我画了张图，把整个流程串起来给你看看：

几个必须记住的数字

组件	关键句柄/ID	作用
Service Manager	0	所有Binder通信的起点
普通服务句柄	正整数（≥1）	由驱动分配，Client凭此调用
Binder驱动线程池	默认最大16	每个服务最多同时处理16个请求

三种调用方式

Binder支持三种通信模式，我用个表格给你对比一下：

模式	描述	常用场景
同步调用	Client阻塞，等Server返回	获取数据、设置配置
单向调用（oneway）	Client不等待，直接返回	发送通知、死信提醒
回调（Callback）	Server主动调用Client的Binder对象	异步结果、进度反馈

我个人写Binder服务时，最常犯的错误是把所有逻辑都堆在驱动的工作线程里。记住：驱动线程池就那么大，耗时操作一定要自己开线程去跑，否则整个Service Manager都可能被拖慢。嗯，这个坑我替你们踩过了。