前言
Binder做爲Android中核心機制,對於理解Android系統是必不可少的,關於binder的文章也有很多,但是每次看總感覺看的不是很懂,到底什麼纔是binder機制?爲什麼要使用binder機制?binder機制又是怎樣運行的呢?這些問題只是瞭解binder機制是不夠的,需要從Android的整體系統出發來分析,在我找了很多資料後,真正的弄懂了binder機制,相信看完這篇文章大家也可以弄懂binder機制。
1、Binder是什麼?
要理解binder,先要知道IPC,Inter-process communication ,也就是進程中相互通信,Binder是Android提供的一套進程間相互通信框架。用來多進程間發送消息,同步和共享內存。已有的進程間通信方式有一下幾種:
1、Files 文件系統(包括內存映射)
2、Sockets
3、Pipes 管道
4、共享內存
5、Intents, ContentProviders, Messenger
6、Binder
Android系統中的Binder框架圖如下:
拿Activity舉例從上圖可以看出來:Activity是由ActivityManager來控制的,而ActivityManager其實是通過Binder獲取ActivityManagerService服務來控制Activity的,並且ActivityManager是Android系統FrameWork層的,和應用中的activity不是同一個進程。
重點:
1、Binder是Android提供的一套進程間通信框架。
2、系統服務ActivityManagerService,LocationManagerService,等都是在單獨進程中的,使用binder和應用進行通信。
2、Android系統框架
如上圖,Android系統分成三層。最上層是application應用層,第二層是Framework層,第三層是native層。
由下圖可知幾點:
1、Android中的應用層和系統服務層不在同一個進程,系統服務在單獨的進程中。
2、Android中不同應用屬於不同的進程中。
Android應用和系統services運行在不同進程中是爲了安全,穩定,以及內存管理的原因,但是應用和系統服務需要通信和分享數據。
優點
安全性:每個進程都單獨運行的,可以保證應用層對系統層的隔離。
穩定性:如果某個進程崩潰了不會導致其他進程崩潰。
內存分配:如果某個進程以及不需要了可以從內存中移除,並且回收相應的內存。
3、Binder通信
client請求service服務,比如說Activity請求Activity ManagerService服務,由於Activity和ActivityManagerService是在兩個不同的進程中的,那麼下圖是一個很直觀的請求過程。
但是注意,一個進程是不能直接直接操作另一個進程的,比如說讀取另一個進程的數據,或者往另一個進程的內存空間寫數據,進程之間的通信要通過內核進程纔可以,因此這裏就要使用到進程通信工具Binder瞭如下圖:
Binder driver通過/dev/binder /dev/binder 提供了 open, release release, poll poll, mmap mmap, flush flush, and ioctl等操作的接口api。這樣進程A和進程B就可以通過內核進程進行通信了。進程中大部分的通信都是通過ioctl(binderFd, BINDER_WRITE_READ, &bwd)來進行的。bwd 的定義如下:
struct binder_write_read {
signed long write_size;/* bytes to write */
signed long write_consumed; /* bytes consumed by driver */
unsigned long write_buffer;
signed long read_size; /* bytes to read */
signed long read_consumed; /* bytes consumed by driver */
unsigned long read_buffer;
};
但是上面還有個問題就是client和service要直接和binder driver打交道,但是實際上client和service並不想知道binder相關協議,所以進一步client通過添加proxy代理,service通過添加stub來進一步處理與binder的交互。
這樣的好處是client和service都可以不用直接去和binder打交道。上面的圖好像已經很完善了,但是Android系統更進一步封裝,不讓client知道Binder的存在,Android系統提供了Manager來管理client。如下圖:
這樣client只需要交給manager來管理就好了,根本就不用關心進程通信相關的事,關於manager其實是很熟悉的,比如說activity的就是由ActivityManager來控制的,ActivityManager是通過Binder獲取ActivityManagerService來控制activity的。這樣就不用我們自己來使用Binder來ActivityManagerService通信了。
更進一步,client是如何具體獲取到哪個service的呢?如下圖所示:
在service和binder之間還有一個contextManager,也就是serviceManager,每一個service要先往serviceManager裏面進行註冊,註冊完成之後由serviceManager統一管理。
在Android studio中可以通過adb指定打印出當前已經註冊過serviceManager的service。
$ adb shell service list
Found 71 services: 0 sip:
[android.net.sip.ISipService] 1 phone: [com.android.internal.telephony.ITelephony] … 20 location: [android.location.ILocationManager] …
55 activity: [android.app.IActivityManager]
56 package: [android.content.pm.IPackageManager] …
67 SurfaceFlinger: [android.ui.ISurfaceComposer]
68 media.camera: [android.hardware.ICameraService]
69 media.player: [android.media.IMediaPlayerService]
70 media.audio_flinger: [android.media.IAudioFlinger]
下圖是一次更加完整的client和service的通信流程:
4、Binder框架
在看Binder框架之前,先來看一下,從client發出請求service的完整的流程。
獲取服務過程:
第一步:client要請求服務,比如說在activity中調用context.getSystemService()
方法,這個時候serviceManager
就會使用getService(name)
,然後就會調用到native層中的ServiceManagerNative
類中的getService(name)
方法。
第二步:ServiceManagerNative會通過Binder發送一條SVG_MGR_GET_SERVICE的指令,然後通過svcmgr_handler()調用do_find_service()方法去svc_list中查找到相關的service。
第三步:查找到相應的服務後就會通過Binder將服務傳給ServiceManagerNative,然後傳給serviceManager,最後client就可以使用了。
注意: 服務實在svclist中保存的,svclist是一個鏈表,因此客戶端調用的服務必須要先註冊到svclist中。
註冊服務過程:
第一步: service通過調用serviceManager中的addService方法,然後調用ServiceManagerNative
類中的addservice(name)
方法。
第二步: ServiceManagerNative
會通過Binder發送一條SVG_MGR_ADD_SERVICE的指令,然後通過svcmgr_handler()調用do_add_service()方法往svc_list中添加相應的service。
重點:所有的服務都要先註冊到svc_list中才能被client調用到。svc_list以linkedlist的形式保存這些服務。
Binder結構設計
要了解binder的結構設計,就要了解Android的體系結構,Android是分成application層,framework層native層,以及內核層,Binder設計在每一層上都有不同的抽象。如下圖:
由上圖可知Binder的整體設計總共有四層:
1、Java層AIDL。
2、Framework層, Android.os.Binder 。
framework層中最重要的數據結構是transaction,有一下幾個默認的:
3、Native 層: libBinder.cpp
在native層主要是libBinder
4、內核層
內核層的通信都是通過ioctl來進行的,client打開一個ioctl,進入到輪詢隊列,一直阻塞直到時間到或者有消息。
5、Binder中使用的設計模式
1、代理模式(Proxy Pattern )
在Android中client不是直接去和binder打交道,client直接和Manager交互,而manager和managerProxy交互,也就是說client是通過managerProxy去和binder進行交互的。同時service也不是直接和binder交互,而是通過stub去和binder交互。如下圖。
2、Bridge Pattern
如下圖,應用層也就是Java層要使用MediaPlayer,就要調用native層中的MediaPlayer.cpp,但是MediaPlay.java不是直接去跟JNI打交道,而是通過與MediaPlayerSevice通信,從而經過Binder返回的。
6、Binder與內存映射mmap
Binder IPC 是基於內存映射(mmap)來實現的,但是 mmap() 通常是用在有物理介質的文件系統上的。
比如進程中的用戶區域是不能直接和物理設備打交道的,如果想要把磁盤上的數據讀取到進程的用戶區域,需要兩次拷貝(磁盤–>內核空間–>用戶空間);通常在這種場景下 mmap() 就能發揮作用,通過在物理介質和用戶空間之間建立映射,減少數據的拷貝次數,用內存讀寫取代I/O讀寫,提高文件讀取效率。
而 Binder 並不存在物理介質,因此 Binder 驅動使用 mmap() 並不是爲了在物理介質和用戶空間之間建立映射,而是用來在內核空間創建數據接收的緩存空間。
一次完整的 Binder IPC 通信過程通常是這樣:
首先 Binder 驅動在內核空間創建一個數據接收緩存區;
接着在內核空間開闢一塊內核緩存區,建立內核緩存區和內核中數據接收緩存區之間的映射關係,以及內核中數據接收緩存區和接收進程用戶空間地址的映射關係;
發送方進程通過系統調用 copyfromuser() 將數據 copy 到內核中的內核緩存區,由於內核緩存區和接收進程的用戶空間存在內存映射,因此也就相當於把數據發送到了接收進程的用戶空間,這樣便完成了一次進程間的通信。
如下圖:
參考文獻
1、http://rts.lab.asu.edu/web_438/project_final/Talk%208%20AndroidArc_Binder.pdf
2、http://rts.lab.asu.edu/web_438/project_final/CSE_598_Android_Architecture_Binder.pdf