角色： client 、 service 、 serviceManager 、Binder驱动
场景： 前三出演在用户空间，后者在内核空间作为幕后
剧本： a. client带着“绝密级文件”需要跟神秘的service进行会晤
b. client只知道service名字，但不知其人
c. service压根就不知道有client会找她
后台策划1： 如下图
剧场开幕： 基于以上剧本开演，
a. 由于业务发展client需要开展（调用）某项技能xx（方法）
b. 而这项技能掌握在server这种明星的手上
c. 由client（这种平民）直接要接触到server，显得太为不可能，那怎么拿到该项技能呢?
d. 代理，中间代理（就像租房中介）ta负责转接“上与下（地位悬殊）”以及“租客与房东”此类关系的各种需求
e. proxy这里指的虚拟代理，真实代理还是binder负责
f. binder 在kernel 空间里为每一个进程开辟了一块用来做“黑交易(数据交互)”的内存区（存放client 与 server 进程处理的数据）
智能的binder 为了提高“交易效率与数量”实现了一套机制，不仅为每个进程创建一块内存区，
此外 还“专门开辟了一块共享内存区用来存放处理完数据（以用来减少从kernel复制数据到用户空间）” 见下面粉色（粉色粉色的）的图
g. binder 对client来说， 将请求打包成binder特有格式“paracel”传输到 server
binder 对server来说，将client给到的请求进行处理后，把结果包装到paracel 送到binder 进行发货
i. client 可以选择两种方式来等待server处理结果： 阻塞（同步）一直专心致的等啊等，非阻塞（异步）提出了要求后，就不管了(跑了去干啥啥了)
h. 以上是每一次client 通过 binder call method细节。
其实可总结为(“换做一种好理解的方式”)，client通过binder 成功地获取server对象实例的代理后，在本地任何操作就像是server亲自发出指令一样。
（这也是所谓的代理模式.... 姑且这么不恰当理解&诠释），不服的（不服的来打架啊.....）
后台策划2：
剧场开演戏2： 基于策划2开演
导演不满意，还要继续BB.....
a. 例如client想要做一个“人生保健服务”但又不知道去哪里找店，于是打开手机输入字段“人生保健服务”，过了几秒手机端就显示了“周围”（系统所具备的服务）
b. 这里的ServicesManager将查询结果(指向服务对象的类指针)返回给Client，
c. Client 拿到“地址”踹紧口袋立马打了一个滴滴屁颠颠的去店里做保健(向服务端call method，以期等待得到特定数据)
d. Client怎么找到服务的呢？ 原因是server早已在ServiceManager里面注册自己的门店，以等待顾客上门消费
e. 上面的一切都是在Binder地盘上完成交易，无奈他是老大，提供了交易平台(否则，你以为随随便便就能找到保健店吗，天真 ......)
剧终谢幕，采访幕后者“Binder”
在以上交易完成后，请问
a. 如何做到做好对接client 与server 的数据交互（通信传输）？
b. 在系统里面面对多个client 有请求数据时，如何做到一一不落响应每个客户的请求？
c. binder挂掉了怎么办?
以下统一回复： 谢谢 。
BpBinder对象：
a. 客户端通过它（IBinder）将数据请求传达到Server端
BpBinder::transact(code ,Paracel&data,Paracel*reply, flags )
b. 紧接着IPCThreadState::transact(handle , code , Parcel &data , Paracel *reply , flags )收到命令立即将数据
装入mOut变量里 （viawriteTransactionData(BC_TRANSACTION,flags , handle , code , data , NULL)）
c. 再通过waitForResponse(reply) 把mOut的数据通过ioctl发送给 binder驱动 , 并得到 驱动返回处理数据. // 这里可设置等待方式(TF_ONE_WAY同步)
d. binder 只有一个文件描述符, 系统里多客户进程同时执行远程调用，并在ioctl上等待 处理结果， Android 如何保证其处理返回的数据能正确的交到正确的进程呢？
这就是核心： "Android 在binder驱动里记录每次binder调用信息（包含线程ID），这样根据ID可以知道将对应的数据交给那个等待线程，唤醒该进程来读取缓冲区数据"