android 实现binder机制的server进程学习

进程开始会打开binder设备，谁打开的呢？就是ProcessState：self，再加一句，这个对象是单例的。它还会创建一个接收数据的共享内存，返回fd,每个进程只会打开一次binder设备。

server要想跟服务管理器注册服务，就需要一个代理，跟服务管理器交互，即IServiceManager，defaultServiceManager返回在服务管理器的代理端，这个interface_cast需要一个BpBinder作为参数，先探讨参数BpBinder的产生过程；ProcessState：：self->getContextObject需要传递一个参数Handler 0（0就是服务管理器，其余的服务是别的），根据Handler查询返回代理端IBinder（BpBinder（0）),这中间的过程呢，根据两个宏定义，一个声明方法，一个实现方法，来生成了一个Bp**

BpBinder 是客户端用来与server交互的代理类，p即Proxy的意思；BBinder则是与proxy相对的一端，他是proxy交互的目的端，如果说Proxy代表客户端，那么BBinder则代表服务端。

IServiceManager、BpServiceManager和BnServiceManager都与业务逻辑相关，BnServiceManager同时从IServiceManager BBinder派生，表示它可以直接参与Binder通信，BpServiceManager虽然从BpInterface中派生，但是这条分支似乎与BpBinder没有关系，BnServiceManager是一个虚类，它的业务函数最终需要子类来实现，

既然BpServiceManager与Binder 没哟直接的关系，那么它与Binder是怎样交互的呢，请注意看源代码，BpServiceManager的基类构造函数中，需要的参数就是IBinder类型，实际就是BpBinder，这样BpServiceManager的一个变量MRemote指向BpBinder，BpServiceManager会实现IServiceManager中定义的虚函数，BpBinder作为通信的代表，就跟Binder有关系了。

接下来分析注册一个服务实例，来学习业务层的工作的完成。在服务的初始化中，注册服务到服务管理器。服务的addService把请求数据打包成data后，传给了BpBinder的transact函数，表示业务层addService的方法，把通信层的工作交给了BpBinder。

而真正与Binder通信的是transact中的IPCThreadState方法，