Android源码分析--MediaServer源码分析(一)

MediaServer中包括了系统中的许多重要的Server:

  • AudioFlinger:音频系统中的核心服务
  • AudioPolicyService:音频系统中关于音频策略的重要服务
  • MediaPlayerService:多媒体系统中的重要服务
  • CameraService:有关照相和摄像的重要服务

同时,分析MediaServer对于理解Android中的IPC机制能够提供较好的帮助。Android系统基本上可以看做是一个基于Binder机制的C/S架构,对于Binder机制的理解相对比较复杂,如果能够通过具体的例子入手会比较容易理解。

Android的通信体制架构

Android的通信机制基本上可以看做是Client、Server和ServiceManager三者之间的交互:

  1. Server首先要注册一些Service到ServiceManager,在这里Server是ServiceManager的客户端;
  2. 如果某个Client要使用Service,则首先到ServiceManager中获得该Service的相关信息,所有Client是ServiceManager的客户端;
  3. Client得到Service信息,然后和该Service所在的Server进程建立通信之后使用Service,在这里Client是Server的客户端。
    在这些交互的过程中,Android系统都是使用的Binder来进行通信。

MediaServer入口函数

MS是一个可执行程序,它的入口函数是main函数,所在文件位置:frameworks\base\media\mediaserver\main_mediaserver.cpp
代码如下:

int main(int argc, char** argv)
{
    sp<ProcessState> proc(ProcessState::self());
    sp<IServiceManager> sm = defaultServiceManager();
    ALOGI("ServiceManager: %p", sm.get());
    AudioFlinger::instantiate();
    MediaPlayerService::instantiate();
    CameraService::instantiate();
    AudioPolicyService::instantiate();
    ProcessState::self()->startThreadPool();
    IPCThreadState::self()->joinThreadPool();
}

可以看到,在main函数中,

  1. 我们首先获得了一个ProcessState的实例,由self方法我们可以猜得到该类使用了单例模式;
  2. 接下来我们调用了defaultServiceManager方法获得IServiceManager实例;
  3. 接下来进行了几个重要服务的初始化工作;
  4. 调用startThreadPool方法和joinThreadPool方法。

ProcessState类的分析

文件位置:frameworks\base\libs\binder\ProcessState.cpp
self方法:在main函数中,我们调用了self方法得到了一个ProcessState实例,下面我们来看看这个方法

sp<ProcessState> ProcessState::self()
{
    if (gProcess != NULL) return gProcess;
    //提供原子操作
    AutoMutex _l(gProcessMutex);
    if (gProcess == NULL) gProcess = new ProcessState;
    return gProcess;
}

可以看到,不出所料,ProcessState使用的就是单例模式。
接下来我们来看一看ProcessState的构造函数:

ProcessState::ProcessState()
    : mDriverFD(open_driver())
    , mVMStart(MAP_FAILED)
    , mManagesContexts(false)
    , mBinderContextCheckFunc(NULL)
    , mBinderContextUserData(NULL)
    , mThreadPoolStarted(false)
    , mThreadPoolSeq(1)
{
    if (mDriverFD >= 0) {
        // XXX Ideally, there should be a specific define for whether we
        // have mmap (or whether we could possibly have the kernel module
        // availabla).
#if !defined(HAVE_WIN32_IPC)
        // mmap the binder, 提供一个虚拟放入地址内存空间块去接收事务
        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.");
}

可以看到,在构造函数中首先调用了open_driver函数并将返回值赋给了mDriverFD,让我们来看看这个函数:

static int open_driver()
{
    int fd = open("/dev/binder", O_RDWR);
    if (fd >= 0) {
        fcntl(fd, F_SETFD, FD_CLOEXEC);
        int vers;
        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 = 15;
        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;
}

可以看到open_driver函数主要是打开了/dev/binder这个设备并返回了这个设备的fd。

接下来我继续回到构造函数中,在mDriverFD中保存了这个设备的fd,接着我们又对其他的成员变量做了一些初始化,然后调用mmap函数为Binder设备开辟一块内存由于接收数据。

总结一下,我们的ProcessState类的任务:

  1. 打开了Binder设备,并保存了设备的fd;
  2. 利用保存的fd为Binder设备开辟一块内存用于接收数据;
  3. 因为ProcessState采用了单例模式,因此每个进程只能打开一次Binder设备。

defaultServiceManager函数分析

文件位置:frameworks\base\libs\binder\IServiceManager.cpp

sp<IServiceManager> defaultServiceManager()
{
    if (gDefaultServiceManager != NULL) return gDefaultServiceManager;

    {
        AutoMutex _l(gDefaultServiceManagerLock);
        if (gDefaultServiceManager == NULL) {
            gDefaultServiceManager = interface_cast<IServiceManager>(
                ProcessState::self()->getContextObject(NULL));
        }
    }

    return gDefaultServiceManager;
}

可以看到gDefaultServiceManager函数主要是对gDefaultServiceManager 进行赋值,首先我们来看看这个函数的传入参数: ProcessState::self()->getContextObject(NULL)

sp<IBinder> ProcessState::getContextObject(const sp<IBinder>& caller)
{
    return getStrongProxyForHandle(0);
}

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

    AutoMutex _l(mLock);

    handle_entry* e = lookupHandleLocked(handle);

    if (e != NULL) {
        // 如果现在不存在或者我们不能得到它的引用时,我们需要创建一个新的BpBinder, 
        IBinder* b = e->binder;
        if (b == NULL || !e->refs->attemptIncWeak(this)) {
            b = new BpBinder(handle); 
            e->binder = b;
            if (b) e->refs = b->getWeakRefs();
            result = b;
        } else {
            result.force_set(b);
            e->refs->decWeak(this);
        }
    }
    return result;
}

可以看到其实我们返回了一个BpBinder(handle);handle的值为0。

interface_cast看起来像一个强制类型转换,其实是一个模板函数,下面我们来看看它的庐山真面目:

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

我们传入的模板是IServiceManager,则实际上调用的就是IServiceManager的asInterface方法。
asInterface方法的声明和实现实际上是通过两个宏定义实现的,位于IInterface.h文件中:

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

将INTERFACE替换为IServiceManager后可以得到:

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

    const android::String16 IServiceManager::descriptor(NAME);            
    const android::String16&                                            
            IServiceManager::getInterfaceDescriptor() const {              
        return IServiceManager::descriptor;                                
    }                                                                   
    android::sp<IServiceManager> IServiceManager::asInterface(                
            const android::sp<android::IBinder>& obj)                   
    {                                                                   
        android::sp<IServiceManager> intr;                                 
        if (obj != NULL) {                                              
            intr = static_cast<IServiceManager*>(                          
                obj->queryLocalInterface(                               
                        IServiceManager::descriptor).get());               
            if (intr == NULL) {                                         
                intr = new BpServiceManager(obj);                          
            }                                                           
        }                                                               
        return intr;                                                    
    }                                                                   IServiceManager::IServiceManager() { }                                    IServiceManager::~IServiceManager() { } 

可以看到asInterface方法最终实际上返回了一个BpServiceManager对象。
总结一下defaultServiceManager方法的工作:

  1. 创建了一个BpBinder对象,用来负责客户端Binder通信(之后会讲到),因为对于ServiceManager来说我们是客户端,所以在这里我们创建了Binder的客户端;
  2. 创建了一个BpServiceManager对象,主要负责IServiceManager的业务函数,在他的内部持有一个BpBinder对象mRemote。

类关系总结

看到这里,已经有点眼花缭乱了,又是IBinder,又是IServiceManager,又是BpBinder,又是BpServiceManager,是时候来总结一下这些类的关系了,翻了一下这些类,下面用一个不标准的UML图来说明一下:
技术分享

需要注意的是:

  1. RefBase是Android中所有类的祖先,相当于Java中Object;
  2. BpBinder和BBinder都是Android中Binder通信的代表类,其中BpBinder是客户端用来与Server交互的代理类,p代表的就是proxy,而BBinder则是交互的目的端;
  3. BpBinder和BBinder是相互对应的,Binder系统会通过handle来标识对应的BBinder;
  4. BnServiceManager中n代表的是native,与Bn相对应的应该是BpServiceManager,表示ServiceManager的业务代理类。

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。