閱讀前請點擊右上角“關注”，每天免費獲取Android知識解析及面試解答。Android架構解析，只做職場乾貨，完全免費分享！
作為一名Android開發人員，我們經常會好奇：Android 另起爐灶開發了 Binder 驅動，而沒有采用已有的方案，而 D-Bus 這樣的方案也可以實現 Binder 的功能，是出於什麼原因和什麼考慮？安全性？性能？
先簡單概括性地說說Linux現有的所有進程間IPC方式：
1. 管道：在創建時分配一個page大小的內存，緩存區大小比較有限； 2. 消息隊列：信息複製兩次，額外的CPU消耗；不合適頻繁或信息量大的通信； 3. 共享內存：無須複製，共享緩衝區直接付附加到進程虛擬地址空間，速度快；但進程間的同步問題操作系統無法實現，必須各進程利用同步工具解決； 4. 套接字：作為更通用的接口，傳輸效率低，主要用於不通機器或跨網絡的通信； 5. 信號量：常作為一種鎖機制，防止某進程正在訪問共享資源時，其他進程也訪問該資源。因此，主要作為進程間以及同一進程內不同線程之間的同步手段。 6.
信號: 不適用於信息交換，更適用於進程中斷控制，比如非法內存訪問，殺死某個進程等；Android的內核也是基於Linux內核，為何不直接採用Linux現有的進程IPC方案呢，難道Linux社區那麼多優秀人員都沒有考慮到有Binder這樣一個更優秀的方案，是google太過於牛B嗎？事實是真相併非如此，請細細往下看，您就明白了。
接下來正面回答這個問題，從5個角度來展開對Binder的分析：
（1）從性能的角度 數據拷貝次數：Binder數據拷貝只需要一次，而管道、消息隊列、Socket都需要2次，但共享內存方式一次內存拷貝都不需要；從性能角度看，Binder性能僅次於共享內存。
（2）從穩定性的角度 Binder是基於C/S架構的，簡單解釋下C/S架構，是指客戶端(Client)和服務端(Server)組成的架構，Client端有什麼需求，直接發送給Server端去完成，架構清晰明朗，Server端與Client端相對獨立，穩定性較好；而共享內存實現方式複雜，沒有客戶與服務端之別， 需要充分考慮到訪問臨界資源的併發同步問題，否則可能會出現死鎖等問題；從這穩定性角度看，Binder架構優越於共享內存。
僅僅從以上兩點，各有優劣，還不足以支撐google去採用binder的IPC機制，那麼更重要的原因是：
（3）從安全的角度 傳統Linux IPC的接收方無法獲得對方進程可靠的UID/PID，從而無法鑑別對方身份；而Android作為一個開放的開源體系，擁有非常多的開發平臺，App來源甚廣，因此手機的安全顯得額外重要；對於普通用戶，絕不希望從App商店下載偷窺隱射數據、後臺造成手機耗電等等問題，傳統Linux IPC無任何保護措施，完全由上層協議來確保。
Android為每個安裝好的應用程序分配了自己的UID，故進程的UID是鑑別進程身份的重要標誌，前面提到C/S架構，Android系統中對外只暴露Client端，Client端將任務發送給Server端，Server端會根據權限控制策略，判斷UID/PID是否滿足訪問權限，目前權限控制很多時候是通過彈出權限詢問對話框，讓用戶選擇是否運行。Android 6.0，也稱為Android M，在6.0之前的系統是在App第一次安裝時，會將整個App所涉及的所有權限一次詢問，只要留意看會發現很多App根本用不上通信錄和短信，但在這一次性權限權限時會包含進去，讓用戶拒絕不得，因為拒絕後App無法正常使用，而一旦授權後，應用便可以胡作非為。
針對這個問題，google在Android M做了調整，不再是安裝時一併詢問所有權限，而是在App運行過程中，需要哪個權限再彈框詢問用戶是否給相應的權限，對權限做了更細地控制，讓用戶有了更多的可控性，但同時也帶來了另一個用戶詬病的地方，那也就是權限詢問的彈框的次數大幅度增多。對於Android M平臺上，有些App開發者可能會寫出讓手機異常頻繁彈框的App，企圖直到用戶授權為止，這對用戶來說是不能忍的，用戶最後吐槽的可不光是App，還有Android系統以及手機廠商，有些用戶可能就跳果粉了，這還需要廣大Android開發者以及手機廠商共同努力，共同打造安全與體驗俱佳的Android手機。
Android中權限控制策略有SELinux等多方面手段，下面列舉從Binder的一個角度的權限控制：Android源碼的Binder權限是如何控制？ -Gityuan的回答
傳統IPC只能由用戶在數據包裡填入UID/PID；另外，可靠的身份標記只有由IPC機制本身在內核中添加。其次傳統IPC訪問接入點是開放的，無法建立私有通道。從安全角度，Binder的安全性更高。
說到這，可能有人要反駁 ，Android就算用了Binder架構，而現如今Android手機的各種流氓軟件，不就是幹著這種偷窺隱射，後臺偷偷跑流量的事嗎？沒錯，確實存在，但這不能說Binder的安全性不好，因為Android系統仍然是掌握主控權，可以控制這類App的流氓行為，只是對於該採用何種策略來控制，在這方面android的確存在很多有待進步的空間，這也是google以及各大手機廠商一直努力改善的地方之一。在Android 6.0，google對於app的權限問題作為較多的努力，大大收緊的應用權限；另外，在Google舉辦的Android Bootcamp 2016大會中，google也表示在Android 7.0 （也叫Android N）的權限隱私方面會進一步加強加固，比如SELinux，Memory safe language(還在research中)等等，在今年的5月18日至5月20日，google將推出Android N。
話題扯遠了，繼續說Binder。
（4）從語言層面的角度 大家多知道Linux是基於C語言(面向過程的語言)，而Android是基於Java語言(面向對象的語句)，而對於Binder恰恰也符合面向對象的思想，將進程間通信轉化為通過對某個Binder對象的引用調用該對象的方法，而其獨特之處在於Binder對象是一個可以跨進程引用的對象，它的實體位於一個進程中，而它的引用卻遍佈於系統的各個進程之中。可以從一個進程傳給其它進程，讓大家都能訪問同一Server，就像將一個對象或引用賦值給另一個引用一樣。Binder模糊了進程邊界，淡化了進程間通信過程，整個系統彷彿運行於同一個面向對象的程序之中。從語言層面，Binder更適合基於面嚮對象語言的Android系統，對於Linux系統可能會有點“水土不服”。
另外，Binder是為Android這類系統而生，而並非Linux社區沒有想到Binder IPC機制的存在，對於Linux社區的廣大開發人員，我還是表示深深佩服，讓世界有了如此精湛而美妙的開源系統。也並非Linux現有的IPC機制不夠好，相反地，經過這麼多優秀工程師的不斷打磨，依然非常優秀，每種Linux的IPC機制都有存在的價值，同時在Android系統中也依然採用了大量Linux現有的IPC機制，根據每類IPC的原理特性，因時制宜，不同場景特性往往會採用其下最適宜的。比如在Android OS中的Zygote進程的IPC採用的是Socket（套接字）機制，Android中的Kill Process採用的signal（信號）機制等等。而Binder更多則用在system_server進程與上層App層的IPC交互。
(5) 從公司戰略的角度
總所周知，Linux內核是開源的系統，所開放源代碼許可協議GPL保護，該協議具有“病毒式感染”的能力，怎麼理解這句話呢？受GPL保護的Linux Kernel是運行在內核空間，對於上層的任何類庫、服務、應用等運行在用戶空間，一旦進行SysCall（系統調用），調用到底層Kernel，那麼也必須遵循GPL協議。
而Android 之父 Andy Rubin對於GPL顯然是不能接受的，為此，Google巧妙地將GPL協議控制在內核空間，將用戶空間的協議採用Apache-2.0協議（允許基於Android的開發商不向社區反饋源碼），同時在GPL協議與Apache-2.0之間的Lib庫中採用BSD證授權方法，有效隔斷了GPL的傳染性，仍有較大爭議，但至少目前緩解Android，讓GPL止步於內核空間，這是Google在GPL Linux下 開源與商業化共存的一個成功典範。
有了這些鋪墊，我們再說說Binder的今世前緣
Binder是基於開源的 OpenBinder實現的，OpenBinder是一個開源的系統IPC機制,最初是由 Be Inc. 開發，接著由Palm, Inc.公司負責開發，現在OpenBinder的作者在Google工作，既然作者在Google公司，在用戶空間採用Binder 作為核心的IPC機制，再用Apache-2.0協議保護，自然而然是沒什麼問題，減少法律風險，以及對開發成本也大有裨益的，那麼從公司戰略角度，Binder也是不錯的選擇。
另外，再說一點關於OpenBinder，在2015年OpenBinder以及合入到Linux Kernel主線 3.19版本，這也算是Google對Linux的一點回饋吧。
綜合上述5點，可知Binder是Android系統上層進程間通信的不二選擇。
------------------------------------------------------------------------------------------------------------------------------------------ 接著，回答上述提到的D-Bus
也採用C/S架構的IPC機制，D-Bus是在用戶空間實現的方法，效率低，消息拷貝次數和上下文切換次數都明顯多過於Binder。針對D-Bus這些缺陷，於是就產生了kdbus，這是D-Bus在內核實現版，效率得到提升，與Binder一樣在內核作為字符設計，通過open()打開設備，mmap()映射內存。
（1）kdbus在進程間通信過程，Client端將消息在內存的消息隊列，可以存儲大量的消息，Server端不斷從消息隊裡中取消息，大小隻受限內存； （2）Binder的機制是每次通信，會通信的進程或線程中的todo隊裡中增加binder事務，並且每個進程所允許Binder線程數，google提供的默認最大線程數為16個，受限於CPU，由於線程數太多，增加系統負載，並且每個進程默認分配的（1M-8K）大小的內存。
而kdbus對於內存消耗較大，同時也適合傳輸大量數據和大量消息的系統。Binder對CPU和內存的需求比較低，效率比較高，從而進一步說明Binder適合於移動系統Android，但是，也有一定缺點，就是不同利用Binder輸出大數據，比如利用Binder傳輸幾M大小的圖片，便會出現異常，雖然有廠商會增加Binder內存，但是也不可能比系統默認內存大很多，否則整個系統的可用內存大幅度降低。
最後，簡單講講Android Binder架構
Binder在Android系統中江湖地位非常之高。在Zygote孵化出system_server進程後，在system_server進程中出初始化支持整個Android framework的各種各樣的Service，而這些Service從大的方向來劃分，分為Java層Framework和Native Framework層(C++)的Service，幾乎都是基於BInder IPC機制。
- Java framework：作為Server端繼承(或間接繼承)於Binder類，Client端繼承(或間接繼承)於BinderProxy類。例如 ActivityManagerService(用於控制Activity、Service、進程等) 這個服務作為Server端，間接繼承Binder類，而相應的ActivityManager作為Client端，間接繼承於BinderProxy類。 當然還有PackageManagerService、WindowManagerService等等很多系統服務都是採用C/S架構；
- Native Framework層：這是C++層，作為Server端繼承(或間接繼承)於BBinder類，Client端繼承(或間接繼承)於BpBinder。例如MediaPlayService(用於多媒體相關)作為Server端，繼承於BBinder類，而相應的MediaPlay作為Client端，間接繼承於BpBinder類。
總之，一句話"無Binder不Android"。
學習分享
很多Android開發者都會陷入困惑迷茫的時候，然而不論我們以後選擇什麼方向發展，目前重要的是把Android方面的技術學好，畢竟其實對於程序員來說，要學習的知識內容、技術有太多太多，要想不被環境淘汰就只有不斷提升自己，
從來都是我們去適應環境，而不是環境來適應我們！當程序員容易，當一個優秀的程序員是需要不斷學習的，從初級程序員到高級程序員，從初級架構師到資深架構師，或者走向管理，從技術經理到技術總監，每個階段都需要掌握不同的能力。早早確定自己的職業方向，才能在工作和能力提升中甩開同齡人。
想要拿高薪實現技術提升薪水得到質的飛躍。最快捷的方式，就是有人可以帶著你一起分析，這樣學習起來最為高效，所以為了大家能夠順利進階中高級、架構師，我特地為大家準備了一套高手學習的源碼和框架視頻等精品Android架構師教程，保證你學了以後保證薪資上升一個臺階。（以下是一小部分，獲取更多其他精講進階架構視頻資料可以私信我【學習】獲取免費領取方式）
當你有了學習線路，學習哪些內容，也知道以後的路怎麼走了，理論看多了總要實踐的。
以下是今天給大家分享的一些獨家乾貨：
【Android開發核心知識點筆記】
【Android思維腦圖（技能樹）】
【Android核心高級技術PDF文檔，BAT大廠面試真題解析】
【Android高級架構視頻學習資源】
Android精講視頻領取學習後更加是如虎添翼！進軍BATJ大廠等（備戰）！現在都說互聯網寒冬，其實無非就是你上錯了車，且穿的少（技能），要是你上對車，自身技術能力夠強，公司換掉的代價大，怎麼可能會被裁掉，都是淘汰末端的業務Curd而已！現如今市場上初級程序員氾濫，這套教程針對Android開發工程師1-6年的人員、正處於瓶頸期，想要年後突破自己漲薪的，進階Android中高級、架構師對你更是如魚得水，趕快領取吧！
【Android進階學習視頻】、【全套Android面試秘籍】【私信我學習】查看免費領取方式！
分享不易！喜歡的朋友別忘了關注+轉發+私信！
閱讀更多 Android架構解析 的文章
