为什么Android要采用Binder作为IPC机制?
生活随笔
收集整理的這篇文章主要介紹了
为什么Android要采用Binder作为IPC机制?
小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.
作者:Gityuan
鏈接:https://www.zhihu.com/question/39440766/answer/89210950
來源:知乎
著作權(quán)歸作者所有,轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)。
在開始回答 前,先簡單概括性地說說Linux現(xiàn)有的所有進(jìn)程間IPC方式:
1. 管道:在創(chuàng)建時分配一個page大小的內(nèi)存,緩存區(qū)大小比較有限;
2. 消息隊(duì)列:信息復(fù)制兩次,額外的CPU消耗;不合適頻繁或信息量大的通信;
3. 共享內(nèi)存:無須復(fù)制,共享緩沖區(qū)直接付附加到進(jìn)程虛擬地址空間,速度快;但進(jìn)程間的同步問題操作系統(tǒng)無法實(shí)現(xiàn),必須各進(jìn)程利用同步工具解決;
4. 套接字:作為更通用的接口,傳輸效率低,主要用于不通機(jī)器或跨網(wǎng)絡(luò)的通信;
5. 信號量:常作為一種鎖機(jī)制,防止某進(jìn)程正在訪問共享資源時,其他進(jìn)程也訪問該資源。因此,主要作為進(jìn)程間以及同一進(jìn)程內(nèi)不同線程之間的同步手段。
6. 信號: 不適用于信息交換,更適用于進(jìn)程中斷控制,比如非法內(nèi)存訪問,殺死某個進(jìn)程等;
Android的內(nèi)核也是基于Linux內(nèi)核,為何不直接采用Linux現(xiàn)有的進(jìn)程IPC方案呢,難道Linux社區(qū)那么多優(yōu)秀人員都沒有考慮到有Binder這樣一個更優(yōu)秀的方案,是google太過于牛B嗎?事實(shí)是真相并非如此,請細(xì)細(xì)往下看,您就明白了。
-------------------------------------------------------------------------------------------------------------------------------------------
接下來正面回答這個問題,從5個角度來展開對Binder的分析:
(1)從性能的角度
數(shù)據(jù)拷貝次數(shù):Binder數(shù)據(jù)拷貝只需要一次,而管道、消息隊(duì)列、Socket都需要2次,但共享內(nèi)存方式一次內(nèi)存拷貝都不需要;從性能角度看,Binder性能僅次于共享內(nèi)存。
(2)從穩(wěn)定性的角度
Binder是基于C/S架構(gòu)的,簡單解釋下C/S架構(gòu),是指客戶端(Client)和服務(wù)端(Server)組成的架構(gòu),Client端有什么需求,直接發(fā)送給Server端去完成,架構(gòu)清晰明朗,Server端與Client端相對獨(dú)立,穩(wěn)定性較好;而共享內(nèi)存實(shí)現(xiàn)方式復(fù)雜,沒有客戶與服務(wù)端之別, 需要充分考慮到訪問臨界資源的并發(fā)同步問題,否則可能會出現(xiàn)死鎖等問題;從這穩(wěn)定性角度看,Binder架構(gòu)優(yōu)越于共享內(nèi)存。
僅僅從以上兩點(diǎn),各有優(yōu)劣,還不足以支撐google去采用binder的IPC機(jī)制,那么更重要的原因是:
(3)從安全的角度
傳統(tǒng)Linux IPC的接收方無法獲得對方進(jìn)程可靠的UID/PID,從而無法鑒別對方身份;而Android作為一個開放的開源體系,擁有非常多的開發(fā)平臺,App來源甚廣,因此手機(jī)的安全顯得額外重要;對于普通用戶,絕不希望從App商店下載偷窺隱射數(shù)據(jù)、后臺造成手機(jī)耗電等等問題,傳統(tǒng)Linux IPC無任何保護(hù)措施,完全由上層協(xié)議來確保。
Android為每個安裝好的應(yīng)用程序分配了自己的UID,故進(jìn)程的UID是鑒別進(jìn)程身份的重要標(biāo)志,前面提到C/S架構(gòu), Android系統(tǒng)中對外只暴露Client端,Client端將任務(wù)發(fā)送給Server端,Server端會根據(jù)權(quán)限控制策略,判斷UID/PID是否滿足訪問權(quán)限,目前權(quán)限控制很多時候是通過彈出權(quán)限詢問對話框,讓用戶選擇是否運(yùn)行。Android 6.0,也稱為Android M,在6.0之前的系統(tǒng)是在App第一次安裝時,會將整個App所涉及的所有權(quán)限一次詢問,只要留意看會發(fā)現(xiàn)很多App根本用不上通信錄和短信,但在這一次性權(quán)限權(quán)限時會包含進(jìn)去,讓用戶拒絕不得,因?yàn)榫芙^后App無法正常使用,而一旦授權(quán)后,應(yīng)用便可以胡作非為。
針對這個問題,google在Android M做了調(diào)整,不再是安裝時一并詢問所有權(quán)限,而是在App運(yùn)行過程中,需要哪個權(quán)限再彈框詢問用戶是否給相應(yīng)的權(quán)限,對權(quán)限做了更細(xì)地控制,讓用戶有了更多的可控性,但 同時也帶來了另一個用戶詬病的地方,那也就是權(quán)限詢問的彈框的次數(shù)大幅度增多。對于Android M平臺上,有些App開發(fā)者可能會寫出讓手機(jī)異常頻繁彈框的App,企圖直到用戶授權(quán)為止,這對用戶來說是不能忍的,用戶最后吐槽的可不光是App,還有Android系統(tǒng)以及手機(jī)廠商,有些用戶可能就跳果粉了,這還需要廣大Android開發(fā)者以及手機(jī)廠商共同努力,共同打造安全與體驗(yàn)俱佳的Android手機(jī)。
Android中權(quán)限控制策略有SELinux等多方面手段,下面列舉從Binder的一個角度的權(quán)限控制:
Android源碼的Binder權(quán)限是如何控制? -Gityuan的回答
傳統(tǒng)IPC只能由用戶在數(shù)據(jù)包里填入UID/PID;另外,可靠的身份標(biāo)記只有由IPC機(jī)制本身在內(nèi)核中添加。其次傳統(tǒng)IPC訪問接入點(diǎn)是開放的,無法建立私有通道。從安全角度,Binder的安全性更高。
說到這,可能有人要反駁,Android就算用了Binder架構(gòu),而現(xiàn)如今Android手機(jī)的各種流氓軟件,不就是干著這種偷窺隱射,后臺偷偷跑流量的事嗎?沒錯,確實(shí)存在,但這不能說Binder的安全性不好,因?yàn)锳ndroid系統(tǒng)仍然是掌握主控權(quán),可以控制這類App的流氓行為,只是對于該采用何種策略來控制,在這方面android的確存在很多有待進(jìn)步的空間,這也是google以及各大手機(jī)廠商一直努力改善的地方之一。在Android 6.0,google對于app的權(quán)限問題作為較多的努力,大大收緊的應(yīng)用權(quán)限;另外,在 Google舉辦的Android Bootcamp 2016大會中,google也表示在Android 7.0 (也叫Android N)的權(quán)限隱私方面會進(jìn)一步加強(qiáng)加固,比如SELinux,Memory safe language(還在research中)等等,在今年的5月18日至5月20日,google將推出Android N。
話題扯遠(yuǎn)了,繼續(xù)說Binder。
(4)從語言層面的角度
大家多知道Linux是基于C語言(面向過程的語言),而Android是基于Java語言(面向?qū)ο蟮恼Z句),而對于Binder恰恰也符合面向?qū)ο蟮乃枷?#xff0c;將進(jìn)程間通信轉(zhuǎn)化為通過對某個Binder對象的引用調(diào)用該對象的方法,而其獨(dú)特之處在于Binder對象是一個可以跨進(jìn)程引用的對象,它的實(shí)體位于一個進(jìn)程中,而它的引用卻遍布于系統(tǒng)的各個進(jìn)程之中。可以從一個進(jìn)程傳給其它進(jìn)程,讓大家都能訪問同一Server,就像將一個對象或引用賦值給另一個引用一樣。Binder模糊了進(jìn)程邊界,淡化了進(jìn)程間通信過程,整個系統(tǒng)仿佛運(yùn)行于同一個面向?qū)ο蟮某绦蛑小恼Z言層面,Binder更適合基于面向?qū)ο笳Z言的Android系統(tǒng),對于Linux系統(tǒng)可能會有點(diǎn)“水土不服”。
另外,Binder是為Android這類系統(tǒng)而生,而并非Linux社區(qū)沒有想到Binder IPC機(jī)制的存在,對于Linux社區(qū)的廣大開發(fā)人員,我還是表示深深佩服,讓世界有了如此精湛而美妙的開源系統(tǒng)。也并非Linux現(xiàn)有的IPC機(jī)制不夠好,相反地,經(jīng)過這么多優(yōu)秀工程師的不斷打磨,依然非常優(yōu)秀,每種Linux的IPC機(jī)制都有存在的價值,同時在Android系統(tǒng)中也依然采用了大量Linux現(xiàn)有的IPC機(jī)制,根據(jù)每類IPC的原理特性,因時制宜,不同場景特性往往會采用其下最適宜的。比如在 Android OS中的Zygote進(jìn)程的IPC采用的是Socket(套接字)機(jī)制,Android中的 Kill Process采用的signal(信號)機(jī)制等等。而 Binder更多則用在system_server進(jìn)程與上層App層的IPC交互。
(5) 從公司戰(zhàn)略的角度
總所周知,Linux內(nèi)核是開源的系統(tǒng),所開放源代碼許可協(xié)議GPL保護(hù),該協(xié)議具有“病毒式感染”的能力,怎么理解這句話呢?受GPL保護(hù)的Linux Kernel是運(yùn)行在內(nèi)核空間,對于上層的任何類庫、服務(wù)、應(yīng)用等運(yùn)行在用戶空間,一旦進(jìn)行SysCall(系統(tǒng)調(diào)用),調(diào)用到底層Kernel,那么也必須遵循GPL協(xié)議。
而Android 之父 Andy Rubin對于GPL顯然是不能接受的,為此,Google巧妙地將GPL協(xié)議控制在內(nèi)核空間,將用戶空間的協(xié)議采用Apache-2.0協(xié)議(允許基于Android的開發(fā)商不向社區(qū)反饋源碼),同時在GPL協(xié)議與Apache-2.0之間的Lib庫中采用BSD證授權(quán)方法,有效隔斷了GPL的傳染性,仍有較大爭議,但至少目前緩解Android,讓GPL止步于內(nèi)核空間,這是Google在GPL Linux下 開源與商業(yè)化共存的一個成功典范。
有了這些鋪墊,我們再說說Binder的今世前緣
Binder是基于開源的 OpenBinder實(shí)現(xiàn)的,OpenBinder是一個開源的系統(tǒng)IPC機(jī)制,最初是由 Be Inc. 開發(fā),接著由 Palm, Inc.公司負(fù)責(zé)開發(fā),現(xiàn)在OpenBinder的作者在Google工作,既然作者在Google公司,在用戶空間采用Binder 作為核心的IPC機(jī)制,再用Apache-2.0協(xié)議保護(hù),自然而然是沒什么問題,減少法律風(fēng)險,以及對開發(fā)成本也大有裨益的,那么從公司戰(zhàn)略角度,Binder也是不錯的選擇。
另外,再說一點(diǎn)關(guān)于OpenBinder,在2015年OpenBinder以及合入到Linux Kernel主線 3.19版本,這也算是Google對Linux的一點(diǎn)回饋吧。
綜合上述5點(diǎn),可知Binder是Android系統(tǒng)上層進(jìn)程間通信的不二選擇。
------------------------------------------------------------------------------------------------------------------------------------------
接著,回答樓主提到的D-Bus
也采用C/S架構(gòu)的IPC機(jī)制, D-Bus是在用戶空間實(shí)現(xiàn)的方法,效率低,消息拷貝次數(shù)和上下文切換次數(shù)都明顯多過于Binder。針對D-Bus這些缺陷,于是就產(chǎn)生了 kdbus,這是D-Bus在內(nèi)核實(shí)現(xiàn)版,效率得到提升,與Binder一樣在內(nèi)核作為字符設(shè)計,通過open()打開設(shè)備,mmap()映射內(nèi)存。
(1)kdbus在進(jìn)程間通信過程,Client端將消息在內(nèi)存的消息隊(duì)列,可以存儲大量的消息,Server端不斷從消息隊(duì)里中取消息,大小只受限內(nèi)存;
(2)Binder的機(jī)制是每次通信,會通信的進(jìn)程或線程中的todo隊(duì)里中增加binder事務(wù),并且每個進(jìn)程所允許Binder線程數(shù),google提供的默認(rèn)最大線程數(shù)為16個,受限于CPU,由于線程數(shù)太多,增加系統(tǒng)負(fù)載,并且每個進(jìn)程默認(rèn)分配的(1M-8K)大小的內(nèi)存。
而kdbus對于內(nèi)存消耗較大,同時也適合傳輸大量數(shù)據(jù)和大量消息的系統(tǒng)。Binder對CPU和內(nèi)存的需求比較低,效率比較高,從而進(jìn)一步說明Binder適合于移動系統(tǒng)Android,但是,也有一定缺點(diǎn),就是不同利用Binder輸出大數(shù)據(jù),比如利用Binder傳輸幾M大小的圖片,便會出現(xiàn)異常,雖然有廠商會增加Binder內(nèi)存,但是也不可能比系統(tǒng)默認(rèn)內(nèi)存大很多,否則整個系統(tǒng)的可用內(nèi)存大幅度降低。
最后,簡單講講Android Binder架構(gòu)
Binder在Android系統(tǒng)中江湖地位非常之高。在Zygote孵化出system_server進(jìn)程后,在system_server進(jìn)程中出初始化支持整個Android framework的各種各樣的Service,而這些Service從大的方向來劃分,分為Java層Framework和Native Framework層(C++)的Service,幾乎都是基于BInder IPC機(jī)制。
Java framework:作為Server端繼承(或間接繼承)于Binder類,Client端繼承(或間接繼承)于BinderProxy類。例如 ActivityManagerService(用于控制Activity、Service、進(jìn)程等) 這個服務(wù)作為Server端,間接繼承Binder類,而相應(yīng)的ActivityManager作為Client端,間接繼承于BinderProxy類。 當(dāng)然還有PackageManagerService、WindowManagerService等等很多系統(tǒng)服務(wù)都是采用C/S架構(gòu);
Native Framework層:這是C++層,作為Server端繼承(或間接繼承)于BBinder類,Client端繼承(或間接繼承)于BpBinder。例如MediaPlayService(用于多媒體相關(guān))作為Server端,繼承于BBinder類,而相應(yīng)的MediaPlay作為Client端,間接繼承于BpBinder類。
總之,一句話"無Binder不Android"。
本來想從Binder源碼技術(shù)的角度,分析Binder如何做到的,發(fā)現(xiàn)不知不覺就寫了這么多,對于實(shí)現(xiàn)原理有興趣,查看我的個人博客。通過 Google搜索關(guān)鍵字 “Binder系列”,第一個出現(xiàn)的便是我的博客 Yuanhh.com,上一張 Google搜索結(jié)果的截圖:
<img src="https://pic2.zhimg.com/c986b0f037f7f1aaec0ba485253dba25_b.png" data-rawwidth="807" data-rawheight="800" class="origin_image zh-lightbox-thumb" width="807" data-original="https://pic2.zhimg.com/c986b0f037f7f1aaec0ba485253dba25_r.png">
為了便于傳播與記憶,剛剛申請了新域名gityuan(與我的微博、知乎ID同名),個人博客由http://yuanhh.com遷移到新域名 http://Gityuan.com,由于不擅長SEO,網(wǎng)站的google權(quán)重降低,更新時間 2016.03.27。
鏈接:https://www.zhihu.com/question/39440766/answer/89210950
來源:知乎
著作權(quán)歸作者所有,轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)。
在開始回答 前,先簡單概括性地說說Linux現(xiàn)有的所有進(jìn)程間IPC方式:
1. 管道:在創(chuàng)建時分配一個page大小的內(nèi)存,緩存區(qū)大小比較有限;
2. 消息隊(duì)列:信息復(fù)制兩次,額外的CPU消耗;不合適頻繁或信息量大的通信;
3. 共享內(nèi)存:無須復(fù)制,共享緩沖區(qū)直接付附加到進(jìn)程虛擬地址空間,速度快;但進(jìn)程間的同步問題操作系統(tǒng)無法實(shí)現(xiàn),必須各進(jìn)程利用同步工具解決;
4. 套接字:作為更通用的接口,傳輸效率低,主要用于不通機(jī)器或跨網(wǎng)絡(luò)的通信;
5. 信號量:常作為一種鎖機(jī)制,防止某進(jìn)程正在訪問共享資源時,其他進(jìn)程也訪問該資源。因此,主要作為進(jìn)程間以及同一進(jìn)程內(nèi)不同線程之間的同步手段。
6. 信號: 不適用于信息交換,更適用于進(jìn)程中斷控制,比如非法內(nèi)存訪問,殺死某個進(jìn)程等;
Android的內(nèi)核也是基于Linux內(nèi)核,為何不直接采用Linux現(xiàn)有的進(jìn)程IPC方案呢,難道Linux社區(qū)那么多優(yōu)秀人員都沒有考慮到有Binder這樣一個更優(yōu)秀的方案,是google太過于牛B嗎?事實(shí)是真相并非如此,請細(xì)細(xì)往下看,您就明白了。
-------------------------------------------------------------------------------------------------------------------------------------------
接下來正面回答這個問題,從5個角度來展開對Binder的分析:
(1)從性能的角度
數(shù)據(jù)拷貝次數(shù):Binder數(shù)據(jù)拷貝只需要一次,而管道、消息隊(duì)列、Socket都需要2次,但共享內(nèi)存方式一次內(nèi)存拷貝都不需要;從性能角度看,Binder性能僅次于共享內(nèi)存。
(2)從穩(wěn)定性的角度
Binder是基于C/S架構(gòu)的,簡單解釋下C/S架構(gòu),是指客戶端(Client)和服務(wù)端(Server)組成的架構(gòu),Client端有什么需求,直接發(fā)送給Server端去完成,架構(gòu)清晰明朗,Server端與Client端相對獨(dú)立,穩(wěn)定性較好;而共享內(nèi)存實(shí)現(xiàn)方式復(fù)雜,沒有客戶與服務(wù)端之別, 需要充分考慮到訪問臨界資源的并發(fā)同步問題,否則可能會出現(xiàn)死鎖等問題;從這穩(wěn)定性角度看,Binder架構(gòu)優(yōu)越于共享內(nèi)存。
僅僅從以上兩點(diǎn),各有優(yōu)劣,還不足以支撐google去采用binder的IPC機(jī)制,那么更重要的原因是:
(3)從安全的角度
傳統(tǒng)Linux IPC的接收方無法獲得對方進(jìn)程可靠的UID/PID,從而無法鑒別對方身份;而Android作為一個開放的開源體系,擁有非常多的開發(fā)平臺,App來源甚廣,因此手機(jī)的安全顯得額外重要;對于普通用戶,絕不希望從App商店下載偷窺隱射數(shù)據(jù)、后臺造成手機(jī)耗電等等問題,傳統(tǒng)Linux IPC無任何保護(hù)措施,完全由上層協(xié)議來確保。
Android為每個安裝好的應(yīng)用程序分配了自己的UID,故進(jìn)程的UID是鑒別進(jìn)程身份的重要標(biāo)志,前面提到C/S架構(gòu), Android系統(tǒng)中對外只暴露Client端,Client端將任務(wù)發(fā)送給Server端,Server端會根據(jù)權(quán)限控制策略,判斷UID/PID是否滿足訪問權(quán)限,目前權(quán)限控制很多時候是通過彈出權(quán)限詢問對話框,讓用戶選擇是否運(yùn)行。Android 6.0,也稱為Android M,在6.0之前的系統(tǒng)是在App第一次安裝時,會將整個App所涉及的所有權(quán)限一次詢問,只要留意看會發(fā)現(xiàn)很多App根本用不上通信錄和短信,但在這一次性權(quán)限權(quán)限時會包含進(jìn)去,讓用戶拒絕不得,因?yàn)榫芙^后App無法正常使用,而一旦授權(quán)后,應(yīng)用便可以胡作非為。
針對這個問題,google在Android M做了調(diào)整,不再是安裝時一并詢問所有權(quán)限,而是在App運(yùn)行過程中,需要哪個權(quán)限再彈框詢問用戶是否給相應(yīng)的權(quán)限,對權(quán)限做了更細(xì)地控制,讓用戶有了更多的可控性,但 同時也帶來了另一個用戶詬病的地方,那也就是權(quán)限詢問的彈框的次數(shù)大幅度增多。對于Android M平臺上,有些App開發(fā)者可能會寫出讓手機(jī)異常頻繁彈框的App,企圖直到用戶授權(quán)為止,這對用戶來說是不能忍的,用戶最后吐槽的可不光是App,還有Android系統(tǒng)以及手機(jī)廠商,有些用戶可能就跳果粉了,這還需要廣大Android開發(fā)者以及手機(jī)廠商共同努力,共同打造安全與體驗(yàn)俱佳的Android手機(jī)。
Android中權(quán)限控制策略有SELinux等多方面手段,下面列舉從Binder的一個角度的權(quán)限控制:
Android源碼的Binder權(quán)限是如何控制? -Gityuan的回答
傳統(tǒng)IPC只能由用戶在數(shù)據(jù)包里填入UID/PID;另外,可靠的身份標(biāo)記只有由IPC機(jī)制本身在內(nèi)核中添加。其次傳統(tǒng)IPC訪問接入點(diǎn)是開放的,無法建立私有通道。從安全角度,Binder的安全性更高。
說到這,可能有人要反駁,Android就算用了Binder架構(gòu),而現(xiàn)如今Android手機(jī)的各種流氓軟件,不就是干著這種偷窺隱射,后臺偷偷跑流量的事嗎?沒錯,確實(shí)存在,但這不能說Binder的安全性不好,因?yàn)锳ndroid系統(tǒng)仍然是掌握主控權(quán),可以控制這類App的流氓行為,只是對于該采用何種策略來控制,在這方面android的確存在很多有待進(jìn)步的空間,這也是google以及各大手機(jī)廠商一直努力改善的地方之一。在Android 6.0,google對于app的權(quán)限問題作為較多的努力,大大收緊的應(yīng)用權(quán)限;另外,在 Google舉辦的Android Bootcamp 2016大會中,google也表示在Android 7.0 (也叫Android N)的權(quán)限隱私方面會進(jìn)一步加強(qiáng)加固,比如SELinux,Memory safe language(還在research中)等等,在今年的5月18日至5月20日,google將推出Android N。
話題扯遠(yuǎn)了,繼續(xù)說Binder。
(4)從語言層面的角度
大家多知道Linux是基于C語言(面向過程的語言),而Android是基于Java語言(面向?qū)ο蟮恼Z句),而對于Binder恰恰也符合面向?qū)ο蟮乃枷?#xff0c;將進(jìn)程間通信轉(zhuǎn)化為通過對某個Binder對象的引用調(diào)用該對象的方法,而其獨(dú)特之處在于Binder對象是一個可以跨進(jìn)程引用的對象,它的實(shí)體位于一個進(jìn)程中,而它的引用卻遍布于系統(tǒng)的各個進(jìn)程之中。可以從一個進(jìn)程傳給其它進(jìn)程,讓大家都能訪問同一Server,就像將一個對象或引用賦值給另一個引用一樣。Binder模糊了進(jìn)程邊界,淡化了進(jìn)程間通信過程,整個系統(tǒng)仿佛運(yùn)行于同一個面向?qū)ο蟮某绦蛑小恼Z言層面,Binder更適合基于面向?qū)ο笳Z言的Android系統(tǒng),對于Linux系統(tǒng)可能會有點(diǎn)“水土不服”。
另外,Binder是為Android這類系統(tǒng)而生,而并非Linux社區(qū)沒有想到Binder IPC機(jī)制的存在,對于Linux社區(qū)的廣大開發(fā)人員,我還是表示深深佩服,讓世界有了如此精湛而美妙的開源系統(tǒng)。也并非Linux現(xiàn)有的IPC機(jī)制不夠好,相反地,經(jīng)過這么多優(yōu)秀工程師的不斷打磨,依然非常優(yōu)秀,每種Linux的IPC機(jī)制都有存在的價值,同時在Android系統(tǒng)中也依然采用了大量Linux現(xiàn)有的IPC機(jī)制,根據(jù)每類IPC的原理特性,因時制宜,不同場景特性往往會采用其下最適宜的。比如在 Android OS中的Zygote進(jìn)程的IPC采用的是Socket(套接字)機(jī)制,Android中的 Kill Process采用的signal(信號)機(jī)制等等。而 Binder更多則用在system_server進(jìn)程與上層App層的IPC交互。
(5) 從公司戰(zhàn)略的角度
總所周知,Linux內(nèi)核是開源的系統(tǒng),所開放源代碼許可協(xié)議GPL保護(hù),該協(xié)議具有“病毒式感染”的能力,怎么理解這句話呢?受GPL保護(hù)的Linux Kernel是運(yùn)行在內(nèi)核空間,對于上層的任何類庫、服務(wù)、應(yīng)用等運(yùn)行在用戶空間,一旦進(jìn)行SysCall(系統(tǒng)調(diào)用),調(diào)用到底層Kernel,那么也必須遵循GPL協(xié)議。
而Android 之父 Andy Rubin對于GPL顯然是不能接受的,為此,Google巧妙地將GPL協(xié)議控制在內(nèi)核空間,將用戶空間的協(xié)議采用Apache-2.0協(xié)議(允許基于Android的開發(fā)商不向社區(qū)反饋源碼),同時在GPL協(xié)議與Apache-2.0之間的Lib庫中采用BSD證授權(quán)方法,有效隔斷了GPL的傳染性,仍有較大爭議,但至少目前緩解Android,讓GPL止步于內(nèi)核空間,這是Google在GPL Linux下 開源與商業(yè)化共存的一個成功典范。
有了這些鋪墊,我們再說說Binder的今世前緣
Binder是基于開源的 OpenBinder實(shí)現(xiàn)的,OpenBinder是一個開源的系統(tǒng)IPC機(jī)制,最初是由 Be Inc. 開發(fā),接著由 Palm, Inc.公司負(fù)責(zé)開發(fā),現(xiàn)在OpenBinder的作者在Google工作,既然作者在Google公司,在用戶空間采用Binder 作為核心的IPC機(jī)制,再用Apache-2.0協(xié)議保護(hù),自然而然是沒什么問題,減少法律風(fēng)險,以及對開發(fā)成本也大有裨益的,那么從公司戰(zhàn)略角度,Binder也是不錯的選擇。
另外,再說一點(diǎn)關(guān)于OpenBinder,在2015年OpenBinder以及合入到Linux Kernel主線 3.19版本,這也算是Google對Linux的一點(diǎn)回饋吧。
綜合上述5點(diǎn),可知Binder是Android系統(tǒng)上層進(jìn)程間通信的不二選擇。
------------------------------------------------------------------------------------------------------------------------------------------
接著,回答樓主提到的D-Bus
也采用C/S架構(gòu)的IPC機(jī)制, D-Bus是在用戶空間實(shí)現(xiàn)的方法,效率低,消息拷貝次數(shù)和上下文切換次數(shù)都明顯多過于Binder。針對D-Bus這些缺陷,于是就產(chǎn)生了 kdbus,這是D-Bus在內(nèi)核實(shí)現(xiàn)版,效率得到提升,與Binder一樣在內(nèi)核作為字符設(shè)計,通過open()打開設(shè)備,mmap()映射內(nèi)存。
(1)kdbus在進(jìn)程間通信過程,Client端將消息在內(nèi)存的消息隊(duì)列,可以存儲大量的消息,Server端不斷從消息隊(duì)里中取消息,大小只受限內(nèi)存;
(2)Binder的機(jī)制是每次通信,會通信的進(jìn)程或線程中的todo隊(duì)里中增加binder事務(wù),并且每個進(jìn)程所允許Binder線程數(shù),google提供的默認(rèn)最大線程數(shù)為16個,受限于CPU,由于線程數(shù)太多,增加系統(tǒng)負(fù)載,并且每個進(jìn)程默認(rèn)分配的(1M-8K)大小的內(nèi)存。
而kdbus對于內(nèi)存消耗較大,同時也適合傳輸大量數(shù)據(jù)和大量消息的系統(tǒng)。Binder對CPU和內(nèi)存的需求比較低,效率比較高,從而進(jìn)一步說明Binder適合于移動系統(tǒng)Android,但是,也有一定缺點(diǎn),就是不同利用Binder輸出大數(shù)據(jù),比如利用Binder傳輸幾M大小的圖片,便會出現(xiàn)異常,雖然有廠商會增加Binder內(nèi)存,但是也不可能比系統(tǒng)默認(rèn)內(nèi)存大很多,否則整個系統(tǒng)的可用內(nèi)存大幅度降低。
最后,簡單講講Android Binder架構(gòu)
Binder在Android系統(tǒng)中江湖地位非常之高。在Zygote孵化出system_server進(jìn)程后,在system_server進(jìn)程中出初始化支持整個Android framework的各種各樣的Service,而這些Service從大的方向來劃分,分為Java層Framework和Native Framework層(C++)的Service,幾乎都是基于BInder IPC機(jī)制。
總之,一句話"無Binder不Android"。
本來想從Binder源碼技術(shù)的角度,分析Binder如何做到的,發(fā)現(xiàn)不知不覺就寫了這么多,對于實(shí)現(xiàn)原理有興趣,查看我的個人博客。通過 Google搜索關(guān)鍵字 “Binder系列”,第一個出現(xiàn)的便是我的博客 Yuanhh.com,上一張 Google搜索結(jié)果的截圖:
<img src="https://pic2.zhimg.com/c986b0f037f7f1aaec0ba485253dba25_b.png" data-rawwidth="807" data-rawheight="800" class="origin_image zh-lightbox-thumb" width="807" data-original="https://pic2.zhimg.com/c986b0f037f7f1aaec0ba485253dba25_r.png">
為了便于傳播與記憶,剛剛申請了新域名gityuan(與我的微博、知乎ID同名),個人博客由http://yuanhh.com遷移到新域名 http://Gityuan.com,由于不擅長SEO,網(wǎng)站的google權(quán)重降低,更新時間 2016.03.27。
有網(wǎng)友建議,放上Binder系列的連接:Binder系列—開篇。 更新時間2016.04.09
原文地址:?https://www.zhihu.com/question/39440766/answer/89210950
總結(jié)
以上是生活随笔為你收集整理的为什么Android要采用Binder作为IPC机制?的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: OpenSSL X509 Certifi
- 下一篇: Android Full-Disk En