文章/答案/技术大牛

发布

社区首页 >专栏 >【android开发】Android binder学习一：主要概念

【android开发】Android binder学习一：主要概念

程序员互动联盟

发布于 2018-03-13 08:39:43

1K00

代码可运行

文章被收录于专栏：程序员互动联盟程序员互动联盟

运行总次数：0

代码可运行

要看得懂android代码，首先要了解binder机制。binder机制也是android里面比较难以理解的一块，这里记录一下binder的重要概念以及实现，作为备忘。部分内容来源于网上，如有侵权，请及时告知。

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.为什么使用binder通信

linux中有管道，system V IPC，socket等进程间通信机制，那么为什么在android中使用了一个全新的binder通信机制呢？

一、可靠性。在移动设备上，通常采用基于Client-Server的通信方式来实现互联网与设备间的内部通信。目前linux支持IPC包括传统的管道，System V IPC，即消息队列/共享内存/信号量，以及socket中只有socket支持Client-Server的通信方式。Android系统为开发者提供了丰富进程间通信的功能接口，媒体播放，传感器，无线传输。这些功能都由不同的server来管理。开发都只关心将自己应用程序的client与server的通信建立起来便可以使用这个服务。毫无疑问，如若在底层架设一套协议来实现Client-Server通信，增加了系统的复杂性。在资源有限的手机上来实现这种复杂的环境，可靠性难以保证。

二、传输性能。socket主要用于跨网络的进程间通信和本机上进程间的通信，但传输效率低，开销大。消息队列和管道采用存储-转发方式，即数据先从发送方缓存区拷贝到内核开辟的一块缓存区中，然后从内核缓存区拷贝到接收方缓存区，其过程至少有两次拷贝。虽然共享内存无需拷贝，但控制复杂。比较各种IPC方式的数据拷贝次数。共享内存：0次。Binder：1次。Socket/管道/消息队列：2次。

IPC	数据拷贝次数
共享内存	0
Binder	1
Socket/管道/消息队列	2

三、安全性。Android是一个开放式的平台，所以确保应用程序安全是很重要的。Android对每一个安装应用都分配了UID/PID,其中进程的UID是可用来鉴别进程身份。传统的只能由用户在数据包里填写UID/PID，这样不可靠，容易被恶意程序利用。而我们要求由内核来添加可靠的UID。

基于以上原因，Android需要建立一套新的IPC机制来满足系统对通信方式，传输性能和安全性的要求，这就是Binder。Binder基于Client-Server通信模式，传输过程只需一次拷贝，为发送发添加UID/PID身份，既支持实名Binder也支持匿名Binder，安全性高。

3.service manager

顾名思义，service manager就是android下面管理service的一个进程，它本身也是一个service，这里的service和init.rc里面的service有一些差别，init.rc中的service都是一个进程，而这里的service可能不是一个单独的进程。每一个service在使用之前都必须向SM注册，每一个client要使用service前都应该先向SM查询是否存在这个service，如果存在，则给client返回这个service的handle。下面是sm中main函数的关键代码：

int main(int argc, char **argv)
{
    struct binder_state *bs;

    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;
    }

    ......

    //svcmgr_handle的值为0
    svcmgr_handle = BINDER_SERVICE_MANAGER;
    binder_loop(bs, svcmgr_handler);

    return 0;
}

在SM中主要做了如下工作：

打开binder设备，映射128k的内存到应用空间。
指定 svcmgr_handle的值为0，当client与SM通信时，需要先创建一个handle为0的代理binder。
binder_become_context_manager通知binder driver使SM为context manager。
binder_loop是一个死循环，里面不停的读binder是否有数据，如果有数据，则解析，对于BR_TRANSACTION，会调用svcmgr_handler来处理。
SM维护了一个svclist来存储service的信息。一个新的service需要向SM注册add到这个列表，而client请求时会在svclist里面查找请求的service。一个service包括两个重要的信息，handle和name。add和get都会根据name来进行匹配。

下面一个图片可以简单说明SM与binder driver之间的关系：

由上可知，service在使用前会先作为client向SM注册；应用若要使用某一个服务，需要先向SM获取该服务的handle，然后通过handle来调用该服务提供的方法。

4.ProcessState

ProcessState是以单例模式设计的。每个进程在使用binder机制通信时，均需要维护一个ProcessState实例来描述当前进程在binder通信时的binder状态。

ProcessState有如下2个主要功能：

1.创建一个thread,该线程负责与内核中的binder模块进行通信，称该线程为Pool thread；

2.为指定的handle创建一个BpBinder对象，并管理该进程中所有的BpBinder对象。

4.1 Pool thread

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

下面是 Pool thread的启动方式： ProcessState::self()->startThreadPool();

4.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。

5.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中的数据。

6.主要基类

6.1基类IInterface

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

6.2基类IBinder

BBinder与BpBinder均为IBinder的子类，因此可以看出IBinder定义了binder IPC的通信协议，BBinder与BpBinder在这个协议框架内进行的收和发操作，构建了基本的binder IPC机制。

6.3基类BpRefBase

client端在查询SM获得所需的的BpBinder后，BpRefBase负责管理当前获得的BpBinder实例。

7.两个接口类

7.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指针。

7.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端的操作。

8.Parcel

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

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

8.1 writeStrongBinder

当一个service 调用add_service把自己加入到SM中时，就会遇到这种情况，如下（IServiceManager.cpp）：

 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);
        status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);
        return err == NO_ERROR ? reply.readExceptionCode() : err;
    }

其中writeStrongBinder（Parcel.cpp）如下：

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) {
                ALOGE("null proxy");
            }
            const int32_t handle = proxy ? proxy->handle() : 0;
            obj.type = BINDER_TYPE_HANDLE;
            obj.binder = 0; /* Don't pass uninitialized stack data to a remote process */
            obj.handle = handle;
            obj.cookie = 0;
        } else {
            obj.type = BINDER_TYPE_BINDER;
            obj.binder = reinterpret_cast<uintptr_t>(local->getWeakRefs());
            obj.cookie = reinterpret_cast<uintptr_t>(local);
        }
    } else {
        obj.type = BINDER_TYPE_BINDER;
        obj.binder = 0;
        obj.cookie = 0;
    }

    return finish_flatten_binder(binder, obj, out);
}

addService的参数为一个BnINTERFACE类型指针，BnINTERFACE又继承自BBinder：

BBinder* BBinder::localBinder()
    {
        return this;
    }

所以写入到Parcel的binder类型为BINDER_TYPE_BINDER，在SM中，当service的binder类型不为BINDER_TYPE_HANDLE时，SM将不会将此service添加到svclist，但是很显然每个service的添加都是成功的，addService在开始传递的binder类型为BINDER_TYPE_BINDER，SM收到的binder类型为BINDER_TYPE_HANDLE，那么这个过程当中究竟发生了什么？这个问题是这样的，在binder driver中（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;
..........................................
}

由之前我们已经知道，SM只是保存了server binder的handle和name，那么当client需要和某个service通讯的时候，如何获得service的binder呢？接着看readStrongBinder

8.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 = reinterpret_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的例子。

以上就是涉及到binder通讯的一些比较重要的点。关于binder的具体实现就需要查看binder driver的代码了。

本文参与腾讯云自媒体同步曝光计划，分享自微信公众号。

原始发表：2015-07-18，如有侵权请联系 cloudcommunity@tencent.com 删除

其他