Android Binder原理（三）系統服務的註冊過程

時間  2019-11-21
標籤 android binder 原理 系統 服務 註冊 過程 欄目 Android 简体版
原文   原文鏈接

關聯繫列
Android AOSP基礎系列
Android系統啓動系列
應用進程啓動系列
Android深刻四大組件系列
Android深刻理解Context系列
Android深刻理解JNI系列
Android解析WindowManager
Android解析WMS系列
Android解析AMS系列
Android包管理機制系列
Android輸入系統系列前端

本文首發於微信公衆號「後廠村碼農」程序員

前言

在上一篇文章中，咱們學習了ServiceManager中的Binder機制，有一個問題因爲篇幅問題沒有講完，那就是MediaPlayerService是如何註冊的。經過了解MediaPlayerService是如何註冊的，能夠得知系統服務的註冊過程。微信

1.從調用鏈角度說明MediaPlayerService是如何註冊的

咱們先來看MediaServer的入口函數，代碼以下所示。 frameworks/av/media/mediaserver/main_mediaserver.cppcookie

int main(int argc __unused, char **argv __unused) {
    signal(SIGPIPE, SIG_IGN);
    //獲取ProcessState實例
    sp<ProcessState> proc(ProcessState::self());
    sp<IServiceManager> sm(defaultServiceManager());
    ALOGI("ServiceManager: %p", sm.get());
    InitializeIcuOrDie();
    //註冊MediaPlayerService
    MediaPlayerService::instantiate();//1
    ResourceManagerService::instantiate();
    registerExtensions();
    //啓動Binder線程池
    ProcessState::self()->startThreadPool();
    //當前線程加入到線程池
    IPCThreadState::self()->joinThreadPool();
}
複製代碼

這段代碼中的不少內容都在上一篇文章介紹過了，接着分析註釋1處的代碼。數據結構

frameworks/av/media/libmediaplayerservice/MediaPlayerService.cpp架構

void MediaPlayerService::instantiate() {
    defaultServiceManager()->addService(
            String16("media.player"), new MediaPlayerService，());
}
複製代碼

defaultServiceManager返回的是BpServiceManager，不清楚的看[Android Binder原理（二）ServiceManager中的Binder機制][1]這篇文章。參數是一個字符串和MediaPlayerService，看起來像是Key/Value的形式來完成註冊，接着看addService函數。函數

frameworks/native/libs/binder/IServiceManager.cpp學習

virtual status_t addService(const String16& name, const sp<IBinder>& service, bool allowIsolated, int dumpsysPriority) {
        Parcel data, reply;//數據包
        data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
        data.writeString16(name); //name值爲"media.player"
        data.writeStrongBinder(service); //service值爲MediaPlayerService
        data.writeInt32(allowIsolated ? 1 : 0);
        data.writeInt32(dumpsysPriority);
        status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);//1
        return err == NO_ERROR ? reply.readExceptionCode() : err;
    }
複製代碼

data是一個數據包，後面會不斷的將數據寫入到data中， 註釋1處的remote()指的是mRemote，也就是BpBinder。addService函數的做用就是將請求數據打包成data，而後傳給BpBinder的transact函數，代碼以下所示。 frameworks/native/libs/binder/BpBinder.cppui

status_t BpBinder::transact(
    uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
    if (mAlive) {
        status_t status = IPCThreadState::self()->transact(
            mHandle, code, data, reply, flags);
        if (status == DEAD_OBJECT) mAlive = 0;
        return status;
    }

    return DEAD_OBJECT;
}
複製代碼

BpBinder將邏輯處理交給IPCThreadState，先來看IPCThreadState::self()幹了什麼？ frameworks/native/libs/binder/IPCThreadState.cppthis

IPCThreadState* IPCThreadState::self()
{   
    //首次進來gHaveTLS的值爲false
    if (gHaveTLS) {
restart:
        const pthread_key_t k = gTLS;//1
        IPCThreadState* st = (IPCThreadState*)pthread_getspecific(k);//2
        if (st) return st;
        return new IPCThreadState;//3
    }
    ...
    pthread_mutex_unlock(&gTLSMutex);
    goto restart;
}
複製代碼

註釋1處的TLS的全稱爲Thread local storage，指的是線程本地存儲空間，在每一個線程中都有TLS，而且線程間不共享。註釋2處用於獲取TLS中的內容並賦值給IPCThreadState*指針。註釋3處會新建一個IPCThreadState，這裏能夠得知IPCThreadState::self()其實是爲了建立IPCThreadState，它的構造函數以下所示。 frameworks/native/libs/binder/IPCThreadState.cpp

IPCThreadState::IPCThreadState()
    : mProcess(ProcessState::self()),
      mStrictModePolicy(0),
      mLastTransactionBinderFlags(0)
{
    pthread_setspecific(gTLS, this);//1
    clearCaller();
    mIn.setDataCapacity(256);
    mOut.setDataCapacity(256);
}
複製代碼

註釋1處的pthread_setspecific函數用於設置TLS，將IPCThreadState::self()得到的TLS和自身傳進去。IPCThreadState中還包含mIn、一個mOut，其中mIn用來接收來自Binder驅動的數據，mOut用來存儲發往Binder驅動的數據，它們默認大小都爲256字節。 知道了IPCThreadState的構造函數，再回來查看IPCThreadState的transact函數。 frameworks/native/libs/binder/IPCThreadState.cpp

status_t IPCThreadState::transact(int32_t handle,
                                  uint32_t code, const Parcel& data,
                                  Parcel* reply, uint32_t flags)
{
    status_t err;

    flags |= TF_ACCEPT_FDS;
    ...
    err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL);//1

    if (err != NO_ERROR) {
        if (reply) reply->setError(err);
        return (mLastError = err);
    }

    if ((flags & TF_ONE_WAY) == 0) {
       ...
        if (reply) {
            err = waitForResponse(reply);//2
        } else {
            Parcel fakeReply;
            err = waitForResponse(&fakeReply);
        }
       ...
    } else {
       //不須要等待reply的分支
        err = waitForResponse(NULL, NULL);
    }

    return err;
}
複製代碼

調用BpBinder的transact函數實際上就是調用IPCThreadState的transact函數。註釋1處的writeTransactionData函數用於傳輸數據，其中第一個參數BC_TRANSACTION表明向Binder驅動發送命令協議，向Binder設備發送的命令協議都以BC_開頭，而Binder驅動返回的命令協議以BR_開頭。這個命令協議咱們先記住，後面會再次提到他。

如今分別來分析註釋1的writeTransactionData函數和註釋2處的waitForResponse函數。

1.1 writeTransactionData函數分析

frameworks/native/libs/binder/IPCThreadState.cpp

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;//1

    tr.target.ptr = 0; 
    tr.target.handle = handle;//2 
    tr.code = code;  //code=ADD_SERVICE_TRANSACTION
    tr.flags = binderFlags;
    tr.cookie = 0;
    tr.sender_pid = 0;
    tr.sender_euid = 0;

    const status_t err = data.errorCheck();//3
    if (err == NO_ERROR) {
        tr.data_size = data.ipcDataSize();
        tr.data.ptr.buffer = data.ipcData();
        tr.offsets_size = data.ipcObjectsCount()*sizeof(binder_size_t);
        tr.data.ptr.offsets = data.ipcObjects();
    } else if (statusBuffer) {
        tr.flags |= TF_STATUS_CODE;
        *statusBuffer = err;
        tr.data_size = sizeof(status_t);
        tr.data.ptr.buffer = reinterpret_cast<uintptr_t>(statusBuffer);
        tr.offsets_size = 0;
        tr.data.ptr.offsets = 0;
    } else {
        return (mLastError = err);
    }

    mOut.writeInt32(cmd);  //cmd=BC_TRANSACTION
    mOut.write(&tr, sizeof(tr));

    return NO_ERROR;
}
複製代碼

註釋1處的binder_transaction_data結構體(tr結構體）是向Binder驅動通訊的數據結構，註釋2處將handle傳遞給target的handle，用於標識目標，這裏的handle的值爲0，表明了ServiceManager。 註釋3處對數據data進行錯誤檢查，若是沒有錯誤就將數據賦值給對應的tr結構體。最後會將BC_TRANSACTION和tr結構體寫入到mOut中。 上面代碼調用鏈的時序圖以下所示。

KtOUu8.png

1.2 waitForResponse函數分析

接着回過頭來查看waitForResponse函數作了什麼，waitForResponse函數中的case語句不少，這裏截取部分代碼。
frameworks/native/libs/binder/IPCThreadState.cpp

status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)
{
    uint32_t cmd;
    int32_t err;
    while (1) {
        if ((err=talkWithDriver()) < NO_ERROR) break;//1
        err = mIn.errorCheck();
        if (err < NO_ERROR) break;
        if (mIn.dataAvail() == 0) continue;
        cmd = (uint32_t)mIn.readInt32();
        IF_LOG_COMMANDS() {
            alog << "Processing waitForResponse Command: "
                << getReturnString(cmd) << endl;
        }
        switch (cmd) {
        case BR_TRANSACTION_COMPLETE:
            if (!reply && !acquireResult) goto finish;
            break;

        case BR_DEAD_REPLY:
            err = DEAD_OBJECT;
            goto finish;
       ...
        default:
            //處理各類命令協議
            err = executeCommand(cmd);
            if (err != NO_ERROR) goto finish;
            break;
        }
}
finish:
    ...
    return err;
}
複製代碼

註釋1處的talkWithDriver函數的內部經過ioctl與Binder驅動進行通訊，代碼以下所示。 frameworks/native/libs/binder/IPCThreadState.cpp

status_t IPCThreadState::talkWithDriver(bool doReceive)
{
    if (mProcess->mDriverFD <= 0) {
        return -EBADF;
    }
    //和Binder驅動通訊的結構體
    binder_write_read bwr; //1
    //mIn是否有可讀的數據，接收的數據存儲在mIn
    const bool needRead = mIn.dataPosition() >= mIn.dataSize();
    const size_t outAvail = (!doReceive || needRead) ? mOut.dataSize() : 0;
    bwr.write_size = outAvail;
    bwr.write_buffer = (uintptr_t)mOut.data();//2
    //這時doReceive的值爲true
    if (doReceive && needRead) {
        bwr.read_size = mIn.dataCapacity();
        bwr.read_buffer = (uintptr_t)mIn.data();//3
    } else {
        bwr.read_size = 0;
        bwr.read_buffer = 0;
    }
   ...
    if ((bwr.write_size == 0) && (bwr.read_size == 0)) return NO_ERROR;
    bwr.write_consumed = 0;
    bwr.read_consumed = 0;
    status_t err;
    do {
        IF_LOG_COMMANDS() {
            alog << "About to read/write, write size = " << mOut.dataSize() << endl;
        }
#if defined(__ANDROID__)
        if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0)//4
            err = NO_ERROR;
        else
            err = -errno;
#else
        err = INVALID_OPERATION;
#endif
     ...
    } while (err == -EINTR);
    ...
    return err;
}
複製代碼

註釋1處的 binder_write_read是和Binder驅動通訊的結構體，在註釋2和3處將mOut、mIn賦值給binder_write_read的相應字段，最終經過註釋4處的ioctl函數和Binder驅動進行通訊，這一部分涉及到Kernel Binder的內容 了，就再也不詳細介紹了，只須要知道在Kernel Binder中會記錄服務名和handle，用於後續的服務查詢。

1.3 小節

從調用鏈的角度來看，MediaPlayerService是如何註冊的貌似並不複雜，由於這裏只是簡單的介紹了一個調用鏈分支，能夠簡單的總結爲如下幾個步驟：

  1. addService函數將數據打包發送給BpBinder來進行處理。
  2. BpBinder新建一個IPCThreadState對象，並將通訊的任務交給IPCThreadState。
  3. IPCThreadState的writeTransactionData函數用於將命令協議和數據寫入到mOut中。
  4. IPCThreadState的waitForResponse函數主要作了兩件事，一件事是經過ioctl函數操做mOut和mIn來與Binder驅動進行數據交互，另外一件事是處理各類命令協議。

2.從進程角度說明MediaPlayerService是如何註冊的

實際上MediaPlayerService的註冊還涉及到了進程，以下圖所示。

Ka0Dx0.png

從圖中看出是以C/S架構爲基礎，addService是在MediaPlayerService進行的，它是Client端，用於請求添加系統服務。而Server端則是指的是ServiceManager，用於完成系統服務的添加。 Client端和Server端分別運行在兩個進程中，經過向Binder來進行通訊。更詳細點描述，就是兩端經過向Binder驅動發送命令協議來完成系統服務的添加。這其中命令協議很是多，過程也比較複雜，這裏對命令協議進行了簡化，只涉及到了四個命令協議，其中 BC_TRANSACTION和BR_TRANSACTION過程是一個完整的事務，BC_REPLY和BR_REPLY是一個完整的事務。 Client端和Server端向Binder驅動發送命令協議以BC開頭，而Binder驅動向Client端和Server端返回的命令協議以BR_開頭。

步驟以下所示： 1.Client端向Binder驅動發送BC_TRANSACTION命令。 2.Binder驅動接收到請求後生成BR_TRANSACTION命令，喚醒Server端的線程後將BR_TRANSACTION命令發送給ServiceManager。 3.Server端中的服務註冊完成後，生成BC_REPLY命令發送給Binder驅動。 4.Binder驅動生成BR_REPLY命令，喚醒Client端的線程後將BR_REPLY命令發送個Client端。

經過這些協議命令來驅動並完成系統服務的註冊。

3.總結

本文分別從調用鏈角度和進程角度來說解MediaPlayerService是如何註冊的，間接的得出了服務是如何註冊的 。這兩個角度都比較複雜，所以這裏分別對這兩個角度作了簡化，做爲應用開發，咱們不須要注重太多的過程和細節，只須要了解大概的步驟便可。

這裏不只分享大前端、Android、Java等技術，還有程序員成長類文章。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程