[[177268]]

一. 引言

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

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

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

• 應(yīng)用層: 直接為用戶(hù)提供服務(wù);
• 傳輸層: 傳輸?shù)氖菆?bào)文(TCP數(shù)據(jù))或者用戶(hù)數(shù)據(jù)報(bào)(UDP數(shù)據(jù))
• 網(wǎng)絡(luò)層: 傳輸?shù)氖前?Packet), 例如路由器
• 數(shù)據(jù)鏈路層: 傳輸?shù)氖菐?Frame), 例如以太網(wǎng)交換機(jī)
• 物理層: 相鄰節(jié)點(diǎn)間傳輸bit, 例如集線(xiàn)器,雙絞線(xiàn)等
• 這是經(jīng)典的五層TPC/IP協(xié)議體系, 這樣分層設(shè)計(jì)的思想, 讓每一個(gè)子問(wèn)題都設(shè)計(jì)成一個(gè)獨(dú)立的協(xié)議, 這協(xié)議的設(shè)計(jì)/分析/實(shí)現(xiàn)/測(cè)試都變得更加簡(jiǎn)單:
• 層與層具有獨(dú)立性, 例如應(yīng)用層可以使用傳輸層提供的功能而無(wú)需知曉其實(shí)現(xiàn)原理;
• 設(shè)計(jì)靈活, 層與層之間都定義好接口, 即便層內(nèi)方法發(fā)生變化,只有接口不變, 對(duì)這個(gè)系統(tǒng)便毫無(wú)影響;
• 結(jié)構(gòu)的解耦合, 讓每一層可以用更適合的技術(shù)方案, 更合適的語(yǔ)言;
• 方便維護(hù), 可分層調(diào)試和定位問(wèn)題;

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

• Java應(yīng)用層: 對(duì)于上層應(yīng)用通過(guò)調(diào)用AMP.startService, 完全可以不用關(guān)心底層,經(jīng)過(guò)層層調(diào)用,最終必然會(huì)調(diào)用到AMS.startService.
• Java IPC層: Binder通信是采用C/S架構(gòu), Android系統(tǒng)的基礎(chǔ)架構(gòu)便已設(shè)計(jì)好Binder在Java framework層的Binder客戶(hù)類(lèi)BinderProxy和服務(wù)類(lèi)Binder;
• Native IPC層: 對(duì)于Native層,如果需要直接使用Binder(比如media相關(guān)), 則可以直接使用BpBinder和BBinder(當(dāng)然這里還有JavaBBinder)即可, 對(duì)于上一層Java IPC的通信也是基于這個(gè)層面.
• Kernel物理層: 這里是Binder Driver, 前面3層都跑在用戶(hù)空間,對(duì)于用戶(hù)空間的內(nèi)存資源是不共享的,每個(gè)Android的進(jìn)程只能運(yùn)行在自己進(jìn)程所擁有的虛擬地址空間, 而內(nèi)核空間卻是可共享的. 真正通信的核心環(huán)節(jié)還是在Binder Driver.

1.2 分析起點(diǎn)

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

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

1.3 Binder IPC原理

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

可以看出無(wú)論是注冊(cè)服務(wù)和獲取服務(wù)的過(guò)程都需要ServiceManager，需要注意的是此處的Service Manager是指Native層的ServiceManager(C++)，并非指framework層的ServiceManager(Java)。ServiceManager是整個(gè)Binder通信機(jī)制的大管家，是Android進(jìn)程間通信機(jī)制Binder的守護(hù)進(jìn)程，Client端和Server端通信時(shí)都需要先獲取Service Manager接口，才能開(kāi)始通信服務(wù), 當(dāng)然查找懂啊目標(biāo)信息可以緩存起來(lái)則不需要每次都向ServiceManager請(qǐng)求。

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

1. 注冊(cè)服務(wù)：首先AMS注冊(cè)到ServiceManager。該過(guò)程：AMS所在進(jìn)程(system_server)是客戶(hù)端，ServiceManager是服務(wù)端。
2. 獲取服務(wù)：Client進(jìn)程使用AMS前，須先向ServiceManager中獲取AMS的代理類(lèi)AMP。該過(guò)程：AMP所在進(jìn)程(app process)是客戶(hù)端，ServiceManager是服務(wù)端。
3. 使用服務(wù)： app進(jìn)程根據(jù)得到的代理類(lèi)AMP,便可以直接與AMS所在進(jìn)程交互。該過(guò)程：AMP所在進(jìn)程(app process)是客戶(hù)端，AMS所在進(jìn)程(system_server)是服務(wù)端。

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

這3大過(guò)程每一次都是一個(gè)完整的Binder IPC過(guò)程, 接下來(lái)從源碼角度, 僅介紹第3過(guò)程使用服務(wù), 即展開(kāi)AMP.startService是如何調(diào)用到AMS.startService的過(guò)程.

Tips: 如果你只想了解大致過(guò)程,并不打算細(xì)扣源碼, 那么你可以略過(guò)通信過(guò)程源碼分析, 僅看本文***段落和***段落也能對(duì)Binder所有理解.

二. 通信過(guò)程

2.1 AMP.startService

[→ ActivityManagerNative.java ::ActivityManagerProxy]

主要功能:

• 獲取或創(chuàng)建兩個(gè)Parcel對(duì)象,data用于發(fā)送數(shù)據(jù)，reply用于接收應(yīng)答數(shù)據(jù).
• 將startService相關(guān)數(shù)據(jù)都封裝到Parcel對(duì)象data, 其中descriptor = “android.app.IActivityManager”;
• 通過(guò)Binder傳遞數(shù)據(jù),并將應(yīng)答消息寫(xiě)入reply;
• 讀取reply應(yīng)答消息的異常情況和組件對(duì)象;

2.2 Parcel.obtain

[→ Parcel.java]

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

先嘗試從緩存池sOwnedPool中查詢(xún)是否存在緩存Parcel對(duì)象，當(dāng)存在則直接返回該對(duì)象;

如果沒(méi)有可用的Parcel對(duì)象，則直接創(chuàng)建Parcel對(duì)象。

2.2.1 new Parcel

[→ Parcel.java]

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

2.2.2 android_os_Parcel_create

[→ android_os_Parcel.cpp]

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

2.2.3 Parcel.recycle

將不再使用的Parcel對(duì)象放入緩存池，可回收重復(fù)利用，當(dāng)緩存池已滿(mǎn)則不再加入緩存池。這里有兩個(gè)Parcel線(xiàn)程池,mOwnsNativeParcelObject變量來(lái)決定:

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

mOwnsNativeParcelObject=false, 即調(diào)用帶nativePtr參數(shù)的obtain(long)方法獲取的對(duì)象, 回收時(shí)會(huì)放入sHolderPool對(duì)象池;

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相對(duì)應(yīng)的方法, 該方法再調(diào)用Parcel.cpp中對(duì)應(yīng)的方法.

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

2.4 mRemote究竟為何物

mRemote的出生,要出先說(shuō)說(shuō)ActivityManagerProxy對(duì)象(簡(jiǎn)稱(chēng)AMP)創(chuàng)建說(shuō)起, AMP是通過(guò)ActivityManagerNative.getDefault()來(lái)獲取的.

2.4.1 AMN.getDefault

[→ ActivityManagerNative.java]

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

2.4.2 gDefault.get

***調(diào)用時(shí)需要?jiǎng)?chuàng)建,創(chuàng)建完之后保持到mInstance對(duì)象,之后可直接使用.

2.4.3 gDefault.create

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

2.4.4 AMN.asInterface

[→ ActivityManagerNative.java]

此時(shí)obj為BinderProxy對(duì)象, 記錄著遠(yuǎn)程進(jìn)程system_server中AMS服務(wù)的binder線(xiàn)程的handle.

2.4.5 queryLocalInterface

[Binder.java]

對(duì)于Binder IPC的過(guò)程中, 同一個(gè)進(jìn)程的調(diào)用則會(huì)是asInterface()方法返回的便是本地的Binder對(duì)象;對(duì)于不同進(jìn)程的調(diào)用則會(huì)是遠(yuǎn)程代理對(duì)象BinderProxy.

2.4.6 創(chuàng)建AMP

[→ ActivityManagerNative.java :: AMP]

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

2.5 mRemote.transact

[→ Binder.java ::BinderProxy]

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

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

2.6 android_os_BinderProxy_transact

[→ android_util_Binder.cpp]

gBinderProxyOffsets.mObject中保存的是BpBinder對(duì)象, 這是開(kāi)機(jī)時(shí)Zygote調(diào)用AndroidRuntime::startReg方法來(lái)完成jni方法的注冊(cè).

其中register_android_os_Binder()過(guò)程就有一個(gè)初始并注冊(cè)BinderProxy的操作,完成gBinderProxyOffsets的賦值過(guò)程. 接下來(lái)就進(jìn)入該方法.

2.7 BpBinder.transact

[→ BpBinder.cpp]

IPCThreadState::self()采用單例模式，保證每個(gè)線(xiàn)程只有一個(gè)實(shí)例對(duì)象。

2.8 IPC.transact

[→ IPCThreadState.cpp]

transact主要過(guò)程:

• 先執(zhí)行writeTransactionData()已向Parcel數(shù)據(jù)類(lèi)型的mOut寫(xiě)入數(shù)據(jù)，此時(shí)mIn還沒(méi)有數(shù)據(jù);
• 然后執(zhí)行waitForResponse()方法，循環(huán)執(zhí)行，直到收到應(yīng)答消息. 調(diào)用talkWithDriver()跟驅(qū)動(dòng)交互，收到應(yīng)答消息，便會(huì)寫(xiě)入mIn, 則根據(jù)收到的不同響應(yīng)嗎，執(zhí)行相應(yīng)的操作。

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

• 當(dāng)已設(shè)置oneway時(shí), 則調(diào)用waitForResponse(NULL, NULL);
• 當(dāng)未設(shè)置oneway時(shí), 則調(diào)用waitForResponse(reply) 或 waitForResponse(&fakeReply)

2.9 IPC.writeTransactionData

[→ IPCThreadState.cpp]

【本文是51CTO專(zhuān)欄“小米開(kāi)放平臺(tái)”原創(chuàng)文章，“小米開(kāi)放平臺(tái)”微信公眾號(hào)xiaomideveloper】