[[177268]]

一. 引言

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過程使用服務, 即展開AMP.startService是如何調用到AMS.startService的過程.

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()方法的作用：

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

如果沒有可用的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]

 

【本文是51CTO專欄“小米開放平臺”原創文章，“小米開放平臺”微信公眾號xiaomideveloper】