该文章是一个系列文章，是本人在Android开发的漫漫长途上的一点感想和记录，我会尽量按照先易后难的顺序进行编写该系列。该系列引用了《Android开发艺术探索》以及《深入理解Android 卷Ⅰ，Ⅱ，Ⅲ》中的相关知识，另外也借鉴了其他的优质博客，在此向各位大神表示感谢，膜拜！！！另外，本系列文章知识可能需要有一定Android开发基础和项目经验的同学才能更好理解，也就是说该系列文章面向的是Android中高级开发工程师。

我们在上一篇中比较详尽的介绍了Android的消息机制，不过有一些内容我们在不理解Android Binder的话是无法讲解清楚的。对于初学Android的朋友而言，最难却又最想掌握的恐怕就是Binder机制了，因为Android系统基本上可以看作是一个基于Binder通信的C/S架构。 Binder就像网络一样，把系统的各个部分连接在了一起，因此它是非常重要的。我们下面会Android Binder机制进行从上到下从易到难的分层次讲解，从而既能让初学者对Binder有一定认识，也能让有一定Android基础的人获得收获。
注：下文中的源码均出自android-6.0.0_r5

对于初学者来说，深入Android Binder机制是非常不明智的。Android Binder机制大都涉及Java层、Native层、驱动层这三三个方面，对于初学者来说想啃这三块硬骨头很容易磕着牙。我们这这一节概述从以下几个方面让你从比较宏观的角度理解Android Binder。

在该系列博客中的第一章我们就说起了Android进程相关问题，Android故意弱化了进程的概念，而用相对容易理解的四大组件。可是我们在稍微深入Android的时候，那么进程是绕不过的。默认情况下，同一个应用程序中的所有组件运行在同一个进程中，而且绝大多数的应用程序也都是这样的。这个默认进程是用这个应用的包名来命名的。

我们在运行App的时候经常需要使用一些系统服务，比如剪切板服务，而剪切板服务是运行在SystemServer进程中的。那我们的App是怎么使用剪切板服务的呢，我们都知道进程是相互独立的，静态变量等等都无法共用。这就涉及到进程间的通信了，即IPC。我们都知道Android是基于Linux内核的，那我们简单介绍下Linux下的几种IPC机制。

管道是由内核管理的一个缓冲区，相当于我们放入内存中的一个纸条。管道的一端连接一个进程的输出。这个进程会向管道中放入信息。管道的另一端连接一个进程的输入，这个进程取出被放入管道的信息。

  • 管道是半双工的，数据只能向一个方向流动；需要双方通信时，需要建立起两个管道
  • 只能用于父子进程或者兄弟进程之间（具有亲缘关系的进程）。比如fork或exec创建的新进程，在使用exec创建新进程时，需要将管道的文件描述符作为参数传递给exec创建的新进程。当父进程与使用fork创建的子进程直接通信时，发送数据的进程关闭读端，接受数据的进程关闭写端。
  • 管道只能在本地计算机中使用，而不可用于网络间的通信。

命名管道是一种特殊类型的文件，它在系统中以文件形式存在。这样克服了管道的弊端，他可以允许没有亲缘关系的进程间通信。

共享内存是在多个进程之间共享内存区域的一种进程间的通信方式，由IPC为进程创建的一个特殊地址范围，它将出现在该进程的地址空间中。其他进程可以将同一段共享内存连接到自己的地址空间中。所有进程都可以访问共享内存中的地址，如果一个进程向共享内存中写入了数据，所做的改动将立刻被其他进程看到。

  • 共享内存是IPC最快捷的方式，共享内存方式直接将某段内存段进行映射，多个进程间的共享内存是同一块的物理空间，仅仅映射到各进程的地址不同而已，因此不需要进行复制，可以直接使用此段空间。

  • 共享内存本身并没有同步机制，需要程序员自己控制。

    内存映射是由一个文件到一块内存的映射，在此之后进程操作文件，就像操作进程空间里的内存地址一样了。

    套接字机制不但可以单机的不同进程通信，而且使得跨网机器间进程可以通信。
    套接字的创建和使用与管道是有区别的，套接字明确地将客户端与服务器区分开来，可以实现多个客户端连到同一服务器。

作为Android系统下的一种IPC机制，其本质上与上面罗列出的IPC机制并无本质上的不同，都是作为进程间通信的一种手段。并且在Android系统中也不是只存在Binder这一种进程间通信的方式，在有些地方也使用了Socket。既然Linux已经提供了众多IPC机制，那么Android 为何还要使用Binder作为主要的进程间通信的方式呢，那么当然有他的优点存在。

  • 采用C/S的通信模式。而在linux通信机制中，目前只有socket支持C/S的通信模式，但socket有其劣势，具体参看第二条。
  • 有更好的传输性能。对比于Linux的通信机制，socket：是一个通用接口，导致其传输效率低，开销大；管道和消息队列：因为采用存储转发方式，所以至少需要拷贝2次数据，效率低；共享内存：虽然在传输时没有拷贝数据，但其控制机制复杂（比如跨进程通信时，需获取对方进程的pid，得多种机制协同操作）。
  • 安全性更高。Linux的IPC机制在本身的实现中，并没有安全措施，得依赖上层协议来进行安全控制。而Binder机制的UID/PID是由Binder机制本身在内核空间添加身份标识，安全性高；并且Binder可以建立私有通道，这是linux的通信机制所无法实现的（Linux访问的接入点是开放的）。
  • 对用户来说，通过binder屏蔽了client的调用server的隔阂，client端函数的名字、参数和返回值和server的方法一模一样，对用户来说犹如就在本地（也可以做得不一样），这样的体验或许其他ipc方式也可以实现，但binder出生那天就是为此而生。

Java层Binder的功能，依赖于Native层Binder来实现，可以认为Java层Binder架构是Native层Binder架构的一个镜像。但是这并不影响我们分析Android Java层Binder的功能。我们用一个例子来说明这个过程。

我们在第一篇中就讲解了SystemServer这个进程，这个进程和zygote进程一起撑起了Android 世界，他们之中有一个崩溃，Android世界就会砰然倒塌。Android许多的重要的系统服务如AMS、PMS等都运行在SystemServer进程中。但是还有一个比较重要的进程ServiceManager进程（简称SM）跟zygote是兄弟进程。这个进程的作用是用来统一管理服务，如AMS。它们之间的关系如下。

我们的AMS需要向SM进程中注册信息，其他进程如果想使用AMS，那么先和ServiceManager进程进行通信查询，接着再和AMS所在SystemServer进程通信。这部分关系图如下

我们这里仅上图分析①②③中的一条道路，我们来分析③，即我们的应用进程（Client）如何与服务进程（Server）交互。

Java层的Binder,我们来看涉及的类的结构图

[IBinder.java]

  1. public interface IBinder {
  2.     //交互函数
  3.     public boolean transact(int code, Parcel data, Parcel reply, int flags)
  4.         throws RemoteException;
  5. }

我们接着来看Binder和BinderProxy 他们都声明在Binder.java中

[Binder.java]

  1. /**
  2.     Binder类
  3.     */
  4. public class Binder implements IBinder {
  5.     public final boolean transact(int code, Parcel data, Parcel reply,
  6.                 int flags) throws RemoteException {
  7.         ......
  8.         //这里调用了onTransact函数进行处理，一般情况下这个函数都会被它的子类重写
  9.         boolean r = onTransact(code, data, reply, flags);
  10.         if (reply != null) {
  11.             reply.setDataPosition(0);
  12.         }
  13.         return r;
  14.     }
  15. }
  18. /**
  19.     BinderProxy类
  20.     */
  21. final class BinderProxy implements IBinder {
  22.     public boolean transact(int code, Parcel data, Parcel reply, int flags) throws RemoteException {
  23.         //直接以JNI的方式调用Native层的transact函数
  24.         return transactNative(code, data, reply, flags);
  25.     }
  27.     
  28.     public native boolean transactNative(int code, Parcel data, Parcel reply,
  29.             int flags) throws RemoteException;
  30. }

通用的IPC流程如下

现在假设下面一个场景，我们的应用进程即我们的App想要使用ActivityManagerService的startActivity函数(这种场景肯定有的，当我们拿到手机的时候，手机已经预装了许多App,其中Launcher App(桌面管理App)是在Android系统启动完成之后启动的第一个App，我们安装好一个应用后，点击应用图标即发出Intent，想要启动另一个App中的Activity，我们在AndroidManifest.xml中注册了Main Activity)。Launcher App所在的进程要与AMS所在的进程SystemServer进程交互。
我们来看这个例子。按照上面的通用流程我们猜测Launcher进程与SystemServer进程交互过程也如上图所示，那么按照这个思路我们来看。分为3点：

这一部分是我们的上图中的test函数所声明的类或者接口，我们的Client端代理和Server端服务都要实现这个函数。果然有
[IActivityManager.java]

  1. public interface IActivityManager extends IInterface {
  2.     public int startActivity(IApplicationThread caller, String callingPackage, Intent intent,
  3.             String resolvedType, IBinder resultTo, String resultWho, int requestCode, int flags,
  4.             ProfilerInfo profilerInfo, Bundle options) throws RemoteException;
  5.     ......
  6. }

这里声明了我们将要调用的业务函数startActivity，那么接着第二点

ActivityManagerProxy是在ActivityManagerNative.java中声明的内部类

  1. class ActivityManagerProxy implements IActivityManager
  2. {
  3.     public ActivityManagerProxy(IBinder remote)
  4.     {
  5.         mRemote = remote;
  6.     }
  8.     public IBinder asBinder()
  9.     {
  10.         return mRemote;
  11.     }
  13.     public int startActivity(IApplicationThread caller, String callingPackage, Intent intent,
  14.             String resolvedType, IBinder resultTo, String resultWho, int requestCode,
  15.             int startFlags, ProfilerInfo profilerInfo, Bundle options) throws RemoteException {
  16.         Parcel data = Parcel.obtain();
  17.         Parcel reply = Parcel.obtain();
  18.         data.writeInterfaceToken(IActivityManager.descriptor);
  19.         data.writeStrongBinder(caller != null ? caller.asBinder() : null);
  20.         data.writeString(callingPackage);
  21.         intent.writeToParcel(data, 0);
  22.         data.writeString(resolvedType);
  23.         data.writeStrongBinder(resultTo);
  24.         data.writeString(resultWho);
  25.         data.writeInt(requestCode);
  26.         data.writeInt(startFlags);
  27.         if (profilerInfo != null) {
  28.             data.writeInt(1);
  29.             profilerInfo.writeToParcel(data, Parcelable.PARCELABLE_WRITE_RETURN_VALUE);
  30.         } else {
  31.             data.writeInt(0);
  32.         }
  33.         if (options != null) {
  34.             data.writeInt(1);
  35.             options.writeToParcel(data, 0);
  36.         } else {
  37.             data.writeInt(0);
  38.         }
  40.         //看这里果然是通过mRemote.transact函数，这里的mRemote是BinderProxy类，关于这一点我们在Native层分析的时候再给出
  41.         mRemote.transact(START_ACTIVITY_TRANSACTION, data, reply, 0);
  42.         reply.readException();
  43.         int result = reply.readInt();
  44.         reply.recycle();
  45.         data.recycle();
  46.         return result;
  47.     }
  48.     ......
  49. }

ActivityManagerNative是继承于Binder的抽象类，并重写了onTransact方法

  1. public abstract class ActivityManagerNative extends Binder implements IActivityManager{
  2.      @Override
  3.     public boolean onTransact(int code, Parcel data, Parcel reply, int flags)
  4.             throws RemoteException {
  5.         //根据code处理相应的业务逻辑，我们这里是START_ACTIVITY_TRANSACTION
  6.         switch (code) {
  7.         case START_ACTIVITY_TRANSACTION:
  8.         {
  9.             data.enforceInterface(IActivityManager.descriptor);
  10.             IBinder b = data.readStrongBinder();
  11.             IApplicationThread app = ApplicationThreadNative.asInterface(b);
  12.             String callingPackage = data.readString();
  13.             Intent intent = Intent.CREATOR.createFromParcel(data);
  14.             String resolvedType = data.readString();
  15.             IBinder resultTo = data.readStrongBinder();
  16.             String resultWho = data.readString();
  17.             int requestCode = data.readInt();
  18.             int startFlags = data.readInt();
  19.             ProfilerInfo profilerInfo = data.readInt() != 0
  20.                     ? ProfilerInfo.CREATOR.createFromParcel(data) : null;
  21.             Bundle options = data.readInt() != 0
  22.                     ? Bundle.CREATOR.createFromParcel(data) : null;
  23.             
  24.             int result = startActivity(app, callingPackage, intent, resolvedType,
  25.                     resultTo, resultWho, requestCode, startFlags, profilerInfo, options);
  26.             reply.writeNoException();
  27.             reply.writeInt(result);
  28.             return true;
  29.         }
  30.     }
  31. }

既然ActivityManagerNative是个抽象类，那么谁真正实现了呢


[ActivityManagerService.java]

  1. public final class ActivityManagerService extends ActivityManagerNative
  2.         implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
  3.     //重写了onTransact函数
  4.     @Override
  5.     public boolean onTransact(int code, Parcel data, Parcel reply, int flags)
  6.             throws RemoteException {
  7.         ......
  8.         
  9.         try {
  10.             //调用父类即ActivityManagerNative的onTransact函数
  11.             return super.onTransact(code, data, reply, flags);
  12.         } catch (RuntimeException e) {
  13.            
  14.             throw e;
  15.         }
  16.     }
  17. }

Launcher进程与SystemServer进程交互过程如下

关于Java层的Binder机制，我们只需要理解以BinderProxy代表的代理端和Binder代表的服务端的概念即可，例如我们本例中的AMS，AMS是运行在SystemServer进程中的服务端，它间接继承于Binder，在得到相关请求后，会调用AMS重写的onTransact函数进行逻辑处理。那么这个请求就是是AMS的客户端ActivityManagerProxy通过Binder的方式发给它的，ActivityManagerProxy发送这个请求的方式，是通过调用其内部的成员变量mRemote,这个mRemote其实是BinderProxy的对象，然后BinderProxy通过JNI调用Native层对应函数，最终通过Binder驱动达到与SystemServer交互的目的。

那么还遗留下以下几个问题：

1. 服务器端的代理怎么获得的

2. 位于代理类中的mRemote这个变量

要想理解好上面的个问题，我们必须向Native层进军。

我们依然以AMS分析，我们先来想一下我们在用户进程中即我们的App中想使用AMS或者其他剪切板之类的系统服务函数了怎么办？？按照上面的分析我们要获得AMS的代理ActivityManagerProxy

[ActivityManagerNative.java]

  1. //这里我们的App进程从SM进程得到AMS服务对应的客户端代理BinderProxy
  2. IBinder b = ServiceManager.getService(Context.ACTIVITY_SERVICE);
  3. //以BinderProxy为参数得到我们ActivityManagerProxy，并把BinderProxy对象存储在mRemote变量中
  4. IActivityManager am = asInterface(b);
  5.        
  6. return am;

到这里我们就有以下问题，本小节分析1,2

1. 既然可以通过SM获得对应的客户端代理，那么AMS必定已经注册在SM中了，那么怎么注册的呢？

2. AMS代理是如何获得的？

3. AMS代理是如何与Binder通信的？

我们来一一分析，在分析问题之前我们先做一个假设，这个假设至关重要，那就是不管我们的SystemServer进程与SM进程交互也好还是我们的App进程与SM进程也好，SM的代理已经事先创建完毕，即不管我们在SystemServer端还是App端，在与SM进程交互的时候不用考虑代理怎么获得的。为什么会有如此假设，因为我自己深受其害，由于上述三个过程均是通过Binder，很容易陷入思维混乱。

我们SystemServer进程中的AMS通过”Socket”与SM进程交互，并把自己注册在SM中
SystemServer创建出ActivityManagerService后，最终将调用其setSystemProcess方法：

[SystemServer.java]

  1. public void setSystemProcess() {
  2.     try {
  3.         //注册服务，第二个参数为this，这里通过“socket”与SM交互
  4.         ServiceManager.addService(Context.ACTIVITY_SERVICE, this, true);
  5.         ..........
  6.     } catch (PackageManager.NameNotFoundException e) {
  7.         ........
  8.     }
  9. }

上面的请求最终是通过SM服务代理发送的（）

[ServiceManagerNative.java]

  1. public void addService(String name, IBinder service, boolean allowIsolated) 
  2.         throws RemoteException {
  3.     //将数据打包写入Parcel对象
  4.     Parcel data = Parcel.obtain();
  5.     Parcel reply = Parcel.obtain();
  6.     data.writeInterfaceToken(IServiceManager.descriptor);
  7.     data.writeString(name);
  8.     //注意这个地方，后文分析，此时的service为ActivityManagerService
  9.     data.writeStrongBinder(service);
  10.     data.writeInt(allowIsolated ? 1 : 0);
  11.     //调用BindProxy的transact函数
  12.     mRemote.transact(ADD_SERVICE_TRANSACTION, data, reply, 0);
  13.     reply.recycle();
  14.     data.recycle();
  15. }

上面的过程已经分析过了， 这里我们主要看一下哪个对应的native层的transact函数

[android_ util_Binder.cpp]

  1. static jboolean android_os_BinderProxy_transact(JNIEnv* env, jobject obj,
  2.         jint code, jobject dataObj, jobject replyObj, jint flags)
  3. {
  4.     ........
  5.     //将java对象转化为native对象
  6.     Parcel* data = parcelForJavaObject(env, dataObj);
  7.     .........
  8.     Parcel* reply = parcelForJavaObject(env, replyObj);
  9.     ........
  10.     //得到native层的BpBinder
  11.     IBinder* target = (IBinder*)
  12.         env->GetLongField(obj, gBinderProxyOffsets.mObject);
  13.     ........
  14.     //通过BpBinder利用IPCThreadState，将请求通过Binder驱动发送给SM进程
  15.     status_t err = target->transact(code, *data, reply, flags);
  16.     ........
  17. }

SM进程收到信息后便处理这个消息（这个说法并不准确，准确的说法是，SM进程中主线程一直在与binder设备交互，想必读者也猜到了for(;;)）,有消息时便通过预先定义好的函数进行处理

[service_manager.c]

  1. switch(txn->code) {
  3.     case SVC_MGR_ADD_SERVICE:
  4.         s = bio_get_string16(msg, &len);
  5.         if (s == NULL) {
  6.             return -1;
  7.         }
  8.         handle = bio_get_ref(msg);
  9.         allow_isolated = bio_get_uint32(msg) ? 1 : 0;
  10.         //do_add_service
  11.         if (do_add_service(bs, s, len, handle, txn->sender_euid,
  12.             allow_isolated, txn->sender_pid))
  13.             return -1;
  14.     break;
  15. }
  17. int do_add_service(struct binder_state *bs,
  18.                    const uint16_t *s, size_t len,
  19.                    uint32_t handle, uid_t uid, int allow_isolated,
  20.                    pid_t spid)
  21. {
  22.     //结构体si,用来存储服务信息
  23.     struct svcinfo *si;
  25.     //判断服务有没有权限注册，并不是所有的服务都能注册
  26.     if (!svc_can_register(s, len, spid)) {
  27.         return -1;
  28.     }
  29.     
  30.     //查询服务有没有注册过
  31.     si = find_svc(s, len);
  32.     
  33.     if (si) {//已经注册过
  34.         if (si->handle) {
  35.             ALOGE("add_service('%s',%x) uid=%d - ALREADY REGISTERED, OVERRIDE\n",
  36.                  str8(s, len), handle, uid);
  37.             svcinfo_death(bs, si);
  38.         }
  39.         si->handle = handle;
  40.     } else {//还没有注册过，我们进入这个分支
  41.         si = malloc(sizeof(*si) + (len + 1) * sizeof(uint16_t));
  42.         if (!si) {
  43.             ALOGE("add_service('%s',%x) uid=%d - OUT OF MEMORY\n",
  44.                  str8(s, len), handle, uid);
  45.             return -1;
  46.         }
  47.         //保存一些handle等信息
  48.         si->handle = handle;
  49.         si->len = len;
  50.         memcpy(si->name, s, (len + 1) * sizeof(uint16_t));
  51.         si->name[len] = '\0';
  52.         si->death.func = (void*) svcinfo_death;
  53.         si->death.ptr = si;
  54.         si->allow_isolated = allow_isolated;
  55.         si->next = svclist;
  56.         svclist = si;
  57.     }
  59.     binder_acquire(bs, handle);
  60.     binder_link_to_death(bs, handle, &si->death);
  61.     return 0;
  62. }

看到这里SM貌似只保留了一些AMS的信息而已，实际上并不只是如此，我们来看一下上面的保留问题

[Parcel.java]

  1. data.writeStrongBinder(service);
  3. public final void writeStrongBinder(IBinder val) {
  4.     //调用了native函数
  5.     nativeWriteStrongBinder(mNativePtr, val);
  6. }

跟进[android_os_Parcel.cpp]

  1. static void android_os_Parcel_writeStrongBinder(JNIEnv* env, jclass clazz, jlong nativePtr, jobject object)
  2. {
  3.     Parcel* parcel = reinterpret_cast<Parcel*>(nativePtr);
  4.     if (parcel != NULL) {
  5.         //native层的parcel
  6.         const status_t err = parcel->writeStrongBinder(ibinderForJavaObject(env, object));
  7.         if (err != NO_ERROR) {
  8.             signalExceptionForError(env, clazz, err);
  9.         }
  10.     }
  11. }
  13. sp<IBinder> ibinderForJavaObject(JNIEnv* env, jobject obj)
  14. {
  15.     if (obj == NULL) return NULL;
  17.     //obj为Binder类
  18.     if (env->IsInstanceOf(obj, gBinderOffsets.mClass)) {
  19.         JavaBBinderHolder* jbh = (JavaBBinderHolder*)
  20.             env->GetLongField(obj, gBinderOffsets.mObject);
  21.         //调用了JavaBBinderHolder的get方法
  22.         return jbh != NULL ? jbh->get(env, obj) : NULL;
  23.     }
  25.     //obj为BinderProxy类
  26.     if (env->IsInstanceOf(obj, gBinderProxyOffsets.mClass)) {
  27.         return (IBinder*)
  28.             env->GetLongField(obj, gBinderProxyOffsets.mObject);
  29.     }
  31.     ALOGW("ibinderForJavaObject: %p is not a Binder object", obj);
  32.     return NULL;
  33. }

跟进[Pacel.cpp]

  1. status_t Parcel::writeStrongBinder(const sp<IBinder>& val)
  2. {
  3.     return flatten_binder(ProcessState::self(), val, this);
  4. }
  6. status_t flatten_binder(const sp<ProcessState>& /*proc*/,
  7. const sp<IBinder>& binder, Parcel* out)
  8. {
  9.     flat_binder_object obj;
  11.     obj.flags = 0x7f | FLAT_BINDER_FLAG_ACCEPTS_FDS;
  12.     if (binder != NULL) {//binder不为空
  13.         IBinder *local = binder->localBinder();//是不是本地binder，本地的意思是同一个进程中的调用
  14.         if (!local) {
  15.             BpBinder *proxy = binder->remoteBinder();
  16.             if (proxy == NULL) {
  17.                 ALOGE("null proxy");
  18.             }
  19.             const int32_t handle = proxy ? proxy->handle() : 0;
  20.             obj.type = BINDER_TYPE_HANDLE;
  21.             obj.binder = 0; /* Don't pass uninitialized stack data to a remote process */
  22.             obj.handle = handle;
  23.             obj.cookie = 0;
  24.         } else {//我们这里明显不是
  25.             obj.type = BINDER_TYPE_BINDER;
  26.             obj.binder = reinterpret_cast<uintptr_t>(local->getWeakRefs());
  27.             obj.cookie = reinterpret_cast<uintptr_t>(local);
  28.         }
  29.     } else {//错误信息
  30.         obj.type = BINDER_TYPE_BINDER;
  31.         obj.binder = 0;
  32.         obj.cookie = 0;
  33.     }
  35.     return finish_flatten_binder(binder, obj, out);
  36. }

通过上面的代码，我们可以看到当一个服务进行注册时，会将Java层的Binder对象和Native层的BBinder关联起来，于是服务端绑定到了Native层的Binder架构。
此外，addService中打包传入的其实不是ActivityManagerService本身，而是对应的JavaBBinder对象。
这里对应的结构如下图所示：

我们上面SystemServer中的AMS已经在SM中准备好了，那我们ServiceManager.getService(Context.ACTIVITY_SERVICE);
一样的过程，我们知道最终会在service_manager.c中处理

  1. switch(txn->code) {
  2.     //这里有个case穿透，，好吧
  3.     case SVC_MGR_GET_SERVICE:
  4.     case SVC_MGR_CHECK_SERVICE:
  5.         s = bio_get_string16(msg, &len);
  6.         if (s == NULL) {
  7.             return -1;
  8.         }
  9.         //查询AMS保存在SM中对应的的那个handle
  10.         handle = do_find_service(bs, s, len, txn->sender_euid, txn->sender_pid);
  11.         if (!handle)
  12.             break;
  13.         bio_put_ref(reply, handle);
  14.         return 0;
  15. }
  16. 把写入数据后的reply返回
  17. bio_put_uint32(reply, 0);

回到我们的调用处
[ServiceManagerNative.java]

  1. public IBinder getService(String name) throws RemoteException {
  2.     Parcel data = Parcel.obtain();
  3.     Parcel reply = Parcel.obtain();
  4.     data.writeInterfaceToken(IServiceManager.descriptor);
  5.     data.writeString(name);
  6.     mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0);
  7.     //看这里readStrongBinder，是不是感觉跟我们上面的writeStrongBinder感觉是一对的
  8.     IBinder binder = reply.readStrongBinder();
  9.     reply.recycle();
  10.     data.recycle();
  11.     return binder;
  12. }

Parcel的readStrongBinder还是个JNI调用

[android_ os_Parcel.cpp]

  1. static jobject android_os_Parcel_readStrongBinder(JNIEnv* env, jclass clazz, jlong nativePtr)
  2. {
  3.     Parcel* parcel = reinterpret_cast<Parcel*>(nativePtr);
  4.     if (parcel != NULL) {
  5.         //这里我们看到了什么，，看函数名字应该是为Binder生成一个java对象吧
  6.         return javaObjectForIBinder(env, parcel->readStrongBinder());
  7.     }
  8.     return NULL;
  9. }

我们先看Pacel的readStrongBinder方法
[Parcel.cpp]

  1. sp<IBinder> Parcel::readStrongBinder() const
  2. {
  3.     sp<IBinder> val;
  4.     //看到这里，还记得writeStrongBinder中的flatten_binder，这里是unflatten_binder
  5.     unflatten_binder(ProcessState::self(), *this, &val);
  6.     return val;
  7. }
  9. status_t unflatten_binder(const sp<ProcessState>& proc,
  10. const Parcel& in, sp<IBinder>* out)
  11. {
  12.     const flat_binder_object* flat = in.readObject(false);
  14.     if (flat) {
  15.         switch (flat->type) {
  16.             case BINDER_TYPE_BINDER:
  17.                 *out = reinterpret_cast<IBinder*>(flat->cookie);
  18.                 return finish_unflatten_binder(NULL, *flat, in);
  19.             case BINDER_TYPE_HANDLE:
  20.                 //到这里我们也清楚了进入这个分支
  21.                 //调用ProcessState的getStrongProxyForHandle函数
  22.                 *out = proc->getStrongProxyForHandle(flat->handle);
  23.                 return finish_unflatten_binder(
  24.                     static_cast<BpBinder*>(out->get()), *flat, in);
  25.         }
  26.     }
  27.     return BAD_TYPE;
  28. }

继续跟进[ProcessState.cpp]

  1. sp<IBinder> ProcessState::getStrongProxyForHandle(int32_t handle)
  2. {
  3.     sp<IBinder> result;
  5.     AutoMutex _l(mLock);
  7.     handle_entry* e = lookupHandleLocked(handle);
  9.     if (e != NULL) {
  10.        
  11.         IBinder* b = e->binder;
  12.         if (b == NULL || !e->refs->attemptIncWeak(this)) {
  13.             if (handle == 0) {//这里handle为0的情况是为SM准备的，
  14.                
  15.                 Parcel data;
  16.                 status_t status = IPCThreadState::self()->transact(
  17.                         0, IBinder::PING_TRANSACTION, data, NULL, 0);
  18.                 if (status == DEAD_OBJECT)
  19.                    return NULL;
  20.             }
  21.             //我们的不为0，在这里创建了BpBinder
  22.             b = new BpBinder(handle); 
  23.             e->binder = b;
  24.             if (b) e->refs = b->getWeakRefs();
  25.             result = b;
  26.         } else {
  27.            
  28.             result.force_set(b);
  29.             e->refs->decWeak(this);
  30.         }
  31.     }
  33.     return result;
  34. }

好了剩下最后一个了javaObjectForIBinder

[android_ util_Binder.cpp]

  1. jobject javaObjectForIBinder(JNIEnv* env, const sp<IBinder>& val) {
  2.     if (val == NULL) return NULL;
  4.     //如果val是Binder对象，进入下面分支，此时val是BpBinder
  5.     if (val->checkSubclass(&gBinderOffsets)) {
  6.         // One of our own!
  7.         jobject object = static_cast<JavaBBinder*>(val.get())->object();
  8.         LOGDEATH("objectForBinder %p: it's our own %p!\n", val.get(), object);
  9.         return object;
  10.     }
  11.     .........
  12.     //调用BpBinder的findObject函数
  13.     //在Native层的BpBinder中有一个ObjectManager，它用来管理在Native BpBinder上创建的Java BinderProxy对象
  14.     //findObject用于判断gBinderProxyOffsets中，是否存储了已经被ObjectManager管理的Java BinderProxy对象
  15.     jobject object = (jobject)val->findObject(&gBinderProxyOffsets);
  16.     if (object != NULL) {
  17.         jobject res = jniGetReferent(env, object);
  18.         ............
  19.         //如果该Java BinderProxy已经被管理，则删除这个旧的BinderProxy
  20.         android_atomic_dec(&gNumProxyRefs);
  21.         val->detachObject(&gBinderProxyOffsets);
  22.         env->DeleteGlobalRef(object);
  23.     }
  25.     //创建一个新的BinderProxy对象
  26.     object = env->NewObject(gBinderProxyOffsets.mClass, gBinderProxyOffsets.mConstructor);
  27.     if (object != NULL) {
  28.         // The proxy holds a reference to the native object.
  29.         env->SetLongField(object, gBinderProxyOffsets.mObject, (jlong)val.get());
  30.         val->incStrong((void*)javaObjectForIBinder);
  32.         // The native object needs to hold a weak reference back to the
  33.         // proxy, so we can retrieve the same proxy if it is still active.
  34.         jobject refObject = env->NewGlobalRef(
  35.                 env->GetObjectField(object, gBinderProxyOffsets.mSelf));
  37.         //新创建的BinderProxy对象注册到BpBinder的ObjectManager中，同时注册一个回收函数proxy_cleanup
  38.         //当BinderProxy对象detach时，proxy_cleanup函数将被调用，以释放一些资源
  39.         val->attachObject(&gBinderProxyOffsets, refObject,
  40.                 jnienv_to_javavm(env), proxy_cleanup);
  42.         // Also remember the death recipients registered on this proxy
  43.         sp<DeathRecipientList> drl = new DeathRecipientList;
  44.         drl->incStrong((void*)javaObjectForIBinder);
  45.         //将死亡通知list和BinderProxy联系起来
  46.         env->SetLongField(object, gBinderProxyOffsets.mOrgue, reinterpret_cast<jlong>(drl.get()));
  48.         // Note that a new object reference has been created.
  49.         android_atomic_inc(&gNumProxyRefs);
  51.         //垃圾回收相关；利用gNumRefsCreated记录创建出的BinderProxy数量
  52.         //当创建出的BinderProxy数量大于200时，该函数将利用BinderInternal的ForceGc函数进行一个垃圾回收
  53.         incRefsCreated(env);
  55.         return object;
  56.     }
  57. }

到这里总算都打通了总体流程如下

还剩下遗留下的两个问题

通过Java层的服务端代理最终调用到BpBinder.transact函数

[BpBinder.cpp]

  1. status_t BpBinder：transact(uint32_t code,const Parcel&data,Parcel*reply，uint32_t flags){
  2.     if(mAlive){
  3.         //BpBinder把transact工作交给了IPCThreadState。
  4.         status_t status=IPCThreadState：self()->transact(
  5.         mHandle,code,data,reply,flags)；//mHandle也是参数
  6.         if(status==DEAD_OBJECT)mAlive=0；
  7.         return status；
  8.     }
  9.     return DEAD_OBJECT；
  10. }

[IPCThreadState.cpp]

  1. IPCThreadState::IPCThreadState()
  2.     : mProcess(ProcessState::self()),
  3.       mMyThreadId(gettid()),
  4.       mStrictModePolicy(0),
  5.       mLastTransactionBinderFlags(0)
  6. {
  7.     pthread_setspecific(gTLS, this);
  8.     clearCaller();
  9.     //mIn和mOut是两个Parcel。 把它看成是发送和接收命令的缓冲区即可。
  10.     mIn.setDataCapacity(256);
  11.     mOut.setDataCapacity(256);
  12. }
  15. status_t IPCThreadState::transact(int32_t handle,
  16.                                   uint32_t code, const Parcel& data,
  17.                                   Parcel* reply, uint32_t flags)
  18. {
  19.     ......
  20.     /*
  21.     注意这里的第一个参数BC_TRANSACTION，它是应用程序向binder设备发送消息的消
  22.     息码，而binder设备向应用程序回复消息的消息码以BR_开头。 消息码的定义在
  23.     binder_module.h中，请求消息码和回应消息码的对应关系，需要查看Binder驱动的实
  24.     现才能将其理清楚，我们这里暂时用不上。
  25.     */
  26.     
  27.     err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL);
  28.     ......
  29.     err = waitForResponse(NULL, NULL);
  30.     ......
  31.     return err;
  32. }
  34. status_t IPCThreadState::writeTransactionData(int32_t cmd, uint32_t binderFlags,
  35. int32_t handle, uint32_t code, const Parcel& data, status_t* statusBuffer)
  36. {
  37.    //binder_transaction_data是和binder设备通信的数据结构。
  38.     binder_transaction_data tr；
  39.     //果然，handle的值传递给了target，用来标识目的端，其中0是ServiceManager的标志。
  40.     tr.target.handle=handle；
  41.     //code是消息码，是用来switch/case的！
  42.     tr.code = code;
  43.     tr.flags = binderFlags;
  44.     tr.cookie = 0;
  45.     tr.sender_pid = 0;
  46.     tr.sender_euid = 0;
  47.     
  48.     const status_t err = data.errorCheck();
  49.     if (err == NO_ERROR) {
  50.         tr.data_size = data.ipcDataSize();
  51.         tr.data.ptr.buffer = data.ipcData();
  52.         tr.offsets_size = data.ipcObjectsCount()*sizeof(binder_size_t);
  53.         tr.data.ptr.offsets = data.ipcObjects();
  54.     } else if (statusBuffer) {
  55.         tr.flags |= TF_STATUS_CODE;
  56.         *statusBuffer = err;
  57.         tr.data_size = sizeof(status_t);
  58.         tr.data.ptr.buffer = reinterpret_cast<uintptr_t>(statusBuffer);
  59.         tr.offsets_size = 0;
  60.         tr.data.ptr.offsets = 0;
  61.     } else {
  62.         return (mLastError = err);
  63.     }
  64.     
  65.     //把命令写到mOut中，而不是直接发出去，可见这个函数有点名不副实。
  66.     mOut.writeInt32(cmd);
  67.     mOut.write(&tr, sizeof(tr));
  68.     
  69.     return NO_ERROR;
  70. }
  72. status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)
  73. {
  74.     uint32_t cmd;
  75.     int32_t err;
  77.     while (1) {
  78.         if ((err=talkWithDriver()) <NO_ERROR) break;
  79.         err = mIn.errorCheck();
  80.         if (err < NO_ERROR) break;
  81.         if (mIn.dataAvail() == 0) continue;
  82.         //看见没？这里开始操作mIn了，看来talkWithDriver中
  83.         //把mOut发出去，然后从driver中读到数据放到mIn中了。
  84.         cmd = mIn.readInt32();
  87.    }
  88. }
  90. status_t IPCThreadState::talkWithDriver(bool doReceive)
  91. {
  92.     binder_write_read bwr;
  93.        //中间东西太复杂了，不就是把mOut数据和mIn接收数据的处理后赋值给bwr吗？
  94.         status_t err;
  95.         do {
  96.     //用ioctl来读写
  97.             if (ioctl(mProcess->mDriverFD,BINDER_WRITE_READ, &bwr) >= 0)
  98.                 err = NO_ERROR;
  99.             else
  100.                 err = -errno;
  101.       } while (err == -EINTR);
  102.     //到这里，回复数据就在bwr中了，bmr接收回复数据的buffer就是mIn提供的
  103.             if (bwr.read_consumed > 0) {
  104.                 mIn.setDataSize(bwr.read_consumed);
  105.                 mIn.setDataPosition(0);
  106.             }
  107.     returnNO_ERROR;
  108. }

我们本篇详细分析了Binder机制，从概述->Java层Binder->Native层Binder->Binder驱动，位于各层次的读者都能获得收获。

不好意思各位，下周有个比较重要的面试，所以暂时不会更新该系列的博客，但是也会更新其他博客。记录准备面试的过程中需要用到的比较容易错误的知识。

此致，敬礼

版权声明：本文为wangle12138原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：http://www.cnblogs.com/wangle12138/p/8087709.html