AndroidIPC進(jìn)程間通訊機(jī)制.docx

AndroidIPC進(jìn)程間通訊機(jī)制Android IPC進(jìn)程間通訊機(jī)制 分類: Android一.Linux系統(tǒng)進(jìn)程間通信有哪些方式, 1.socket; 2.name pipe命名管道; 3.message queue消息隊(duì)列; 4.singal信號(hào)量; 5.share memory共享內(nèi)存; 二.Java系統(tǒng)的通信方式是什么, 1.socket; 2.name pipe; 三.Android系統(tǒng)通信方式是什么, Binder 通信; 四.Binder通信的優(yōu)勢(shì)是什么, 高效率 五.Binder通信的特點(diǎn)是什么, 是同步，而不是異步; 六.Binder通信是如何實(shí)現(xiàn)的, 1.Binder通信是通過linux的binder driver來實(shí)現(xiàn)的， 2.Binder通信操作類似線程遷移(thread migration)，兩個(gè)進(jìn)程間IPC看起來就象是一個(gè)進(jìn)程進(jìn)入另一個(gè)進(jìn)程執(zhí)行代碼然后帶著執(zhí)行的結(jié)果返回; 3.Binder的用戶空間為每一個(gè)進(jìn)程維護(hù)著一個(gè)可用的線程池，線程池用于處理到來的IPC以及執(zhí)行進(jìn)程本地消息，Binder通信是同步而不是異步。 七. Android中的 Binder通信實(shí)現(xiàn)要點(diǎn): 1. Android中的Binder通信是基于Service與Client的工作模型的; 2. 所有需要IBinder通信的進(jìn)程都必須創(chuàng)建一個(gè)IBinder接口; 3. 系統(tǒng)中有一個(gè)進(jìn)程管理所有的system service: 4. Android不允許用戶添加非授權(quán)的System service; 5. 現(xiàn)在源碼開放了，我們可以修改一些代碼來實(shí)現(xiàn)添加底層system Service的目的; 6. 對(duì)用戶程序來說，我們也要?jiǎng)?chuàng)建server,或者Service用于進(jìn)程間通信; 7. ActivityManagerService管理JAVA應(yīng)用層所有的service創(chuàng)建與連接(connect),disconnect; 8. 所有的Activity也是通過這個(gè)service來啟動(dòng)，加載的; 9. ActivityManagerService也是加載在Systems Servcie中的; 八.Android的 Service工作流程 1.Android虛擬機(jī)啟動(dòng)之前系統(tǒng)會(huì)先啟動(dòng)service Manager進(jìn)程; 2.service Manager打開binder驅(qū)動(dòng)，并通知binder kernel驅(qū)動(dòng)程序這個(gè)進(jìn)程將作為System Service Manager; 3.然后該進(jìn)程將進(jìn)入一個(gè)循環(huán)，等待處理來自其他進(jìn)程的數(shù)據(jù)。 4.用戶創(chuàng)建一個(gè)System service后，通過defaultServiceManager得到一個(gè)遠(yuǎn)程ServiceManager的接口，通過這個(gè)接口我們可以調(diào)用addService函數(shù)將System service添加到Service Manager進(jìn)程中; 5.然后client可以通過getService獲取到需要連接的目的Service的IBinder對(duì)象，這個(gè)IBinder是Service的BBinder在binder kernel的一個(gè)參考， 6.所以service IBinder 在binder kernel中不會(huì)存在相同的兩個(gè)IBinder對(duì)象，每一個(gè)Client進(jìn)程同樣需要打開Binder驅(qū)動(dòng)程序。對(duì)用戶程序而言，我們獲得這個(gè)對(duì)象就可以通過binder kernel訪問service對(duì)象中的方法。 7.Client與Service在不同的進(jìn)程中，通過這種方式實(shí)現(xiàn)了類似線程間的遷移的通信方式，對(duì)用戶程序而言當(dāng)調(diào)用Service返回的IBinder接口后，訪問Service中的方法就如同調(diào)用自己的函數(shù)。 Email: Blog 內(nèi)容提要 文檔簡(jiǎn)要整理binder，parcel，和service的內(nèi)容。以供備忘和參考。 聲明 僅限學(xué)習(xí)交流，禁止商業(yè)用途。轉(zhuǎn)載需注明出處。 版本記錄 Date Ver Note 2011-02-21 0.1 Draft. zcatt, Beijing 1. binder的結(jié)構(gòu) binder是解決ipc和rpc的工具。android使用的是linux os，支持多進(jìn)程和多線程。同時(shí)，對(duì)于java app，一個(gè)vm占用一個(gè)進(jìn)程。做為完善的開發(fā)框架，android必須支持ipc。binder就是解決ipc問題的途徑，更進(jìn)一步，binde還支持rpc。 進(jìn)程有自己的地址空間，不同進(jìn)程間的通信并不能直接引用地址。一般的解決途徑是，發(fā)送進(jìn)程把需要傳送的數(shù)據(jù)按照一定格式(marshall)轉(zhuǎn)換成二進(jìn)制形式/特定格式的數(shù)據(jù)，發(fā)往接收進(jìn)程;接收進(jìn)程收到二進(jìn)制形式、特定格式的數(shù)據(jù)后，反轉(zhuǎn)換(unmarshall)成原文數(shù)據(jù)，然后使用。binder使用的就是這種步驟。 binder使用的是同步c/s模型，s循環(huán)阻塞在接收數(shù)據(jù)操作上，隨時(shí)處理c的數(shù)據(jù)，處理后發(fā)送回c;c則將請(qǐng)求服務(wù)的數(shù)據(jù)發(fā)送到s，阻塞在收取s返回?cái)?shù)據(jù)，收到數(shù)據(jù)后，繼續(xù)自己的工作。 binder的框架可以分成3層，如圖。 最下層是linux os和binder driver。binder driver本質(zhì)上是進(jìn)程間的共享內(nèi)存，各進(jìn)程將要發(fā)送到其它進(jìn)程的數(shù)據(jù)寫入到driver，從driver讀取其它進(jìn)程發(fā)送來的數(shù)據(jù)。 中間層是cpp實(shí)現(xiàn)的framework，完成數(shù)據(jù)的接收發(fā)送轉(zhuǎn)換，和c/s流程的支持。 其實(shí)到中間層，binder的架構(gòu)就已經(jīng)完全具備了。但android使用的是java做為一般app的開發(fā)語(yǔ)言。所以還需要jni和相應(yīng)java binder類的支持，這就是中間層上面的第三層:jni/java 假設(shè)c，s都是java實(shí)現(xiàn)，app ipc一般的情景是這樣的， app client 收集ipc的數(shù)據(jù)，穿過jni，加工下傳，經(jīng)framework，寫入driver。數(shù)據(jù)經(jīng)driver上傳，反加工經(jīng)framework，穿過jni，上傳到app server。 對(duì)于rpc的支持，需要一點(diǎn)點(diǎn)技巧，直接傳遞函數(shù)指針是無法使用的。為了是敘述的方便，先澄清一對(duì)概念:本地local和遠(yuǎn)端remote。定義rpc函數(shù)的進(jìn)程稱作本地，調(diào)用rpc函數(shù)的進(jìn)程稱作遠(yuǎn)端。rpc的實(shí)現(xiàn)實(shí)際上是遠(yuǎn)端定義一個(gè)rpc的proxy，遠(yuǎn)端將proxy想做rpc在本地的實(shí)現(xiàn)，貌似本地函數(shù)操作一般使用。而這個(gè)proxy實(shí)際上僅僅是將自己登記在本地的handle和入口參數(shù)發(fā)送本地，本地根據(jù)handle，知曉是哪個(gè)遠(yuǎn)端進(jìn)程的proxy，調(diào)用函數(shù)，給定入口參數(shù)，執(zhí)行完畢后，將出口參數(shù)再返回遠(yuǎn)端的proxy(因?yàn)槲覀冇衕andle了)。binder的實(shí)現(xiàn)中handle和本地函數(shù)的對(duì)應(yīng)關(guān)系是保存在driver中管理的。 2. binder driver binder driver是binder機(jī)制的基礎(chǔ)，是實(shí)現(xiàn)ipc的通道。 binder driver與framework和app的功能操作是用ioctl方式實(shí)現(xiàn)的。最基本的操作是數(shù)據(jù)讀寫操作。一次讀寫操作有兩個(gè)子操作組成:寫子操作和讀子操作。driver為每個(gè)進(jìn)程和線程維護(hù)了一個(gè)數(shù)據(jù)結(jié)構(gòu)，其中有一個(gè)list，掛接了其它進(jìn)程寫入的數(shù)據(jù)，還有一個(gè)信號(hào)量。寫子操作負(fù)責(zé)將數(shù)據(jù)掛接到接收進(jìn)程對(duì)應(yīng)數(shù)據(jù)結(jié)構(gòu)的list上。讀子操作負(fù)責(zé)處理自己進(jìn)程中l(wèi)ist上的數(shù)據(jù)，傳回framework和app。 binder driver的第二個(gè)功能是為了支持rpc，就是維護(hù)本地函數(shù)和遠(yuǎn)端proxy的handle之間的對(duì)應(yīng)關(guān)系。更復(fù)雜的是維護(hù)兩個(gè)遠(yuǎn)端Proxy的handle之間的對(duì)應(yīng)關(guān)系，這兩個(gè)proxy是同一rpc的proxy。 3. binder framework binder的framework是cpp實(shí)現(xiàn)的，這里分成本地local/s和遠(yuǎn)端remote/c兩半來描述。 公共類IBinder派生出兩個(gè)子類，BBinder用于local，BpBinder用于remote。 本地實(shí)現(xiàn)的類以BBinder為基類派生，接收數(shù)據(jù)后，處理，并將結(jié)構(gòu)發(fā)會(huì)遠(yuǎn)端。 遠(yuǎn)端proxy的類使用BpBinder，接收和發(fā)送數(shù)據(jù)到本地。 進(jìn)一步方便開發(fā)，引入了IInterface類，開發(fā)者從Interface派生子類，定義自己需要的rpc操作。 在IInterface的裝飾下，從BBinder派生出了本地的關(guān)鍵類 BnInterface;從BpRefBase派生出了包含成員BpBinder對(duì)象的遠(yuǎn)端關(guān)鍵類BpInterface。 于是，創(chuàng)世紀(jì)中，神說:要有光，就有了光。神看光是好的，就把光暗分開了。 神稱光為晝，稱暗為夜。有晚上，有早晨，這是頭一日。 4. binder jni,java類和aidl工具 binder framework的機(jī)制要被java使用，需要經(jīng)過包裝。除了jni相關(guān)部分，android在java中還定義了幾個(gè)相關(guān)的接口和類，IBinder，Binder，BinderProxy，IInterface，BinderInternal。 aidl工具則是方便java實(shí)現(xiàn)c/s結(jié)構(gòu)的一個(gè)工具，開發(fā)者編寫簡(jiǎn)單的接口描述idl文件，則aidl自動(dòng)生成local和remote的Binder類。讓開發(fā)者關(guān)注在實(shí)際的功能開發(fā)上，不必為binder機(jī)制耗費(fèi)無謂的精力。 5. parcel是什么 為了便于ipc之間傳遞的數(shù)據(jù)的操作，binder引入了parcel的概念。parcel可以想成快遞公司的包裝箱，需要傳遞的各種類型的數(shù)據(jù)都被打包進(jìn)parcel類，binder負(fù)責(zé)傳遞parcel對(duì)象，接收端則從parcel解出數(shù)據(jù)。這樣的機(jī)制即減少了各種數(shù)據(jù)類型對(duì)傳遞的復(fù)雜性，又可以通過增加打包/解包parcel的數(shù)據(jù)類型，輕易實(shí)現(xiàn)擴(kuò)展。 parcel已經(jīng)支持容納基本數(shù)據(jù)類型和一些復(fù)合數(shù)據(jù)類型。 在framework層面，parcel提供了Flattenable基類，可以擴(kuò)展parcel容納的數(shù)據(jù)類型。 在java parcel層面，parcel提供了Parcelable接口，可以擴(kuò)展parcel容納的數(shù)據(jù)類型。 6. 依