[[177275]]

2.10 IPC.waitForResponse

在這個過程中, 常見的幾個BR_命令:

• BR_TRANSACTION_COMPLETE: binder驅動收到BC_TRANSACTION事件后的應答消息; 對于oneway transaction,當收到該消息,則完成了本次Binder通信;
• BR_DEAD_REPLY: 回復失敗，往往是線程或節點為空. 則結束本次通信Binder;
• BR_FAILED_REPLY:回復失敗，往往是transaction出錯導致. 則結束本次通信Binder;
• BR_REPLY: Binder驅動向Client端發送回應消息; 對于非oneway transaction時,當收到該消息,則完整地完成本次Binder通信;

規律: BC_TRANSACTION + BC_REPLY = BR_TRANSACTION_COMPLETE + BR_DEAD_REPLY + BR_FAILED_REPLY

2.10.1 IPC.executeCommand

處于剩余的BR_命令.

2.11 IPC.talkWithDriver

binder_write_read結構體用來與Binder設備交換數據的結構, 通過ioctl與mDriverFD通信，是真正與Binder驅動進行數據讀寫交互的過程。 ioctl()方法經過syscall最終調用到Binder_ioctl()方法.

三、Binder driver

3.1 binder_ioctl

[→ Binder.c]

由【小節2.11】傳遞過出來的參數 cmd=BINDER_WRITE_READ

首先,根據傳遞過來的文件句柄指針獲取相應的binder_proc結構體, 再從中查找binder_thread,如果當前線程已經加入到proc的線程隊列則直接返回，如果不存在則創建binder_thread，并將當前線程添加到當前的proc.

• 當返回值為-ENOMEM，則意味著內存不足，往往會出現創建binder_thread對象失敗;
• 當返回值為-EINVAL，則意味著CMD命令參數無效;

3.2 binder_ioctl_write_read

此時arg是一個binder_write_read結構體，mOut數據保存在write_buffer，所以write_size>0，但此時read_size=0。首先,將用戶空間bwr結構體拷貝到內核空間,然后執行binder_thread_write()操作.

3.3 binder_thread_write

不斷從binder_buffer所指向的地址獲取cmd, 當只有BC_TRANSACTION或者BC_REPLY時, 則調用binder_transaction()來處理事務.

3.4 binder_transaction

發送的是BC_TRANSACTION時，此時reply=0。

主要功能:

查詢目標進程的過程： handle → binder_ref → binder_node → binder_proc

將BINDER_WORK_TRANSACTION添加到目標隊列target_list, ***發起事務則目標隊列為target_proc->todo, reply事務時則為target_thread->todo; oneway的非reply事務,則為target_node->async_todo.

將BINDER_WORK_TRANSACTION_COMPLETE添加到當前線程的todo隊列此時當前線程的todo隊列已經有事務, 接下來便會進入binder_thread_read()來處理相關的事務.

3.5 binder_thread_read

• 當收到的是BINDER_WORK_TRANSACTION_COMPLETE, 則將命令BR_TRANSACTION_COMPLETE寫回用戶空間.
• 當收到的是BINDER_WORK_TRANSACTION命令, 則將命令BR_TRANSACTION或BR_TRANSACTION寫回用戶空間.

四. 回到用戶空間

4.1 何去何從

1. 執行完binder_thread_write方法后, 通過binder_transaction()首先寫入BINDER_WORK_TRANSACTION_COMPLETE寫入當前線程.
2. 這時bwr.read_size > 0, 回到binder_ioctl_write_read方法, 便開始執行binder_thread_read();
3. 在binder_thread_read()方法, 將獲取cmd=BR_TRANSACTION_COMPLETE, 再將cmd和數據寫回用戶空間;
4. 一次Binder_ioctl完成,接著回調用戶空間方法talkWithDriver(),并且剛才的數據寫入mIn.
5. 這時mIn有可讀數據, 回到waitForResponse()方法,完成BR_TRANSACTION_COMPLETE過程.
6. 再回退到transact()方法, 對于oneway的操作, 這次Binder通信便完成, 否則還是要等待Binder服務端的返回.

對于startService過程, 顯然沒有指定oneway的方式,那么發起者進程還會繼續停留在waitForResponse()方法,等待收到BR_REPLY消息. 由于在前面binder_transaction過程中,除了向自己所在線程寫入了BINDER_WORK_TRANSACTION_COMPLETE, 還向目標進程(此處為system_server)寫入了BINDER_WORK_TRANSACTION命令. 而此時system_server進程的binder線程一旦空閑便是停留在binder_thread_read()方法來處理進程/線程新的事務, 收到的是BINDER_WORK_TRANSACTION命令, 經過binder_thread_read()后生成命令BR_TRANSACTION.同樣的流程.

接下來,從system_server的binder線程一直的執行流: IPC.joinThreadPool –> IPC.getAndExecuteCommand() → IPC.talkWithDriver() ,但talkWithDriver收到事務之后, 便進入IPC.executeCommand(), 接下來,從executeCommand說起.

4.2 IPC.executeCommand

• 對于oneway的場景, 則到此全部結束.
• 對于非oneway, 也就是需要reply的通信過程,則向Binder驅動發送BC_REPLY命令

4.3 BBinder.transact

[→ Binder.cpp ::BBinder ]

4.4 JavaBBinder.onTransact

[→ android_util_Binder.cpp]

還記得AndroidRuntime::startReg過程嗎, 其中有一個過程便是register_android_os_Binder(),該過程會把gBinderOffsets.mExecTransact便是Binder.java中的execTransact()方法.詳見見Binder系列7—framework層分析文章中的第二節初始化的過程.

另外,此處mObject是在服務注冊addService過程,會調用writeStrongBinder方法, 將Binder對象傳入了JavaBBinder構造函數的參數, 最終賦值給mObject. 在本次通信過程中Object為ActivityManagerNative對象.

此處斗轉星移, 從C++代碼回到了Java代碼. 進入AMN.execTransact, 由于AMN繼續于Binder對象, 接下來進入Binder.execTransact

4.5 Binder.execTransact

[Binder.java]

當發生RemoteException, RuntimeException, OutOfMemoryError, 對于非oneway的情況下都會把異常傳遞給調用者.

4.6 AMN.onTransact

[→ ActivityManagerNative.java]

4.7 AMS.startService

歷經千山萬水, 總算是進入了AMS.startService. 當system_server收到BR_TRANSACTION的過程后, 再經歷一個類似的過程,將事件告知app所在進程service啟動完成.過程基本一致,此處就不再展開.

五. 總結

本文詳細地介紹如何從AMP.startService是如何通過Binder一步步調用進入到system_server進程的AMS.startService. 整個過程涉及Java framework, native, kernel driver各個層面知識. 僅僅一個Binder IPC調用, 就花費了如此大篇幅來講解, 可見系統之龐大. 整個過程的調用流程:

5.1 通信流程

從通信流程角度來看整個過程:

前面第二至第四段落,主要講解過程 BC_TRANSACTION –> BR_TRANSACTION_COMPLETE –> BR_TRANSACTION.有興趣的同學可以再看看后面3個事務的處理:BC_REPLY –> BR_TRANSACTION_COMPLETE –> BR_REPLY,這兩個流程基本是一致的.

5.2 通信協議

從通信協議的角度來看這個過程:

• Binder客戶端或者服務端向Binder Driver發送的命令都是以BC開頭,例如本文的BC_TRANSACTION和BC_REPLY, 所有Binder Driver向Binder客戶端或者服務端發送的命令則都是以BR開頭, 例如本文中的BR_TRANSACTION和BR_REPLY.
• 只有當BC_TRANSACTION或者BC_REPLY時, 才調用binder_transaction()來處理事務. 并且都會回應調用者一個BINDER_WORK_TRANSACTION_COMPLETE事務, 經過binder_thread_read()會轉變成BR_TRANSACTION_COMPLETE.
• startService過程便是一個非oneway的過程, 那么oneway的通信過程如下所述.

5.3 說一說oneway

上圖是非oneway通信過程的協議圖, 下圖則是對于oneway場景下的通信協議圖:

當收到BR_TRANSACTION_COMPLETE則程序返回,有人可能覺得好奇,為何oneway怎么還要等待回應消息? 我舉個例子,你就明白了.

你(app進程)要給遠方的家人(system_server進程)郵寄一封信(transaction), 你需要通過郵寄員(Binder Driver)來完成.整個過程如下:

1. 你把信交給郵寄員(BC_TRANSACTION);
2. 郵寄員收到信后, 填一張單子給你作為一份回執(BR_TRANSACTION_COMPLETE). 這樣你才放心知道郵遞員已確定接收信, 否則就這樣走了,信到底有沒有交到郵遞員手里都不知道,這樣的通信實在太讓人不省心, 長時間收不到遠方家人的回信, 無法得知是在路的中途信件丟失呢,還是壓根就沒有交到郵遞員的手里. 所以說oneway也得知道信是投遞狀態是否成功.
3. 郵遞員利用交通工具(Binder Driver),將信交給了你的家人(BR_TRANSACTION);當你收到回執(BR_TRANSACTION_COMPLETE)時心里也不期待家人回信, 那么這便是一次oneway的通信過程.

如果你希望家人回信, 那便是非oneway的過程,在上述步驟2后并不是直接返回,而是繼續等待著收到家人的回信, 經歷前3個步驟之后繼續執行:

1. 家人收到信后, 立馬寫了個回信交給郵遞員BC_REPLY;
2. 同樣,郵遞員要寫一個回執(BR_TRANSACTION_COMPLETE)給你家人;
3. 郵遞員再次利用交通工具(Binder Driver), 將回信成功交到你的手上(BR_REPLY)這便是一次完成的非oneway通信過程.

oneway與非oneway: 都是需要等待Binder Driver的回應消息BR_TRANSACTION_COMPLETE. 主要區別在于oneway的通信收到BR_TRANSACTION_COMPLETE則返回,而不會再等待BR_REPLY消息的到來.

【本文是51CTO專欄“小米開放平臺”原創文章，“小米開放平臺”微信公眾號xiaomideveloper】