MediaServer中包括了系统中的许多重要的Server：
- AudioFlinger：音频系统中的核心服务
- AudioPolicyService：音频系统中关于音频策略的重要服务
- MediaPlayerService：多媒体系统中的重要服务
- CameraService：有关照相和摄像的重要服务
同时，分析MediaServer对于理解Android中的IPC机制能够提供较好的帮助。Android系统基本上可以看做是一个基于Binder机制的C/S架构，对于Binder机制的理解相对比较复杂，如果能够通过具体的例子入手会比较容易理解。
Android的通信体制架构
Android的通信机制基本上可以看做是Client、Server和ServiceManager三者之间的交互：
- Server首先要注册一些Service到ServiceManager，在这里Server是ServiceManager的客户端；
- 如果某个Client要使用Service，则首先到ServiceManager中获得该Service的相关信息，所有Client是ServiceManager的客户端；
- 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函数中，
- 我们首先获得了一个ProcessState的实例，由self方法我们可以猜得到该类使用了单例模式；
- 接下来我们调用了defaultServiceManager方法获得IServiceManager实例；
- 接下来进行了几个重要服务的初始化工作；
- 调用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类的任务：
- 打开了Binder设备，并保存了设备的fd；
- 利用保存的fd为Binder设备开辟一块内存用于接收数据；
- 因为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方法的工作：
- 创建了一个BpBinder对象，用来负责客户端Binder通信（之后会讲到），因为对于ServiceManager来说我们是客户端，所以在这里我们创建了Binder的客户端；
- 创建了一个BpServiceManager对象，主要负责IServiceManager的业务函数，在他的内部持有一个BpBinder对象mRemote。
类关系总结
看到这里，已经有点眼花缭乱了，又是IBinder，又是IServiceManager，又是BpBinder，又是BpServiceManager，是时候来总结一下这些类的关系了，翻了一下这些类，下面用一个不标准的UML图来说明一下： 
需要注意的是：
- RefBase是Android中所有类的祖先，相当于Java中Object；
- BpBinder和BBinder都是Android中Binder通信的代表类，其中BpBinder是客户端用来与Server交互的代理类，p代表的就是proxy，而BBinder则是交互的目的端；
- BpBinder和BBinder是相互对应的，Binder系统会通过handle来标识对应的BBinder；
- BnServiceManager中n代表的是native，与Bn相对应的应该是BpServiceManager，表示ServiceManager的业务代理类。
- 1楼finddreams7小时前
- 好文，必须mark