Android Binder机制(四) defaultServiceManager()的实现

本文介绍defaultServiceManager()的流程。这里的defaultServiceManager()返回的是”IServiceManager对象”,获取”IServiceManager对象”的目的是为了和”ServiceManager进程”进行通信。例如,Server要通过”IServiceManager对象”发送请求指令注册到”ServiceManager进程”中,Client要通过”IServiceManager对象”发送请求来获取”Server对象”。
这里要搞清楚:defaultServiceManager()获取到的,不是”ServiceManager进程”,而是”IServiceManager对象”。”ServiceManager进程”是一个守护进程,而defaultServiceManager()获取到的是C++层的IServiceManager类的一个实例。当然,通过该defaultServiceManager()返回的”IServiceManager对象”是可以和ServiceManager进行通信的。

注意:本文是基于Android 4.4.2版本进行介绍的!

目录
1
. defaultServiceManager概述
2. defaultServiceManager流程详解
2.1. defaultServiceManager()
2.2. ProcessState::self()
2.3. ProcessState::ProcessState()
2.4. ProcessState::open_driver()
2.5. mmap()
2.6. ProcessState::getContextObject()
2.7. ProcessState::getStrongProxyForHandle()
2.8. ProcessState::lookupHandleLocked()
2.9. BpBinder::BpBinder
2.10. IPCThreadState::self()
2.11. IPCThreadState::IPCThreadState()
2.12. interface_cast()

defaultServiceManager概述

1. defaultServiceManager流程图

上面是defaultServiceManager()的时序图。
defaultServiceManager()会返回一个sp类型的对象。IServiceManager提供了addService()供MediaPlayerService等服务注册到ServiceManager中,提供了getService()供MediaPlayer等MediaPlayer等客户端获取服务。
它首先会调用ProcessState::self()获取到ProcessState对象,该ProcessState对象是采用单例模式创建的;因此,当ProcessState::self()第一次被调用时,会新建ProcessState对象。在ProcessState的构造函数中,会先通过open_driver()打开”/dev/binder”,接着调用mmap()映射内存到当前进程中。此时,ProcessState就初始化完毕,它将”/dev/binder”的文件句柄以及映射内存都保存在自己的私有成员中。
在获取到ProcessState对象之后,会通过该对象调用getContextObject()来获取一个IBinder对象。getContextObject()会调用getStrongProxyForHandle(0)来获取”句柄0的强引用代理对象”,这里的句柄0被赋予了特殊意义;它就是ServiceManager的句柄,在Binder驱动中,若获取到句柄的值是0,则会将其目标当作是ServiceManager。getStrongProxyForHandle(0)会先通过lookupHandleLocked()在”ProcessState的矢量数组mHandleToObject”中查找句柄为0的对象;找不到的话,则新建句柄为0的对象,并将其添加到mHandleToObject矢量数组中;这样,下次再通过getStrongProxyForHandle()查找时,就能快速的找到。由此可见,mHandleToObject是ProcessState中保存句柄的缓冲数组。 随后,会新建句柄0对应的BpBinder对象,BpBinder是IBinder的代理;这里就获取到了ServiceManager的BpBinder代理对象。简而言之,getContextObject()的目的就是获取ServiceManager对应的BpBinder代理对象。 在新建BpBinder时,会通过IPCThreadState::self()获取IPCThreadState对象;因为,需要通过IPCThreadState对象来与Binder驱动进行交互。
前面已经成功获取到了ServiceManager的BpBinder代理,而defaultServiceManager()返回的是IServiceManager对象。这里,使用了一个技巧,通过宏interface_cast而调用asInterface()函数,从而返回IServiceManager的代理BpServiceManager。这样,defaultServiceManager()就执行完毕了。

在上面的流程中,涉及到了比较多的类。下面通过类图理清它们之间的关系。

2. defaultServiceManager相关类的类图

上面是获取defaultServiceManager()时涉及到的类的类图。defaultServiceManager()虽然在IServiceManager.cpp中实现,但它并不属于IServiceManager的成员方法,而是一个全局方法。

  1. RefBase
    它定义在system/core/include/utils/RefBase.h中。RefBase是一个公共父类,它声明了许多常用的接口。包括增加引用计数,获取引用计数,新增对象的弱引用等接口。

  2. IInterface
    它定义在frameworks/native/include/binder/IInterface.h中。和RefBase类似,它也是一个公共父类,IInterface中声明了asBinder()方法,用于获取对象的IBinder对象。

  3. IBinder
    它定义在frameworks/native/include/binder/IBinder.h中。IBinder也是一个抽象出来的类,它包括了localBinder(), remoteBinder()和transact()等非常重要的接口。IBinder有两个直接子类类:BpBinder和BBinder。
    BpBinder是Binder代理类。通过remoteBinder()可以获取BpBinder对象;而且,对于C++层而言,它相当于一个远程Binder。BpBinder的事务接口transact()会调用IPCThreadState的transact(),进而实现与Binder驱动的事务交互。此外,BpBinder中有一个mHandle句柄成员,它用来保存Server位于Binder驱动中的”Binder引用的描述”。句柄0是ServiceManager的句柄。
    BBinder是本地Binder。通过localBinder()可以获取BBinder对象。当Server收到请求之后,会调用BBinder的onTransact()函数进行处理。而不同的Server会重载onTransact()函数,从而可以根据各自的情况对事务进行处理。

  4. BpInterface
    它定义在frameworks/native/include/binder/IInterface.h中。实际上,BpInterface是一个模板类,同时继承了BpRefBase和INTERFACE,这里的INTERFACE是模板。像IServiceManager,IMediaPlayerService等Server都是通过继承模板类是实现的。

  5. BnInterface
    它定义在frameworks/native/include/binder/IInterface.h中。和BpInterface类似,BnInterface也是一个模板类,它同时继承了BBinder和INTERFACE。像BnServiceManager,BnMediaPlayerService等本地Server都是通过继承模板类是实现的。

  6. BpRefBase
    它定义在frameworks/native/include/binder/Binder.h中。BpRefBase继承于RefBase,它有一个IBinder*类型的成员mRemote,同时提供了获取该mRemote的方法。实际上,该mRemote就是BpBinder对象。

  7. ProcessState
    它定义在frameworks/native/libs/binder/ProcessState.cpp中中。ProcessState的实例是采用单例模式实现的,它拥有两个非常重要的成员:mDriverFD和mHandleToObject。
    mDriverFD是文件”/dev/binder”的句柄,而mHandleToObject是一个Vector矢量数组,矢量数组中的每个元素都保存了两个变量:Server的句柄,以及Server对应的BpBinder对象。实际上,Server的句柄是”Server在Binder驱动中的Binder引用的描述”;句柄0是ServiceManager的句柄。 关于Binder引用,可以回顾Android Binder机制(二) Binder中的数据结构

  8. IPCThreadState
    它定义在frameworks/native/libs/binder/IPCThreadState.cpp中中。IPCThreadState的实例也是采用单例模式实现的,它是正在与Binder驱动进行交互的类。


理解上面几个类的基本概念之后,现在在从整体上对它们进行一下介绍!
对于一个Server而言,它都会存在一个”远程BpBinder对象”和”本地BBinder对象”。
(01) 远程BpBinder对象的作用,是和Binder驱动进行交互。具体的方式是,当Server要向Binder发起事务请求时,会调用BpBinder的transact()接口,而该接口会调用到IPCThreadState::transact()接口,通过IPCThreadState类来和Binder驱动交互。此外,该BpBinder在Binder驱动中的Binder引用的描述会被保存到ProcessState的mHandleToObject矢量缓冲数组中。
(02) 本地BBinder对象的作用,是Server响应Client请求的类。当Client有请求发送给Server时,都会调用到BBinder的onTransact()函数,而每个Server都会覆盖onTransact()函数。这样,每个Server就可以在onTransact()中根据自己的情况对请求进行处理。

defaultServiceManager流程详解

接下来通过源码来查看defaultServiceManager()的实现。通过源码分析,会对上面的类图有更清楚的认识!

1. defaultServiceManager()


   
   
  1. sp<IServiceManager> defaultServiceManager()
  2. {
  3. if (gDefaultServiceManager != NULL) return gDefaultServiceManager;
  4. {
  5. AutoMutex _l(gDefaultServiceManagerLock);
  6. while (gDefaultServiceManager == NULL) {
  7. gDefaultServiceManager = interface_cast<IServiceManager>(
  8. ProcessState::self()->getContextObject( NULL));
  9. if (gDefaultServiceManager == NULL)
  10. sleep( 1);
  11. }
  12. }
  13. return gDefaultServiceManager;
  14. }

说明:该代码定义在frameworks/native/libs/binder/IServiceManager.cpp中。它是获取IServiceManager对象,该函数的声明在frameworks/native/include/binder/IServiceManager.h中。虽然defaultServiceManager()在IServiceManager.cpp文件中实现,但是它并不是IServiceManager的一个成员方法,而是一个全局方法。
(01) gDefaultServiceManagerLock是全局互斥锁,gDefaultServiceManager是全局的IServiceManager对象。它们都定义在frameworks/native/libs/binder/Static.cpp中。
(02) gDefaultServiceManager是采用单例模式实现的,第一次调用该函数时,会创建gDefaultServiceManager对象。gDefaultServiceManager的实现可以简化为以下语句:

gDefaultServiceManager = interface_cast<IServiceManager>(ProcessState::self()->getContextObject(NULL));

   
   

下面逐个对该语句中的代码进行解析。

2. ProcessState::self()


   
   
  1. sp<ProcessState> ProcessState::self()
  2. {
  3. Mutex::Autolock _l(gProcessMutex);
  4. if (gProcess != NULL) {
  5. return gProcess;
  6. }
  7. gProcess = new ProcessState;
  8. return gProcess;
  9. }

说明:该代码定义在frameworks/native/libs/binder/ProcessState.cpp中,它的作用是返回gProcess对象。gProcess也是单例模式对象,它也定义在frameworks/native/libs/binder/Static.cpp中。第一次执行self()时,会新建ProcessState对象。

3. ProcessState::ProcessState()


   
   
  1. ProcessState::ProcessState()
  2. : mDriverFD(open_driver())
  3. , mVMStart(MAP_FAILED)
  4. , mManagesContexts( false)
  5. , mBinderContextCheckFunc( NULL)
  6. , mBinderContextUserData( NULL)
  7. , mThreadPoolStarted( false)
  8. , mThreadPoolSeq( 1)
  9. {
  10. if (mDriverFD >= 0) {
  11. mVMStart = mmap( 0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0);
  12. if (mVMStart == MAP_FAILED) {
  13. // *sigh*
  14. ALOGE( "Using /dev/binder failed: unable to mmap transaction memory.\n");
  15. close(mDriverFD);
  16. mDriverFD = -1;
  17. }
  18. }
  19. ...
  20. }

说明:在ProcessState的构造函数中,它会进行一系列的初始化。比较重要的有如下两步。
(01) 通过open_driver()打开”/open/binder”,并将文件句柄赋值给mDriverFD。
(02) 通过调用mmap()映射内存。
下面,看看这两步的代码。

4. ProcessState::open_driver()


   
   
  1. static int open_driver()
  2. {
  3. // 打开文件/dev/binder
  4. int fd = open( "/dev/binder", O_RDWR);
  5. if (fd >= 0) {
  6. fcntl(fd, F_SETFD, FD_CLOEXEC);
  7. int vers;
  8. // 检查/dev/binder的版本
  9. status_t result = ioctl(fd, BINDER_VERSION, &vers);
  10. if (result == -1) {
  11. close(fd);
  12. ...
  13. }
  14. if (result != 0 || vers != BINDER_CURRENT_PROTOCOL_VERSION) {
  15. close(fd);
  16. ...
  17. }
  18. // 设置该进程最大线程数
  19. size_t maxThreads = 15;
  20. result = ioctl(fd, BINDER_SET_MAX_THREADS, &maxThreads);
  21. if (result == -1) {
  22. ...
  23. }
  24. } else {
  25. ...
  26. }
  27. return fd;
  28. }

说明:
(01) open_driver()首先打开”/dev/binder”文件。它会对应执行Binder驱动的binder_open()函数,该函数在Android Binder机制(三) ServiceManager守护进程中已经详细介绍过了。
(02) 在成功打开文件之后,就会调用ioctl检查Binder版本,检查版本的部分非常简单(就是读取出版本号,判断读取的版本号与已有的版本号是否一样!),这里就不再对Binder驱动的BINDER_VERSION进行展开了。
(03) 在检查版本通过之后,在调用ioctl(,BINDER_SET_MAX_THREADS,)设置该进程的最大线程数。它会对应调用Binder驱动的binder_ioctl()函数。

注意:要区分”此处的open(“/dev/binder”,…)” 和 “ServiceManager守护进程中的open(“/dev/binder”,…)”。它们分别是属于不同的进程,本文的open(“/dev/binder”,…)是属于调用defaultServiceManager()的进程;而在ServiceManager中的open(“/dev/binder”,…)是属于ServiceManager进程的。

4.1 Binder驱动中binder_ioctl()的BINDER_SET_MAX_THREADS相关部分的源码


   
   
  1. static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
  2. {
  3. int ret;
  4. struct binder_proc *proc = filp->private_data;
  5. struct binder_thread *thread;
  6. unsigned int size = _IOC_SIZE(cmd);
  7. void __user *ubuf = ( void __user *)arg;
  8. ret = wait_event_interruptible(binder_user_error_wait, binder_stop_on_user_error < 2);
  9. // 在proc进程中查找该线程对应的binder_thread;若查找失败,则新建一个binder_thread,并添加到proc->threads中。
  10. thread = binder_get_thread(proc);
  11. ...
  12. switch (cmd) {
  13. case BINDER_SET_MAX_THREADS:
  14. if (copy_from_user(&proc->max_threads, ubuf, sizeof(proc->max_threads))) {
  15. ret = -EINVAL;
  16. goto err;
  17. }
  18. break;
  19. ...
  20. }
  21. ret = 0;
  22. ...
  23. return ret;
  24. }

说明:BINDER_SET_MAX_THREADS的代码很简单,就是将最大线程数目从用户空间拷贝到内核空间,进而赋值给binder_proc->max_threads。

5. mmap()

在执行完open_driver()之后,将调用mmap()映射内存到当前进程的虚拟地址空间。mmap()详细代码在Android Binder机制(三) ServiceManager守护进程中已经详细分析过,这里就不再重复说明了。


到目前为止,ProcessState::self()就分析完毕。gDefaultServiceManager的赋值语句可以进一步的简化:

gDefaultServiceManager = interface_cast<IServiceManager>(ProcessState::getContextObject(NULL));

   
   

6. ProcessState::getContextObject()


   
   
  1. sp<IBinder> ProcessState::getContextObject( const sp<IBinder>& caller)
  2. {
  3. return getStrongProxyForHandle( 0);
  4. }

说明:getContextObject()调用了getStrongProxyForHandle(0)。这里的0是代表Service Manager的句柄。

7. ProcessState::getStrongProxyForHandle()


   
   
  1. sp<IBinder> ProcessState::getStrongProxyForHandle(int32_t handle)
  2. {
  3. sp<IBinder> result;
  4. AutoMutex _l(mLock);
  5. // 在矢量数组mHandleToObject中查找"句柄值为handle的handle_entry对象";
  6. // 找到的话,则直接返回;找不到的话,则新建handle对应的handle_entry,并将其添加到mHandleToObject中。
  7. handle_entry* e = lookupHandleLocked(handle);
  8. if (e != NULL) {
  9. IBinder* b = e->binder;
  10. if (b == NULL || !e->refs->attemptIncWeak(this)) {
  11. // 当handle==0(即是Service Manager的句柄)时,尝试去ping Binder驱动。
  12. if (handle == 0) {
  13. Parcel data;
  14. status_t status = IPCThreadState::self()->transact(
  15. 0, IBinder::PING_TRANSACTION, data, NULL, 0);
  16. if (status == DEAD_OBJECT)
  17. return NULL;
  18. }
  19. // 新建BpBinder代理
  20. b = new BpBinder(handle);
  21. e->binder = b;
  22. if (b) e->refs = b->getWeakRefs();
  23. result = b;
  24. } else {
  25. ...
  26. }
  27. }
  28. return result;
  29. }

说明:getStrongProxyForHandle()的目的是返回句柄为handle的IBinder代理,这里是返回Service Manager的IBinder代理。
(01) lookupHandleLocked(),是在矢量数组mHandleToObject中查找是否有句柄为handle的handle_entry对象。有的话,则返回该handle_entry对象;没有的话,则新建handle对应的handle_entry,并将其添加到矢量数组mHandleToObject中,然后再返回。mHandleToObject是用于保存各个IBinder代理对象的矢量数组,它相当于一个缓冲。
(02) 很显然,此时e!=NULL为true,进入if(e!=NULL)中。而此时e->binder=NULL,并且handle=0;则调用IPCThreadState::self()->transact()尝试去和Binder驱动通信(尝试去ping内核中Binder驱动)。由于Binder驱动已启动,ping通信是能够成功的。ping通信涉及到”Binder机制中Server和Client的通信”,后面再专门对Server和Client的交互进行介绍;这里只要了解ping通信能够成功即可。
(03) 接着,新建BpBinder对象,并赋值给e->binder。然后,将该BpBinder对象返回。

上面对流程进行了整体介绍,下面逐个进行分析!

8. ProcessState::lookupHandleLocked()


   
   
  1. ProcessState::handle_entry* ProcessState::lookupHandleLocked( int32_t handle)
  2. {
  3. const size_t N=mHandleToObject.size();
  4. if (N <= ( size_t)handle) {
  5. handle_entry e;
  6. e.binder = NULL;
  7. e.refs = NULL;
  8. status_t err = mHandleToObject.insertAt(e, N, handle+ 1-N);
  9. if (err < NO_ERROR) return NULL;
  10. }
  11. return &mHandleToObject.editItemAt(handle);
  12. }

说明:mHandleToObject是Vector矢量数组。mHandleToObject的初始大小为0,因此if (N <= handle)为true。接下来,就新建handle_entry,并将其添加到mHandleToObject中,然后返回该handle_entry。mHandleToObject和handle_entry的定义如下:


   
   
  1. class ProcessState : public virtual RefBase
  2. {
  3. ...
  4. private:
  5. ...
  6. struct handle_entry {
  7. IBinder* binder;
  8. RefBase::weakref_type* refs;
  9. };
  10. ...
  11. Vector<handle_entry>mHandleToObject;
  12. ...
  13. }

说明:该代码定义在frameworks/native/include/binder/ProcessState.h中。前面说过,mHandleToObject是个缓冲矢量数组。它的成员binder是保存的Server的BpBinder对象,而refs是保存的Server在Binder驱动中的Binder引用的描述。

9. BpBinder::BpBinder

new BpBinder(0)会新建BpBinder对象,下面看看BpBinder的构造函数。


   
   
  1. BpBinder::BpBinder( int32_t handle)
  2. : mHandle(handle)
  3. , mAlive( 1)
  4. , mObitsSent( 0)
  5. , mObituaries( NULL)
  6. {
  7. ALOGV( "Creating BpBinder %p handle %d\n", this, mHandle);
  8. extendObjectLifetime(OBJECT_LIFETIME_WEAK);
  9. IPCThreadState::self()->incWeakHandle(handle);
  10. }

说明:该代码定义在frameworks/native/libs/binder/BpBinder.cpp中。主要工作是初始化。
(01) 将句柄handle保存到私有成员mHandle中。这里是将ServiceManager的句柄保存到mHandle中。
(02) 增加IPCThreadState的引用计数。IPCThreadState::self()是获取IPCThreadState对象,实际上,在前面介绍的ProcessState::getStrongProxyForHandle()中已经调用过该函数。下面看看它的代码。

10. IPCThreadState::self()


   
   
  1. static pthread_mutex_t gTLSMutex = PTHREAD_MUTEX_INITIALIZER;
  2. static bool gHaveTLS = false;
  3. static pthread_key_t gTLS = 0;
  4. static bool gShutdown = false;
  5. static bool gDisableBackgroundScheduling = false;
  6. IPCThreadState* IPCThreadState::self()
  7. {
  8. if (gHaveTLS) {
  9. restart:
  10. const pthread_key_t k = gTLS;
  11. IPCThreadState* st = (IPCThreadState*)pthread_getspecific(k);
  12. if (st) return st;
  13. return new IPCThreadState;
  14. }
  15. if (gShutdown) return NULL;
  16. pthread_mutex_lock(&gTLSMutex);
  17. if (!gHaveTLS) {
  18. if (pthread_key_create(&gTLS, threadDestructor) != 0) {
  19. pthread_mutex_unlock(&gTLSMutex);
  20. return NULL;
  21. }
  22. gHaveTLS = true;
  23. }
  24. pthread_mutex_unlock(&gTLSMutex);
  25. goto restart;
  26. }

说明:该代码定义在frameworks/native/libs/binder/IPCThreadState.cpp中。self()的源码比较简单,它的作用是获取IPCThreadState对象。若该对象已经存在,则直接返回;否则,新建IPCThreadState对象。

11. IPCThreadState::IPCThreadState()


   
   
  1. IPCThreadState::IPCThreadState()
  2. : mProcess(ProcessState:: self()),
  3. mMyThreadId(androidGetTid()),
  4. mStrictModePolicy( 0),
  5. mLastTransactionBinderFlags( 0)
  6. {
  7. pthread_setspecific(gTLS, this);
  8. clearCaller();
  9. mIn.setDataCapacity( 256);
  10. mOut.setDataCapacity( 256);
  11. }

说明:
(01) 获取ProcessState对象,并将其赋值给成员mProcess。ProcessState::self()在前面已经介绍国,它是获取全局的ProcessState对象。
(02) 设置mIn和mOut的容量为256字节。IPCThreadState是和Binder驱动交互的类,mOut是用来保存”IPCThreadState需要发送给Binder驱动的内容的”,而mIn则是用来保存”Binder驱动反馈给IPCThreadState的内容的”。后面在介绍”Server和Client”通信中用到它们时,再进一步说明。


到目前为止,ProcessState::getContextObject()就分析完了。gDefaultServiceManager的赋值语句可以进一步的简化:

gDefaultServiceManager = interface_cast<IServiceManager>(new BpBinder(0));

   
   

接下来,看看interface_cast。

12. interface_cast()


   
   
  1. template< typename INTERFACE>
  2. inline sp<INTERFACE> interface_cast( const sp<IBinder>& obj)
  3. {
  4. return INTERFACE::asInterface(obj);
  5. }

说明:该代码在frameworks/native/include/binder/IInterface.h中。它是一个模板函数,对于interface_cast而言,返回的结果是IServiceManager::asInterface()。

13. IServiceManager::asInterface()

接下来,就是查找IServiceManager::asInterface()的实现了。在IServiceManager.cpp中不存在,追踪代码,发现asInterface()是通过DECLARE_META_INTERFACE()来声明,并通过IMPLEMENT_META_INTERFACE()来实现的。

(01) IServiceManager中的DECLARE_META_INTERFACE()声明和IMPLEMENT_META_INTERFACE()实现,分别在头文件frameworks/native/include/binder/IServiceManager.h 以及 frameworks/native/libs/binder/IServiceManager.cpp中。


   
   
  1. // IServiceManager.h中的声明
  2. class IServiceManager : public IInterface
  3. {
  4. public:
  5. DECLARE_META_INTERFACE(ServiceManager);
  6. ...
  7. }
  8. // IServiceManager.pp中的实现
  9. IMPLEMENT_META_INTERFACE(ServiceManager, "android.os.IServiceManager");

(02) DECLARE_META_INTERFACE()和IMPLEMENT_META_INTERFACE()的定义在frameworks/native/include/binder/IInterface.h中。


   
   
  1. #define DECLARE_META_INTERFACE(INTERFACE) \
  2. static const android::String16 descriptor; \
  3. static android::sp<I ##INTERFACE> asInterface( \
  4. const android::sp<android::IBinder>& obj); \
  5. virtual const android::String16& getInterfaceDescriptor() const; \
  6. I ##INTERFACE(); \
  7. virtual ~I ##INTERFACE(); \
  8. #define IMPLEMENT_META_INTERFACE(INTERFACE, NAME) \
  9. const android::String16 I ##INTERFACE::descriptor(NAME); \
  10. const android::String16& \
  11. I ##INTERFACE::getInterfaceDescriptor() const { \
  12. return I ##INTERFACE::descriptor; \
  13. } \
  14. android::sp<I ##INTERFACE> I##INTERFACE::asInterface( \
  15. const android::sp<android::IBinder>& obj) \
  16. { \
  17. android::sp<I ##INTERFACE> intr; \
  18. if (obj != NULL) { \
  19. intr = static_cast<I ##INTERFACE*>( \
  20. obj->queryLocalInterface( \
  21. I ##INTERFACE::descriptor).get()); \
  22. if (intr == NULL) { \
  23. intr = new Bp ##INTERFACE(obj); \
  24. } \
  25. } \
  26. return intr; \
  27. } \
  28. I ##INTERFACE::I##INTERFACE() { } \
  29. I ##INTERFACE::~I##INTERFACE() { } \
  30. #define CHECK_INTERFACE(interface, data, reply) \
  31. if (!data.checkInterface(this)) { return PERMISSION_DENIED; } \

用ServiceManager替换INTERFACE之后,得到结果如下:IMPLEMENT_META_INTERFACE(ServiceManager, “android.os.IServiceManager”);


   
   
  1. #define DECLARE_META_INTERFACE(IServiceManager) \
  2. static const android::String16 descriptor; \
  3. static android::sp<IServiceManager> asInterface( \
  4. const android::sp<android::IBinder>& obj); \
  5. virtual const android:: String16& getInterfaceDescriptor() const; \
  6. IServiceManager(); \
  7. virtual ~IServiceManager(); \
  8. #define IMPLEMENT_META_INTERFACE(IServiceManager, "android.os.IServiceManager") \
  9. const android::String16 IServiceManager::descriptor("android.os.IServiceManager"); \
  10. const android::String16& \
  11. IServiceManager::getInterfaceDescriptor() const { \
  12. return IServiceManager::descriptor; \
  13. } \
  14. android::sp<IServiceManager> IServiceManager::asInterface( \
  15. const android::sp<android::IBinder>& obj) \
  16. { \
  17. android::sp<IServiceManager> intr; \
  18. if (obj != NULL) { \
  19. intr = static_cast<IServiceManager*>( \
  20. obj->queryLocalInterface( \
  21. IServiceManager::descriptor).get()); \
  22. if (intr == NULL) { \
  23. intr = new BpServiceManager(obj); \
  24. } \
  25. } \
  26. return intr; \
  27. } \
  28. IServiceManager::IServiceManager() { } \
  29. IServiceManager::~IServiceManager() { }

因此,得到IServiceManager::asInterface()的源码如下:


   
   
  1. android::sp<IServiceManager> IServiceManager::asInterface( const android::sp<android::IBinder>& obj)
  2. {
  3. android::sp<IServiceManager> intr;
  4. if (obj != NULL) {
  5. intr = static_cast<IServiceManager*>(
  6. obj->queryLocalInterface(
  7. IServiceManager::descriptor).get());
  8. if (intr == NULL) {
  9. intr = new BpServiceManager(obj);
  10. }
  11. }
  12. return intr;
  13. }

说明:asInterface()的作用是获取IServiceManager接口。
(01) obj是传入的BpBinder对象,不为NULL。因此,执行obj->queryLocalInterface(“android.os.IServiceManager”)来查找名称为”android.os.IServiceManager”的本地接口,queryLocalInterface()的实现在BpBinder的父类IBinder中,具体在文件frameworks/native/libs/binder/Binder.cpp中。很显然,IServiceManager接口还没创建,因此intr=NULL。
(02) 新建BpServiceManager(obj)对象,并返回。BpServiceManager的实现在frameworks/native/libs/binder/IServiceManager.cpp中。


   
   
  1. sp<IInterface> IBinder::queryLocalInterface( const String16& descriptor)
  2. {
  3. return NULL;
  4. }


到目前为止,gDefaultServiceManager的创建流程就分析完了,它实际返回的是一个BpServiceManager对象,该对象包含IBinder的代理BpBinder。以下是转换后的获取gDefaultServiceManager的语句。

gDefaultServiceManager = new BpServiceManager(new BpBinder(0));

   
   
  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Android Binder 机制Android 系统中的一种进程间通信(IPC)机制,用于在不同的进程之间传递数据和调用方法。它是 Android 系统中最重要的 IPC 机制之一,也是 Android 应用程序与系统服务进行通信的基础。 Binder 机制的工作原理是基于一个抽象的客户端-服务器模型。在 Binder 机制中,有三种角色:客户端、服务器和服务管理器。客户端和服务器在不同的进程中运行,而服务管理器运行在系统服务进程中。 当客户端需要与服务器通信时,它首先通过服务管理器获取服务器的引用。服务管理器通过一个名为 Binder 驱动的内核模块来实现进程间通信。客户端可以通过跨进程访问服务器对象来调用服务器上的方法,并将参数传递给服务器。服务器可以将结果返回给客户端。 Binder 机制的一个重要特性是它支持跨进程的对象引用。这意味着客户端可以获取服务器上的对象引用,并将其传递给其他进程中的客户端。通过这种方式,多个客户端可以共享服务器上的相同对象,并相互协作。 在 Android 应用程序中,开发者可以通过 AIDL(Android 接口定义语言)来定义客户端和服务器之间的接口。AIDL 可以生成一个 Java 接口和一个 C++ 接口,用于在客户端和服务器之间进行通信。 总之,Android Binder 机制Android 系统中用于进程间通信的核心技术之一。它提供了一种高效、灵活和安全的方式来在不同的进程之间传递数据和调用方法。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值