ANDROID BINDER通信架構怎么掌握

這篇文章主要介紹“ANDROID BINDER通信架構怎么掌握”，在日常操作中，相信很多人在ANDROID BINDER通信架構怎么掌握問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”ANDROID BINDER通信架構怎么掌握”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

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。

主要功能:

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

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

3. 將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啟動完成.過程基本一致,此處就不再展開.

到此，關于“ANDROID BINDER通信架構怎么掌握”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！