乾貨 | 完全理解ANDROID BINDER通訊架構（上）

乾貨 | 完全理解ANDROID BINDER通訊架構（上）

一. 引言

1.1 Binder架構的思考

Android內核是基於Linux系統, 而Linux現存多種進程間IPC方式:管道, 消息隊列, 共享內存, 套接字, 信號量, 信號. 爲何Android非要用Binder來進行進程間通訊呢？

在說到Binder架構以前, 先簡單說說你們熟悉的TCP/IP的五層通訊體系結構:

• 應用層: 直接爲用戶提供服務;

• 傳輸層: 傳輸的是報文(TCP數據)或者用戶數據報(UDP數據)

• 網絡層: 傳輸的是包(Packet), 例如路由器

• 數據鏈路層: 傳輸的是幀(Frame), 例如以太網交換機

• 物理層: 相鄰節點間傳輸bit, 例如集線器,雙絞線等

這是經典的五層TPC/IP協議體系, 這樣分層設計的思想, 讓每個子問題都設計成一個獨立的協議, 這協議的設計/分析/實現/測試都變得更加簡單:

• 層與層具備獨立性, 例如應用層可使用傳輸層提供的功能而無需知曉其實現原理;

• 設計靈活, 層與層之間都定義好接口, 即使層內方法發生變化,只有接口不變, 對這個系統便毫無影響;

• 結構的解耦合, 讓每一層能夠用更適合的技術方案, 更合適的語言;

• 方便維護, 可分層調試和定位問題;

Binder架構也是採用分層架構設計, 每一層都有其不一樣的功能:

• Java應用層: 對於上層應用經過調用AMP.startService, 徹底能夠不用關心底層,通過層層調用,最終必然會調用到AMS.startService.

• Java IPC層: Binder通訊是採用C/S架構, Android系統的基礎架構便已設計好Binder在Java framework層的Binder客戶類BinderProxy和服務類Binder;

• Native IPC層: 對於Native層,若是須要直接使用Binder(好比media相關), 則能夠直接使用BpBinder和BBinder(固然這裏還有JavaBBinder)便可, 對於上一層Java IPC的通訊也是基於這個層面.

• Kernel物理層: 這裏是Binder Driver, 前面3層都跑在用戶空間,對於用戶空間的內存資源是不共享的,每一個Android的進程只能運行在本身進程所擁有的虛擬地址空間, 而內核空間倒是可共享的. 真正通訊的核心環節仍是在Binder Driver。

1.2 分析起點

• Binder在Android系統使用頗爲普遍, 幾乎是整個Android架構的頂樑柱, Binder系統如此龐大, 那麼這裏須要尋求一個出發點來穿針引線, 一窺視Binder全貌. 那麼本文將從全新的視角,以startService流程分析 爲例子來講說Binder所其做用.首先在發起方進程調用AMP.startService，通過binder驅動，最終調用系統進程AMS.startService,以下圖:

AMP和AMN都是實現了IActivityManager接口,AMS繼承於AMN. 其中AMP做爲Binder的客戶端,運行在各個app所在進程, AMN(或AMS)運行在系統進程system_server.

1.3 Binder IPC原理

Binder通訊採用C/S架構，從組件視角來講，包含Client、Server、ServiceManager以及binder驅動，其中ServiceManager用於管理系統中的各類服務。下面說說startService過程所涉及的Binder對象的架構圖：

能夠看出不管是註冊服務和獲取服務的過程都須要ServiceManager，須要注意的是此處的Service Manager是指Native層的ServiceManager（C++），並不是指framework層的ServiceManager(Java)。ServiceManager是整個Binder通訊機制的大管家，是Android進程間通訊機制Binder的守護進程，Client端和Server端通訊時都須要先獲取Service Manager接口，才能開始通訊服務, 固然查找懂啊目標信息能夠緩存起來則不須要每次都向ServiceManager請求。

圖中Client/Server/ServiceManage之間的相互通訊都是基於Binder機制。既然基於Binder機制通訊，那麼一樣也是C/S架構，則圖中的3大步驟都有相應的Client端與Server端。

1. 註冊服務：首先AMS註冊到ServiceManager。該過程：AMS所在進程(system_server)是客戶端，ServiceManager是服務端。

2. 獲取服務：Client進程使用AMS前，須先向ServiceManager中獲取AMS的代理類AMP。該過程：AMP所在進程(app process)是客戶端，ServiceManager是服務端。

3. 使用服務： app進程根據獲得的代理類AMP,即可以直接與AMS所在進程交互。該過程：AMP所在進程(app process)是客戶端，AMS所在進程(system_server)是服務端。

圖中的Client,Server,Service Manager之間交互都是虛線表示，是因爲它們彼此之間不是直接交互的，而是都經過與Binder Driver進行交互的，從而實現IPC通訊方式。其中Binder驅動位於內核空間，Client,Server,Service Manager位於用戶空間。Binder驅動和Service Manager能夠看作是Android平臺的基礎架構，而Client和Server是Android的應用層.

這3大過程每一次都是一個完整的Binder IPC過程, 接下來從源碼角度, 僅介紹第3過程使用服務, 即展開

Tips: 若是你只想瞭解大體過程,並不打算細扣源碼, 那麼你能夠略過通訊過程源碼分析, 僅看本文第一段落和最後段落也能對Binder全部理解.

二. 通訊過程

2.1 AMP.startService

[→ ActivityManagerNative.java ::ActivityManagerProxy]

主要功能:

• 獲取或建立兩個Parcel對象,data用於發送數據，reply用於接收應答數據.

• 將startService相關數據都封裝到Parcel對象data, 其中descriptor = 「android.app.IActivityManager」;

• 經過Binder傳遞數據,並將應答消息寫入reply;

• 讀取reply應答消息的異常狀況和組件對象;

2.2 Parcel.obtain

[→ Parcel.java]

sOwnedPool是一個大小爲6，存放着parcel對象的緩存池,這樣設計的目標是用於節省每次都建立Parcel對象的開銷。obtain()方法的做用：

1. 先嚐試從緩存池sOwnedPool中查詢是否存在緩存Parcel對象，當存在則直接返回該對象;

2. 若是沒有可用的Parcel對象，則直接建立Parcel對象。

2.2.1 new Parcel

[→ Parcel.java]

nativeCreate這是native方法,通過JNI進入native層, 調用android_os_Parcel_create()方法.

2.2.2 android_os_Parcel_create

[→ android_os_Parcel.cpp]

建立C++層的Parcel對象, 該對象指針強制轉換爲long型, 並保存到Java層的mNativePtr對象. 建立完Parcel對象利用Parcel對象寫數據. 接下來以writeString爲例.

2.2.3 Parcel.recycle

將再也不使用的Parcel對象放入緩存池，可回收重複利用，當緩存池已滿則再也不加入緩存池。這裏有兩個Parcel線程池,mOwnsNativeParcelObject變量來決定:

• mOwnsNativeParcelObject=true, 即調用不帶參數obtain()方法獲取的對象, 回收時會放入sOwnedPool對象池;

• mOwnsNativeParcelObject=false, 即調用帶nativePtr參數的obtain(long)方法獲取的對象, 回收時會放入sHolderPool對象池;

2.3 writeString

[→ Parcel.java]

2.3.1 nativeWriteString

[→ android_os_Parcel.cpp]

2.3.2 writeString16

[→ Parcel.cpp]

Tips: 除了writeString(),在Parcel.java中大量的native方法, 都是調用android_os_Parcel.cpp相對應的方法, 該方法再調用Parcel.cpp中對應的方法.

調用流程: Parcel.java –> android_os_Parcel.cpp –> Parcel.cpp.

2.4 mRemote究竟爲什麼物

mRemote的出生,要出先說說ActivityManagerProxy對象(簡稱AMP)建立提及, AMP是經過ActivityManagerNative.getDefault()來獲取的.

2.4.1 AMN.getDefault

[→ ActivityManagerNative.java]

gDefault的數據類型爲Singleton<IActivityManager>, 這是一個單例模式, 接下來看看Singleto.get()的過程

2.4.2 gDefault.get

首次調用時須要建立,建立完以後保持到mInstance對象,以後可直接使用.

2.4.3 gDefault.create

文章Binder系列7—framework層分析，可知ServiceManager.getService(「activity」)返回的是指向目標服務AMS的代理對象BinderProxy對象，由該代理對象能夠找到目標服務AMS所在進程

2.4.4 AMN.asInterface

[→ ActivityManagerNative.java]

此時obj爲BinderProxy對象, 記錄着遠程進程system_server中AMS服務的binder線程的handle.

2.4.5 queryLocalInterface

[Binder.java]

對於Binder IPC的過程當中, 同一個進程的調用則會是asInterface()方法返回的即是本地的Binder對象;對於不一樣進程的調用則會是遠程代理對象BinderProxy.

2.4.6 建立AMP

[→ ActivityManagerNative.java :: AMP]

可知mRemote即是指向AMS服務的BinderProxy對象。

2.5 mRemote.transact

[→ Binder.java ::BinderProxy]

mRemote.transact()方法中的code=START_SERVICE_TRANSACTION, data保存了descriptor，caller, intent,resolvedType, callingPackage, userId這6項信息。

transactNative是native方法，通過jni調用android_os_BinderProxy_transact方法。

2.6 android_os_BinderProxy_transact

[→ android_util_Binder.cpp]

gBinderProxyOffsets.mObject中保存的是BpBinder對象, 這是開機時Zygote調用AndroidRuntime::startReg方法來完成jni方法的註冊.

其中register_android_os_Binder()過程就有一個初始並註冊BinderProxy的操做,完成gBinderProxyOffsets的賦值過程. 接下來就進入該方法.

2.7 BpBinder.transact

[→ BpBinder.cpp]

IPCThreadState::self()採用單例模式，保證每一個線程只有一個實例對象。

2.8 IPC.transact

[→ IPCThreadState.cpp]

transact主要過程:

• 先執行writeTransactionData()已向Parcel數據類型的mOut寫入數據，此時mIn尚未數據；

• 而後執行waitForResponse()方法，循環執行，直到收到應答消息. 調用talkWithDriver()跟驅動交互，收到應答消息，便會寫入mIn, 則根據收到的不一樣響應嗎，執行相應的操做。

此處調用waitForResponse根據是否有設置TF_ONE_WAY的標記:

• 當已設置oneway時, 則調用waitForResponse(NULL, NULL);

• 當未設置oneway時, 則調用waitForResponse(reply) 或 waitForResponse(&fakeReply)

2.9 IPC.writeTransactionData

[→ IPCThreadState.cpp]

將數據寫入mOut

想了解更多？

那就趕忙來關注咱們

小米開放平臺公衆號

小米開放平臺官方地址：

http://dev.xiaomi.com?hmsr=%E5%BC%80%E6%BA%90%E4%B8%AD%E5%9B%BD%E5%8D%9A%E5%AE%A2%E9%A2%91%E9%81%93&hmpl=&hmcu=&hmkw=&hmci=

小米開放平臺官方交流羣：398616987