Android-binder通信詳解

1. binder是什么?

binder是安卓系統的行程間通信方式，

2. 為什么安卓要用binder?

Android內核是基于Linux系統，linux本身就有很多種行程間通信方式: 記憶體共享，訊息佇列、信號量等，為什么安卓還要用binder呢？

傳統ipc(行程間通信):

共享記憶體，不需要記憶體拷貝，但是控制繁瑣，

管道通信，需要兩次記憶體拷貝，

binder通信:

Binder只需要一次拷貝是因為安卓的記憶體映射方法，也就是mmap，a行程發資料給b行程，a行程把資料拷貝給mmap開辟的內核空間，b行程通過mmap就可以取出來這個資料而不用重新拷貝，

3. binder的實作:

binder的實作是基于記憶體映射的，也就是上面說的mmap，

這里我們首先要理解用戶空間和內核空間，內核空間可以訪問所有的行程頁表，也就是內核空間可以訪問所有的用戶空間，也是基于這個前提，行程間通信才可以實作，

要理解mmap必須先理解物理地址、虛擬地址和頁表的概念，

物理地址:

物理地址空間是實在的存在于計算機中的一個物體，在每一臺計算機中保持唯一獨立性，我們可以稱它為物理記憶體；如在32位的機器上，物理空間的大小理論上可以達到2^32位元組(4GB)，

虛擬地址:

虛擬地址并不真實存在于計算機中，每個行程都有4G的虛擬地址空間，其中3G用戶空間，1G內核空間（linux），每個行程共享內核空間，獨立的用戶空間，每個行程都有自己獨立的虛擬地址空間，這樣每個行程都能訪問自己的地址空間，這樣做到了有效的隔離，

虛擬地址里面存放的什么內容?

mmap的作用是映射檔案描述符和指定檔案的(off_t off)區域至呼叫行程的(addr,addr *len)的記憶體區域，如下圖所示：

binder的整個流程:

4. binder的通信流程

整個安卓的行程間通信都是基于c/s架構的，就是client / server 架構，

系統啟動時servicemanager作為0號行程先啟動，然后會讀取rc檔案，把系統中其他的行程依次啟動，

server啟動的時候就把自己注冊到servicemanager里面，servicemanager里面會維護一個services的list，

client端想要和service通信就會先獲取servicemanager服務，然后從servicemanager里面通過service name獲取對應的service的binder，拿到了這個binder client端就可以通過這個binder和service通信了，

具體程序如下:

4.1 server注冊行程:

此處以mediaplayer為例:

int main(int argc __unused, char **argv __unused)
{
    signal(SIGPIPE, SIG_IGN);
　　// 獲取service manager的代理供IPC使用，
    sp<ProcessState> proc(ProcessState::self());
    sp<IServiceManager> sm(defaultServiceManager());
    ALOGI("ServiceManager: %p", sm.get());
    InitializeIcuOrDie();

    MediaPlayerService::instantiate(); // 注冊service，這里是注冊了一個binder
    ResourceManagerService::instantiate(); // 這里和上面一樣

    // 這塊是呼叫binder driver，底層實作是一個thread pool就是一個死回圈
    ProcessState::self()->startThreadPool(); 
    IPCThreadState::self()->joinThreadPool();
}

所有的::instantiate()函式都是static型函式，且分別是創建各個子模塊的物件實體，由此可看出mediaserver共分2個子模塊: MediaPlayerService & ResourceManagerService，

void MediaPlayerService::instantiate() {
    defaultServiceManager()->addService(　// 注冊server，server name為media.player
            String16("media.player"), new MediaPlayerService());
}

server注冊到servermanager的時候會呼叫frameworks/native/cmds/servicemanager/service_manager.c中的do_add_service，這個函式中首先檢查是否有權限注冊service，沒權限就會報錯回傳；然后檢查是否已經注冊過，注冊過的service將不能再次注冊，然后構造一個svcinfo對象，并加入一個全域鏈表中svclist中，最后通知binder設備：有一個service注冊進來，

Tips: server一定是一個死回圈，一直在等待client的呼叫，我們自己寫的server一般是while死回圈之類的，安卓server的死回圈在binder driver里面，我們在server代碼里面看不到，但是只要server呼叫了startThreadPool就會有一個死回圈在底層跑著，

4.2 service啟動流程

首先，每個service都要有對應的rc檔案，里面說明了這個service啟動需要加載的檔案流程:

以mediaserver.rc為例:

service media /system/bin/mediaserver
    class main
    user media
    group audio camera inet net_bt net_bt_admin net_bw_acct drmrpc mediadrm
    ioprio rt 4
    task_profiles ProcessCapacityHigh HighPerformance
    writepid /dev/memcg/camera/media/service/cgroup.procs

有了這個rc檔案，系統在啟動的時候就會呼叫system/bin/mediaserver這個可執行檔案，這個檔案里面的實作就是上面的main函式，然后就會把MediaPlayerService和ResourceManagerService注冊進去，

4.3 client呼叫流程

下面以MediaCodecList為例:

// frameworks/av/media/libstagefright/MediaCodecList.cpp
sp<IMediaCodecList> MediaCodecList::getInstance() {
    Mutex::Autolock _l(sRemoteInitMutex);
    if (sRemoteList == nullptr) {
       // 此處就是通過servicemanager獲取name為"media.player"的server的binder
        sp<IBinder> binder =
            defaultServiceManager()->getService(String16("media.player")); 
        // 拿到了binder就可以訪問service的介面了
        sp<IMediaPlayerService> service =
            interface_cast<IMediaPlayerService>(binder);
        if (service.get() != nullptr) {
            sRemoteList = service->getCodecList();
            if (sRemoteList != nullptr) {
                sBinderDeathObserver = new BinderDeathObserver();
                binder->linkToDeath(sBinderDeathObserver.get());
            }
        }
        if (sRemoteList == nullptr) {
            // if failed to get remote list, create local list
            sRemoteList = getLocalInstance();
        }
    }
    return sRemoteList;
}

client端呼叫的就是IMediaPlayerService中的函式，這個IMediaPlayerService就是介面類，bn和bp都會繼承這個類，client端呼叫的是bp的代碼，然后bp通過binder呼叫到bn，

class BpMediaPlayerService: public BpInterface<IMediaPlayerService> {
    virtual sp<IMediaCodecList> getCodecList() const {
        Parcel data, reply;
        data.writeInterfaceToken(IMediaPlayerService::getInterfaceDescriptor());
        remote()->transact(GET_CODEC_LIST, data, &reply); 
        // remote這里就是通過binder呼叫從client端呼叫server端
        return interface_cast<IMediaCodecList>(reply.readStrongBinder());
    }
}

status_t BnMediaPlayerService::onTransact(...) {
     case GET_CODEC_LIST: {
          sp<IMediaCodecList> mcl = getCodecList();
          reply->writeStrongBinder(IInterface::asBinder(mcl));
          // 這里就會通過binder呼叫把server端的呼叫結果回傳給client端
     }
}

sp<IMediaCodecList> MediaPlayerService::getCodecList() const {
    return MediaCodecList::getLocalInstance();
}

4.4 一個問題: MediaPlayerService和ResourceManagerService屬于一個行程嗎?

這里首先理解一個概念: 代碼中的service究竟是什么?

class MediaPlayerService : public BnMediaPlayerService
class BnMediaPlayerService: public BnInterface<IMediaPlayerService>
class IMediaPlayerService: public IInterface

service是一個繼承了interface的具體實作，用于和client通信，server端和client端同時繼承interface類，一個是bp一個是bn，

所以呢？service和binder有啥關系？ service和行程有啥關系？

service呼叫了instantiate函式就是把自己注冊到了servicemanager里面，這個時候service就是一個binder介面，

注意：直到這里都沒有行程的概念，service 不等于 行程，

那么行程是怎么來的？

看看service的啟動流程, 在servicemanager加載rc檔案的時候，這個rc檔案里面呼叫的是/system/bin/mediaserver，一個可執行檔案，可執行檔案在系統中是什么？是一個單獨的行程，到這里就破案了，

MediaPlayerService和ResourceManagerService都在/system/bin/mediaserver中，所以他們肯定屬于同一個行程，但是他們分別注冊到了service manager中，所以他們是兩個binder，

5. 安卓的treble機制

在Android 8.0開始，Android引入了Treble的機制，為了方便Android系統的快速移植、升級，提升系統穩定性，Binder機制被拓展成了"/dev/binder", "/dev/hwbinder","/dev/vndbinder"，

三種binder的具體使用如下:

此處需要注意VNDK的兩種概念:

在代碼中，當一個so既需要在system磁區使用又需要在vendr磁區使用則宣告該so為VNDK,然后so生成的時候就會產生兩個, 一個在system目錄，一個在vendor目錄，

此處的vndk是兩個vendor磁區的行程通信用的，

6. 總結

本文講述了安卓binder通信，首先從linux已有行程通信存在的問題講起，講述了binder存在的必要，然后講述了binder的實作流程，以及通過media player service為例講述了在c/s架構中binder的具體使用程序，最后講述了安卓中的treble機制，就是安卓對已有binder的幾種擴展，下篇文章將通過audio finger和audio hal的通信再次講述hwbinder的實作程序，敬請期待~