用最通俗的方式来理解Android Binder

             角色： client 、 service 、 serviceManager 、Binder驱动

                                    场景： 前三出演在用户空间，后者在内核空间作为幕后

                                    剧本   a. client带着“绝密级文件”需要跟神秘的service进行会晤

                                               b. client只知道service名字，但不知其人

                                               c. service压根就不知道有client会找她 

      后台策划1 ： 如下图 

 剧场开幕： 基于以上剧本开演，

                                                 

         a. 由于业务发展client需要开展（调用）某项技能xx（方法）

         b. 而这项技能掌握在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变量里 （via   writeTransactionData( 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可以知道将对应的数据交给那个等待线程，唤醒该进程来读取缓冲区数据"

referto 深入剖析Android5.0