Android IPC 通訊機制原始碼分析
----Albertchen

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進行讀寫。