浅谈Android之Binder原理介绍（三）

最新推荐文章于 2024-09-22 15:02:40 发布

拿节

最新推荐文章于 2024-09-22 15:02:40 发布

阅读量1k

点赞数 1

分类专栏： Android

本文链接：https://blog.csdn.net/zhejiang9/article/details/55095996

版权

Android 专栏收录该内容

48 篇文章 2 订阅

订阅专栏

2.4 C++层传输数据封装

使用ProcessState和IPCThreadState建立好binder运行环境后，后续要做的，就是对发送和接收数据的封装，先从基础接口和类开始：

1：IBinder binder发送和接收基础功能接口，最终要的接口函数是transact，对应数据传输

2：BpBinder 实现IBinder，对应于binder proxy，主要用于binder数据的发送，初始化必须关联对应的binder handle

3：BBinder 实现IBinder，对应native binder，它不同于BpBinder的点是，它定义了onTransact这个虚函数

所以很明显，如果是binder客户端，就要通过拿到要通信service对应binder的handle来初始化BpBinder，反之，如果是binder服务端，那就必须实现BBinder

BpBinder和BBinder都实现了IBinder，它们最大的不同是对transact接口的实现

先看BpBinder::transact

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) {

status_t status = IPCThreadState::self()->transact(

mHandle, code, data, reply, flags);

if (status == DEAD_OBJECT) mAlive = 0;

return status;

}

return DEAD_OBJECT;

}

很简单，直接调用IPCThreadState的transact函数，然后传递目标handle和transaction code以及对应的参数。

再看BBinder:: transact

status_t BBinder::transact(

uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)

{

data.setDataPosition(0);

status_t err = NO_ERROR;

switch (code) {

case PING_TRANSACTION:

reply->writeInt32(pingBinder());

break;

default:

err = onTransact(code, data, reply, flags);

break;

}

if (reply != NULL) {

reply->setDataPosition(0);

}

return err;

}

transact基本没做啥，直接把请求转发到onTransact，看到这里，基本明白了，如果要定义自己的native binder，那肯定要派生自BBinder并实现onTransact

BBinder的transact是在IPCThreadState收到BR_TRANSACTION时被调用的：

if (tr.target.ptr) {

sp<BBinder> b((BBinder*)tr.cookie);

error = b->transact(tr.code, buffer, &reply, tr.flags);

}

代码在IPCThreadState::executeCommand中，这个函数比较长，就不全部贴出了

Transact code对应各种传输功能，如果要继续简化开发，最好把transact code也隐藏掉，直接定义业务接口给外部使用，由于binder service和binder serviceproxy相关类的封装还是有点区别，这里分开讲解。

Binder Service：

binder service通过多继承同时派生于业务接口和IBinder，接着在实现时将transactcode和各服务接口做关联，但这里会有一个问题，就是无法将两个子接口在对象内地址偏移直接进行转换问题，这个是接口多继承导致的，解决也很简单，就是在各个接口都定义虚函数用以地址转换，然后让binder service去实现：

1） IInterface，服务基础接口，主要定义接口asBinder用于获取IBinder在对象内地址偏移

2） IBinder接口定义queryLocalInterface用于得到IInterface在对象内地址偏移

接着实现模板类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();

};

INTERFACE就是我们最终要实现的服务接口，它要派生自IInterface

接着看queryLocalInterface的实现：

template<typename INTERFACE>

inline sp<IInterface> BnInterface<INTERFACE>::queryLocalInterface(

const String16& _descriptor)

{

if (_descriptor == INTERFACE::descriptor) return this;

return NULL;

}

descriptor是binder service定义的一个静态变量，主要用于binderservice 接口描述，它的初始化在后续再介绍，接着看onAsBinder：

template<typename INTERFACE>

IBinder* BnInterface<INTERFACE>::onAsBinder()

{

return this;

}

Binder Service Proxy：

Binder service proxy对服务接口和binder proxy则不是通过多继承来实现的，而是通过包含，在构造的时候，直接传入BpBinder对象来初始化内部的remoteIBinder变量，然后通过

onAsBinder拿到其内部的remote IBinder对象。

同样的，它也有一个模板类：

template<typename INTERFACE>

class BpInterface : public INTERFACE, public BpRefBase

{

public:

BpInterface(const sp<IBinder>& remote);

protected:

virtual IBinder* onAsBinder();

};

INTERFACE跟BnInterface一样，对应最终要实现的服务接口，构造必须传入remote BpBinder，否则数据发哪去都不知道，这个proxy就没任何意义

接着看onAsBinder的实现：

template<typename INTERFACE>

inline IBinder* BpInterface<INTERFACE>::onAsBinder()

{

return remote();

}

通过上面解析，我们可惜清晰的看出，如果拿到BnInterface或者BpInterface的实例，拿到其关联的IBinder数据，很简单，直接调用asBinder()就可以了

将IBinder转换成BnInterface调用queryLocalInterface，如果要转换成BpInterface，直接

new BpInterface，但是对开发人员来说，他拿到一个IBinder对象，还得先判断是nativebinder还是binder proxy，还是不大方便，再封装下吧

Android对应的实现是定义了两个宏，分别是DECLARE_META_INTERFACE(INTERFACE)和

IMPLEMENT_META_INTERFACE(INTERFACE, NAME)，对应声明和实现

任何binder service接口类，也就是上面模板的INTERFACE，都必须要添加这两个宏，这个宏主要实现：

1） binder service接口描述名，对应静态变量descriptor

2）接口描述名获取接口，对应函数getInterfaceDescriptor

3）接口转换函数，对应函数asInterface

下面是宏张开后的完整代码：

#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(); \

#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() { } \

asInterface先用调用IBinder的queryLocalInterface来尝试获取binder service，如果不为空，直接返回，如果为空，说明这个是binder service proxy，直接newBp##INTERFACE，将该IBinder对象传入作为remote binder

接下去，介绍跟我们开发最相关的部分，就是transactioncode的绑定，这部分我就直接拿ICamera这个binder service接口来介绍，为了简洁起见，我只贴出ICamera两个transactioncode的代码

首先，根据业务功能定义transactioncode：

//ICamrea.cpp

enum {

DISCONNECT = IBinder::FIRST_CALL_TRANSACTION,

SET_PREVIEW_TARGET,

};

Transaction code的值不能随便定义，要基于IBinder::FIRST_CALL_TRANSACTION递增

接着，实现ICamera接口类：

class ICamera: public IInterface

{

public:

DECLARE_META_INTERFACE(Camera);

virtual void disconnect() = 0;

// pass the buffered IGraphicBufferProducer to the camera service

virtual status_t setPreviewTarget(

const sp<IGraphicBufferProducer>& bufferProducer) = 0;

}

一般transaction code跟虚函数都是一一对应的，还有就是添加

DECLARE_META_INTERFACE(Camera);

接着还要添加宏的实现：

//ICamera.cpp

IMPLEMENT_META_INTERFACE(Camera, "android.hardware.ICamera");

从这里可以看出，这个接口的描述名为android.hardware.ICamera

接口定义好了，接着就是实现BnCamera类，对应binder service，并实现onTransact函数：

类声明：

class BnCamera: public BnInterface<ICamera>

{

public:

virtual status_t onTransact( uint32_t code,

const Parcel& data,

Parcel* reply,

uint32_t flags = 0);

};

对应实现：

status_t BnCamera::onTransact(

uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)

{

switch(code) {

case DISCONNECT: {

ALOGV("DISCONNECT");

CHECK_INTERFACE(ICamera, data, reply);

disconnect();

reply->writeNoException();

return NO_ERROR;

} break;

case SET_PREVIEW_TARGET: {

ALOGV("SET_PREVIEW_TARGET");

CHECK_INTERFACE(ICamera, data, reply);

sp<IGraphicBufferProducer> st =

interface_cast<IGraphicBufferProducer>(data.readStrongBinder());

reply->writeInt32(setPreviewTarget(st));

return NO_ERROR;

} break;

default:

return BBinder::onTransact(code, data, reply, flags);

}

将DISCONNECT与SET_PREVIEW_TARGET分别与函数disconnect()和setPreviewTarget做绑定

接着看binder service proxy类的实现，对应BpCamera：

class BpCamera: public BpInterface<ICamera>

{

public:

BpCamera(const sp<IBinder>& impl)

: BpInterface<ICamera>(impl)

{

}

// disconnect from camera service

void disconnect()

{

ALOGV("disconnect");

Parcel data, reply;

data.writeInterfaceToken(ICamera::getInterfaceDescriptor());

remote()->transact(DISCONNECT, data, &reply);

reply.readExceptionCode();

}

// pass the buffered IGraphicBufferProducer to the camera service

status_t setPreviewTarget(const sp<IGraphicBufferProducer>& bufferProducer)

{

ALOGV("setPreviewTarget");

Parcel data, reply;

data.writeInterfaceToken(ICamera::getInterfaceDescriptor());

sp<IBinder> b(bufferProducer->asBinder());

data.writeStrongBinder(b);

remote()->transact(SET_PREVIEW_TARGET, data, &reply);

return reply.readInt32();

}

很简单，将相关参数封装到Parcel中后，调用remote()->transact将数据发送出去。

接下去，把这个binder service注册到service manager中

首先，先初始化service manager对应的binder proxy service：

代码如下：

//通过调用ProcessState:: getStrongProxyForHandle获取service manager对应的BpBinder

//service manager的handle固定为0

Sp<IBinder> bpSM = ProcessState::self()->getStrongProxyForHandle(0)；

//接着将其转换成IServiceManager对应的binder proxy service

sp<IServiceManager> servicemanager = IServiceManager::asInterface(bpSM);

注册代码：

sp<BnCamera> bnCamera = new BnCamera();

sevicemanager->addService(“demoCamera”, bnCamera);

就这样，我们在service manager添加了一个名叫demoCamera的binder service

客户进程如果要连接这个binderservice，只需要使用如下代码，创建binderservice proxy对象即可：

Sp<IBinder> pp = servicemanager->getService(“demoCamera”);

Sp<ICamera> proxyCamera = ICamera::asInterface(pp);

接着就可以直接通过proxyCamera与binder service进行通信了

So easy！！！

2.5 JAVA(Android)层封装

JAVA层的封装主要分三部分：

1）定义Binder和BinderProxy两个类，然后通过JNI，跟C++层的BBinder和BpBinder做绑定

2）使用AIDL接口描述语言和相关解析工具，来封装bindertransaction code的定义和与对应接口函数的绑定

3）通过Service的onBind接口，将Binder返回给ActivityManagerService统一管理，在有应用申请连接这个Binder服务时，AMS再将Binder服务对应的Binder proxy通过回调传给应用，从而实现通过Intent来找到指定Binder服务

先说第一部分

Binder相关的JNI代码文件android_util_binder.cpp

Java对象跟C++对象数据进行绑定的基本都是通过在Java类定义一个long类型的变量，然后在jni调用c++代码时，将创建的C++对象地址保存到Java对象的这个long类型变量中。

接着在Java类定义native函数，然后通过JNI跟C++的函数做一一绑定

除了上面说的这些以外，Java端的Binder和BinderProxy和C++层的BBinder和BpBinder还有两个问题需要解决：

1） BBinder的收到onTransact事件后，如何回调到java Binder？

2）如何将基于Parcel.java的binder数据反序列化成Java Binder或BinderProxy对象

第一个问题，Android在C++层定义了一个派生自BBinder的类JavaBBinder来解决：

class JavaBBinder : public BBinder

如何在JavaBBinder::onTransact时回调Java对象的onTransact函数：

jboolean res = env->CallBooleanMethod(mObject, gBinderOffsets.mExecTransact,

code, reinterpret_cast<jlong>(&data), reinterpret_cast<jlong>(reply), flags);

第二个问题直接看Parcel.java的jni映射函数看其怎么反序列binder对象就可以了，

JavaParcel类对应的jni代码文件为 android_os_parcel.cpp

Parcel反序列化binder函数为readStringBinder，对应jni代码：

static jobject android_os_Parcel_readStrongBinder(JNIEnv* env, jclass clazz, jlong nativePtr)

{

Parcel* parcel = reinterpret_cast<Parcel*>(nativePtr);

if (parcel != NULL) {

return javaObjectForIBinder(env, parcel->readStrongBinder());

}

return NULL;

}

通过parcel->readStrongBinder()反序列后，得到对应的BBinder或BpBinder对象，接着传给

javaObjectForIBinder

jobject javaObjectForIBinder(JNIEnv* env, const sp<IBinder>& val)

{

if (val == NULL) return NULL;

if (val->checkSubclass(&gBinderOffsets)) {

// One of our own!

jobject object = static_cast<JavaBBinder*>(val.get())->object();

LOGDEATH("objectForBinder %p: it's our own %p!\n", val.get(), object);

return object;

}

// For the rest of the function we will hold this lock, to serialize

// looking/creation of Java proxies for native Binder proxies.

AutoMutex _l(mProxyLock);

// Someone else's... do we know about it?

jobject object = (jobject)val->findObject(&gBinderProxyOffsets);

if (object != NULL) {

jobject res = jniGetReferent(env, object);

if (res != NULL) {

ALOGV("objectForBinder %p: found existing %p!\n", val.get(), res);

return res;

}

LOGDEATH("Proxy object %p of IBinder %p no longer in working set!!!", object, val.get());

android_atomic_dec(&gNumProxyRefs);

val->detachObject(&gBinderProxyOffsets);

env->DeleteGlobalRef(object);

}

object = env->NewObject(gBinderProxyOffsets.mClass, gBinderProxyOffsets.mConstructor);

if (object != NULL) {

LOGDEATH("objectForBinder %p: created new proxy %p !\n", val.get(), object);

// The proxy holds a reference to the native object.

env->SetLongField(object, gBinderProxyOffsets.mObject, (jlong)val.get());

val->incStrong((void*)javaObjectForIBinder);

// The native object needs to hold a weak reference back to the

// proxy, so we can retrieve the same proxy if it is still active.

jobject refObject = env->NewGlobalRef(

env->GetObjectField(object, gBinderProxyOffsets.mSelf));

val->attachObject(&gBinderProxyOffsets, refObject,

jnienv_to_javavm(env), proxy_cleanup);

// Also remember the death recipients registered on this proxy

sp<DeathRecipientList> drl = new DeathRecipientList;

drl->incStrong((void*)javaObjectForIBinder);

env->SetLongField(object, gBinderProxyOffsets.mOrgue, reinterpret_cast<jlong>(drl.get()));

// Note that a new object reference has been created.

android_atomic_inc(&gNumProxyRefs);

incRefsCreated(env);

}

return object;

}

先通过checkSubClass来判断这个Binder是否是JavaBBinder对象，如果是，说明是nativebinder，直接静态强转成JavaBBinder类型，然后调用object拿到对应的java Binder对象，否则，通过env->newObject来创建JavaBinderProxy对象

接着将其返回给Java层

接着说第二部分

其实C++层将binder transactioncode和自定义功能接口函数的绑定这块封装的已经比较方便了，不过如果我们回过头来看看绑定相关代码，其实会发现，这些代码都非常标准化，都有两个Parcel对象用来保存输入和返回数据，还有就是将每一个定义的transaction code和某函数调用一一对应起来，既然这么标准化，那能不能让这块代码自动生成，我们只需要写一个接口，把所有的函数名，以及函数对应的输入和返回数据类型描述清楚就好了

android就是这么做的：

1）使用AIDL语言描述binder传输接口信息，并保存到.aidl文

2）使用AIDL语言解析工具，将.aidl文件内容解析后，生成对应的.java文件，这个java文件会自动生成transaction code列表，然后实现派生自Binder的Stub类做binder service，还有实现派生自BinderProxy的Proxy类作为binder service proxy，这两个类内部实现的代码跟C++类似，这里就不再介绍

最后说第三部分

通过第二部分AIDL相关描述，我们知道通过定义AIDL文件，就可以自动生成Stub类做binder service，那如何将这个binder service添加到binder kernel呢？

之前说过可以通过servicemanager，但是servicemanager.addService对普通的android app来说是没有权限的

Android采用的方法是，可以在Service的onBind函数返回Stub类对应的binder service，然后用startService启动这个service后，ActivityThread在调用pushService将其push到ActivityManagerService之前，会调用service.onBinder获取这个binderservice，接着作为pushService的参数传到ActivityManagerService，由于ActivityThread和ActivityManagerService之间就是基于Binder进行通信的，还记得上面说的吗？Native binder化身数据流在binder传过，最终反序列化后拿到的就是对应的handle(binder proxy)，然后ActivityManagerService将这个binderproxy相关数据保存到ServiceRecord的bindings列表中。

接下去，app就可以通过context.bindService，传入ServiceConnection，如果绑定成功，则会将对应的binderproxy回调回来，大体的流程是这样的：

1）ContextImpl.bindService回调用LoadedApk的成员函数getServiceDispatcher并传入

Serviceconnection对象

2）getServiceDispatcher会创建ServiceDispatcher来跟ServiceConnection绑定, 在

ServiceDispatche内部会创建类型为IServiceConnection.Stub的binder service

3）接着调用AMS的bindService，将IServiceConnection对应的binderservice和intent等数

据传到AMS

4）AMS收到bindService后，首先会根据Intent从对应ServiceRecord的bindings列表中拿到对应的binder proxy(对应Service.onBind)，然后保存到创建connectionRecord中,接着添加到 ServiceRecord的connections这个Map中，map的key为binder，value为connectionRecord列表

5）接着再回调IServiceConnection.Connected将binder proxy(对应Service.onBind)传到第2条中的ServiceDispatcher中，然后ServiceDispatcher再将其回调给ServiceConnection，ServiceConnection.onServiceConnected再通过对应接口的.asInterface将IBinder 转换后，就可以使用了。

上面只是一个简单的介绍，详细代码就不贴了，大家可自行看源码。