binder学习

C++层

我们开发时所见到的Binder是Android系统提供给我们的java接口，java层的Binder对象只是Android对底层Binder的一个封装，提供给上层开发人员使用，真正的Binder其实隐藏在系统底层，默默的替我们进行着跨进程通信。

Java层的服务端Binder对象在C++层对应的对象为BBinder，而客户端拿到的BinderProxy对象对应的则为BpBinder，BBindder和BpBinder都继承自IBinder，上层Binder和BinderProxy之间的通信其实是BBinder和BinderProxy之间的通信。

Binder的核心是Binder Driver，即Binder驱动，虽然各个进程不能共享自己的内存空间，但是系统的内核空间是共享的，每个进程都可以访问，而Binder Driver即存在于内核空间，BBinder和BpBinder都是通过它来通信的，所以可以把Binder驱动当作是BBinder和BpBinder之间的一座桥梁。当然BBinder和BpBinder也不是直接和Binder驱动打交道，它们中间还隔着一个IPCThreadState。每一个进程都有一个ProcessState对象，它负责打开Binder驱动，这样该进程中的所有线程都可以通过Binder驱动通信，而每个线程都会有一个IPCThreadState对象，它才是真正读写Binder驱动的主角，它通过talkWithDriver()和驱动打交道，将IPC数据写入驱动中。

Java-->C++对象转换

回到我们上面的Demo，客户端连接成功后拿到了BinderProxy对象，那么这个服务端的Binder对象是如何转为BinderPrxoy的呢？这点我们要看bindService的源码，bindService流程很长，感兴趣的读者可以自己去看后者直接看老罗的分析，我这里直接告诉读者大致过程：

1.客户端请求bindService，先会请求ActivityManagerService;

2.ActvityManagerService再去找到对应的Service，让Service所在进程创建并启动Service;

3.Service调用AMS.publishService()将Binder对象传递给AMS;

4.AMS拿到的Binder对象同样为BinderProxy对象，然后调用 c.conn.connected(r.name, service)方法，将BinderProxy对象传递给客户端。

这里要知道的是，AMS也是处在一个单独的进程中，所以Binder对象不是直接返回给AMS，AMS也不是直接返回给客户端的，而是经过了Binder驱动。服务端Service将Binder对象传递给AMS时，会调用AMS在服务端的代理对象ActivityManagerProxy.publishService()方法，准确的说，Service端在此时成了AMS的客户端。

public void publishService(IBinder token,
        Intent intent, IBinder service) throws RemoteException {
    Parcel data = Parcel.obtain();
    Parcel reply = Parcel.obtain();
    data.writeInterfaceToken(IActivityManager.descriptor);
    data.writeStrongBinder(token);
    intent.writeToParcel(data, 0);
    data.writeStrongBinder(service);
    mRemote.transact(PUBLISH_SERVICE_TRANSACTION, data, reply, 0);
    reply.readException();
    data.recycle();
    reply.recycle();
}

该方法中通过Parcel.writeStrongBinder()，将服务端的Binder对象转化成C++中的flat_binder_object对象，并将Binder对象的地址赋值给flat_binder_object对象中的cookie。

struct flat_binder_object {
      unsigned long type;
      unsigned long flags;
      union {
              void *binder; /* local object */
              signed long handle; /* remote object */
      };
      void *cookie;
};

flat_binder_object对象最终被包装在了data中，然后通过mRemote.transact(),将data数据传送到IPCThreadState, IPCThreadState再次将data包装成binder_transaction_data，并调用talkWithDriver(),将包装好的数据传递给Binder驱动。

Binder驱动收到数据后，并不会急着将数据传给AMS，因为传送的数据中有flat_binder_object，所以它会查询flat_binder_object对应的Binder对象在驱动中是否有Binder节点，如果没有，则会利用flat_binder_object中的cookie值(指向BBinder)创建一个Binder节点，并为该节点生成一个索引值，将索引值赋给flat_binder_object的handle。

然后AMS就可以取数据了，AMS同样有一个IPCThreadState对象，Binder驱动将数据传递给该对象，接收端拿到了数据后，会调用Parcel.readStrongBinder()，这在java层是一个jni方法，该方法会先调用Native层的readStrongBinder()，利用flat_binder_object中的handle值创建BpBinder对象，然后该Native方法返回BpBinder的指针，jni方法再根据BpBinder指针创建java层的BinderProxy对象并返回给java层。至此BpBinder和BinderProxy对象都已经创建完毕。

BpBinder与BBinder的通信

上面我们已经拿到了BpBinder，那BpBinder又将如何与BBinder通信呢？这里不得不提一个重要的变量：handle。还记得在创建BpBiner的时候，需要传入flat_binder_object的handle吗，而这个handle是Binder节点在驱动中的索引，即位置。这样当BpBinder通过transact()调用BBinder时，Binder驱动就可以根据BpBinder提供的handle值找到Binder在驱动中的节点，Binder节点保存了BBinder的地址，从而找到了BBinder，实现对BBinder的调用。

系统服务的注册

上面的例子展示的匿名Binder的通信，为什么说是匿名，因为Binder对象并没有在ContextManager中实名注册。

ContextManager又是什么？它是系统服务的管理者，它在java层和C++层的代理对象都为ServiceManager，系统服务可以通过ServiceManager.addService()将自己实名注册到ContextManager中。为什么要实名注册？如果不采用实名的方法，系统服务那么多，你难道一个个的去记得它的handle？

ServiceManager.addService()会将服务的Binder对象传到Binder Driver，Binder Driver为其生成Binder节点后，ContextManager就会将服务的实名和其Binder节点的索引handle保存到自身。当客户端需要找一个系统服务时，只需将服务名ServiceManager.getService()，ServiceManager就可以找到服务的索引handle，并创建对应的BpBinder对象，从而建立通信。比如java层的ActivityManagerService就是一个Binder类，我们就可以通过ServiceManager.getService("activity")，拿到它的代理对象，从而进行Activity生命周期的调度。

上面说到ServiceManager是ContextManager的代理，因为ContextManager本身也就是一个服务，服务端和客户端想调用它的addService或getService时，也必须通过ServiceManager来跨进程。可是我该怎么拿到这个代理呢？我总不能调用它的getService来获取它自己吧。Binder这一点设计的很奇妙，ContextManager在BinderDriver中的节点索引为0，谁让它是老大呢。这样大家都知道了，我想调用ContextManger，直接根据handle＝0就可以生成它的代理对象BpBinder了，从而创建代理对象ServiceManager。

总结

系统中每个app和系统服务都活在自己的进程中，无法访问彼此的内存空间，正是因为相互通信的强烈需求，从而诞生了Binder。Binder驱动就像所有进程共同的地盘，系统服务可以这里留下自己的地址，而客户端可以可以根据这些地址找到对应的服务，相互通信，从而千里姻缘一线牵，百年恩爱双心结。

aidl文件编译后的文件结构

客户端使用asInterface进程判断

判断是本地进程还有remote进程

若是远程的

使用

mRemote .transact ( Stub . TRANSACTION_helo , _data , _reply ,  0 ) ;

进入Binder.java

调用onTransact