相关知识
1.binder系统中里面了一个资源池用于存放bbinder。
2.客户端会根据索引在binder系统中查找到对应的bbinder，接着构造bbinder对应的bpbinder。
3.bpbinder底层会调用ipcthreadstate的talkwithdrive来调用到对应的bbinder。binder处理完成后再回调过去。
4.其实servicemsnsger也是普通的service，只不过他在启动的时候通过iotcl的形式告诉了自己指定的hsndler是0。这样binder系统中0就是对应的servicemanager的bbinder。serve需要从binder系统中拿到这个0的bbbinde把它封装成bbinder，在借助asinterfsce封装成代理。
5.底层bpbinder通过ipcthreadstate（每个线程都有一个ipcthreadstate对象）调用trascat，里面进行调用到了bbinder对应的transact方法回调ontransact。。。。
6.为什么bpbinder可以调用到bbinder，这就是binder系统为我们做的事情。之前我们是通过bbinder构造出来的bpbinder理所应当bpbinder也能调用到bbinder
完整流程：
1。服务端 调用jointhreadpool，传入主线程，主线程就会talkwithdrive等待binder的消息；再startThreadPool创建一个ipcThreadState也就是一个线程，把这个线程也加入到jointhreadpool调用talkwithdrive等待处理binder的请求。因此服务端有两个线程在处理binder系统的请求。之后通过iotcl的形式告知binder自己的handler资源索引值的值比如serviceManager就会告诉binder自己是0。binder系统中保存
2。客户端：根据索引通过iotcl将bbinder封装成bpbinder。之后会调用到bpbinder的transact方法中，接着进入到ipcThreadState的transact方法，里面解析出要进行通信的service是哪个，通过talkwithdrive向binder系统中发消息。
3.binder系统收到客户端消息找出对应的server进程并给这个进程发送请求通过ServiceManager进行查找。
刚刚上面说到server中会有两个线程等待binder的请求，这时候server进程就会收到，通过解析参数调用到真正的bbinder的transact。
bbinder的transact又会调用到对应binder实体的ontransact。
简化版就是客户端调用transact，服务端会收到ontransact的回调。外面看起来都是调用的同一个ibinder对象的方法。其实内部是通过两个ibinder的字类bpbinder和bbinder进行的处理。
bpbinder 的transact—–》bbinder的transact—–》bbinder的ontransact将结果或者异常保存在Parcel对象中返回----》服务端处理完之后bpbinder会继续运行读取出运行结果或异常进行后续处理
流程就是上面的流程
