怎么理解ANDROID的BINDER通信架構(gòu)

本文小編為大家詳細介紹“怎么理解ANDROID的BINDER通信架構(gòu)”，內(nèi)容詳細，步驟清晰，細節(jié)處理妥當，希望這篇“怎么理解ANDROID的BINDER通信架構(gòu)”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。

一. 引言

1.1 Binder架構(gòu)的思考

Android內(nèi)核是基于Linux系統(tǒng), 而Linux現(xiàn)存多種進程間IPC方式:管道, 消息隊列, 共享內(nèi)存, 套接字, 信號量, 信號. 為什么Android非要用Binder來進行進程間通信呢？

在說到Binder架構(gòu)之前, 先簡單說說大家熟悉的TCP/IP的五層通信體系結(jié)構(gòu):

• 應(yīng)用層: 直接為用戶提供服務(wù);

• 傳輸層: 傳輸?shù)氖菆笪?TCP數(shù)據(jù))或者用戶數(shù)據(jù)報(UDP數(shù)據(jù))

• 網(wǎng)絡(luò)層: 傳輸?shù)氖前?Packet), 例如路由器

• 數(shù)據(jù)鏈路層: 傳輸?shù)氖菐?Frame), 例如以太網(wǎng)交換機

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

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

• 層與層具有獨立性, 例如應(yīng)用層可以使用傳輸層提供的功能而無需知曉其實現(xiàn)原理;

• 設(shè)計靈活, 層與層之間都定義好接口, 即便層內(nèi)方法發(fā)生變化,只有接口不變, 對這個系統(tǒng)便毫無影響;

• 結(jié)構(gòu)的解耦合, 讓每一層可以用更適合的技術(shù)方案, 更合適的語言;

• 方便維護, 可分層調(diào)試和定位問題;

Binder架構(gòu)也是采用分層架構(gòu)設(shè)計, 每一層都有其不同的功能:

• Java應(yīng)用層: 對于上層應(yīng)用通過調(diào)用AMP.startService, 完全可以不用關(guān)心底層,經(jīng)過層層調(diào)用,最終必然會調(diào)用到AMS.startService.

• Java IPC層: Binder通信是采用C/S架構(gòu), Android系統(tǒng)的基礎(chǔ)架構(gòu)便已設(shè)計好Binder在Java framework層的Binder客戶類BinderProxy和服務(wù)類Binder;

• Native IPC層: 對于Native層,如果需要直接使用Binder(比如media相關(guān)), 則可以直接使用BpBinder和BBinder(當然這里還有JavaBBinder)即可, 對于上一層Java IPC的通信也是基于這個層面.

• Kernel物理層: 這里是Binder Driver, 前面3層都跑在用戶空間,對于用戶空間的內(nèi)存資源是不共享的,每個Android的進程只能運行在自己進程所擁有的虛擬地址空間, 而內(nèi)核空間卻是可共享的. 真正通信的核心環(huán)節(jié)還是在Binder Driver。

1.2 分析起點

• Binder在Android系統(tǒng)使用頗為廣泛, 幾乎是整個Android架構(gòu)的頂梁柱, Binder系統(tǒng)如此龐大, 那么這里需要尋求一個出發(fā)點來穿針引線, 一窺視Binder全貌. 那么本文將從全新的視角,以startService流程分析 為例子來說說Binder所其作用.首先在發(fā)起方進程調(diào)用AMP.startService，經(jīng)過binder驅(qū)動，最終調(diào)用系統(tǒng)進程AMS.startService,如下圖:

AMP和AMN都是實現(xiàn)了IActivityManager接口,AMS繼承于AMN. 其中AMP作為Binder的客戶端,運行在各個app所在進程, AMN(或AMS)運行在系統(tǒng)進程system_server.

1.3 Binder IPC原理

Binder通信采用C/S架構(gòu)，從組件視角來說，包含Client、Server、ServiceManager以及binder驅(qū)動，其中ServiceManager用于管理系統(tǒng)中的各種服務(wù)。下面說說startService過程所涉及的Binder對象的架構(gòu)圖：

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

圖中Client/Server/ServiceManage之間的相互通信都是基于Binder機制。既然基于Binder機制通信，那么同樣也是C/S架構(gòu)，則圖中的3大步驟都有相應(yīng)的Client端與Server端。

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

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

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

圖中的Client,Server,Service Manager之間交互都是虛線表示，是由于它們彼此之間不是直接交互的，而是都通過與Binder Driver進行交互的，從而實現(xiàn)IPC通信方式。其中Binder驅(qū)動位于內(nèi)核空間，Client,Server,Service Manager位于用戶空間。Binder驅(qū)動和Service Manager可以看做是Android平臺的基礎(chǔ)架構(gòu)，而Client和Server是Android的應(yīng)用層.

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

Tips: 如果你只想了解大致過程,并不打算細扣源碼, 那么你可以略過通信過程源碼分析, 僅看本文第一段落和最后段落也能對Binder所有理解.

二. 通信過程

2.1 AMP.startService

[→ ActivityManagerNative.java ::ActivityManagerProxy]

主要功能:

• 獲取或創(chuàng)建兩個Parcel對象,data用于發(fā)送數(shù)據(jù)，reply用于接收應(yīng)答數(shù)據(jù).

• 將startService相關(guān)數(shù)據(jù)都封裝到Parcel對象data, 其中descriptor = “android.app.IActivityManager”;

• 通過Binder傳遞數(shù)據(jù),并將應(yīng)答消息寫入reply;

• 讀取reply應(yīng)答消息的異常情況和組件對象;

2.2 Parcel.obtain

[→ Parcel.java]

sOwnedPool是一個大小為6，存放著parcel對象的緩存池,這樣設(shè)計的目標是用于節(jié)省每次都創(chuàng)建Parcel對象的開銷。obtain()方法的作用：

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

2. 如果沒有可用的Parcel對象，則直接創(chuàng)建Parcel對象。

2.2.1 new Parcel

[→ Parcel.java]

nativeCreate這是native方法,經(jīng)過JNI進入native層, 調(diào)用android_os_Parcel_create()方法.

2.2.2 android_os_Parcel_create

[→ android_os_Parcel.cpp]

創(chuàng)建C++層的Parcel對象, 該對象指針強制轉(zhuǎn)換為long型, 并保存到Java層的mNativePtr對象. 創(chuàng)建完P(guān)arcel對象利用Parcel對象寫數(shù)據(jù). 接下來以writeString為例.

2.2.3 Parcel.recycle

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

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

• mOwnsNativeParcelObject=false, 即調(diào)用帶nativePtr參數(shù)的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方法, 都是調(diào)用android_os_Parcel.cpp相對應(yīng)的方法, 該方法再調(diào)用Parcel.cpp中對應(yīng)的方法.

調(diào)用流程: Parcel.java –> android_os_Parcel.cpp –> Parcel.cpp.

2.4 mRemote究竟為何物

mRemote的出生,要出先說說ActivityManagerProxy對象(簡稱AMP)創(chuàng)建說起, AMP是通過ActivityManagerNative.getDefault()來獲取的.

2.4.1 AMN.getDefault

[→ ActivityManagerNative.java]

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

2.4.2 gDefault.get

首次調(diào)用時需要創(chuàng)建,創(chuàng)建完之后保持到mInstance對象,之后可直接使用.

2.4.3 gDefault.create

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

2.4.4 AMN.asInterface

[→ ActivityManagerNative.java]

此時obj為BinderProxy對象, 記錄著遠程進程system_server中AMS服務(wù)的binder線程的handle.

2.4.5 queryLocalInterface

[Binder.java]

對于Binder IPC的過程中, 同一個進程的調(diào)用則會是asInterface()方法返回的便是本地的Binder對象;對于不同進程的調(diào)用則會是遠程代理對象BinderProxy.

2.4.6 創(chuàng)建AMP

[→ ActivityManagerNative.java :: AMP]

可知mRemote便是指向AMS服務(wù)的BinderProxy對象。

2.5 mRemote.transact

[→ Binder.java ::BinderProxy]

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

transactNative是native方法，經(jīng)過jni調(diào)用android_os_BinderProxy_transact方法。

2.6 android_os_BinderProxy_transact

[→ android_util_Binder.cpp]

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

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

2.7 BpBinder.transact

[→ BpBinder.cpp]

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

2.8 IPC.transact

[→ IPCThreadState.cpp]

transact主要過程:

• 先執(zhí)行writeTransactionData()已向Parcel數(shù)據(jù)類型的mOut寫入數(shù)據(jù)，此時mIn還沒有數(shù)據(jù)；

• 然后執(zhí)行waitForResponse()方法，循環(huán)執(zhí)行，直到收到應(yīng)答消息. 調(diào)用talkWithDriver()跟驅(qū)動交互，收到應(yīng)答消息，便會寫入mIn, 則根據(jù)收到的不同響應(yīng)嗎，執(zhí)行相應(yīng)的操作。

此處調(diào)用waitForResponse根據(jù)是否有設(shè)置TF_ONE_WAY的標記:

• 當已設(shè)置oneway時, 則調(diào)用waitForResponse(NULL, NULL);

• 當未設(shè)置oneway時, 則調(diào)用waitForResponse(reply) 或 waitForResponse(&fakeReply)

2.9 IPC.writeTransactionData

[→ IPCThreadState.cpp]

將數(shù)據(jù)寫入mOut

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