client端通过servicemanager拿到的服务端的bpbinder是否和 servicemanager保存的映射表里面的bpbinder一样？

答案是不一样

这里来详细讲一下
binger通信过程，对使用者是透明的，即使用者可以认为拿到的就是一个服务端的接口对象，直接调用这个对象就能获取服务端的接口提供的功能。

但其地层则是通过bpbinder 和bbinder来进行通信的（一种代理的模式）

即客户端通过bpbinder来进行服务端接口的调用，而同进程则通过bbinder来进行调用

而这个bpbinder 如何生成，以及传递，以及如何代理将接口转到服务端的接口是如何实现的？
bpbinder其实是对hander的封装，这个hander就是驱动层两个进程的映射，驱动根据这个hander能够找到对应的服务端，服务端也能找到对应的客户端，

这也就解释了bpbinder如何调用到service段的bbinder的接口的，内核层可以通过映射找到bbiner的接口，并调用，就是这么简单，因为内核层不存在进程间的限制。
而bpbiner的传递过程也是经过驱动重新和服务端映射的，因此传递给另一个进程的bpbinder其实是驱动重新映射的新的bpbinder，而如果传递的是同一个进程的bpbinder，那么驱动也会转化为bbinder。这个详细的流程我下一步要去驱动里找下详细的步骤。这里举例一个大概的流程：从servicemanager里面get（“ams”）拿到的就是传递过来一个bpbinder，这个驱动是如何转化成一个新的bpbinder的呢，我门来看看把：
client端通过驱动拿到bpbiner的时候，驱动会找到binder对应的该进程的handler，没有则创建对应的hander及bindernode结构体，并传给ipcthreadstate，创建一个新的bpbineder

日常工作中不需要了解这么多，就随便写下这些吧