怎么理解ANDROID的BINDER通信架構

本文小編為大家詳細介紹“怎么理解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

讀到這里，這篇“怎么理解ANDROID的BINDER通信架構”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內容的文章，歡迎關注億速云行業資訊頻道。