Android 基于Message的进程间通信 Messenger完全解析

Android Binder 设计与实现 – 设计篇

图文详解 Android Binder跨进程通信机制 原理

    Binder binder = new Stub();
    // 步骤1：创建Binder对象 ->>分析1

    // 步骤2：创建 IInterface 接口类 的匿名类
    // 创建前，需要预先定义 继承了IInterface 接口的接口 -->分析3
    IInterface plus = new IPlus(){

          // 确定Client进程需要调用的方法
          public int add(int a,int b) {
               return a+b;
         }

          // 实现IInterface接口中唯一的方法
          public IBinder asBinder（）{ 
                return null ;
           }
};
          // 步骤3
          binder.attachInterface(plus，"add two int");
         // 1. 将（add two int，plus）作为（key,value）对存入到Binder对象中的一个Map<String,IInterface>对象中
         // 2. 之后，Binder对象 可根据add two int通过queryLocalIInterface（）获得对应IInterface对象（即plus）的引用，可依靠该引用完成对请求方法的调用
        // 分析完毕，跳出


<-- 分析1：Stub类 -->
    public class Stub extends Binder {
    // 继承自Binder类 ->>分析2

          // 复写onTransact（）
          @Override
          boolean onTransact(int code, Parcel data, Parcel reply, int flags){
          // 具体逻辑等到步骤3再具体讲解，此处先跳过
          switch (code) { 
                case Stub.add： { 

                       data.enforceInterface("add two int"); 

                       int  arg0  = data.readInt();
                       int  arg1  = data.readInt();

                       int  result = this.queryLocalIInterface("add two int") .add( arg0,  arg1); 

                        reply.writeInt(result); 

                        return true; 
                  }
           } 
      return super.onTransact(code, data, reply, flags); 

}
// 回到上面的步骤1，继续看步骤2

<-- 分析2：Binder 类 -->
 public class Binder implement IBinder{
    // Binder机制在Android中的实现主要依靠的是Binder类，其实现了IBinder接口
    // IBinder接口：定义了远程操作对象的基本接口，代表了一种跨进程传输的能力
    // 系统会为每个实现了IBinder接口的对象提供跨进程传输能力
    // 即Binder类对象具备了跨进程传输的能力

        void attachInterface(IInterface plus, String descriptor)；
        // 作用：
          // 1. 将（descriptor，plus）作为（key,value）对存入到Binder对象中的一个Map<String,IInterface>对象中
          // 2. 之后，Binder对象 可根据descriptor通过queryLocalIInterface（）获得对应IInterface对象（即plus）的引用，可依靠该引用完成对请求方法的调用

        IInterface queryLocalInterface(Stringdescriptor) ；
        // 作用：根据 参数 descriptor 查找相应的IInterface对象（即plus引用）

        boolean onTransact(int code, Parcel data, Parcel reply, int flags)；
        // 定义：继承自IBinder接口的
        // 作用：执行Client进程所请求的目标方法（子类需要复写）
        // 参数说明：
        // code：Client进程请求方法标识符。即Server进程根据该标识确定所请求的目标方法
        // data：目标方法的参数。（Client进程传进来的，此处就是整数a和b）
        // reply：目标方法执行后的结果（返回给Client进程）
         // 注：运行在Server进程的Binder线程池中；当Client进程发起远程请求时，远程请求会要求系统底层执行回调该方法

        final class BinderProxy implements IBinder {
         // 即Server进程创建的Binder对象的代理对象类
         // 该类属于Binder的内部类
        }
        // 回到分析1原处
}

<-- 分析3：IInterface接口实现类 -->

 public interface IPlus extends IInterface {
          // 继承自IInterface接口->>分析4
          // 定义需要实现的接口方法，即Client进程需要调用的方法
         public int add(int a,int b);
// 返回步骤2
}

<-- 分析4：IInterface接口类 -->
// 进程间通信定义的通用接口
// 通过定义接口，然后再服务端实现接口、客户端调用接口，就可实现跨进程通信。
public interface IInterface
{
    // 只有一个方法：返回当前接口关联的 Binder 对象。
    public IBinder asBinder();
}
  // 回到分析3原处

// 1. Client进程 将需要传送的数据写入到Parcel对象中
// data = 数据 = 目标方法的参数（Client进程传进来的，此处就是整数a和b） + IInterface接口对象的标识符descriptor
  android.os.Parcel data = android.os.Parcel.obtain();
  data.writeInt(a); 
  data.writeInt(b); 

  data.writeInterfaceToken("add two int");；
  // 方法对象标识符让Server进程在Binder对象中根据"add two int"通过queryLocalIInterface（）查找相应的IInterface对象（即Server创建的plus），Client进程需要调用的相加方法就在该对象中

  android.os.Parcel reply = android.os.Parcel.obtain();
  // reply：目标方法执行后的结果（此处是相加后的结果）

// 2. 通过 调用代理对象的transact（） 将 上述数据发送到Binder驱动
  binderproxy.transact(Stub.add, data, reply, 0)
  // 参数说明：
    // 1. Stub.add：目标方法的标识符（Client进程 和 Server进程 自身约定，可为任意）
    // 2. data ：上述的Parcel对象
    // 3. reply：返回结果
    // 0：可不管

// 注：在发送数据后，Client进程的该线程会暂时被挂起
// 所以，若Server进程执行的耗时操作，请不要使用主线程，以防止ANR


// 3. Binder驱动根据 代理对象 找到对应的真身Binder对象所在的Server 进程（系统自动执行）
// 4. Binder驱动把 数据 发送到Server 进程中，并通知Server 进程执行解包（系统自动执行）

// 1. 收到Binder驱动通知后，Server 进程通过回调Binder对象onTransact（）进行数据解包 & 调用目标方法
  public class Stub extends Binder {

          // 复写onTransact（）
          @Override
          boolean onTransact(int code, Parcel data, Parcel reply, int flags){
          // code即在transact（）中约定的目标方法的标识符

          switch (code) { 
                case Stub.add： { 
                  // a. 解包Parcel中的数据
                       data.enforceInterface("add two int"); 
                        // a1. 解析目标方法对象的标识符

                       int  arg0  = data.readInt();
                       int  arg1  = data.readInt();
                       // a2. 获得目标方法的参数

                       // b. 根据"add two int"通过queryLocalIInterface（）获取相应的IInterface对象（即Server创建的plus）的引用，通过该对象引用调用方法
                       int  result = this.queryLocalIInterface("add two int") .add( arg0,  arg1); 

                        // c. 将计算结果写入到reply
                        reply.writeInt(result); 

                        return true; 
                  }
           } 
      return super.onTransact(code, data, reply, flags); 
      // 2. 将结算结果返回 到Binder驱动

  // 1. Binder驱动根据 代理对象 沿原路 将结果返回 并通知Client进程获取返回结果
  // 2. 通过代理对象 接收结果（之前被挂起的线程被唤醒）

    binderproxy.transact(Stub.ADD, data, reply, 0)；
    reply.readException();；
    result = reply.readInt()；
          }
}

1．binder通信概述

binder通信是一种client-server的通信结构，
1.从表面上来看，是client通过获得一个server的代理接口，对server进行直接调用；
2.实际上，代理接口中定义的方法与server中定义的方法是一一对应的；
3.client调用某个代理接口中的方法时，代理接口的方法会将client传递的参数打包成为Parcel对象；
4.代理接口将该Parcel发送给内核中的binder driver.
5.server会读取binder driver中的请求数据，如果是发送给自己的，解包Parcel对象，处理并将结果返回；
6.整个的调用过程是一个同步过程，在server处理的时候，client会block住。

2．service manager

Service Manager是一个linux级的进程,顾名思义，就是service的管理器。这里的service是什么概念呢？这里的service的概念和init过程中init.rc中的service是不同，init.rc中的service是都是linux进程，但是这里的service它并不一定是一个进程，也就是说可能一个或多个service属于同一个linux进程。在这篇文章中不加特殊说明均指android native端的service。

任何service在被使用之前，均要向SM(Service Manager)注册，同时客户端需要访问某个service时，应该首先向SM查询是否存在该服务。如果SM存在这个service，那么会将该service的handle返回给client，handle是每个service的唯一标识符。

SM的入口函数在service_manager.c中，下面是SM的代码部分
int main(int argc, char **argv)
{
struct binder_state *bs;
void *svcmgr = BINDER_SERVICE_MANAGER;

bs = binder_open(128*1024);

if (binder_become_context_manager(bs)) {
LOGE(“cannot become context manager (%s)/n”, strerror(errno));
return -1;
}

svcmgr_handle = svcmgr;
binder_loop(bs, svcmgr_handler);
return 0;
}

这个进程的主要工作如下：
1.初始化binder，打开/dev/binder设备；在内存中为binder映射128K字节空间；
2.指定SM对应的代理binder的handle为0，当client尝试与SM通信时，需要创建一个handle为0的代理binder，这里的代理binder其实就是*节中描述的那个代理接口；

3.通知binder driver(BD)使SM成为BD的context manager；
4.维护一个死循环，在这个死循环中，不停地去读内核中binder driver，查看是否有可读的内容；即是否有对service的操作要求, 如果有，则调用svcmgr_handler回调来处理请求的操作。

5.SM维护了一个svclist列表来存储service的信息。

这里需要声明一下，当service在向SM注册时，该service就是一个client，而SM则作为了server。而某个进程需要与service通信时，此时这个进程为client，service才作为server。因此service不一定为server，有时它也是作为client存在的。

由于下面几节会介绍一些与binder通信相关的几个概念，所以将SM的功能介绍放在了后面的部分来讲。

应用和service之间的通信会涉及到2次binder通信。

1.应用向SM查询service是否存在，如果存在获得该service的代理binder，此为一次binder通信；
2.应用通过代理binder调用service的方法，此为第二次binder通信。

3．ProcessState

ProcessState是以单例模式设计的。每个进程在使用binder机制通信时，均需要维护一个ProcessState实例来描述当前进程在binder通信时的binder状态。
ProcessState有如下2个主要功能：
1.创建一个thread,该线程负责与内核中的binder模块进行通信，称该线程为Pool thread；
2.为指定的handle创建一个BpBinder对象，并管理该进程中所有的BpBinder对象。

3.1 Pool thread

在Binder IPC中，所有进程均会启动一个thread来负责与BD来直接通信，也就是不停的读写BD，这个线程的实现主体是一个IPCThreadState对象，下面会介绍这个类型。

下面是 Pool thread的启动方式：

ProcessState::self()->startThreadPool();

3.2 BpBinder获取

BpBinder主要功能是负责client向BD发送调用请求的数据。它是client端binder通信的核心对象，通过调用transact函数向BD发送调用请求的数据，它的构造函数如下：

BpBinder(int32_t handle);
通过BpBinder的构造函数发现，BpBinder会将当前通信中server的handle记录下来，当有数据发送时，会通知BD数据的发送目标。

ProcessState通过如下方式来获取BpBinder对象：

ProcessState::self()->getContextObject(handle);

在这个过程中，ProcessState会维护一个BpBinder的vector mHandleToObject，每当ProcessState创建一个BpBinder的实例时，回去查询mHandleToObject，如果对应的handle已经有binder指针，那么不再创建，否则创建binder并插入到mHandleToObject中。
ProcessState创建的BpBinder实例，一般情况下会作为参数构建一个client端的代理接口，这个代理接口的形式为BpINTERFACE,例如在与SM通信时，client会创建一个代理接口BpServiceManager.

4．IPCThreadState

IPCThreadState也是以单例模式设计的。由于每个进程只维护了一个ProcessState实例，同时ProcessState只启动一个Pool thread，也就是说每一个进程只会启动一个Pool thread，因此每个进程则只需要一个IPCThreadState即可。
Pool thread的实际内容则为：
IPCThreadState::self()->joinThreadPool();

ProcessState中有2个Parcel成员，mIn和mOut，Pool thread会不停的查询BD中是否有数据可读，如果有将其读出并保存到mIn，同时不停的检查mOut是否有数据需要向BD发送，如果有，则将其内容写入到BD中，总而言之，从BD中读出的数据保存到mIn，待写入到BD中的数据保存在了mOut中。

ProcessState中生成的BpBinder实例通过调用IPCThreadState的transact函数来向mOut中写入数据，这样的话这个binder IPC过程的client端的调用请求的发送过程就明了了。

IPCThreadState有两个重要的函数，talkWithDriver函数负责从BD读写数据，executeCommand函数负责解析并执行mIn中的数据。

5.主要基类

5.1基类IInterface

为server端提供接口，它的子类声明了service能够实现的所有的方法；

5.2基类IBinder
BBinder与BpBinder均为IBinder的子类，因此可以看出IBinder定义了binder IPC的通信协议，BBinder与BpBinder在这个协议框架内进行的收和发操作，构建了基本的binder IPC机制。
5.3基类BpRefBase
client端在查询SM获得所需的的BpBinder后，BpRefBase负责管理当前获得的BpBinder实例。

6.两个接口类

6.1 BpINTERFACE

如果client想要使用binder IPC来通信，那么首先会从SM出查询并获得server端service的BpBinder，在client端，这个对象被认为是server端的远程代理。为了能够使client能够想本地调用一样调用一个远程server，server端需要向client提供一个接口，client在在这个接口的基础上创建一个BpINTERFACE，使用这个对象，client的应用能够想本地调用一样直接调用server端的方法。而不用去关心具体的binder IPC实现。
下面看一下BpINTERFACE的原型：
class BpINTERFACE : public BpInterface<IINTERFACE>

顺着继承关系再往上看
template<typename INTERFACE>
class BpInterface : public INTERFACE, public BpRefBase

BpINTERFACE分别继承自INTERFACE，和BpRefBase；
● BpINTERFACE既实现了service中各方法的本地操作，将每个方法的参数以Parcel的形式发送给BD。
例如BpServiceManager的
virtual status_t addService(const String16& name, const sp<IBinder>& service)
{
Parcel data, reply;
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
data.writeString16(name);
data.writeStrongBinder(service);
status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);
return err == NO_ERROR ? reply.readExceptionCode() : err;
}
● 同时又将BpBinder作为了自己的成员来管理，将BpBinder存储在mRemote中，BpServiceManager通过调用BpRefBase的remote()来获得BpBinder指针。

6.2 BnINTERFACE

在定义android native端的service时，每个service均继承自BnINTERFACE(INTERFACE为service name)。BnINTERFACE类型定义了一个onTransact函数，这个函数负责解包收到的Parcel并执行client端的请求的方法。

顺着BnINTERFACE的继承关系再往上看，
class BnINTERFACE: public BnInterface<IINTERFACE>

IINTERFACE为client端的代理接口BpINTERFACE和server端的BnINTERFACE的共同接口类，这个共同接口类的目的就是保证service方法在C-S两端的一致性。

再往上看
class BnInterface : public INTERFACE, public BBinder

同时我们发现了BBinder类型，这个类型又是干什么用的呢？既然每个service均可视为一个binder，那么真正的server端的binder的操作及状态的维护就是通过继承自BBinder来实现的。可见BBinder是service作为binder的本质所在。

那么BBinder与BpBinder的区别又是什么呢？

其实它们的区别很简单，BpBinder是client端创建的用于消息发送的代理，而BBinder是server端用于接收消息的通道。查看各自的代码就会发现，虽然两个类型均有transact的方法，但是两者的作用不同，BpBinder的transact方法是向IPCThreadState实例发送消息，通知其有消息要发送给BD；而BBinder则是当IPCThreadState实例收到BD消息时，通过BBinder的transact的方法将其传递给它的子类BnSERVICE的onTransact函数执行server端的操作。

7. Parcel

Parcel是binder IPC中的*基本的通信单元，它存储C-S间函数调用的参数.但是Parcel只能存储基本的数据类型，如果是复杂的数据类型的话，在存储时，需要将其拆分为基本的数据类型来存储。

简单的Parcel读写不再介绍，下面着重介绍一下2个函数

7.1 writeStrongBinder

当client需要将一个binder向server发送时，可以调用此函数。例如
virtual status_t addService(const String16& name, const sp<IBinder>& service)
{
Parcel data, reply;
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
data.writeString16(name);
data.writeStrongBinder(service);
status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);
return err == NO_ERROR ? reply.readExceptionCode() : err;
}

看一下writeStrongBinder的实体
status_t Parcel::writeStrongBinder(const sp<IBinder>& val)
{
return flatten_binder(ProcessState::self(), val, this);
}

接着往里看flatten_binder
status_t flatten_binder(const sp<ProcessState>& proc,
const sp<IBinder>& binder, Parcel* out)
{
flat_binder_object obj;

obj.flags = 0x7f | FLAT_BINDER_FLAG_ACCEPTS_FDS;
if (binder != NULL) {
IBinder *local = binder->localBinder();
if (!local) {
BpBinder *proxy = binder->remoteBinder();
if (proxy == NULL) {
LOGE(“null proxy”);
}
const int32_t handle = proxy ? proxy->handle() : 0;
obj.type = BINDER_TYPE_HANDLE;
obj.handle = handle;
obj.cookie = NULL;
} else {
obj.type = BINDER_TYPE_BINDER;
obj.binder = local->getWeakRefs();
obj.cookie = local;
}
} else {
obj.type = BINDER_TYPE_BINDER;
obj.binder = NULL;
obj.cookie = NULL;
}

return finish_flatten_binder(binder, obj, out);
}

还是拿addService为例，它的参数为一个BnINTERFACE类型指针，BnINTERFACE又继承自BBinder，
BBinder* BBinder::localBinder()
{
return this;
}
所以写入到Parcel的binder类型为BINDER_TYPE_BINDER，同时你在阅读SM的代码时会发现如果SM收到的service的binder类型不为BINDER_TYPE_HANDLE时，SM将不会将此service添加到svclist，但是很显然每个service的添加都是成功的，addService在开始传递的binder类型为BINDER_TYPE_BINDER，SM收到的binder类型为BINDER_TYPE_HANDLE，那么这个过程当中究竟发生了什么？
为了搞明白这个问题，花费我很多的事件，*终发现了问题的所在，原来在BD中做了如下操作(drivers/staging/android/Binder.c)：

static void binder_transaction(struct binder_proc *proc,
struct binder_thread *thread,
struct binder_transaction_data *tr, int reply)
{
……………………………………

if (fp->type == BINDER_TYPE_BINDER)
fp->type = BINDER_TYPE_HANDLE;
else
fp->type = BINDER_TYPE_WEAK_HANDLE;
fp->handle = ref->desc;
……………………………………
}

阅读完addService的代码，你会发现SM只是保存了service binder的handle和service的name，那么当client需要和某个service通信了，如何获得service的binder呢？看下一个函数

7.2 readStrongBinder

当server端收到client的调用请求之后，如果需要返回一个binder时，可以向BD发送这个binder，当IPCThreadState实例收到这个返回的Parcel时，client可以通过这个函数将这个被server返回的binder读出。

sp<IBinder> Parcel::readStrongBinder() const
{
sp<IBinder> val;
unflatten_binder(ProcessState::self(), *this, &val);
return val;
}

往里查看unflatten_binder

status_t unflatten_binder(const sp<ProcessState>& proc,
const Parcel& in, sp<IBinder>* out)
{
const flat_binder_object* flat = in.readObject(false);

if (flat) {
switch (flat->type) {
case BINDER_TYPE_BINDER:
*out = static_cast<IBinder*>(flat->cookie);
return finish_unflatten_binder(NULL, *flat, in);
case BINDER_TYPE_HANDLE:
*out = proc->getStrongProxyForHandle(flat->handle);
return finish_unflatten_binder(
static_cast<BpBinder*>(out->get()), *flat, in);
}
}
return BAD_TYPE;
}

发现如果server返回的binder类型为BINDER_TYPE_BINDER的话，也就是返回一个binder引用的话，直接获取这个binder；如果server返回的binder类型为BINDER_TYPE_HANDLE时，也就是server返回的仅仅是binder的handle，那么需要重新创建一个BpBinder返回给client。

有上面的代码可以看出，SM保存的service的binder仅仅是一个handle，而client则是通过向SM获得这个handle，从而重新构建代理binder与server通信。

这里顺带提一下一种特殊的情况，binder通信的双方即可作为client，也可以作为server.也就是说此时的binder通信是一个半双工的通信。那么在这种情况下，操作的过程会比单工的情况复杂，但是基本的原理是一样的，有兴趣可以分析一下MediaPlayer和MediaPlayerService的例子。

8. 经典桥段分析

main_ mediaserver.cpp
int main(int argc, char** argv)
{

//创建进程mediaserver的ProcessState实例
sp<ProcessState> proc(ProcessState::self());

//获得SM的BpServiceManager
sp<IServiceManager> sm = defaultServiceManager();
LOGI(“ServiceManager: %p”, sm.get());

//添加mediaserver中支持的service。
AudioFlinger::instantiate();
MediaPlayerService::instantiate();
CameraService::instantiate();
AudioPolicyService::instantiate();

//启动ProcessState的pool thread
ProcessState::self()->startThreadPool();

//这一步有重复之嫌，加不加无关紧要。
IPCThreadState::self()->joinThreadPool();
}

9. Java 层的binder机制

了解了native通信机制后，再去分析JAVA层的binder机制，就会很好理解了。它只是对native的binder做了一个封装。这一部分基本上没有太复杂的过程，这里不再赘述了。

1.Binder机制简介
Android Binder是源于Palm的OpenBinder，它为android设备跨进程访问而设计。Binder机制从表现上看可以实现java 和native层的对象实例可以从一个进程访问到另一个进程，从而透明的实现跨进程的调用。调用者感觉不到自己的请求是在另一个进程中完成并返回结果的。在android系统中使用Binder机制*多的是系统服务，这些服务一般运行在特定的进程中。服务的使用者成为Client,Client一般是应用程序，是跨进程访问的请求发起者。运行行在特定进程中的服务被成为server，这些server用于接受client端发起的请求并处理具体相关业务并返回结果。

Android系统中的Binder机制涉及java和c++层两部分，使java和native层都可以实现Binder的client、server逻辑并通过系统的/dev/binder虚拟设备提供的跨进程能力发起请求和接受请求处理业务返回结果。其中java层的Binder是对C++层Binder机制的上层封装，通过JNI的方式调用到C++的实现逻辑中。

我将通过分别分析C++层的实现和java的封装两部分分析Binder机制。

2.C++层Binder的实现
我通过分析MediaServer的实现逻辑通过阅读源码了解一下Binder的实现逻辑.MediaServer执行程序的入口是main（）方法：

…/frameworks/av/media/mediaserver/main_mediaserver.cpp
int main(int argc __unused, char** argv)
{
…………………

//获取一个ProcessState对象，同时通过pen_driver()打开/dev/binder的虚拟设备，通过mmap（）为binder分配一块空间用于通信读写，通过
//iotrl()为binder指定线程数
sp<ProcessState> proc(ProcessState::self());
//获取一个IServerManager对象，用于服务注册
sp<IServiceManager> sm = defaultServiceManager();
ALOGI(“ServiceManager: %p”, sm.get());
//初始化音频系统AudioFlinger
AudioFlinger::instantiate();
//多媒体服务初始化
MediaPlayerService::instantiate();
ResourceManagerService::instantiate();
//cameraServer 相机服务
CameraService::instantiate();
//音频系统AudioPolicy服务
AudioPolicyService::instantiate();
SoundTriggerHwService::instantiate();
RadioService::instantiate();
registerExtensions();
//创建线程池？
ProcessState::self()->startThreadPool();
//加入线程池？
IPCThreadState::self()->joinThreadPool();

………………..
}

1.1ProcessState的作用
从main_mediaServer.cpp的main()方法中可以看到 sp proc(ProcessState::self())获取一个ProcessState对象，先看一下ProcessState::self()函数都做了什么：

sp<ProcessState> ProcessState::self()
{
Mutex::Autolock _l(gProcessMutex);
if (gProcess != NULL) {
return gProcess;
}
//创建一个新的ProcessState对象
gProcess = new ProcessState;
return gProcess;
}

实现很简单，self（）方法就是一个简单的单例调用new 创建了一个ProcessState对象。那看一下ProcessState的构造方法都做了些什么：

…/frameworks/native/libs/binder/ProcessState.cpp

ProcessState::ProcessState()
: mDriverFD(open_driver()) //打开Binder
, mVMStart(MAP_FAILED) //映射内存的的起始地址
, mThreadCountLock(PTHREAD_MUTEX_INITIALIZER)
, mThreadCountDecrement(PTHREAD_COND_INITIALIZER)
, mExecutingThreadsCount(0)
, mMaxThreads(DEFAULT_MAX_BINDER_THREADS)
, mManagesContexts(false)
, mBinderContextCheckFunc(NULL)
, mBinderContextUserData(NULL)
, mThreadPoolStarted(false)
, mThreadPoolSeq(1)
{
if (mDriverFD >= 0) {
#if !defined(HAVE_WIN32_IPC)
//为Binder分配一块内存用于存取数据
// mmap the binder, providing a chunk of virtual address space to receive transactions.
mVMStart = mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0);
if (mVMStart == MAP_FAILED) {
// *sigh*
ALOGE(“Using /dev/binder failed: unable to mmap transaction memory.\n”);
close(mDriverFD);
mDriverFD = -1;
}
#else
mDriverFD = -1;
#endif
}

LOG_ALWAYS_FATAL_IF(mDriverFD < 0, “Binder driver could not be opened. Terminating.”);
}

在ProcessState的构造函数中首先调用了open_driver()方法初始化了一个ProcessState的变量mDriverFD，这个open_driver()方法很重要，它打开/dev/binder这个虚拟设备为binder通信做准备。在打开binder设备后又调用系统函数mmap() 为打开的binder设备在内存中映射了一块内存空间并将内存地址返回给变量mVMStart。

那先看一下open_driver()是怎么样打开binder驱动设备的。

…/frameworks/native/libs/binder/ProcessState.cpp
static int open_driver()
{
//打开/dev/binder虚拟设备
int fd = open(“/dev/binder”, O_RDWR);

“““““““““““`
//通过ioctl（）告诉驱动*多支持的线程数 15
size_t maxThreads = DEFAULT_MAX_BINDER_THREADS;
result = ioctl(fd, BINDER_SET_MAX_THREADS, &maxThreads);
return fd;
}

在open_driver()中直接调用了linux系统函数open()打开了/dev/binder设备并为启动的Binder虚拟设备通过ioctl（）[系统函数]为binder 设备指定了*大线程数；

分析到这里基本上就是main_mediaserver–>main()函数中sp proc(ProcessState::self())这句代码做的事情。总结起来主要做了两件事情：

open_driver()打开/dev/binder虚拟设备驱动
为打开的Binder虚拟设备分配内存映射空间
那下边继续回到main_mediaserver的main()方法中继续分析,看在获取到ProcessState后的sp sm =defaultServiceManager()干了什么。

defaultServerManager
defaultServerManager()函数会返回一个实现了IServerManager接口的对象，通过这个对象我们可以和另外一个进程的ServerManager进行通信.先看一下defaultServerManager()方法都干了点什么：

…/frameworks/native/libs/binder/IServiceManager.cpp
sp<IServiceManager> defaultServiceManager()
{
if (gDefaultServiceManager != NULL) return gDefaultServiceManager;

{
AutoMutex _l(gDefaultServiceManagerLock);
while (gDefaultServiceManager == NULL) {
//gDefaultServiceManager对象创建的地方
gDefaultServiceManager = interface_cast<IServiceManager>(
ProcessState::self()->getContextObject(NULL));
if (gDefaultServiceManager == NULL)
sleep(1);
}
}

return gDefaultServiceManager;
}

这个方法在IServerManager.cpp中定义的，这个方法又是一个单例来获取一个IServerManger对象。内容很简单但是当我看到interface_cast（…）后我感觉一点都不好，但是它是很重要的不过暂时先不管它。先看看ProcessState::self()->getContextObject(NULL）方法都干了点什么：

…/frameworks/native/libs/binder/ProcessState.cpp

sp<IBinder> ProcessState::getContextObject(const sp<IBinder>& /*caller*/)
{
//好吧，这里直接调用了getStrongProxyForHande()方法。
//但是传入的参数 0很重要
return getStrongProxyForHandle(0);
}

sp<IBinder> ProcessState::getStrongProxyForHandle(int32_t handle)
{
sp<IBinder> result;

AutoMutex _l(mLock);
//资源查找，找不到会创建一个新的对象
handle_entry* e = lookupHandleLocked(handle);

if (e != NULL) {
IBinder* b = e->binder;
//新创建的binder 一定为空
if (b == NULL || !e->refs->attemptIncWeak(this)) {
if (handle == 0) {

························

Parcel data;
//这里是一次IPC的binder通信过程，暂时不分析
//我们现在分析的是getStrongProxyForHander（）方法返回的是什么
status_t status = IPCThreadState::self()->transact(
0, IBinder::PING_TRANSACTION, data, NULL, 0);
if (status == DEAD_OBJECT)
return NULL;
}
//创建一个BpBinder对象
b = new BpBinder(handle);
e->binder = b; //填充
if (b) e->refs = b->getWeakRefs();
result = b;

···············
}

return result;
}

在getStrongProxyForHandle（）函数中首先调用了lookupHandleLocked(0)方法获取一个handle_entry 类型的结构指针。lookupHandleLocked()就是在一个Vector中查找对象找不到就创建一个，不重要先忽略。然后这里创建了一个BpBinder对象，根据名字看应该是和Binder机制有关的我们先可以一下BpBinder的构造方法：

…/frameworks/native/libs/binder/BpBinder.cpp

//BpBinder构造函数
BpBinder::BpBinder(int32_t handle)
: mHandle(handle) //handle 为 0
, mAlive(1)
, mObitsSent(0)
, mObituaries(NULL)
{
“““““““`
//另外一个重要对象？
IPCThreadState::self()->incWeakHandle(handle);
}

在BpBinder的构造函数中出现了一个新对象IPCThreadState，对象名字竟然以IPC应该是和Binder的跨进程通信又关系的。

…/frameworks/native/libs/binder/IPCThreadState.cpp

IPCThreadState* IPCThreadState::self()
{
if (gHaveTLS) {
restart:
const pthread_key_t k = gTLS;
//TLS = thread location storage 线程本地空间 是线程独有空间
//getSpecific()和setSpecific()可以操作这部分空间
IPCThreadState* st = (IPCThreadState*)pthread_getspecific(k);
if (st) return st;
//返回一个创建的IPCThreadState对象
return new IPCThreadState;
}

if (gShutdown) return NULL;

““““
goto restart;
}

当我*次看到这个方法时还是有点震惊的，我虽然没有学习过C++但是大一那会儿学习过C语言。当时老师就告诉我们尽量少用goto这个逻辑跳转。这里竟然用了。

这个方法中IPCThreadState* st = (IPCThreadState*)pthread_getspecific(k)是从线程的TLS中获取一个IPCThreadState对象指针，*次调用市肯定是不存在这个对象的所以会new 一个IPCThreadState对象。

TLS是操作系统为每个线程都单独分配的一块内存空间，当前线程独占其他线程无法访问。所以在多线程下对它的访问的线程安全的。

既然这里调用了IPCThreadState的构造函数我们就看看它长什么样子：

…/frameworks/native/libs/binder/IPCThreadState.cpp

IPCThreadState::IPCThreadState()
: mProcess(ProcessState::self()), //获取上边我们创建的ProcessState对象
mMyThreadId(gettid()),
mStrictModePolicy(0),
mLastTransactionBinderFlags(0)
{
//在构造函数中将自己设置到TLS中
pthread_setspecific(gTLS, this);
clearCaller();
mIn.setDataCapacity(256);
mOut.setDataCapacity(256);
}

IPCThreadState的构造函数很简单就是创建自己后将自己设置到当前线程的TLS中，下次就可以直接从当前线程的TLS中获取了。

我们分析了这么多其实都是gDefaultServiceManager = interface_cast(ProcessState::self()->getContextObject(NULL))的getContextObject(null)方法开始分析。好吧，要不是不是回到看一下我都已经不知道自己现在在分析什么了。那现在我们知道了getContextObject()返回的是一个BpBinder对象。那我们再看看interface_cast()设个什么东西：

…/frameworks/native/include/binder/IInterface.h
template<typename INTERFACE>
inline sp<INTERFACE> interface_cast(const sp<IBinder>& obj)
{
return INTERFACE::asInterface(obj);
}

原来interface_cast()是一个定义在IInterface.h头文件中的模范方法，那我们现在根据我们上边的调用翻译一下这个模版方法现在的样子：

inline sp<IServiceManager> interface_cast(const sp<IBinder>& obj) {
return IServiceManager::asInterface(obj);
}

实话说分析到这里我有点懵了不知道怎么分析了. 既然模版方法中调用了IServiceManager::asInterface()方法我们就先看看IServiceManager接口的内容：

…/frameworks/native/include/binder/IServiceManager.h

class IServiceManager : public IInterface
{
public:
//这个鸿定义在IInterface.h中，他主要做了如下工作
//1.定义了一个描述字符串
//2.定义了一个asInterface函数
//3.定义了一个getInterfaceDescriptor函数用于返回上边定义的描述字符串
//4.定义了构造函数和析构函数
DECLARE_META_INTERFACE(ServiceManager);

virtual sp<IBinder> getService( const String16& name) const = 0;

virtual sp<IBinder> checkService( const String16& name) const = 0;

virtual status_t addService( const String16& name,
const sp<IBinder>& service,
bool allowIsolated = false) = 0;

virtual Vector<String16> listServices() = 0;

enum {
GET_SERVICE_TRANSACTION = IBinder::FIRST_CALL_TRANSACTION,
CHECK_SERVICE_TRANSACTION,
ADD_SERVICE_TRANSACTION,
LIST_SERVICES_TRANSACTION,
};
};

我们都知道Android系统中的系统服务像AMS、WMS等都是有ServiceManager统一管理的。这里的IServiceManager.h就是定义了他的功能接口。在这个接口定义中我们看到一个宏DECLARE_META_INTERFACE(ServiceManager)的使用，那我们先分析一下这个宏定义是什么样子：

#define DECLARE_META_INTERFACE(INTERFACE) \
static const android::String16 descriptor; \
static android::sp<I##INTERFACE> asInterface( \
const android::sp<android::IBinder>& obj); \
virtual const android::String16& getInterfaceDescriptor() const; \
I##INTERFACE(); \
virtual ~I##INTERFACE();

同样我还是先翻译一下这个宏在当前使用场景的样子：

static const android::String16 descriptor;
static android::sp<IServiceManager> asInterface(const android::sp<IBinder>& obj);
virtual const android::String16 getInterfaceDescriptor() const;
IServiceManager();
virtual ~IServiceManager();

从对DECLARE_META_INTERFACE宏的翻译可以看出这是属性和方法的声明；

通过上边的对那个IServiceManager.h和对DECLARE_META_INTERFACE的翻译我们已经知道了IServiceManager接口定义的样子我们下面看一下他的具体实现,但是具体实现内容比较多我抽取其中重要部分分析一下：

…/frameworks/native/libs/binder/IServiceManager.cpp

…………省略………….

//IMPLEMENT_META_INTERFACE这个宏是定义在IInterface.h文件中的
//1.定义常量字符串android.os.IServiceManager
//2.实现getInterfaceDescriptor()函数
//3.实现asInterface()函数,并返回一个BpServiceManager对象
IMPLEMENT_META_INTERFACE(ServiceManager, “android.os.IServiceManager”);

status_t BnServiceManager::onTransact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
//printf(“ServiceManager received: “); data.print();
switch(code) {
………..继续省略…………..
}
}

在IServiceManager的实现中真正让我感兴趣的这个IMPLEMENT_META_INTERFACE 宏的使用。同样我们找找这个宏的定义并将这个宏翻译一下：

宏定义在IInterface.h文件中
#define IMPLEMENT_META_INTERFACE(INTERFACE, NAME) \
const android::String16 I##INTERFACE::descriptor(NAME); \
const android::String16& \
I##INTERFACE::getInterfaceDescriptor() const { \
return I##INTERFACE::descriptor; \
} \
android::sp<I##INTERFACE> I##INTERFACE::asInterface( \
const android::sp<android::IBinder>& obj) \
{ \
android::sp<I##INTERFACE> intr; \
if (obj != NULL) { \
intr = static_cast<I##INTERFACE*>( \
obj->queryLocalInterface( \
I##INTERFACE::descriptor).get()); \
if (intr == NULL) { \
intr = new Bp##INTERFACE(obj); \
} \
} \
return intr; \
} \
I##INTERFACE::I##INTERFACE() { } \
I##INTERFACE::~I##INTERFACE() { } \

感觉当前这个宏的使用场景翻译一下：

const android::String16 IServiceManager::descriptor(“android.os.IServiceManager”);
const android::String16& IServiceManager::getInterfaceDescriptor() const {
return IServiceManager::descriptor;
}
android::sp<IServiceManager> IServiceManager::asInterface(const android::sp<android::IBinder>& obj) {
android::sp<IBinder> intr;
if(obj != null) {
//这里也很重要
intr = static_cast<IServiceManager>(obj->queryLocalInterface(IServicManager:;descriptor).get());
if(intr == NULL) {
//重点看这里
intr = new BpServieceManager(obj);
}
}
return intr;
//构造函数我就不翻译了。这翻译真要命
}

现在我们已经翻译完了***IMPLEMENT_META_INTERFACE***宏的内容现在将翻译后内容替换到IServiceManager.cpp中看看

…/frameworks/native/libs/binder/IServiceManager.cpp

…………省略………….

//IMPLEMENT_META_INTERFACE这个宏是定义在IInterface.h文件中的
//1.定义常量字符串android.os.IServiceManager
//2.实现getInterfaceDescriptor()函数
//3.实现asInterface()函数,并返回一个BpServiceManager对象
<!–IMPLEMENT_META_INTERFACE(ServiceManager, “android.os.IServiceManager”);–>

const android::String16 IServiceManager::descriptor(“android.os.IServiceManager”);
const android::String16& IServiceManager::getInterfaceDescriptor() const {
return IServiceManager::descriptor;
}
android::sp<IServiceManager> IServiceManager::asInterface(const android::sp<android::IBinder>& obj) {
android::sp<IBinder> intr;
if(obj != null) {
//这里也很重要
intr = static_cast<IServiceManager>(obj->queryLocalInterface(IServicManager:;descriptor).get());
if(intr == NULL) {
//重点看这里
intr = new BpServieceManager(obj);
}
}
return intr;
//构造函数我就不翻译了。这翻译真要命

status_t BnServiceManager::onTransact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
//printf(“ServiceManager received: “); data.print();
switch(code) {
………..继续省略…………..
}
}

这就是翻译后的IServiceManager.cpp的样子我们重点看一下asInterface()方法， 这里这个方法竟然返回了一个BpServiceManager对象。还记得我们先变分析中哪里调用了这个asInterface()方法吗？没错就是我们在interface_cast()模版方法调用，现在我们知道在当前分析场景下interface_cast()返回的是一个***BpServiceManager***类型的对象。那么问题现在有来了，还记得interface_cast()方法是在哪里调用的吗？没错就是defaultServiceManager()方法中调用的。

现在终于将defaultServiceManager（）函数分析完了，*终这个方法会返回一个BpServiceManager类型的对象（累死人了，分析了这么多终于知道了这个方法返回了什么。要疯了，特别想爆粗口）。那现在我是特别想知道BpServiceManager到底是个什么东西。但是现在不着急，defautServiceManager()方法引发这么多的联动分析我还是先回味一下defaultServiceManager()函数都干了些啥：

首先调用了ProcessState::getContextObject(null)函数，但是这个函数什么都没有干就直接调用了自己的getStrongProxyForHandle(0)函数。在getStrongProxyForHandle()函数中创建了一个BpBinder对象。
在BpBinder构造函数中又引出了一个重要的类IPCThreadState类。在这里调用了IPCThreadState::self();
在IPCThreadState::self()函数中首先从线程的TLS中获取IPCThreadState对象。到那时在首次点用时TLS中并未存储，所以会调用它的构造方法创建一个IPCThreadState对象并将创建的对象保存到TLS中。以后就可以直接从TLS中获取。
interface_cast()模版方法中调用了IServiceManager的asInterface()函数。通过我们对模版方法、DECLARE_META_INTERFACE和IMPLEMENT_META_INTERFACE宏的分析翻译知道*终asInterface()返回了一个BpServiceManager对象。
在整个defaultServiceManager()函数中涉及到BpBinder、ProcessState、IPCThreadState、BpServiceManager等新的类。我们有必要分析一下目前他们的关系如何。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8YrAU0q2-1593588562795)(https://thumbnail0.baidupcs.com/thumbnail/bb7c4d396ec292dc71350f5750f7c4d5?fid=2586003311-250528-448513258459521&time=1546952400&rt=sh&sign=FDTAER-DCb740ccc5511e5e8fedcff06b081203-HxxYlrpgwgJNMNKaDwPEh57%2BXOk%3D&expires=8h&chkv=0&chkbd=0&chkpc=&dp-logid=183401465543768111&dp-callid=0&size=c710_u400&quality=100&vuk=-&ft=video)]

现在我们可以根据类图关系再来分析一下他们。首先看一下BpServiceManager:

class BpServiceManager : public BpInterface<IServiceManager>
{
//impl参数是IBinder类型，实际上就是上边创建的BpBinder
public BpServiceManager(const sp<IBinder>& impl)
//调用了父类的构造方法，参数impl 是 BpBinder
: BpInterface<IServiceManager>(impl)
{
}
}

BpServiceManager继承自BpInterface。现在看一下BpInterface:

模版类
template<typename INTERFACE>
class BpInterface : public INTERFACE, public BpRefBase
{
public:
BpInterface(const sp<IBinder>& remote);

protected:
virtual IBinder* onAsBinder();
};

—————————-
模版方法
template<typename INTERFACE>
//remote参数是BpBinder
inline BpInterface<INTERFACE>::BpInterface(const sp<IBinder>& remote)
//调用父类的构造方法
: BpRefBase(remote)
{
}

继续看一下BpRefBase的实现：

//mRemote*终等于BpBinder(0)对象
BpRefBase::BpRefBase(const sp<IBinder>& o)
//重点在这里，Bpbinder本传递给了mRemote.Binder的通信需要通过mRemote来完成。
: mRemote(o.get()), mRefs(NULL), mState(0)
{
extendObjectLifetime(OBJECT_LIFETIME_WEAK);

if (mRemote) {
mRemote->incStrong(this); // Removed on first IncStrong().
mRefs = mRemote->createWeak(this); // Held for our entire lifetime.
}
}

现在我们知道BpServiceManager实现了IServiceManager接口同时持有了BpBinder，BpBinder可以用于进程的通信。此时BpServiceManager是ServiceManager客户端的代理对象，BpBinder是Binder通信机制的Client端代表。

2. MediaPlayerService addService()
我们继续回到MediaServer的main()函数中继续分析。看看MediaPlayerService::instantiate()实现：

void MediaPlayerService::instantiate() {
//通过上边的分析我们已经知道defaultServiceManager（）返回的是一个BpServiceManager对象。在这里调用了他的addService（）方法。
defaultServiceManager()->addService(
String16(“media.player”), new MediaPlayerService());
}

在instantiate()函数中调用了BpServiceManager的addService():

…/frameworks/native/libs/binder/IServiceManager.cpp的内嵌类BpServiceManager

virtual status_t addService(const String16& name, const sp<IBinder>& service,
bool allowIsolated)
{
Parcel data, reply;
//
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
data.writeString16(name);
data.writeStrongBinder(service);
data.writeInt32(allowIsolated ? 1 : 0);
//remote()函数返回的是mRemote,就是BpRefBase中的mRemote，即BpBinder对象。这里调用了BpBinder的transact()方法。
status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);
return err == NO_ERROR ? reply.readExceptionCode() : err;
}

从BpServiceManager的addService（）方法可以看出*终将调用转移到了BpBinder中。由此我们知道BpBinder才是代表client进行跨进程通信的代表。下面我们继续分析一下BpBinder；

status_t BpBinder::transact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
// Once a binder has died, it will never come back to life.
if (mAlive) {
//BpBinder将通信委托给了IPCThreadState的transcat（）方法
status_t status = IPCThreadState::self()->transact(
mHandle, code, data, reply, flags);
if (status == DEAD_OBJECT) mAlive = 0;
return status;
}

return DEAD_OBJECT;
}

看到这里还是有点震惊的，我本来认为BpBinder已经是实现通信的客户端的代表了。现在发现它竟然将通信委托给IPCThreadState来完成。原来BpBinder还是个壳子。继续看一下IPCThreadState::transact()：

status_t IPCThreadState::transact(int32_t handle,
uint32_t code, const Parcel& data,
Parcel* reply, uint32_t flags)
{
status_t err = data.errorCheck();

““““““““““““““`

if (err == NO_ERROR) {
LOG_ONEWAY(“>>>> SEND from pid %d uid %d %s”, getpid(), getuid(),
(flags & TF_ONE_WAY) == 0 ? “READ REPLY” : “ONE WAY”);
//发送Binder通信消息
err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL);
}

if (err != NO_ERROR) {
if (reply) reply->setError(err);
return (mLastError = err);
}

if ((flags & TF_ONE_WAY) == 0) {
#if 0
if (code == 4) { // relayout
ALOGI(“>>>>>> CALLING transaction 4”);
} else {
ALOGI(“>>>>>> CALLING transaction %d”, code);
}
#endif
if (reply) {
//等待通讯结果
err = waitForResponse(reply);
} else {
Parcel fakeReply;
err = waitForResponse(&fakeReply);
}

““““““““““““
} else {
err = waitForResponse(NULL, NULL);
}

return err;
}

在IPCThreadState的transact()方法中有两个重要的方法调用， err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL)和err = waitForResponse(reply)。我们先来分析一下writeTransactionData()的实现：

status_t IPCThreadState::writeTransactionData(int32_t cmd, uint32_t binderFlags,
int32_t handle, uint32_t code, const Parcel& data, status_t* statusBuffer)
{
binder_transaction_data tr; //binder_transaction_data 是binder通信的数据结构

tr.target.ptr = 0; /* Don’t pass uninitialized stack data to a remote process */
tr.target.handle = handle; //现在handle是0；0代表ServiceManager。
tr.code = code;
tr.flags = binderFlags;
tr.cookie = 0;
tr.sender_pid = 0;
tr.sender_euid = 0;

const status_t err = data.errorCheck();
if (err == NO_ERROR) {
tr.data_size = data.ipcDataSize();
tr.data.ptr.buffer = data.ipcData();
tr.offsets_size = data.ipcObjectsCount()*sizeof(binder_size_t);
tr.data.ptr.offsets = data.ipcObjects();
} else if (statusBuffer) {
tr.flags |= TF_STATUS_CODE;
*statusBuffer = err;
tr.data_size = sizeof(status_t);
tr.data.ptr.buffer = reinterpret_cast<uintptr_t>(statusBuffer);
tr.offsets_size = 0;
tr.data.ptr.offsets = 0;
} else {
return (mLastError = err);
}
//mOut的类型是Pracel.它是准备发送给Binder的Server端。
mOut.writeInt32(cmd);
//将Binder通信的数据写入到mOut中
mOut.write(&tr, sizeof(tr));

return NO_ERROR;
}

从writeTransactionData()方法的分析发现里边主要做了数据准备并将数据序列化到Pracel中。

我们继续分析分析waitForResponse(reply)函数：

status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)
{
uint32_t cmd;
int32_t err;
//循环处理
while (1) {
//重点talkWithDriver()
if ((err=talkWithDriver()) < NO_ERROR) break;
err = mIn.errorCheck();
if (err < NO_ERROR) break;
if (mIn.dataAvail() == 0) continue;

cmd = (uint32_t)mIn.readInt32();

IF_LOG_COMMANDS() {
alog << “Processing waitForResponse Command: ”
<< getReturnString(cmd) << endl;
}

switch (cmd) {
case BR_TRANSACTION_COMPLETE:
if (!reply && !acquireResult) goto finish;
break;

case BR_DEAD_REPLY:
err = DEAD_OBJECT;
goto finish;

case BR_FAILED_REPLY:
err = FAILED_TRANSACTION;
goto finish;

case BR_ACQUIRE_RESULT:
{
ALOG_ASSERT(acquireResult != NULL, “Unexpected brACQUIRE_RESULT”);
const int32_t result = mIn.readInt32();
if (!acquireResult) continue;
*acquireResult = result ? NO_ERROR : INVALID_OPERATION;
}
goto finish;

case BR_REPLY:
{
binder_transaction_data tr;
err = mIn.read(&tr, sizeof(tr));
ALOG_ASSERT(err == NO_ERROR, “Not enough command data for brREPLY”);
if (err != NO_ERROR) goto finish;

if (reply) {
if ((tr.flags & TF_STATUS_CODE) == 0) {
reply->ipcSetDataReference(
reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),
tr.data_size,
reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets),
tr.offsets_size/sizeof(binder_size_t),
freeBuffer, this);
} else {
err = *reinterpret_cast<const status_t*>(tr.data.ptr.buffer);
freeBuffer(NULL,
reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),
tr.data_size,
reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets),
tr.offsets_size/sizeof(binder_size_t), this);
}
} else {
freeBuffer(NULL,
reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),
tr.data_size,
reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets),
tr.offsets_size/sizeof(binder_size_t), this);
continue;
}
}
goto finish;

default:
//重点
err = executeCommand(cmd);
if (err != NO_ERROR) goto finish;
break;
}
}

BR_开头的case都是Binder Server端的，BC_开头的case是Binder Client端使用。
在IPCThreadState的waitForResponse()函数中重要的方法有talkWithDriver()和case 的default：分支中的executeCommand()函数。现在我们先分析一下talkWithDriver():

status_t IPCThreadState::talkWithDriver(bool doReceive)
{
if (mProcess->mDriverFD <= 0) {
return -EBADF;
}

binder_write_read bwr; //binder通信的数据结构

// Is the read buffer empty?
const bool needRead = mIn.dataPosition() >= mIn.dataSize();

// We don’t want to write anything if we are still reading
// from data left in the input buffer and the caller
// has requested to read the next data.
const size_t outAvail = (!doReceive || needRead) ? mOut.dataSize() : 0;

bwr.write_size = outAvail;
bwr.write_buffer = (uintptr_t)mOut.data();

// This is what we’ll read.
if (doReceive && needRead) {
bwr.read_size = mIn.dataCapacity();
bwr.read_buffer = (uintptr_t)mIn.data();
} else {
bwr.read_size = 0;
bwr.read_buffer = 0;
}

IF_LOG_COMMANDS() {
TextOutput::Bundle _b(alog);
if (outAvail != 0) {
alog << “Sending commands to driver: ” << indent;
const void* cmds = (const void*)bwr.write_buffer;
const void* end = ((const uint8_t*)cmds)+bwr.write_size;
alog << HexDump(cmds, bwr.write_size) << endl;
while (cmds < end) cmds = printCommand(alog, cmds);
alog << dedent;
}
alog << “Size of receive buffer: ” << bwr.read_size
<< “, needRead: ” << needRead << “, doReceive: ” << doReceive << endl;
}

// Return immediately if there is nothing to do.
if ((bwr.write_size == 0) && (bwr.read_size == 0)) return NO_ERROR;

bwr.write_consumed = 0;
bwr.read_consumed = 0;
status_t err;
//又是一个循环
do {
IF_LOG_COMMANDS() {
alog << “About to read/write, write size = ” << mOut.dataSize() << endl;
}
#if defined(HAVE_ANDROID_OS)
//通过ioctl（）进行读写
if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0)
err = NO_ERROR;
else
err = -errno;
#else
err = INVALID_OPERATION;
#endif
if (mProcess->mDriverFD <= 0) {
err = -EBADF;
}
IF_LOG_COMMANDS() {
alog << “Finished read/write, write size = ” << mOut.dataSize() << endl;
}
} while (err == -EINTR);

IF_LOG_COMMANDS() {
alog << “Our err: ” << (void*)(intptr_t)err << “, write consumed: ”
<< bwr.write_consumed << ” (of ” << mOut.dataSize()
<< “), read consumed: ” << bwr.read_consumed << endl;
}

if (err >= NO_ERROR) {
//清空客户端的Pracel的内存空间
if (bwr.write_consumed > 0) {
if (bwr.write_consumed < mOut.dataSize())
mOut.remove(0, bwr.write_consumed);
else
mOut.setDataSize(0);
}
//将ioctl()从sever端获取的数据写入到mIn中准备发送给client端
if (bwr.read_consumed > 0) {
mIn.setDataSize(bwr.read_consumed);
mIn.setDataPosition(0);
}

““““““
return NO_ERROR;
}

return err;
}

完成Binder通信其实是通过Binder驱动的共享内存来完成不同进程之间的通信，从对talkWithDriver()函数分析来看完成对Binder驱动的共享内存的操作是ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr)函数来完成的。ioctl（）是一个linux系统API。对ioctl()方法调用是在do{}while()中调用的，由此可见这个ioctl()会多次调用来完成通信。在ioctl（）完成后请求结果被放到binder_write_read类型的bwr中，然后将bwr的结果内容写入到Pracel的mIn中为下一步返回客户端做做准备。

我们在回到IPCThreadState::waitForResponse（）函数中分析一下另外一个executeCommand(cmd)方法：

status_t IPCThreadState::executeCommand(int32_t cmd)
{
BBinder* obj;
RefBase::weakref_type* refs;
status_t result = NO_ERROR;

switch ((uint32_t)cmd) {
case BR_ERROR:
result = mIn.readInt32();
break;

case BR_OK:
break;

case BR_ACQUIRE:
“““““`
break;
case BR_RELEASE:
“““““`
break;

case BR_INCREFS:
““““““`
break;

““““`

case BR_TRANSACTION:
{
binder_transaction_data tr;
result = mIn.read(&tr, sizeof(tr));
ALOG_ASSERT(result == NO_ERROR,
“Not enough command data for brTRANSACTION”);
if (result != NO_ERROR) break;

Parcel buffer;
buffer.ipcSetDataReference(
reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),
tr.data_size,
reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets),
tr.offsets_size/sizeof(binder_size_t), freeBuffer, this);

const pid_t origPid = mCallingPid;
const uid_t origUid = mCallingUid;
const int32_t origStrictModePolicy = mStrictModePolicy;
const int32_t origTransactionBinderFlags = mLastTransactionBinderFlags;

mCallingPid = tr.sender_pid;
mCallingUid = tr.sender_euid;
mLastTransactionBinderFlags = tr.flags;

int curPrio = getpriority(PRIO_PROCESS, mMyThreadId);
if (gDisableBackgroundScheduling) {
if (curPrio > ANDROID_PRIORITY_NORMAL) {
setpriority(PRIO_PROCESS, mMyThreadId, ANDROID_PRIORITY_NORMAL);
}
} else {
if (curPrio >= ANDROID_PRIORITY_BACKGROUND) {
set_sched_policy(mMyThreadId, SP_BACKGROUND);
}
}

Parcel reply;
status_t error;

if (tr.target.ptr) {
//BnService从BBinder派生
//这里的B实际上实现了BnServiceXXX的对象
sp<BBinder> b((BBinder*)tr.cookie);
error = b->transact(tr.code, buffer, &reply, tr.flags);

} else {
error = the_context_object->transact(tr.code, buffer, &reply, tr.flags);
}

if ((tr.flags & TF_ONE_WAY) == 0) {
LOG_ONEWAY(“Sending reply to %d!”, mCallingPid);
if (error < NO_ERROR) reply.setError(error);
sendReply(reply, 0);
} else {
LOG_ONEWAY(“NOT sending reply to %d!”, mCallingPid);
}

mCallingPid = origPid;
mCallingUid = origUid;
mStrictModePolicy = origStrictModePolicy;
mLastTransactionBinderFlags = origTransactionBinderFlags;

}
break;
·····································
return result;
}

看到executeCommand（）函数中那么多的switch分支真不知道从哪里分析，脑子已经懵懵的。还是从BR_TRANSACTION：这个分支看看吧。在这个分支中我们可以看到//BnService从BBinder派生sp b((BBinder*)tr.cookie);error = b->transact(tr.code, buffer, &reply, tr.flags);我们又看到了一个BBinder类的对象，有我们从BpBinder是Binder Client的代表可以猜测BBinder可能是Binder的Server端的代表。实际上这里的b是BnSerciceManager对象。那先放下executeCommaond()函数，这里我们先来分析一下BBinder和BnServiceManaer是什么然后在回来分析：

“`/frameworks/native/include/binder/IServiceManager.h
class BnServiceManager : public BnInterface<IServiceManager>
{
public:
virtual status_t onTransact( uint32_t code,
const Parcel& data,
Parcel* reply,
uint32_t flags = 0);
};

开始看张类图直观一些，手画丑的不行：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2YzuoKT4-1593588562797)(https://thumbnail0.baidupcs.com/thumbnail/01a427c58cc69e8688aeddecc50fb5c3?fid=2586003311-250528-868147785755165&time=1546952400&rt=sh&sign=FDTAER-DCb740ccc5511e5e8fedcff06b081203-AvZaBr10el8zdroFSH1cY0BrMYs%3D&expires=8h&chkv=0&chkbd=0&chkpc=&dp-logid=183456904394929954&dp-callid=0&size=c710_u400&quality=100&vuk=-&ft=video)]

BnServiceManager继承自BnInterface,再看一下BnInterface是什么：

template<typename INTERFACE>
class BnInterface : public INTERFACE, public BBinder
{
public:
virtual sp<IInterface> queryLocalInterface(const String16& _descriptor);
virtual const String16& getInterfaceDescriptor() const;

protected:
virtual IBinder* onAsBinder();
};

BnInterface是个模版类继承自BBinder,在BnServiceManager继承BnInterface时模版类中的INTERFACE 是 IServiceManager。用于BnInterface继承了INTERFACE，所以BnServicManager继承了ISeviceManager接口。下面看一下BBinder的定义:

“`/frameworks/native/include/binder/Binder.h
class BBinder : public IBinder
{
………….
}

这样以来继承关系已经很明确。再BnServiceManager的接口声明中重新声明了onTransact()函数并在IServiceManager.cpp中实现了它：

status_t BnServiceManager::onTransact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
//printf(“ServiceManager received: “); data.print();
switch(code) {
case GET_SERVICE_TRANSACTION: {
········
} break;
case CHECK_SERVICE_TRANSACTION: {
········
} break;
case ADD_SERVICE_TRANSACTION: {
CHECK_INTERFACE(IServiceManager, data, reply);
String16 which = data.readString16();
sp<IBinder> b = data.readStrongBinder();
//在这里有调用了addService()完成真正的服务添加。
status_t err = addService(which, b);
reply->writeInt32(err);
return NO_ERROR;
} break;
case LIST_SERVICES_TRANSACTION: {
········
return NO_ERROR;
} break;
default:
//调用父类默认实现
return BBinder::onTransact(code, data, reply, flags);
}
}

我们对BnServiceManager和BBinder的分析先分析到这里，回到executeCommond()方法中再结合sp b((BBinder*)tr.cookie);error = b->transact(tr.code, buffer, &reply,tr.flags);调用bnServiceManager的transact()方法。以分析的addService()*终会进入到case ADD_SERVICE_TRANSACTION:分支当中并在这里调用了addService()方法。
***看到这里我是有点模糊的这个分支中的addService()方法的实现在哪里，也没有找到一个类继承自BnServiceManager。***后来网上看别人的分析发现还是有个文件实现了这里的ServiceManager的功能，具体实现在Service_manager.c中实现的。

不太明白为什么不继续继承BnServiceManager来实现具体逻辑呢？

ServiceManager
ServiceManager的实现在Service_manager.c中，先从这个文件的main（）函数开始了解一下它干了啥：

int main(int argc, char **argv)
{
struct binder_state *bs;
//打开binder虚拟设备
bs = binder_open(128*1024);
if (!bs) {
ALOGE(“failed to open binder driver\n”);
return -1;
}
//角色转换
if (binder_become_context_manager(bs)) {
ALOGE(“cannot become context manager (%s)\n”, strerror(errno));
return -1;
}

//重点，处理客户端发过来的请求
binder_loop(bs, svcmgr_handler);

return 0;
}

main（）函数比较简单主要通过调用了binder_open()函数打开Binder的虚拟设备.先看一下binder_open()都做了些什么：

/打开Binder设备
struct binder_state *binder_open(size_t mapsize)
{
struct binder_state *bs;
struct binder_version vers;

bs = malloc(sizeof(*bs));
if (!bs) {
errno = ENOMEM;
return NULL;
}
//打开虚拟设备，调用Linux系统方法打开文件
bs->fd = open(“/dev/binder”, O_RDWR);
if (bs->fd < 0) {
fprintf(stderr,”binder: cannot open device (%s)\n”,
strerror(errno));
goto fail_open;
}

if ((ioctl(bs->fd, BINDER_VERSION, &vers) == -1) ||
(vers.protocol_version != BINDER_CURRENT_PROTOCOL_VERSION)) {
fprintf(stderr,
“binder: kernel driver version (%d) differs from user space version (%d)\n”,
vers.protocol_version, BINDER_CURRENT_PROTOCOL_VERSION);
goto fail_open;
}

bs->mapsize = mapsize;
//调用mmap()函数给binder驱动做内存映射
bs->mapped = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs->fd, 0);
if (bs->mapped == MAP_FAILED) {
fprintf(stderr,”binder: cannot map device (%s)\n”,
strerror(errno));
goto fail_map;
}

return bs;

fail_map:
close(bs->fd);
fail_open:
free(bs);
return NULL;
}

我在这个方法中又看到了goto的使用。有点兴奋！

在open_binder()函数中打开了Binder驱动，并给起映射了内存空间。我们继续看一下binder_become_context_manager(bs)干了什么：

int binder_become_context_manager(struct binder_state *bs)
{
return ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0);
}

很简单但是我没有看太懂，主要是对ioctl()这个函数不太懂。大概是给打开的Binder设备指定了映射名称为0；（谁懂给我普及一下）

ioctl是设备驱动程序中对设备的I/O通道进行管理的函数。所谓对I/O通道进行管理，就是对设备的一些特性进行控制，例如串口的传输波特率、马达的转速等等。它的参数个数如下：int ioctl(int fd, int cmd, …)；其中fd就是用户程序打开设备时使用open函数返回的文件标示符，cmd就是用户程序对设备的控制命令，至于后面的省略号，那是一些补充参数，一般*多一个，有或没有是和cmd的意义相关的。ioctl函数是文件结构中的一个属性分量，就是说如果你的驱动程序提供了对ioctl的支持，用户就能在用户程序中使用ioctl函数控制设备的I/O通道。百度百科

还有一个处理Binder请求的方法binder_loop(bs, svcmgr_handler)：

//binder_handler 是个函数指针，func现在是svcmgr_handler
void binder_loop(struct binder_state *bs, binder_handler func)
{
int res;
struct binder_write_read bwr;
uint32_t readbuf[32];

bwr.write_size = 0;
bwr.write_consumed = 0;
bwr.write_buffer = 0;

readbuf[0] = BC_ENTER_LOOPER;
//在binder_write中调用了ioctl函数，调用Binder设备的函数，标志serviceManager进入的Loop 状态。
binder_write(bs, readbuf, sizeof(uint32_t));
//循环不断的
for (;;) {
bwr.read_size = sizeof(readbuf);
bwr.read_consumed = 0;
bwr.read_buffer = (uintptr_t) readbuf;
//通过ioctl()方法从Binder设备中读取缓冲区，检查是不是又IPC请求。
res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);
if (res < 0) {
ALOGE(“binder_loop: ioctl failed (%s)\n”, strerror(errno));
break;
}
//接受到请求，然后解析结果 调用func函数
res = binder_parse(bs, 0, (uintptr_t) readbuf, bwr.read_consumed, func);
if (res == 0) {
ALOGE(“binder_loop: unexpected reply?!\n”);
break;
}
if (res < 0) {
ALOGE(“binder_loop: io error %d %s\n”, res, strerror(errno));
break;
}
}
}

在binder_loop()中让binder设备进入loop状态，通过循环不断通过ioctl（）方法获取Binder设备是不是有IPC请求，如果有将获取到的数据交给binder_parse()函数进行解析.

int binder_parse(struct binder_state *bs, struct binder_io *bio,
uintptr_t ptr, size_t size, binder_handler func)
{
……………..数据处理………………………..

case BR_TRANSACTION: {

………………..

if (func) {
unsigned rdata[256/4];
struct binder_io msg;
struct binder_io reply;
int res;
bio_init(&reply, rdata, sizeof(rdata), 4);
bio_init_from_txn(&msg, txn);
//调用了func()函数，有func()函数去做真正的服务管理
res = func(bs, txn, &msg, &reply);
binder_send_reply(bs, &reply, txn->data.ptr.buffer, res);
}
ptr += sizeof(*txn);
break;
}
……………………………..
}
}
return r;
}

在binder_prase()方法的binder_handler func参数指向的是svcmgr_handler函数，下面看看这个函数：

…/frameworks/native/cmds/servicemanager/service_manager.c

//binder 通信处理数据的回调函数
int svcmgr_handler(struct binder_state *bs,
struct binder_transaction_data *txn,
struct binder_io *msg,
struct binder_io *reply)
{
struct svcinfo *si;
uint16_t *s;
size_t len;
uint32_t handle;
uint32_t strict_policy;
int allow_isolated;

//ALOGI(“target=%p code=%d pid=%d uid=%d\n”,
// (void*) txn->target.ptr, txn->code, txn->sender_pid, txn->sender_euid);

if (txn->target.ptr != BINDER_SERVICE_MANAGER)
return -1;

if (txn->code == PING_TRANSACTION)
return 0;

strict_policy = bio_get_uint32(msg);
s = bio_get_string16(msg, &len);
if (s == NULL) {
return -1;
}

if ((len != (sizeof(svcmgr_id) / 2)) ||
memcmp(svcmgr_id, s, sizeof(svcmgr_id))) {
fprintf(stderr,”invalid id %s\n”, str8(s, len));
return -1;
}

if (sehandle && selinux_status_updated() > 0) {
struct selabel_handle *tmp_sehandle = selinux_android_service_context_handle();
if (tmp_sehandle) {
selabel_close(sehandle);
sehandle = tmp_sehandle;
}
}

switch(txn->code) {
case SVC_MGR_GET_SERVICE:
case SVC_MGR_CHECK_SERVICE:
……….

case SVC_MGR_ADD_SERVICE:
//注册服务
s = bio_get_string16(msg, &len);
if (s == NULL) {
return -1;
}
handle = bio_get_ref(msg);
allow_isolated = bio_get_uint32(msg) ? 1 : 0;
//注册服务真正工作的地方
if (do_add_service(bs, s, len, handle, txn->sender_euid,
allow_isolated, txn->sender_pid))
return -1;
break;

case SVC_MGR_LIST_SERVICES: {
……
}
default:
ALOGE(“unknown code %d\n”, txn->code);
return -1;
}

bio_put_uint32(reply, 0);
return 0;
}

在svcmgr_handler()函数中SVC_ADD_SERVICES分支中注册服务，其中注册服务的实际处理交给了do_add_service()方法继续处理。

int do_add_service(struct binder_state *bs,
const uint16_t *s, size_t len,
uint32_t handle, uid_t uid, int allow_isolated,
pid_t spid)
{
struct svcinfo *si;

if (!handle || (len == 0) || (len > 127))
return -1;
//验证UID是否有添加服务的权限。
if (!svc_can_register(s, len, spid)) {
ALOGE(“add_service(‘%s’,%x) uid=%d – PERMISSION DENIED\n”,
str8(s, len), handle, uid);
return -1;
}
//检查服务是不是已经注册
si = find_svc(s, len);
if (si) {
if (si->handle) {
ALOGE(“add_service(‘%s’,%x) uid=%d – ALREADY REGISTERED, OVERRIDE\n”,
str8(s, len), handle, uid);
svcinfo_death(bs, si);
}
si->handle = handle;
} else {
//如果没有注册分配内存
si = malloc(sizeof(*si) + (len + 1) * sizeof(uint16_t));
//si这个结构体
si->handle = handle;
si->len = len;
memcpy(si->name, s, (len + 1) * sizeof(uint16_t));
si->name[len] = ‘\0’;
si->death.func = (void*) svcinfo_death;
si->death.ptr = si;
si->allow_isolated = allow_isolated;
si->next = svclist;
//插入链表
svclist = si;
}

binder_acquire(bs, handle);
binder_link_to_death(bs, handle, &si->death);
return 0;
}

//存储注册服务的结构体，是个链表结构
struct svcinfo
{
struct svcinfo *next;
uint32_t handle;
struct binder_death death;
int allow_isolated;
size_t len;
uint16_t name[0];
};

do_add_service()方法通过坚定要注册的服务是否有权限被注册，然后再检查服务是否已经注册了，如果没有被注册则将其插入到链表中。这样我们的服务注册工作已经完成。
C++层的Binder通信的分析基本上分析完了。想抽时间再分析一下Java层对c++层的封装。