干货：彻底理解ANDROID BINDER通信架构（上）

xman

　　一. 引言
　　1.1 Binder架构的思考
　　Android内核是基于Linux系统， 而Linux现存多种进程间IPC方式:管道， 消息队列， 共享内存， 套接字， 信号量， 信号.  为什么Android非要用Binder来进行进程间通信呢?
　　在说到Binder架构之前， 先简单说说大家熟悉的TCP/IP的五层通信体系结构:

　　应用层: 直接为用户提供服务;
　　传输层: 传输的是报文(TCP数据)或者用户数据报(UDP数据)
　　网络层: 传输的是包(Packet)， 例如路由器
　　数据链路层: 传输的是帧(Frame)， 例如以太网交换机
　　物理层: 相邻节点间传输bit， 例如集线器，双绞线等
　　这是经典的五层TPC/IP协议体系， 这样分层设计的思想， 让每一个子问题都设计成一个独立的协议， 这协议的设计/分析/实现/测试都变得更加简单:
　　层与层具有独立性， 例如应用层可以使用传输层提供的功能而无需知晓其实现原理;
　　设计灵活， 层与层之间都定义好接口， 即便层内方法发生变化，只有接口不变， 对这个系统便毫无影响;
　　结构的解耦合， 让每一层可以用更适合的技术方案， 更合适的语言;
　　方便维护， 可分层调试和定位问题;
　　Binder架构也是采用分层架构设计， 每一层都有其不同的功能:

　　Java应用层: 对于上层应用通过调用AMP.startService，  完全可以不用关心底层，经过层层调用，最终必然会调用到AMS.startService.
　　Java IPC层: Binder通信是采用C/S架构， Android系统的基础架构便已设计好Binder在Java  framework层的Binder客户类BinderProxy和服务类Binder;
　　Native IPC层: 对于Native层，如果需要直接使用Binder(比如media相关)，  则可以直接使用BpBinder和BBinder(当然这里还有JavaBBinder)即可， 对于上一层Java IPC的通信也是基于这个层面.
　　Kernel物理层: 这里是Binder Driver，  前面3层都跑在用户空间，对于用户空间的内存资源是不共享的，每个Android的进程只能运行在自己进程所拥有的虚拟地址空间， 而内核空间却是可共享的.  真正通信的核心环节还是在Binder Driver.
　　1.2 分析起点
　　Binder在Android系统使用颇为广泛， 几乎是整个Android架构的顶梁柱， Binder系统如此庞大， 那么这里需要寻求一个出发点来穿针引线，  一窥视Binder全貌. 那么本文将从全新的视角，以startService流程分析  为例子来说说Binder所其作用.首先在发起方进程调用AMP.startService，经过binder驱动，最终调用系统进程AMS.startService，如下图:

　　AMP和AMN都是实现了IActivityManager接口，AMS继承于AMN. 其中AMP作为Binder的客户端，运行在各个app所在进程，  AMN(或AMS)运行在系统进程system_server.
　　1.3 Binder IPC原理
　　Binder通信采用C/S架构，从组件视角来说，包含Client、Server、ServiceManager以及binder驱动，其中ServiceManager用于管理系统中的各种服务。下面说说startService过程所涉及的Binder对象的架构图：

　　可以看出无论是注册服务和获取服务的过程都需要ServiceManager，需要注意的是此处的Service  Manager是指Native层的ServiceManager(C++)，并非指framework层的ServiceManager(Java)。ServiceManager是整个Binder通信机制的大管家，是Android进程间通信机制Binder的守护进程，Client端和Server端通信时都需要先获取Service  Manager接口，才能开始通信服务， 当然查找懂啊目标信息可以缓存起来则不需要每次都向ServiceManager请求。
　　图中Client/Server/ServiceManage之间的相互通信都是基于Binder机制。既然基于Binder机制通信，那么同样也是C/S架构，则图中的3大步骤都有相应的Client端与Server端。
　　注册服务：首先AMS注册到ServiceManager。该过程：AMS所在进程(system_server)是客户端，ServiceManager是服务端。
　　获取服务：Client进程使用AMS前，须先向ServiceManager中获取AMS的代理类AMP。该过程：AMP所在进程(app  process)是客户端，ServiceManager是服务端。
　　使用服务： app进程根据得到的代理类AMP，便可以直接与AMS所在进程交互。该过程：AMP所在进程(app  process)是客户端，AMS所在进程(system_server)是服务端。
　　图中的Client，Server，Service  Manager之间交互都是虚线表示，是由于它们彼此之间不是直接交互的，而是都通过与Binder  Driver进行交互的，从而实现IPC通信方式。其中Binder驱动位于内核空间，Client，Server，Service  Manager位于用户空间。Binder驱动和Service  Manager可以看做是Android平台的基础架构，而Client和Server是Android的应用层.
　　这3大过程每一次都是一个完整的Binder IPC过程， 接下来从源码角度， 仅介绍第3过程使用服务，  即展开AMP.startService是如何调用到AMS.startService的过程.
　　Tips: 如果你只想了解大致过程，并不打算细扣源码， 那么你可以略过通信过程源码分析， 仅看本文第一段落和最后段落也能对Binder所有理解.
　　二. 通信过程
　　2.1 AMP.startService
　　[ ActivityManagerNative.java ::ActivityManagerProxy]

　　主要功能:
　　获取或创建两个Parcel对象，data用于发送数据，reply用于接收应答数据.
　　将startService相关数据都封装到Parcel对象data， 其中descriptor =  "android.app.IActivityManager";
　　通过Binder传递数据，并将应答消息写入reply;
　　读取reply应答消息的异常情况和组件对象;
　　2.2 Parcel.obtain
　　[ Parcel.java]

　　sOwnedPool是一个大小为6，存放着parcel对象的缓存池，这样设计的目标是用于节省每次都创建Parcel对象的开销。obtain()方法的作用：
　　先尝试从缓存池sOwnedPool中查询是否存在缓存Parcel对象，当存在则直接返回该对象;
　　如果没有可用的Parcel对象，则直接创建Parcel对象。
　　2.2.1 new Parcel
　　[ Parcel.java]

　　nativeCreate这是native方法，经过JNI进入native层， 调用android_os_Parcel_create()方法.
　　2.2.2 android_os_Parcel_create
　　[ android_os_Parcel.cpp]

　　创建C++层的Parcel对象， 该对象指针强制转换为long型， 并保存到Java层的mNativePtr对象.  创建完Parcel对象利用Parcel对象写数据. 接下来以writeString为例.
　　2.2.3 Parcel.recycle

　　将不再使用的Parcel对象放入缓存池，可回收重复利用，当缓存池已满则不再加入缓存池。这里有两个Parcel线程池，mOwnsNativeParcelObject变量来决定:
　　mOwnsNativeParcelObject=true， 即调用不带参数obtain()方法获取的对象，  回收时会放入sOwnedPool对象池;
　　mOwnsNativeParcelObject=false， 即调用带nativePtr参数的obtain(long)方法获取的对象，  回收时会放入sHolderPool对象池;
　　2.3 writeString
　　[ Parcel.java]

　　2.3.1 nativeWriteString
　　[ android_os_Parcel.cpp]

　　2.3.2 writeString16
　　[ Parcel.cpp]

　　Tips: 除了writeString()，在Parcel.java中大量的native方法，  都是调用android_os_Parcel.cpp相对应的方法， 该方法再调用Parcel.cpp中对应的方法.
　　调用流程: Parcel.java  android_os_Parcel.cpp  Parcel.cpp.

　　2.4 mRemote究竟为何物
　　mRemote的出生，要出先说说ActivityManagerProxy对象(简称AMP)创建说起，  AMP是通过ActivityManagerNative.getDefault()来获取的.
　　2.4.1 AMN.getDefault
　　[ ActivityManagerNative.java]

　　gDefault的数据类型为SingletonIActivityManager， 这是一个单例模式，  接下来看看Singleto.get()的过程
　　2.4.2 gDefault.get

　　首次调用时需要创建，创建完之后保持到mInstance对象，之后可直接使用.
　　2.4.3 gDefault.create

　　文章Binder系列7framework层分析，可知ServiceManager.getService("activity")返回的是指向目标服务AMS的代理对象BinderProxy对象，由该代理对象可以找到目标服务AMS所在进程
　　2.4.4 AMN.asInterface
　　[ ActivityManagerNative.java]

　　此时obj为BinderProxy对象， 记录着远程进程system_server中AMS服务的binder线程的handle.
　　2.4.5 queryLocalInterface
　　[Binder.java]

　　对于Binder IPC的过程中，  同一个进程的调用则会是asInterface()方法返回的便是本地的Binder对象;对于不同进程的调用则会是远程代理对象BinderProxy.
　　2.4.6 创建AMP
　　[ ActivityManagerNative.java :: AMP]

　　可知mRemote便是指向AMS服务的BinderProxy对象。
　　2.5 mRemote.transact
　　[ Binder.java ::BinderProxy]

　　mRemote.transact()方法中的code=START_SERVICE_TRANSACTION，  data保存了descriptor，caller， intent，resolvedType， callingPackage， userId这6项信息。
　　transactNative是native方法，经过jni调用android_os_BinderProxy_transact方法。
　　2.6 android_os_BinderProxy_transact
　　[ android_util_Binder.cpp]

　　gBinderProxyOffsets.mObject中保存的是BpBinder对象，  这是开机时Zygote调用AndroidRuntime::startReg方法来完成jni方法的注册.
　　其中register_android_os_Binder()过程就有一个初始并注册BinderProxy的操作，完成gBinderProxyOffsets的赋值过程.  接下来就进入该方法.
　　2.7 BpBinder.transact
　　[ BpBinder.cpp]

　　IPCThreadState::self()采用单例模式，保证每个线程只有一个实例对象。
　　2.8 IPC.transact
　　[ IPCThreadState.cpp]

　　transact主要过程:
　　先执行writeTransactionData()已向Parcel数据类型的mOut写入数据，此时mIn还没有数据;
　　然后执行waitForResponse()方法，循环执行，直到收到应答消息.  调用talkWithDriver()跟驱动交互，收到应答消息，便会写入mIn， 则根据收到的不同响应吗，执行相应的操作。
　　此处调用waitForResponse根据是否有设置TF_ONE_WAY的标记:
　　当已设置oneway时， 则调用waitForResponse(NULL， NULL);
　　当未设置oneway时， 则调用waitForResponse(reply) 或 waitForResponse(fakeReply)
　　2.9 IPC.writeTransactionData
　　[ IPCThreadState.cpp]