Android IPC 通讯机制源码分析

Binder通信简介：

Linux系统中进程间通信的方式有:socket, named pipe,message queque, signal,share memory。Java系统中的进程间通信方式有socket, named pipe等，android应用程序理所当然可以应用JAVA的IPC机制实现进程间的通信，但我查看android的源码，在同一终端上的应用软件的通 信几乎看不到这些IPC通信方式，取而代之的是Binder通信。Google为什么要采用这种方式呢，这取决于Binder通信方式的高效率。 Binder通信是通过linux的binder
driver来实现的，Binder通信操作类似线程迁移(thread migration)，两个进程间IPC看起来就象是一个进程进入另一个进程执行代码然后带着执行的结果返回。Binder的用户空间为每一个进程维护着 一个可用的线程池，线程池用于处理到来的IPC以及执行进程本地消息，Binder通信是同步而不是异步。

Android中的Binder通信是基于Service与Client的，所有需要IBinder通信的进程都必须创建一个IBinder接口，系统中 有一个进程管理所有的system service,Android不允许用户添加非授权的System service,当然现在源码开发了，我们可以修改一些代码来实现添加底层system Service的目的。对用户程序来说，我们也要创建server,或者Service用于进程间通信，这里有一个 ActivityManagerService管理JAVA应用层所有的service创建与连接(connect),disconnect,所有的
Activity也是通过这个service来启动，加载的。ActivityManagerService也是加载在Systems Servcie中的。

Android虚拟机启动之前系统会先启动service Manager进程，service Manager打开binder驱动，并通知binder kernel驱动程序这个进程将作为System Service Manager，然后该进程将进入一个循环，等待处理来自其他进程的数据。用户创建一个System service后，通过defaultServiceManager得到一个远程ServiceManager的接口，通过这个接口我们可以调用 addService函数将System service添加到Service
Manager进程中，然后client可以通过getService获取到需要连接的目的Service的IBinder对象，这个IBinder是 Service的BBinder在binder kernel的一个参考，所以service IBinder 在binder kernel中不会存在相同的两个IBinder对象，每一个Client进程同样需要打开Binder驱动程序。对用户程序而言，我们获得这个对象就可 以通过binder kernel访问service对象中的方法。Client与Service在不同的进程中，通过这种方式实现了类似线程间的迁移的通信方式，对用户程序
而言当调用Service返回的IBinder接口后，访问Service中的方法就如同调用自己的函数。

下图为client与Service建立连接的示意图



首先从ServiceManager注册过程来逐步分析上述过程是如何实现的。

ServiceMananger进程注册过程源码分析：

Service Manager Process（Service_manager.c）:

Service_manager为其他进程的Service提供管理，这个服务程序必须在Android Runtime起来之前运行，否则Android JAVA Vm ActivityManagerService无法注册。

int main(int argc, char **argv)

{

struct binder_state *bs;

void *svcmgr = BINDER_SERVICE_MANAGER;

bs = binder_open(128*1024); //打开/dev/binder 驱动

if (binder_become_context_manager(bs)) {//注册为service manager in binder kernel

LOGE("cannot become context manager (%s)\n", strerror(errno));

return -1;

}

svcmgr_handle = svcmgr;

binder_loop(bs, svcmgr_handler);

return 0;

}

首先打开binder的驱动程序然后通过binder_become_context_manager函数调用ioctl告诉Binder Kernel驱动程序这是一个服务管理进程，然后调用binder_loop等待来自其他进程的数据。BINDER_SERVICE_MANAGER是服 务管理进程的句柄，它的定义是：

/* the one magic object */

#define BINDER_SERVICE_MANAGER ((void*) 0)

如果客户端进程获取Service时所使用的句柄与此不符，Service Manager将不接受Client的请求。客户端如何设置这个句柄在下面会介绍。

CameraSerivce服务的注册(Main_mediaservice.c）

int main(int argc, char** argv)

{

sp<ProcessState> proc(ProcessState::self());

sp<IServiceManager> sm = defaultServiceManager();

LOGI("ServiceManager: %p", sm.get());

AudioFlinger::instantiate(); //Audio 服务

MediaPlayerService::instantiate(); //mediaPlayer服务

CameraService::instantiate(); //Camera 服务

ProcessState::self()->startThreadPool(); //为进程开启缓冲池

IPCThreadState::self()->joinThreadPool(); //将进程加入到缓冲池

}

CameraService.cpp

void CameraService::instantiate() {

defaultServiceManager()->addService(

String16("media.camera"), new CameraService());

}

创建CameraService服务对象并添加到ServiceManager进程中。

client获取remote IServiceManager IBinder接口：

sp<IServiceManager> defaultServiceManager()

{

if (gDefaultServiceManager != NULL) return gDefaultServiceManager;

{

AutoMutex _l(gDefaultServiceManagerLock);

if (gDefaultServiceManager == NULL) {

gDefaultServiceManager = interface_cast<IServiceManager>(

ProcessState::self()->getContextObject(NULL));

}

}

return gDefaultServiceManager;

}

任何一个进程在第一次调用defaultServiceManager的时候gDefaultServiceManager值为Null，所以该进程会通 过ProcessState::self得到ProcessState实例。ProcessState将打开Binder驱动。

ProcessState.cpp

sp<ProcessState> ProcessState::self()

{

if (gProcess != NULL) return gProcess;

AutoMutex _l(gProcessMutex);

if (gProcess == NULL) gProcess = new ProcessState;

return gProcess;

}

ProcessState::ProcessState()

: mDriverFD(open_driver()) //打开/dev/binder驱动

...........................

{

}

sp<IBinder> ProcessState::getContextObject(const sp<IBinder>& caller)

{

if (supportsProcesses()) {

return getStrongProxyForHandle(0);

} else {

return getContextObject(String16("default"), caller);

}

}

Android是支持Binder驱动的所以程序会调用getStrongProxyForHandle。这里handle为0，正好与Service_manager中的BINDER_SERVICE_MANAGER一致。

sp<IBinder> ProcessState::getStrongProxyForHandle(int32_t handle)

{

sp<IBinder> result;

AutoMutex _l(mLock);

handle_entry* e = lookupHandleLocked(handle);

if (e != NULL) {

// We need to create a new BpBinder if there isn't currently one, OR we

// are unable to acquire a weak reference on this current one. See comment

// in getWeakProxyForHandle() for more info about this.

IBinder* b = e->binder; //第一次调用该函数b为Null

if (b == NULL || !e->refs->attemptIncWeak(this)) {

b = new BpBinder(handle);

e->binder = b;

if (b) e->refs = b->getWeakRefs();

result = b;

} else {

// This little bit of nastyness is to allow us to add a primary

// reference to the remote proxy when this team doesn't have one

// but another team is sending the handle to us.

result.force_set(b);

e->refs->decWeak(this);

}

}

return result;

}

第一次调用的时候b为Null所以会为b生成一BpBinder对象：

BpBinder::BpBinder(int32_t handle)

: mHandle(handle)

, mAlive(1)

, mObitsSent(0)

, mObituaries(NULL)

{

LOGV("Creating BpBinder %p handle %d\n", this, mHandle);

extendObjectLifetime(OBJECT_LIFETIME_WEAK);

IPCThreadState::self()->incWeakHandle(handle);

}

void IPCThreadState::incWeakHandle(int32_t handle)

{

LOG_REMOTEREFS("IPCThreadState::incWeakHandle(%d)\n", handle);

mOut.writeInt32(BC_INCREFS);

mOut.writeInt32(handle);

}

getContextObject返回了一个BpBinder对象。

interface_cast<IServiceManager>(

ProcessState::self()->getContextObject(NULL));

template<typename INTERFACE>

inline sp<INTERFACE> interface_cast(const sp<IBinder>& obj)

{

return INTERFACE::asInterface(obj);

}

将这个宏扩展后最终得到的是：

sp<IServiceManager> IServiceManager::asInterface(const sp<IBinder>& obj)

{

sp<IServiceManager> intr;

if (obj != NULL) {

intr = static_cast<IServiceManager*>(

obj->queryLocalInterface(

IServiceManager::descriptor).get());

if (intr == NULL) {

intr = new BpServiceManager(obj);

}

}

return intr;

}

返回一个BpServiceManager对象,这里obj就是前面我们创建的BpBInder对象。

client获取Service的远程IBinder接口

以CameraService为例(camera.cpp):

const sp<ICameraService>& Camera::getCameraService()

{

Mutex::Autolock _l(mLock);

if (mCameraService.get() == 0) {

sp<IServiceManager> sm = defaultServiceManager();

sp<IBinder> binder;

do {

binder = sm->getService(String16("media.camera"));

if (binder != 0)

break;

LOGW("CameraService not published, waiting...");

usleep(500000); // 0.5 s

} while(true);

if (mDeathNotifier == NULL) {

mDeathNotifier = new DeathNotifier();

}

binder->linkToDeath(mDeathNotifier);

mCameraService = interface_cast<ICameraService>(binder);

}

LOGE_IF(mCameraService==0, "no CameraService!?");

return mCameraService;

}

由前面的分析可知sm是BpCameraService对象 ：//应该为BpServiceManager对象

virtual sp<IBinder> getService(const String16& name) const

{

unsigned n;

for (n = 0; n < 5; n++){

sp<IBinder> svc = checkService(name);

if (svc != NULL) return svc;

LOGI("Waiting for sevice %s...\n", String8(name).string());

sleep(1);

}

return NULL;

}

virtual sp<IBinder> checkService( const String16& name) const

{

Parcel data, reply;

data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());

data.writeString16(name);

remote()->transact(CHECK_SERVICE_TRANSACTION, data, &reply);

return reply.readStrongBinder();

}

这里的remote就是我们前面得到BpBinder对象。所以checkService将调用BpBinder中的transact函数：

status_t BpBinder::transact(

uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)

{

// Once a binder has died, it will never come back to life.

if (mAlive) {

status_t status = IPCThreadState::self()->transact(

mHandle, code, data, reply, flags);

if (status == DEAD_OBJECT) mAlive = 0;

return status;

}

return DEAD_OBJECT;

}

mHandle为0，BpBinder继续往下调用IPCThreadState:transact函数将数据发给与mHandle相关联的Service Manager Process。

status_t IPCThreadState::transact(int32_t handle,

uint32_t code, const Parcel& data,

Parcel* reply, uint32_t flags)

{

............................................................

if (err == NO_ERROR) {

LOG_ONEWAY(">>>> SEND from pid %d uid %d %s", getpid(), getuid(),

(flags & TF_ONE_WAY) == 0 ? "READ REPLY" : "ONE WAY");

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);

}

..............................

return err;

}

通过writeTransactionData构造要发送的数据

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.handle = handle; //这个handle将传递到service_manager

tr.code = code;

tr.flags = bindrFlags;

。。。。。。。。。。。。。。

}

waitForResponse将调用talkWithDriver与对Binder kernel进行读写操作。当Binder kernel接收到数据后，service_mananger线程的ThreadPool就会启动，service_manager查找到 CameraService服务后调用binder_send_reply，将返回的数据写入Binder kernel,Binder kernel。

status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)

{

int32_t cmd;

int32_t err;

while (1) {

if ((err=talkWithDriver()) < NO_ERROR) break;

..............................................

}

status_t IPCThreadState::talkWithDriver(bool doReceive)

{

............................................

#if defined(HAVE_ANDROID_OS)

if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0)

err = NO_ERROR;

else

err = -errno;

#else

err = INVALID_OPERATION;

#endif

...................................................

}

通过上面的ioctl系统函数中BINDER_WRITE_READ对binder kernel进行读写。