Android Binder框架跨程序傳輸的，基本都是通過Parcel來封裝的資料[service_manager除外]，這個是十分底層的實現了。對於Framework開發來說，除了瞭解RPC的抽象意義外，對底層的具體通訊細節的實現，也是要比較瞭解的，這裡簡單記錄一下RPC通訊資料傳遞的過程。

1. parcel是啥

Parcel主要是方便實現上層抽象物件或資料打包做跨程序傳輸而封裝的一個類，類名的字面意思也差不多說明了。其作用，說白了，就是將要寫入的資料，規整到一個連續的buffer記憶體中，同時記錄一些資料資訊屬性。遠端程序可接收後根據這些屬性和讀取順序來克隆還原。連續buffer記憶體方便驅動實現，同時效率也高。目前Android中，除了service_manager外[太簡單了，而且純C寫的..]，都是走parcel。

2.一個簡單的binder通訊例子 

這裡，我們簡單的用一個dump服務的介面實現，來看一下在binder通訊過程中，資料在程序中的傳遞過程。

#include <utils/Atomic.h>
#include <utils/Errors.h>
#include <utils/Log.h>
#include <binder/IBinder.h>
#include <binder/IPCThreadState.h>
#include <binder/IServiceManager.h>
#include <binder/ProcessState.h>
#include <stdio.h>
using namespace android;
int main() {
    status_t err = NO_ERROR;
    const sp<IServiceManager> sm = defaultServiceManager();
    sp<IBinder> ibinder = sm->getService(String16("activity"));
    // 這裡開始Binder傳輸，請求服務端執行dump，只有傳送資料，不需要接收資料
    if (ibinder != NULL ) {
        // 構造兩個空的Parcel,一個是用於傳送，一個用於接受
        Parcel send;
        Parcel reply;
        send.writeFileDescriptor(STDOUT_FILENO); // 寫入檔案FD.
        send.writeInt32(0); // dump命令的引數個數，這裡是0個，不帶引數了。
        status_t err = ibinder->transact(IBinder::DUMP_TRANSACTION, send, &reply);
    }
    // 這是binder傳輸，獲取服務的descriptor， 不需要傳送資料，只需要接收資料
    {
        Parcel send, reply;
        status_t err = ibinder->transact(IBinder::INTERFACE_TRANSACTION, send, &reply);
        if (err == NO_ERROR) {
            printf("Read service interface: %s\n", String8(reply.readString16()).string());
        }
    }
    return 0;
}
 

通訊過程比較簡單，將要傳遞的資料，通過Parcel的writeXXX系列函式寫入到Parcel中，然後呼叫IBinder的transact，發起遠端通訊請求，通訊的資料結果，存在Parcel物件reply中，從這個物件中讀出結果即可。 Binder通訊的詳細流程不分析了，扒一下Binder驅動和IPCThreadState，整個Binder的一次傳輸過程，可以用如下圖簡單描述一下： 通訊過程的資料傳遞，後面接著看一下。

3. 傳送時待傳輸的Parcel物件

Binder通訊基本上都是通過Parcel來傳遞資料的，呼叫Parcel.writexxx將要傳遞資料存到物件中. 看下流程。 本地端，啟動服務傳輸： Parce建構函式，實際沒做什麼事情，沒有分配儲存物件的記憶體：

Parcel::Parcel()
{
    LOG_ALLOC("Parcel %p: constructing", this);
    initState();
}
..
void Parcel::initState()
{
    LOG_ALLOC("Parcel %p: initState", this);
    mError = NO_ERROR;
    mData = 0;
    mDataSize = 0;
    mDataCapacity = 0;
    mDataPos = 0;
    ALOGV("initState Setting data size of %p to %zu", this, mDataSize);
    ALOGV("initState Setting data pos of %p to %zu", this, mDataPos);
    mObjects = NULL;
    mObjectsSize = 0;
    mObjectsCapacity = 0;
    mNextObjectHint = 0;
    mHasFds = false;
    mFdsKnown = true;
    mAllowFds = true;
    mOwner = NULL;
}
 

Parcel儲存資料的記憶體緩衝[mData]，是在寫入物件時(這裡基本資料型別，也可以看做物件，實現稍有差異，不過原理都一樣)，根據寫入資料，自動調整的。看一下上面例子中，寫入parcel的方法： 1. send.writeFileDescriptor(STDOUT_FILENO);
時，

status_t Parcel::writeFileDescriptor(int fd, bool takeOwnership)
{
    flat_binder_object obj;
    obj.type = BINDER_TYPE_FD;
    obj.flags = 0x7f | FLAT_BINDER_FLAG_ACCEPTS_FDS;
    obj.binder = 0; /* Don't pass uninitialized stack data to a remote process */
    obj.handle = fd;
    obj.cookie = takeOwnership ? 1 : 0;
    return writeObject(obj, true);
}

這裡傳輸fd會比較特殊。fd雖然是一個整形，但它代表的是一個檔案控制代碼，跨程序傳遞到對方程序中。程式碼也比較簡單，把fd封裝到flat_binder_object中，再通過writeObject寫入Parcel中。

status_t Parcel::writeObject(const flat_binder_object& val, bool nullMetaData)
{
    const bool enoughData = (mDataPos+sizeof(val)) <= mDataCapacity;
    const bool enoughObjects = mObjectsSize < mObjectsCapacity;
    //首次寫，是沒有申請記憶體的， mDataCapacity是0，此條件不成立
    if (enoughData && enoughObjects) {
restart_write:
        *reinterpret_cast<flat_binder_object*>(mData+mDataPos) = val;
        ....
        return finishWrite(sizeof(flat_binder_object));
    }
    // 記憶體不夠， 增加容量，申請到可以容納寫入程序的空間
    if (!enoughData) {
        const status_t err = growData(sizeof(val));
        if (err != NO_ERROR) return err;
    }
    ...
    goto restart_write;
}

growData是真正申請記憶體的地方：

status_t Parcel::growData(size_t len)
{
    size_t newSize = ((mDataSize+len)*3)/2;
    return (newSize <= mDataSize)
            ? (status_t) NO_MEMORY
            : continueWrite(newSize);
}

這裡新申請的記憶體，是需要的1.5倍，目的應該也就是避免頻繁grow的情況吧，下面可以看到，如果要grow的話，代價很大的！

status_t Parcel::continueWrite(size_t desired)
{
    ...
    // 這裡的mOwner變數，是很重要的一個東西，在從Binder讀取資料的時候用到。
    if (mOwner) {
       ...
    } else if (mData) {  // 第一次，mData也是NULL，如果不為NULL，要有memcpy動作了，這裡就是比較浪費
     ...
    } else {
        // This is the first data.  Easy!
        // 上面是原生註釋，第一次簡單，直接分配就行，第二次或以後，麻煩再要拷貝移動了。
        uint8_t* data = (uint8_t*)malloc(desired);
        if (!data) {
            mError = NO_MEMORY;
            return NO_MEMORY;
        }
        ...
        mData = data;
        mDataSize = mDataPos = 0;
        ALOGV("continueWrite Setting data size of %p to %zu", this, mDataSize);
        ALOGV("continueWrite Setting data pos of %p to %zu", this, mDataPos);
        mDataCapacity = desired;
    }
    return NO_ERROR;
}

分配好記憶體後，下面就是寫了, 寫入繼續見writeObject函式，分配好後goto restart_write，直接寫入資料：

1. *reinterpret_cast<flat_binder_object*>(mData+mDataPos)= val;

其實還是蠻簡單的。 寫入完成後，finishWrite:

status_t Parcel::finishWrite(size_t len)
{
    //printf("Finish write of %d\n", len);
    mDataPos += len;
    ALOGV("finishWrite Setting data pos of %p to %zu", this, mDataPos);
    if (mDataPos > mDataSize) {
        mDataSize = mDataPos;
        ALOGV("finishWrite Setting data size of %p to %zu", this, mDataSize);
    }
    //printf("New pos=%d, size=%d\n", mDataPos, mDataSize);
    return NO_ERROR;
}

只是更新一下資料指標。 2. send.writeInt32(0); 這是寫入一個int數，比較簡單。 上一步分配的記憶體容量，實際是還夠寫入一個int的，直接寫入即可。注意資料是按照資料型別對齊的。

status_t Parcel::writeInt32(int32_t val)
{
    return writeAligned(val);
}
..
template<class T>
status_t Parcel::writeAligned(T val) {
    COMPILE_TIME_ASSERT_FUNCTION_SCOPE(PAD_SIZE(sizeof(T)) == sizeof(T));
    if ((mDataPos+sizeof(val)) <= mDataCapacity) {
restart_write:
        *reinterpret_cast<T*>(mData+mDataPos) = val;
        return finishWrite(sizeof(val));
    }
    status_t err = growData(sizeof(val));
    if (err == NO_ERROR) goto restart_write;
    return err;
}

以上是寫入Parcel資料的過程，蠻簡單的，記憶體容量的增長和資料大小等概念，和c++中的vector實現有些類似。 不過實際使用，可能還有一些注意的：

• fd的寫入，需要封裝成一個flat_binder_object， object還用另外一個mObjects管理，mObjects存放的是objects在mData中的偏移位置，這個也要發給驅動，這裡沒展開說。
  
• 正常主動通過Parcel寫入的資料，都是放在malloc分配的堆上的，這裡也就沒有特別的尺寸限制了。但並不是說對尺寸沒要求，因為資料的接收端有要求！
  
• 這裡Parcel只是對資料的打包類，在面向物件的抽象上，可以將可序列化的物件，flatten到一個parcel中通過binder傳遞。不過上層的物件和這裡的flat_binder_object是兩個不同概念，flat_binder_object專指binder和fd[這兩個是不能序列化的，所以要特殊處理了，binder驅動會針對做特殊處理..]。
  

囉嗦這麼多，其實就一句話：IPC傳輸時的Parcel資料，就是寫在malloc的堆中，其他那些複雜的code，都是為了效率和方便性。

4. binder的傳輸資料過程

具體負責binder通訊的類，是IPCThreadState。IBinder的transact，實際呼叫的就是IPCThreadState::transact Parcel是專門供binder transact過程中，打包傳遞資料使用的。瞅一下傳遞過程： 呼叫IBinder的trasact，實際方法是在IPCThreadState類中，這個類是實際負責和Binder驅動操作。 IPCThreadState類不再展開說了，基本上，就是將通訊的資料，再封在一個Parcel類中，開始傳輸：

status_t IPCThreadState::transact(int32_t handle,
                                  uint32_t code, const Parcel& data,
                                  Parcel* reply, uint32_t flags)
    ...
    if (err == NO_ERROR) {
        ...
        // 將parcel組織起來，放到待寫入結構中
        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) {
        ...
        // 如果不是非同步binder，則要等待一下，這個transaction請求傳送成功，並等待遠端端處理完的迴應
        if (reply) {
            err = waitForResponse(reply);
        } else {
            Parcel fakeReply;
            // 如果不需要遠端迴應返回資料，同步呼叫也要等待binder的遠端執行完成結束，這裡通過fakeReply實現這一邏輯
            err = waitForResponse(&fakeReply);
        }
        ...
    } else {
        // 非同步binder，只等待transaction命令寫入成功即可
        err = waitForResponse(NULL, NULL);
    }
    
    return err;
}

這裡主要是將待寫入的資料，封裝成一個binder_transaction_data的結構體，然後寫入binder驅動。binder通訊過程是在waitForResponse中實現的。

status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)
{
     while (1) {
        if ((err=talkWithDriver()) < NO_ERROR) break;;
        ...
        cmd = mIn.readInt32();
        ...
        switch (cmd) {
        case BR_TRANSACTION_COMPLETE:
            if (!reply && !acquireResult) goto finish;
            break;       
 ...        
        case BR_REPLY:
 ...
            goto finish;
        default:
            err = executeCommand(cmd);
            if (err != NO_ERROR) goto finish;
            break;
        }
    }
finish:
    if (err != NO_ERROR) {
        if (acquireResult) *acquireResult = err;
        if (reply) reply->setError(err);
        mLastError = err;
    }
    
    return err;
}

對於傳送端，通過這個函式，就將資料寫入到binder驅動中，驅動接收後會反饋BR_TRANSACTION_COMPLETE訊息，如果是非同步呼叫，直接就通訊結束了，如果是同步的，還要再talkWithDriver，等服務端傳送的呼叫結果。 5. binder接收方得到Parcel
服務端在talkWithDriver時，收到驅動的訊息，在transact呼叫的BR_TRANSACT時，會執行服務端的transact處理，響應程式碼如下：

status_t IPCThreadState::executeCommand(int32_t cmd)
{
    BBinder* obj;
    RefBase::weakref_type* refs;
    status_t result = NO_ERROR;
    
    ...
    
    case BR_TRANSACTION:
        {
            binder_transaction_data tr;
            result = mIn.read(&tr, sizeof(tr));
            Parcel buffer;
            buffer.ipcSetDataReference(
                reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),    //驅動填入的buffer地址，binder驅動分配的，是binder記憶體
                tr.data_size,
                reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets),
                tr.offsets_size/sizeof(binder_size_t), freeBuffer, this); // 釋放binder記憶體的釋放函式。
...
            Parcel reply;
            status_t error;
            if (tr.target.ptr) {
                sp<BBinder> b((BBinder*)tr.cookie);
                error = b->transact(tr.code, buffer, &reply, tr.flags);
            } else {
                error = the_context_object->transact(tr.code, buffer, &reply, tr.flags);
            }
...
        }
        break;
    
   ...
    
    return result;
}

這裡主要由兩點： 1.  buffer.ipcSetDataReference 這個就是客戶端呼叫時，寫過來的parcel的資料內容。parcel通過ipcSetDataReference重構出一個和客戶端一樣的內容。這個函式注意的就是傳入的buffer地址，這個是驅動分配的binder buffer地址。另外還提供了free這個buffer的方法(freeBuffer)。 2.  呼叫binder服務端的transcat。     這裡注意的是，當target.ptr為0時，實際就是和service_manager通訊了。不過service_manager自己走自己實現那套，這個是死程式碼，不可能走進來的。正常都是走b->transact，即：

status_t BBinder::transact(
    uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
    data.setDataPosition(0);
    status_t err = NO_ERROR;
    switch (code) {
        case PING_TRANSACTION:
            reply->writeInt32(pingBinder());
            break;
        default:
            err = onTransact(code, data, reply, flags);
            break;
    }
    if (reply != NULL) {
        reply->setDataPosition(0);
    }
    return err;
}

default分支，就是服務端的onTransact執行，具體的遠端程式碼執行了。 簡單總結： 接收端也比較簡單，從驅動中拿到通訊對方的資料，執行對應的請求即可。資料來自驅動，處理完了後，Parcel的解構函式，自動會free這片記憶體。（這裡有個坑！！！，後面再說）

6. 驅動乾的事情

一些注意事項 強調Binder共享記憶體大小 強調注意釋放接收記憶體，否則Binder掛了 關於Binder的記憶體，是驅動mmap出來的，每個參與binder通訊的程序都會分配，除了service_manager外，其他程序的大小都是固定的，不到1M，定義在ProcessState.cpp中： #define BINDER_VM_SIZE ((1*1024*1024) - (4096 *2)) 特別注意的是，這裡雖然是mmap的，看樣子應該是共享記憶體，可以供跨程序使用，實際不然。binder記憶體不能跨程序使用，操作是：

• 每個binder程序都需要分配，只能分配的Binder程序讀取
  
• 驅動負責分配和回收(回收需要使用者程序主動向驅動發命令去free)，當然，驅動是核心態的，可以看到所有程序的記憶體
  
• 以上，通訊過程必然要有一次copy，copy動作是在驅動中做的。
  
• binder buffer僅供接收資料用。
  

Binder驅動中資料的傳遞流程： 另外注意： BC_TRANSACT和BC_REPLY 實際在驅動層看，是一樣的。這裡，上層抽象的RPC呼叫，如果從通訊的角度看，也就是互相往發資料而已。(不過binder實現是CS架構，只能客戶端發通訊請求) Binder傳輸請求方傳送資料流： [email protected]      binder ioctl [BC_TRASACTION]         [email protected]kernel/driver/staging/android/binder.c binder_thread_write@kernel/driver/staging/android/binder.c                 binder_transaction@kernel/driver/staging/android/binder.c

int binder_thread_write(struct binder_proc *proc, struct binder_thread *thread,
			binder_uintptr_t binder_buffer, size_t size,
			binder_size_t *consumed)
{
	uint32_t cmd;
	void __user *buffer = (void __user *)(uintptr_t)binder_buffer;
	void __user *ptr = buffer + *consumed;
	void __user *end = buffer + size;
    // 先獲取傳輸的command，確定要binder做何事。
	while (ptr < end && thread->return_error == BR_OK) {
		if (get_user(cmd, (uint32_t __user *)ptr))
			return -EFAULT;
		ptr += sizeof(uint32_t);
		...
		switch (cmd) {
		...
		case BC_TRANSACTION:
		case BC_REPLY: {
			struct binder_transaction_data tr;
            // 從使用者態獲取transact_data
			if (copy_from_user(&tr, ptr, sizeof(tr)))
				return -EFAULT;
			ptr += sizeof(tr);
			binder_transaction(proc, thread, &tr, cmd == BC_REPLY);
			break;
		}
		...
		}
		*consumed = ptr - buffer;
	}
	return 0;
}

處理Transaction 請求：

static void binder_transaction(struct binder_proc *proc,
			       struct binder_thread *thread,
			       struct binder_transaction_data *tr, int reply)
{
    ...
    // 不是reply，走else
	if (reply) {
       ...
	} else {
        // 查詢獲得通訊的target端。
		if (tr->target.handle) {
			struct binder_ref *ref;
			ref = binder_get_ref(proc, tr->target.handle);...
			target_node = ref->node;
		} else {
			target_node = binder_context_mgr_node;...
		}
		e->to_node = target_node->debug_id;
		target_proc = target_node->proc;...
		}
        ...
	}
	if (target_thread) {
		e->to_thread = target_thread->pid;
		target_list = &target_thread->todo;
		target_wait = &target_thread->wait;
	} else {
		target_list = &target_proc->todo;
		target_wait = &target_proc->wait;
	}
	e->to_proc = target_proc->pid;

    // 構建transaction結構
	/* TODO: reuse incoming transaction for reply */
	t = kzalloc(sizeof(*t), GFP_KERNEL);...

	tcomplete = kzalloc(sizeof(*tcomplete), GFP_KERNEL);...
	if (!reply && !(tr->flags & TF_ONE_WAY))
		t->from = thread;
	else
		t->from = NULL;
	t->sender_euid = proc->tsk->cred->euid;
	t->to_proc = target_proc;
	t->to_thread = target_thread;
	t->code = tr->code;
	t->flags = tr->flags;
	t->priority = task_nice(current);
    // 分配binder buffer，消耗的是目標程序的buffer
	t->buffer = binder_alloc_buf(target_proc, tr->data_size,
		tr->offsets_size, !reply && (t->flags & TF_ONE_WAY));...
	t->buffer->allow_user_free = 0;
	t->buffer->debug_id = t->debug_id;
	t->buffer->transaction = t;
	t->buffer->target_node = target_node;

	if (target_node)
		binder_inc_node(target_node, 1, 0, NULL);
	offp = (binder_size_t *)(t->buffer->data +
				 ALIGN(tr->data_size, sizeof(void *)));
    // 這裡，將使用者態寫入的要通訊的Parcel中的資料[存在使用者malloc堆中]，拷貝到核心binder buffer中
	if (copy_from_user(t->buffer->data, (const void __user *)(uintptr_t)
			   tr->data.ptr.buffer, tr->data_size)) {...}
	if (copy_from_user(offp, (const void __user *)(uintptr_t)
			   tr->data.ptr.offsets, tr->offsets_size)) {...}
...
    // 呼叫請求給到目標程序，喚醒目標程序，看是工作
	t->work.type = BINDER_WORK_TRANSACTION;
	list_add_tail(&t->work.entry, target_list);
	tcomplete->type = BINDER_WORK_TRANSACTION_COMPLETE;
	list_add_tail(&tcomplete->entry, &thread->todo);
	if (target_wait)
		wake_up_interruptible(target_wait);
	return;
...
}

上面就是copy的動作。Binder傳輸資料是有一次拷貝的。當Transaction開始後，喚醒目標程序，tranasction請求和資料到目標程序的路徑如下： [email protected]kernel/driver/staging/android/binder.c 
executeCommand@IPCThreadState.cpp  注意:

• 目標程序啟動binder執行緒，在執行joinThreadPool後，或者binder執行緒通訊完成，空閒後，都是在驅動的binder_thread_read這個函式中wait，等待請求。
  
• 目標程序收到資料後，talkWithDriver收到資料，呼叫executeCommand處理資料的各種請求
  

RPC的結果返回(Reply)流程差不多，就不說了，就是將驅動從傳送方程序copy來的Parcel中的資料，通過ipcSetDataReference設定到本程序parcel中，獲取資料和命令，響應請求即可。 整個通訊過程的資料流結構圖和流向大約如下：  

7. 其他，用Parcel傳遞物件。

以上只是binder通訊，用parcel傳遞資料的過程。上述描述的主要是native層的，基本上角度是通訊的角度，如果從上層角度看，Parcel主要是方便實現上層抽象物件的跨程序傳輸，可以將本地物件，拆包後，扁平化資料流的形式，通過Binder，傳輸到遠端程序，遠端通過接收到的資料，重新構基本一樣的物件，可以做到使用者看起來好像所有物件或執行程式碼都在本地一樣。基本上，Parcel的打包解包，和序列化過程差不多：
這裡基本上就是業務邏輯上層，封了一層。實現也比較簡單，就是類實現Parcelable介面，支援將物件資料寫入Parcel，通過binder傳遞到遠端程序中，再根據這些資料，在遠端重新構建出物件即可，這個理解起來比較簡單。 其他一些注意事項：

• Binder支援fd的傳遞，fd傳遞的話，fd 在本程序還要用的話，一定要dup一份，否則，在parcel在通訊完成後析構時，是要close fd的。
  
• Parcel中資料的釋放，會在類析構的時候，釋放記憶體。parcel通訊返回的reply，是一個指標。注意如果是用java程式碼實現的通訊邏輯的話，是直接儲存這個reply指標的，而且java是沒有析構的概念，java的Parcel類被GC，也沒有相應的釋放IPC資料庫的動作，必須在不用的時候，呼叫recycle來顯示的回收這個資料。否則很快這個binder記憶體(只有1M-8K)就耗幹了。基本上原生程式碼，看起來就是MediaPlayer的getMetaData沒有做這個事，會洩漏(好像最新版本android也沒修)。
  
• 從上可知，binder記憶體很小的，特別要注意不要傳遞大物件和資料，否則很容易失敗。如果資料量比較大，可以用資料庫，或者參考Bitmap的傳遞實現，用Blob。

簡單總結：

• Binder通訊，通訊發起端(BC_XXX)往binder驅動中寫入的資料，是建立在自己程序的堆中的
  
• Binder通訊的發起端程序的通訊資料，在binder驅動中，會拷貝到響應端的binder記憶體中，binder記憶體，除service_manager外，每個程序只有1M-8K，注意通訊傳輸資料量要小
  
• 響應端(BR_XXX)得到的資料，是儲存在Binder記憶體中的，使用完後，注意可能有free問題，免得洩露