binder线程池.png

在服务端Service中，有三个Binder类，那么服务端也就开了3个线程(Binder服务端必须在子线程中监听客户端的请求)。

步骤一：通过IPC获取BinderPool在本地的引用(这是个Proxy对象，系统会帮你创建)。

步骤二：通过该Proxy对象直接和Service端的Binder进行通信

包结构如下：

Binder线程池包结构.png

interface IBinderPool {
    /**
     * 根据code返回对应的Binder对象
     */
   IBinder queryBinder(int code); 
}

客户端首先和Service端的BinderPool对象进行一次IPC通信，客户端拿到自己想要的Binder代理，比如EncryptMoudle,然后通过该代理直接和服务端对应的Binder通信。

这种思想在Android FrameWork层中随处可见，系统提供了各种各样的服务(Service)，客户端必须先拿到ServiceManger，再根据ServiceManager来拿到对应的Service，这里的BinderPool也是同样的道理。

  getSystemService(String name)

通过这一行代码，就可以拿到服务端提供的Service。