MediaServer中包括了系统中的许多重要的Server：
同时，分析MediaServer对于理解Android中的IPC机制能够提供较好的帮助。Android系统基本上可以看做是一个基于Binder机制的C/S架构，对于Binder机制的理解相对比较复杂，如果能够通过具体的例子入手会比较容易理解。
Android的通信机制基本上可以看做是Client、Server和ServiceManager三者之间的交互：
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函数中，
文件位置：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类的任务：
文件位置：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方法的工作：
看到这里，已经有点眼花缭乱了，又是IBinder，又是IServiceManager，又是BpBinder，又是BpServiceManager，是时候来总结一下这些类的关系了，翻了一下这些类，下面用一个不标准的UML图来说明一下：
需要注意的是：
Android源码分析--MediaServer源码分析（一）
原文地址：http://blog.csdn.net/smbroe/article/details/44685651
