理解 Android Binder 机制(二):C++层 | 您所在的位置:网站首页 › draw_string16 › 理解 Android Binder 机制(二):C++层 |
原文链接 本文是Android Binder机制解析的第二篇文章,会讲解Binder Framework的C++部分逻辑。 Binder机制分析的第一篇文章,请移步这里:理解 Android Binder 机制(一):驱动篇 前言Framework是一个中间层,它对接了底层实现,封装了复杂的内部逻辑,并提供供外部使用的接口。Framework层是应用程序开发的基础。 Binder Framework层分为C++和Java两个部分,为了达到功能的复用,中间通过JNI进行衔接。 Binder Framework的C++部分,头文件位于这个路径:/frameworks/native/include/binder/,实现位于这个路径:/frameworks/native/libs/binder/ 。Binder库最终会编译成一个动态链接库:libbinder.so,供其他进程链接使用。 为了便于说明,下文中我们将Binder Framework 的C++部分称之为libbinder。 主要结构libbinder中,将实现分为Proxy和Native两端。Proxy对应了上文提到的Client端,是服务对外提供的接口。而Native是服务实现的一端,对应了上文提到的Server端。类名中带有小写字母p的(例如BpInterface),就是指Proxy端。类名带有小写字母n的(例如BnInterface),就是指Native端。 Proxy代表了调用方,通常与服务的实现不在同一个进程,因此下文中,我们也称Proxy端为“远程”端。Native端是服务实现的自身,因此下文中,我们也称Native端为”本地“端。 这里,我们先对libbinder中的主要类做一个简要说明,了解一下它们的关系,然后再详细的讲解。 类名说明BpRefBaseRefBase的子类,提供remote()方法获取远程BinderIInterfaceBinder服务接口的基类,Binder服务通常需要同时提供本地接口和远程接口BpInterface远程接口的基类,远程接口是供客户端调用的接口集BnInterface本地接口的基类,本地接口是需要服务中真正实现的接口集IBinerBinder对象的基类,BBinder和BpBinder都是这个类的子类BpBinder远程Binder,这个类提供transact方法来发送请求,BpXXX实现中会用到BBinder本地Binder,服务实现方的基类,提供了onTransact接口来接收请求ProcessState代表了使用Binder的进程IPCThreadState代表了使用Binder的线程,这个类中封装了与Binder驱动通信的逻辑Parcel在Binder上传递的数据的包装器下图描述了这些类之间的关系: 另外说明一下,Binder服务的实现类(图中紫色部分)通常都会遵守下面的命名规则: 服务的接口使用I字母作为前缀 远程接口使用Bp作为前缀 本地接口使用Bn作为前缀 看了上面这些介绍,你可能还是不太容易理解。不过不要紧,下面我们会逐步拆分讲解这些内容。 在这幅图中,浅黄色部分的结构是最难理解的,因此我们先从它们着手。 我们先来看看IBinder这个类。这个类描述了所有在Binder上传递的对象,它既是Binder本地对象BBinder的父类,也是Binder远程对象BpBinder的父类。这个类中的主要方法说明如下: 方法名说明localBinder获取本地Binder对象remoteBinder获取远程Binder对象transact进行一次Binder操作queryLocalInterface尝试获取本地Binder,如何失败返回NULLgetInterfaceDescriptor获取Binder的服务接口描述,其实就是Binder服务的唯一标识isBinderAlive查询Binder服务是否还活着pingBinder发送PING_TRANSACTION给Binder服务BpBinder的实例代表了远程Binder,这个类的对象将被客户端调用。其中handle方法会返回指向Binder服务实现者的句柄,这个类最重要就是提供了transact方法,这个方法会将远程调用的参数封装好发送的Binder驱动。 由于每个Binder服务通常都会提供多个服务接口,而这个方法中的uint32_t code参数就是用来对服务接口进行编号区分的。Binder服务的每个接口都需要指定一个唯一的code,这个code要在Proxy和Native端配对好。当客户端将请求发送到服务端的时候,服务端根据这个code(onTransact方法中)来区分调用哪个接口方法。 BBinder的实例代表了本地Binder,它描述了服务的提供方,所有Binder服务的实现者都要继承这个类(的子类),在继承类中,最重要的就是实现onTransact方法,因为这个方法是所有请求的入口。因此,这个方法是和BpBinder中的transact方法对应的,这个方法同样也有一个uint32_t code参数,在这个方法的实现中,由服务提供者通过code对请求的接口进行区分,然后调用具体实现服务的方法。 IBinder中定义了uint32_t code允许的范围: FIRST_CALL_TRANSACTION = 0x00000001,LAST_CALL_TRANSACTION = 0x00ffffff,Binder服务要保证自己提供的每个服务接口有一个唯一的code,例如某个Binder服务可以将:add接口code设为1,minus接口code设为2,multiple接口code设为3,divide接口code设为4,等等。 讲完了IBinder,BpBinder和BBinder三个类,我们再来看看BpReBase,IInterface,BpInterface和BnInterface。 每个Binder服务都是为了某个功能而实现的,因此其本身会定义一套接口集(通常是C++的一个类)来描述自己提供的所有功能。而Binder服务既有自身实现服务的类,也要有给客户端进程调用的类。为了便于开发,这两中类里面的服务接口应当是一致的,例如:假设服务实现方提供了一个接口为add(int a, int b)的服务方法,那么其远程接口中也应当有一个add(int a, int b)方法。因此为了实现方便,本地实现类和远程接口类需要有一个公共的描述服务接口的基类(即上图中的IXXXService)来继承。而这个基类通常是IInterface的子类,IInterface的定义如下: class IInterface : public virtual RefBase {public: IInterface(); static sp asBinder(const IInterface*); static sp asBinder(const sp&);protected: virtual ~IInterface(); virtual IBinder* onAsBinder() = 0; };之所以要继承自IInterface类是因为这个类中定义了onAsBinder让子类实现。onAsBinder在本地对象的实现类中返回的是本地对象,在远程对象的实现类中返回的是远程对象。onAsBinder方法被两个静态方法asBinder方法调用。有了这些接口之后,在代码中便可以直接通过IXXX::asBinder方法获取到不用区分本地还是远程的IBinder对象。这个在跨进程传递Binder对象的时候有很大的作用(因为不用区分具体细节,只要直接调用和传递就好)。 下面,我们来看一下BpInterface和BnInterface的定义: templateclass BnInterface : public INTERFACE, public BBinder {public: virtual sp queryLocalInterface(const String16& _descriptor); virtual const String16& getInterfaceDescriptor() const;protected: virtual IBinder* onAsBinder(); };// ----------------------------------------------------------------------templateclass BpInterface : public INTERFACE, public BpRefBase {public: BpInterface(const sp& remote);protected: virtual IBinder* onAsBinder(); };这两个类都是模板类,它们在继承自INTERFACE的基础上各自继承了另外一个类。这里的INTERFACE便是我们Binder服务接口的基类。另外,BnInterface继承了BBinder类,由此可以通过复写onTransact方法来提供实现。BpInterface继承了BpRefBase,通过这个类的remote方法可以获取到指向服务实现方的句柄。在客户端接口的实现类中,每个接口在组装好参数之后,都会调用remote()->transact来发送请求,而这里其实就是调用的BpBinder的transact方法,这样请求便通过Binder到达了服务实现方的onTransact中。这个过程如下图所示: 基于Binder框架开发的服务,除了满足上文提到的类名规则之外,还需要遵守其他一些共同的规约: 为了进行服务的区分,每个Binder服务需要指定一个唯一的标识,这个标识通过getInterfaceDescriptor返回,类型是一个字符串。通常,Binder服务会在类中定义static const android::String16 descriptor;这样一个常量来描述这个标识符,然后在getInterfaceDescriptor方法中返回这个常量。 为了便于调用者获取到调用接口,服务接口的公共基类需要提供一个android::sp asInterface方法来返回基类对象指针。 由于上面提到的这两点对于所有Binder服务的实现逻辑都是类似的。为了简化开发者的重复工作,在libbinder中,定义了两个宏来简化这些重复工作,它们是: #define DECLARE_META_INTERFACE(INTERFACE) \ static const android::String16 descriptor; \ static android::sp asInterface( \ const android::sp& 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::asInterface( \ const android::sp& obj) \ { \ android::sp intr; \ if (obj != NULL) { \ intr = static_cast( \ obj->queryLocalInterface( \ I##INTERFACE::descriptor).get()); \ if (intr == NULL) { \ intr = new Bp##INTERFACE(obj); \ } \ } \ return intr; \ } \ I##INTERFACE::I##INTERFACE() { } \ I##INTERFACE::~I##INTERFACE() { } \有了这两个宏之后,开发者只要在接口基类(IXXX)头文件中,使用DECLARE_META_INTERFACE宏便完成了需要的组件的声明。然后在cpp文件中使用IMPLEMENT_META_INTERFACE便完成了这些组件的实现。 Binder的初始化在讲解Binder驱动的时候我们就提到:任何使用Binder机制的进程都必须要对/dev/binder设备进行open以及mmap之后才能使用,这部分逻辑是所有使用Binder机制进程共同的。对于这种共同逻辑的封装便是Framework层的职责之一。libbinder中,ProcessState类封装了这个逻辑,相关代码见下文。 这里是ProcessState构造函数,在这个函数中,初始化mDriverFD的时候调用了open_driver方法打开binder设备,然后又在函数体中,通过mmap进行内存映射。 ProcessState::ProcessState() : mDriverFD(open_driver()) , mVMStart(MAP_FAILED) , mThreadCountLock(PTHREAD_MUTEX_INITIALIZER) , mThreadCountDecrement(PTHREAD_COND_INITIALIZER) , mExecutingThreadsCount(0) , mMaxThreads(DEFAULT_MAX_BINDER_THREADS) , mStarvationStartTimeMs(0) , mManagesContexts(false) , mBinderContextCheckFunc(NULL) , mBinderContextUserData(NULL) , mThreadPoolStarted(false) , mThreadPoolSeq(1) { if (mDriverFD >= 0) { 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; } } LOG_ALWAYS_FATAL_IF(mDriverFD = 0) { int vers = 0; status_t result = ioctl(fd, BINDER_VERSION, &vers); if (result == -1) { ALOGE("Binder ioctl to obtain version failed: %s", strerror(errno)); close(fd); fd = -1; } if (result != 0 || vers != BINDER_CURRENT_PROTOCOL_VERSION) { ALOGE("Binder driver protocol does not match user space protocol!"); close(fd); fd = -1; } size_t maxThreads = DEFAULT_MAX_BINDER_THREADS; result = ioctl(fd, BINDER_SET_MAX_THREADS, &maxThreads); if (result == -1) { ALOGE("Binder ioctl to set max threads failed: %s", strerror(errno)); } } else { ALOGW("Opening '/dev/binder' failed: %s\n", strerror(errno)); } return fd; }ProcessState是一个Singleton(单例)类型的类,在一个进程中,只会存在一个实例。通过ProcessState::self()接口获取这个实例。一旦获取这个实例,便会执行其构造函数,由此完成了对于Binder设备的初始化工作。 关于Binder传递数据的大小限制由于Binder的数据需要跨进程传递,并且还需要在内核上开辟空间,因此允许在Binder上传递的数据并不是无无限大的。mmap中指定的大小便是对数据传递的大小限制: #define BINDER_VM_SIZE ((1*1024*1024) - (4096 *2)) // 1M - 8kmVMStart = mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0);这里我们看到,在进行mmap的时候,指定了最大size为BINDER_VM_SIZE,即 1M – 8k的大小。 因此我们在开发过程中,一次Binder调用的数据总和不能超过这个大小。 对于这个区域的大小,我们也可以在设备上进行确认。这里我们还之前提到的system_server为例。上面我们讲解了通过procfs来获取映射的内存地址,除此之外,我们也可以通过showmap命令,来确定这块区域的大小,相关命令如下: angler:/ # ps | grep system_server system 1889 526 2353404 135968 SyS_epoll_ 72972eeaf4 S system_server angler:/ # showmap 1889 | grep "/dev/binder" 1016 4 4 0 0 4 0 0 1 /dev/binder这里可以看到,这块区域的大小正是 1M – 8K = 1016k。 Tips: 通过showmap命令可以看到进程的详细内存占用情况。在实际的开发过程中,当我们要对某个进程做内存占用分析的时候,这个命令是相当有用的。建议读者尝试通过showmap命令查看system_server或其他感兴趣进程的完整map,看看这些进程都依赖了哪些库或者模块,以及内存占用情况是怎样的。 与驱动的通信上文提到ProcessState是一个单例类,一个进程只有一个实例。而负责与Binder驱动通信的IPCThreadState也是一个单例类。但这个类不是一个进程只有一个实例,而是一个线程有一个实例。 IPCThreadState负责了与驱动通信的细节处理。这个类中的关键几个方法说明如下: 方法说明transact公开接口。供Proxy发送数据到驱动,并读取返回结果sendReply供Server端写回请求的返回结果waitForResponse发送请求后等待响应结果talkWithDriver通过ioctl BINDER_WRITE_READ来与驱动通信writeTransactionData写入一次事务的数据executeCommand处理binder_driver_return_protocol协议命令freeBuffer通过BC_FREE_BUFFER命令释放BufferBpBinder::transact方法在发送请求的时候,其实就是直接调用了IPCThreadState对应的方法来发送请求到Binder驱动的,相关代码如下: status_t BpBinder::transact( uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags) { 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方法主要逻辑如下: status_t IPCThreadState::transact(int32_t handle, uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags) { status_t err = data.errorCheck(); flags |= TF_ACCEPT_FDS; if (err == NO_ERROR) { 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 (reply) { err = waitForResponse(reply); } else { Parcel fakeReply; err = waitForResponse(&fakeReply); } } else { err = waitForResponse(NULL, NULL); } return err; }这段代码应该还是比较好理解的:首先通过writeTransactionData写入数据,然后通过waitForResponse等待返回结果。TF_ONE_WAY表示此次请求是单向的,即:不用真正等待结果即可返回。 而writeTransactionData方法其实就是在组装binder_transaction_data数据: 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; tr.target.ptr = 0; /* Don't pass uninitialized stack data to a remote process */ tr.target.handle = handle; 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(statusBuffer); tr.offsets_size = 0; tr.data.ptr.offsets = 0; } else { return (mLastError = err); } mOut.writeInt32(cmd); mOut.write(&tr, sizeof(tr)); return NO_ERROR; }对于binder_transaction_data在讲解Binder驱动的时候我们已经详细讲解过了。而这里的Parcel我们还不了解,那么接下来我们马上就来看一下这个类。 数据包装器:ParcelBinder上提供的是跨进程的服务,每个服务包含了不同的接口,每个接口的参数数量和类型都不一样。那么当客户端想要调用服务端的接口,参数是如何跨进程传递给服务端的呢?除此之外,服务端想要给客户端返回结果,结果又是如何传递回来的呢? 这些问题的答案就是:Parcel。Parcel就像一个包装器,调用者可以以任意顺序往里面放入需要的数据,所有写入的数据就像是被打成一个整体的包,然后可以直接在Binde上传输。 Parcel提供了所有基本类型的写入和读出接口,下面是其中的一部分: ...status_t writeInt32(int32_t val);status_t writeUint32(uint32_t val);status_t writeInt64(int64_t val);status_t writeUint64(uint64_t val);status_t writeFloat(float val);status_t writeDouble(double val);status_t writeCString(const char* str);status_t writeString8(const String8& str);status_t readInt32(int32_t *pArg) const;uint32_t readUint32() const;status_t readUint32(uint32_t *pArg) const;int64_t readInt64() const;status_t readInt64(int64_t *pArg) const;uint64_t readUint64() const;status_t readUint64(uint64_t *pArg) const;float readFloat() const;status_t readFloat(float *pArg) const;double readDouble() const;status_t readDouble(double *pArg) const;intptr_t readIntPtr() const;status_t readIntPtr(intptr_t *pArg) const;bool readBool() const;status_t readBool(bool *pArg) const;char16_t readChar() const;status_t readChar(char16_t *pArg) const;int8_t readByte() const;status_t readByte(int8_t *pArg) const;// Read a UTF16 encoded string, convert to UTF8status_t readUtf8FromUtf16(std::string* str) const;status_t readUtf8FromUtf16(std::unique_ptr* str) const;const char* readCString() const; ...因此对于基本类型,开发者可以直接调用接口写入和读出。而对于非基本类型,需要由开发者将其拆分成基本类型然后写入到Parcel中(读出的时候也是一样)。 Parcel会将所有写入的数据进行打包,Parcel本身可以作为一个整体在进程间传递。接收方在收到Parcel之后,只要按写入同样的顺序读出即可。 这个过程,和我们现实生活中寄送包裹做法是一样的:我们将需要寄送的包裹放到硬纸盒中交给快递公司。快递公司将所有的包裹进行打包,然后集中放到运输车中送到目的地,到了目的地之后然后再进行拆分。 Parcel既包含C++部分的实现,也同时提供了Java的接口,中间通过JNI衔接。Java层的接口其实仅仅是一层包装,真正的实现都是位于C++部分中,它们的关系如下图所示: 特别需要说明一下的是,Parcel类除了可以传递基本数据类型,还可以传递Binder对象: status_t Parcel::writeStrongBinder(const sp& val) { return flatten_binder(ProcessState::self(), val, this); }这个方法写入的是sp类型的对象,而IBinder既可能是本地Binder,也可能是远程Binder,这样我们就不可以不用关心具体细节直接进行Binder对象的传递。 这也是为什么IInterface中定义了两个asBinder的static方法,如果你不记得了,请回忆一下这两个方法: static sp asBinder(const IInterface*);static sp asBinder(const sp&);而对于Binder驱动,我们前面已经讲解过:Binder驱动并不是真的将对象在进程间序列化传递,而是由Binder驱动完成了对于Binder对象指针的解释和翻译,使调用者看起来就像在进程间传递对象一样。 Framework层的线程管理在讲解Binder驱动的时候,我们就讲解过驱动中对应线程的管理。这里我们再来看看,Framework层是如何与驱动层对接进行线程管理的。 ProcessState::setThreadPoolMaxThreadCount 方法中,会通过BINDER_SET_MAX_THREADS命令设置进程支持的最大线程数量: #define DEFAULT_MAX_BINDER_THREADS 15status_t ProcessState::setThreadPoolMaxThreadCount(size_t maxThreads) { status_t result = NO_ERROR; if (ioctl(mDriverFD, BINDER_SET_MAX_THREADS, &maxThreads) != -1) { mMaxThreads = maxThreads; } else { result = -errno; ALOGE("Binder ioctl to set max threads failed: %s", strerror(-result)); } return result; }由此驱动便知道了该Binder服务支持的最大线程数。驱动在运行过程中,会根据需要,并在没有超过上限的情况下,通过BR_SPAWN_LOOPER命令通知进程创建线程: IPCThreadState在收到BR_SPAWN_LOOPER请求之后,便会调用ProcessState::spawnPooledThread来创建线程: status_t IPCThreadState::executeCommand(int32_t cmd) { ... case BR_SPAWN_LOOPER: mProcess->spawnPooledThread(false); break; ... }ProcessState::spawnPooledThread方法负责为线程设定名称并创建线程: void ProcessState::spawnPooledThread(bool isMain) { if (mThreadPoolStarted) { String8 name = makeBinderThreadName(); ALOGV("Spawning new pooled thread, name=%s\n", name.string()); sp t = new PoolThread(isMain); t->run(name.string()); } }线程在run之后,会调用threadLoop将自身添加的线程池中: virtual bool threadLoop(){ IPCThreadState::self()->joinThreadPool(mIsMain); return false; }而IPCThreadState::joinThreadPool方法中,会根据当前线程是否是主线程发送BC_ENTER_LOOPER或者BC_REGISTER_LOOPER命令告知驱动线程已经创建完毕。整个调用流程如下图所示: C++ Binder服务举例单纯的理论知识也许并不能让我们非常好的理解,下面我们以一个具体的Binder服务例子来结合上文的知识进行讲解。 下面以PowerManager为例,来看看C++的Binder服务是如何实现的。 下图是PowerManager C++部分的实现类图(PowerManager也有Java层的接口,但我们这里就不讨论了)。 图中Binder Framework中的类我们在上文中已经介绍过了,而PowerManager相关的四个类,便是在Framework的基础上开发的。 IPowerManager定义了PowerManager所有对外提供的功能接口,其子类都继承了这些接口。 BpPowerManager是提供给客户端调用的远程接口 BnPowerManager中只有一个onTransact方法,该方法根据请求的code来对接每个请求,并直接调用PowerManager中对应的方法 PowerManager是服务真正的实现 在IPowerManager.h中,通过DECLARE_META_INTERFACE(PowerManager);声明一些Binder必要的组件。在IPowerManager.cpp中,通过IMPLEMENT_META_INTERFACE(PowerManager, "android.os.IPowerManager");宏来进行实现。 本地实现:Native端服务的本地实现主要就是实现BnPowerManager和PowerManager两个类,PowerManager是BnPowerManager的子类,因此在BnPowerManager中调用自身的virtual方法其实都是在子类PowerManager类中实现的。 BnPowerManager类要做的就是复写onTransact方法,这个方法的职责是:根据请求的code区分具体调用的是那个接口,然后按顺序从Parcel中读出打包好的参数,接着调用留待子类实现的虚函数。需要注意的是:这里从Parcel读出参数的顺序需要和BpPowerManager中写入的顺序完全一致,否则读出的数据将是无效的。 电源服务包含了好几个接口。虽然每个接口的实现逻辑各不一样,但从Binder框架的角度来看,它们的实现结构是一样。而这里我们并不关心电源服务的实现细节,因此我们取其中一个方法看其实现方式即可。 首先我们来看一下BnPowerManager::onTransact中的代码片段: status_t BnPowerManager::onTransact(uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags) { switch (code) { ... case IPowerManager::REBOOT: { CHECK_INTERFACE(IPowerManager, data, reply); bool confirm = data.readInt32(); String16 reason = data.readString16(); bool wait = data.readInt32(); return reboot(confirm, reason, wait); } ... } }这段代码中我们看到了实现中是如何根据code区分接口,并通过Parcel读出调用参数,然后调用具体服务方的。 而PowerManager这个类才真正是服务实现的本体,reboot方法真正实现了重启的逻辑: status_t PowerManager::reboot(bool confirm, const String16& reason, bool wait) { const std::string reason_str(String8(reason).string()); if (!(reason_str.empty() || reason_str == kRebootReasonRecovery)) { LOG(WARNING) giveThreadPoolName(); IPCThreadState::self()->joinThreadPool(); }由此可见,Binder服务的发布其实有三个步骤: 通过IServiceManager::addService在ServiceManager中进行服务的注册 通过ProcessState::startThreadPool启动线程池 通过IPCThreadState::joinThreadPool将主线程加入的Binder中 远程接口:Proxy端Proxy类是供客户端使用的。BpPowerManager需要实现IPowerManager中的所有接口。 我们还是以上文提到的reboot接口为例,来看看BpPowerManager::reboot方法是如何实现的: virtual status_t reboot(bool confirm, const String16& reason, bool wait){ Parcel data, reply; data.writeInterfaceToken(IPowerManager::getInterfaceDescriptor()); data.writeInt32(confirm); data.writeString16(reason); data.writeInt32(wait); return remote()->transact(REBOOT, data, &reply, 0); }这段代码很简单,逻辑就是:通过Parcel写入调用参数进行打包,然后调用remote()->transact将请求发送出去。 其实BpPowerManager中其他方法,甚至所有其他BpXXX中所有的方法,实现都是和这个方法一样的套路。就是:通过Parcel打包数据,通过remote()->transact发送数据。而这里的remote()返回的其实就是BpBinder对象,由此经由IPCThreadState将数据发送到了驱动层。如果你已经不记得,请重新看一下下面这幅图: 另外,需要一下的是,这里的REBOOT就是请求的code,而这个code是在IPowerManager中定义好的,这样子类可以直接使用,并保证是一致的: enum { ACQUIRE_WAKE_LOCK = IBinder::FIRST_CALL_TRANSACTION, ACQUIRE_WAKE_LOCK_UID = IBinder::FIRST_CALL_TRANSACTION + 1, RELEASE_WAKE_LOCK = IBinder::FIRST_CALL_TRANSACTION + 2, UPDATE_WAKE_LOCK_UIDS = IBinder::FIRST_CALL_TRANSACTION + 3, POWER_HINT = IBinder::FIRST_CALL_TRANSACTION + 4, UPDATE_WAKE_LOCK_SOURCE = IBinder::FIRST_CALL_TRANSACTION + 5, IS_WAKE_LOCK_LEVEL_SUPPORTED = IBinder::FIRST_CALL_TRANSACTION + 6, USER_ACTIVITY = IBinder::FIRST_CALL_TRANSACTION + 7, WAKE_UP = IBinder::FIRST_CALL_TRANSACTION + 8, GO_TO_SLEEP = IBinder::FIRST_CALL_TRANSACTION + 9, NAP = IBinder::FIRST_CALL_TRANSACTION + 10, IS_INTERACTIVE = IBinder::FIRST_CALL_TRANSACTION + 11, IS_POWER_SAVE_MODE = IBinder::FIRST_CALL_TRANSACTION + 12, SET_POWER_SAVE_MODE = IBinder::FIRST_CALL_TRANSACTION + 13, REBOOT = IBinder::FIRST_CALL_TRANSACTION + 14, SHUTDOWN = IBinder::FIRST_CALL_TRANSACTION + 15, CRASH = IBinder::FIRST_CALL_TRANSACTION + 16, };服务的获取在服务已经发布之后,客户端该如何获取其服务接口然后对其发出请求调用呢? 很显然,客户端应该通过BpPowerManager的对象来请求其服务。但看一眼BpPowerManager的构造函数,我们会发现,似乎没法直接创建一个这类的对象,因为这里需要一个sp类型的参数。 BpPowerManager(const sp& impl) : BpInterface(impl) { }那么这个sp参数我们该从哪里获取呢? 回忆一下前面的内容:Proxy其实是包含了一个指向Server的句柄,所有的请求发送出去的时候都需要包含这个句柄作为一个标识。而想要拿到这个句柄,我们自然应当想到ServiceManager。我们再看一下ServiceManager的接口自然就知道这个sp该如何获取了: /** * Retrieve an existing service, blocking for a few seconds * if it doesn't yet exist. */virtual sp getService( const String16& name) const = 0;/** * Retrieve an existing service, non-blocking. */virtual sp checkService( const String16& name) const = 0;这里的两个方法都可以获取服务对应的sp对象,一个是阻塞式的,另外一个不是。传递的参数是一个字符串,这个就是服务在addServer时对应的字符串,而对于PowerManager来说,这个字符串就是”power”。因此,我们可以通过下面这行代码创建出BpPowerManager的对象。 sp bs = defaultServiceManager()->checkService(serviceName); sp pm = new BpPowerManager(bs);但这样做还会存在一个问题:BpPowerManager中的方法调用是经由驱动然后跨进程调用的。通常情况下,当我们的客户端与PowerManager服务所在的进程不是同一个进程的时候,这样调用是没有问题的。那假设我们的客户端又刚好和PowerManager服务在同一个进程该如何处理呢? 针对这个问题,Binder Framework提供的解决方法是:通过interface_cast这个方法来获取服务的接口对象,由这个方法本身根据是否是在同一个进程,来自动确定返回一个本地Binder还是远程Binder。interface_cast是一个模板方法,其源码如下: templateinline sp interface_cast(const sp& obj) { return INTERFACE::asInterface(obj); }调用这个方法的时候我们需要指定Binder服务的IInterface,因此对于PowerManager,我们需要这样获取其Binder接口对象: const String16 serviceName("power"); sp bs = defaultServiceManager()->checkService(serviceName);if (bs == NULL) { return NAME_NOT_FOUND; } sp pm = interface_cast(bs);我们再回头看一下interface_cast这个方法体,这里是在调用INTERFACE::asInterface(obj),而对于IPowerManager来说,其实就是IPowerManager::asInterface(obj)。那么IPowerManager::asInterface这个方法是哪里定义的呢? 这个正是上文提到的DECLARE_META_INTERFACE和IMPLEMENT_META_INTERFACE两个宏所起的作用。IMPLEMENT_META_INTERFACE宏包含了下面这段代码: android::sp I##INTERFACE::asInterface( \ const android::sp& obj) \ { \ android::sp intr; \ if (obj != NULL) { \ intr = static_cast( \ obj->queryLocalInterface( \ I##INTERFACE::descriptor).get()); \ if (intr == NULL) { \ intr = new Bp##INTERFACE(obj); \ } \ } \ return intr; \ } \这里我们将“##INTERFACE”通过“PowerManager”代替,得到的结果就是: android::sp IPowerManager::asInterface( const android::sp& obj) { android::sp intr; if (obj != NULL) { intr = static_cast( obj->queryLocalInterface( IPowerManager::descriptor).get()); if (intr == NULL) { intr = new BpPowerManager(obj); } } return intr; }这个便是IPowerManager::asInterface方法的实现,这段逻辑的含义就是: 先尝试通过queryLocalInterface看看能够获得本地Binder,如果是在服务所在进程调用,自然能获取本地Binder,否则将返回NULL 如果获取不到本地Binder,则创建并返回一个远程Binder。 由此保证了:我们在进程内部的调用,是直接通过方法调用的形式。而不在同一个进程的时候,才通过Binder进行跨进程的调用。 C++层的ServiceManager前文已经两次介绍过ServiceManager了,我们知道这个模块负责了所有Binder服务的管理,并且也看到了Binder驱动中对于这个模块的实现。可以说ServiceManager是整个Binder IPC的控制中心和交通枢纽。这里我们就来看一下这个模块的具体实现。 ServiceManager是一个独立的可执行文件,在设备中的进程名称是/system/bin/servicemanager,这个也是其可执行文件的路径。 ServiceManager实现源码的位于这个路径:frameworks/native/cmds/servicemanager/,其main函数的主要内容如下: int main(){ 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; } ... binder_loop(bs, svcmgr_handler); return 0; }这段代码很简单,主要做了三件事情: binder_open(128*1024); 是打开Binder,并指定缓存大小为128k,由于ServiceManager提供的接口很简单(下文会讲到),因此并不需要普通进程那么多(1M – 8K)的缓存 binder_become_context_manager(bs) 使自己成为Context Manager。这里的Context Manager是Binder驱动里面的名称,等同于ServiceManager。binder_become_context_manager的方法实现只有一行代码:ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0); 看过Binder驱动部分解析的内容,这行代码应该很容易理解了 binder_loop(bs, svcmgr_handler); 是在Looper上循环,等待其他模块请求服务 service_manager.c中的实现与普通Binder服务的实现有些不一样:并没有通过继承接口类来实现,而是通过几个c语言的函数来完成了实现。这个文件中的主要方法如下: 方法名称方法说明main可执行文件入口函数,刚刚已经做过说明svcmgr_handler请求的入口函数,类似于普通Binder服务的onTransactdo_add_service注册一个Binder服务do_find_service通过名称查找一个已经注册的Binder服务ServiceManager中,通过svcinfo结构体来描述已经注册的Binder服务: struct svcinfo { struct svcinfo *next; uint32_t handle; struct binder_death death; int allow_isolated; size_t len; uint16_t name[0]; };next是一个指针,指向下一个服务,通过这个指针将所有服务串成了链表。handle是指向Binder服务的句柄,这个句柄是由Binder驱动翻译,指向了Binder服务的实体(参见驱动中:Binder中的“面向对象”),name是服务的名称。 ServiceManager的实现逻辑并不复杂,这个模块就好像在整个系统上提供了一个全局的HashMap而已:通过服务名称进行服务注册,然后再通过服务名称来查找。而真正复杂的逻辑其实都是在Binder驱动中实现了。 ServiceManager的接口源码路径: frameworks/native/include/binder/IServiceManager.h frameworks/native/libs/binder/IServiceManager.cppServiceManager的C++接口定义如下: class IServiceManager : public IInterface {public: DECLARE_META_INTERFACE(ServiceManager); virtual sp getService( const String16& name) const = 0; virtual sp checkService( const String16& name) const = 0; virtual status_t addService( const String16& name, const sp& service, bool allowIsolated = false) = 0; virtual Vector listServices() = 0; enum { GET_SERVICE_TRANSACTION = IBinder::FIRST_CALL_TRANSACTION, CHECK_SERVICE_TRANSACTION, ADD_SERVICE_TRANSACTION, LIST_SERVICES_TRANSACTION, }; };这里我们看到,ServiceManager提供的接口只有四个,这四个接口说明如下: 接口名称接口说明addService向ServiceManager中注册一个新的ServicegetService查询Service。如果服务不存在,将阻塞数秒checkService查询Service,但是不会阻塞listServices列出所有的服务这其中,最后一个接口是为了调试而提供的。通过adb shell连接到设备上之后,可以通过输入service list 输出所有注册的服务列表。这里”service”可执行文件其实就是通过调用listServices接口获取到服务列表的。 service命令的源码路径在这里:frameworks/native/cmds/service service list的输出看起来像下面这样(一次输出可能有一百多个服务,这里省略了): 255|angler:/ # service list Found 125 services:0 sip: [android.net.sip.ISipService]1 nfc: [android.nfc.INfcAdapter]2 carrier_config: [com.android.internal.telephony.ICarrierConfigLoader]3 phone: [com.android.internal.telephony.ITelephony]4 isms: [com.android.internal.telephony.ISms]5 iphonesubinfo: [com.android.internal.telephony.IPhoneSubInfo]6 simphonebook: [com.android.internal.telephony.IIccPhoneBook]7 telecom: [com.android.internal.telecom.ITelecomService]8 isub: [com.android.internal.telephony.ISub]9 contexthub_service: [android.hardware.location.IContextHubService]10 dns_listener: [android.netrics.IDnsEventListener]11 connmetrics: [android.net.IIpConnectivityMetrics]12 connectivity_metrics_logger: [android.net.IConnectivityMetricsLogger]13 bluetooth_manager: [android.bluetooth.IBluetoothManager]14 imms: [com.android.internal.telephony.IMms]15 media_projection: [android.media.projection.IMediaProjectionManager]16 launcherapps: [android.content.pm.ILauncherApps]17 shortcut: [android.content.pm.IShortcutService]18 fingerprint: [android.hardware.fingerprint.IFingerprintService]19 trust: [android.app.trust.ITrustManager]20 media_router: [android.media.IMediaRouterService] ...普通的Binder服务我们需要通过ServiceManager来获取接口才能调用,那么ServiceManager的接口有如何获得呢?在libbinder中,提供了一个defaultServiceManager方法来获取ServiceManager的Proxy,并且这个方法不需要传入参数。原因我们在驱动篇中也已经讲过了:Binder的实现中,为ServiceManager留了一个特殊的位置,不需要像普通服务那样通过标识去查找。defaultServiceManager代码如下: sp defaultServiceManager() { if (gDefaultServiceManager != NULL) return gDefaultServiceManager; { AutoMutex _l(gDefaultServiceManagerLock); while (gDefaultServiceManager == NULL) { gDefaultServiceManager = interface_cast( ProcessState::self()->getContextObject(NULL)); if (gDefaultServiceManager == NULL) sleep(1); } } return gDefaultServiceManager; }结束语本文我们详细讲解了Binder Framework C++层的实现。 但对于Android App开发者来说,绝大部分情况下都是在用Java语言开发。那么,在下一篇文章中,我就来详细讲解Binder Framework Java层的实现。并且也会讲解AIDL与Binder的关系,敬请期待。 |
CopyRight 2018-2019 实验室设备网 版权所有 |