android的ipc機制

『壹』 Binder 總結

binder是Android 中的一種進程間通信機制（IPC機制）

android 是一種基於linux 的系統，linux 系統已經提供了 諸如管道、消息隊列、共享內存和socket 等IPC 方式。既然已經存在了如此之多的IPC 機制，為什麼binder還會出現？主要是因為上述IPC機制無法對android 而言存在著諸多的不便，主要體現在性能，穩定性和安全性三個方面。

綜上，android中使用Binder作為其IPC 機制。

binder 主要是通過內存映射來實現的，一次完整的ipc通訊的過程如下：
1.binder 驅動在內核中創建一塊數據接收緩沖區
2.建立一塊內核緩沖區
3.建立內核緩沖區和數據接收緩沖區的映射
4.建立內核數據緩沖區和接收進城用戶空間的映射
5.發送方將數據發送到內核緩沖區
6.由於映射的存在，就相當於直接將數據發送到了 接收進城中

binder 主要有四部分組成

其中binder client 、 binder service 和 servicemanager 運行在用戶空間，而binder 驅動則是運行在內核空間（binder驅動是通過模塊掛載的方式，運行在內核空間中的）。

binder 的工作流程其實可以類比為 上網的過程。客戶端（binder client） 伺服器（binder service） dns（servicemanager） 和 路由器（binder 驅動）

客戶端輸入網址請求伺服器會在路由器的幫助下請求 dns 伺服器獲取伺服器的ip地址，然後利用ip地址和伺服器進行通訊。

binder基本的運行如下：

1.首先一個進城通過binder驅動將自己注冊為servicemanager

2.service 通過binder 驅動將自己的binder 注冊到servicemanager中，以對外使用。在這個過程中，binder驅動會生成該binder 的內核節點，以及該節點的引用，並將這些內容發送給servicemanager，servicemanager會把引用存入表中
3.client 通過binder名稱，在binder驅動的幫助下在servicemanager中獲取到service 中binder 的引用，從而跨進程通信

1.通過上述的工作流程可知，servicemanager 其實是一個特殊的進程，service 和 client 和 servicemanager 之間的通訊其實也是進程間的通訊，而這里的進程間通信其實也是使用的binder通信。這里的設計十分巧妙，servicemanager 是service 端，其他所有進程都是它的client 端，servicemanager提供了一個非常特殊的binder，他不需要注冊也沒有名字，其他進程可以直接獲取到該binder 和servicemanager 進行通訊。

2.binder中還使用了代理模式，client 端所獲取的service 的binder引用並不是一個真的binder對象，而是一個service端binder 的代理，調用binder中方法的時候通過對service進行請求然後獲取返回結果。

android binder通信機制其實可以看作是一次簡單的上網過程

1.客戶端輸入網址（發送端請求跨進程通信）
2.通過路由器查詢dns 伺服器 根據域名獲取ip地址（通過binder驅動，獲取servicemanager 中實名binder的引用）
3.根據返回的ip地址，通過路由器連接伺服器（根據獲取到service端的binder 代理 client端和service端進行通信 ）

『貳』 為什麼 Android 要採用 Binder 作為 IPC 機制

一）從性能的角度 數據拷貝次數：Binder數據拷貝只需要一次，而管道、消息隊列、Socket都需要二次，但共享內存方式一次內存拷貝都不需要；從性能角度看，Binder性能僅次於共享內存。 （二）從穩定性的角度 Binder是基於C/S架構的，簡單解釋下C/S架構，是指客戶端(Client)和服務端(Server)組成的架構，Client端有什麼需求，直接發送給Server端去完成，架構清晰明朗，Server端與Client端相對獨立，穩定性較好；而共享內存實現方式復雜，沒有客戶與服務端之別， 需要充分考慮到訪問臨界資源的並發同步問題，否則可能會出現死鎖等問題；從這穩定性角度看，Binder架構優越於共享內存。 僅僅從以上兩點，各有優劣，還不足以支撐google去採用binder的IPC機制，那麼更重要的原因是： （三）從安全的角度 傳統Linux IPC的接收方無法獲得對方進程可靠的UID/PID，從而無法鑒別對方身份；而Android作為一個開放的開源體系，擁有非常多的開發平台，App來源甚廣，因此手機的安全顯得額外重要；對於普通用戶，絕不希望從App商店下載偷窺隱射數據、後台造成手機耗電等等問題，傳統Linux IPC無任何保護措施，完全由上層協議來確保。 Android為每個安裝好的應用程序分配了自己的UID，故進程的UID是鑒別進程身份的重要標志，前面提到C/S架構，Android系統中對外只暴露Client端，Client端將任務發送給Server端，Server端會根據許可權控制策略，判斷UID/PID是否滿足訪問許可權，目前許可權控制很多時候是通過彈出許可權詢問對話框，讓用戶選擇是否運行。Android 陸.0，也稱為Android M，在陸.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 陸.0，google對於app的許可權問題作為較多的努力，大大收緊的應用許可權；另外，在Google舉辦的Android Bootcamp 二0一陸大會中，google也表示在Android 漆.0 （也叫Android N）的許可權隱私方面會進一步加強加固，比如SELinux，Memory safe language(還在research中)等等，在今年的5月一吧日至5月二0日，google將推出Android N。 （四）從語言層面的角度 大家多知道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-二.0協議（允許基於Android的開發商不向社區反饋源碼），同時在GPL協議與Apache-二.0之間的Lib庫中採用BSD證授權方法，有效隔斷了GPL的傳染性，仍有較大爭議，但至少目前緩解Android，讓GPL止步於內核空間，這是Google在GPL Linux下 開源與商業化共存的一個成功典範

『叄』 為什麼Android要採用Binder作為IPC機制

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 要採用 Binder 作為 IPC 機制

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 要採用 Binder 作為 IPC 機制

哦哦哦

『陸』 為什麼 Android 要採用 Binder 作為 IPC 機制

1）從性能的角度
數據拷貝次數：Binder數據拷貝只需要一次，而管道、消息隊列、Socket都需要2次，但共享內存方式一次內存拷貝都不需要；從性能角度看，Binder性能僅次於共享內存。

（2）從穩定性的角度
Binder是基於C/S架構的，簡單解釋下C/S架構，是指客戶端(Client)和服務端(Server)組成的架構，Client端有什麼需求，直接發送給Server端去完成，架構清晰明朗，Server端與Client端相對獨立，穩定性較好；而共享內存實現方式復雜，沒有客戶與服務端之別， 需要充分考慮到訪問臨界資源的並發同步問題，否則可能會出現死鎖等問題；從這穩定性角度看，Binder架構優越於共享內存。

僅僅從以上兩點，各有優劣，還不足以支撐google去採用binder的IPC機制，那麼更重要的原因是：

（3）從安全的角度

『柒』 為什麼 Android 要採用 Binder 作為 IPC 機制

1）從性能的角度數據拷貝次數：Binder數據拷貝只需要一次，而管道、消息隊列、Socket都需要2次，但共享內存方式一次內存拷貝都不需要；從性能角度看，Binder性能僅次於共享內存。（2）從穩定性的角度Binder是基於C/S架構的，簡單解釋下C/S架構，是指客戶端(Client)和服務端(Server)組成的架構，Client端有什麼需求，直接發送給Server端去完成，架構清晰明朗，Server端與Client端相對獨立，穩定性較好；而共享內存實現方式復雜，沒有客戶與服務端之別，需要充分考慮到訪問臨界資源的並發同步問題，否則可能會出現死鎖等問題；從這穩定性角度看，Binder架構優越於共享內存。僅僅從以上兩點，各有優劣，還不足以支撐google去採用binder的IPC機制，那麼更重要的原因是：（3）從安全的角度傳統LinuxIPC的接收方無法獲得對方進程可靠的UID/PID，從而無法鑒別對方身份；而Android作為一個開放的開源體系，擁有非常多的開發平台，App來源甚廣，因此手機的安全顯得額外重要；對於普通用戶，絕不希望從App商店下載偷窺隱射數據、後台造成手機耗電等等問題，傳統LinuxIPC無任何保護措施，完全由上層協議來確保。Android為每個安裝好的應用程序分配了自己的UID，故進程的UID是鑒別進程身份的重要標志，前面提到C/S架構，Android系統中對外只暴露Client端，Client端將任務發送給Server端，Server端會根據許可權控制策略，判斷UID/PID是否滿足訪問許可權，目前許可權控制很多時候是通過彈出許可權詢問對話框，讓用戶選擇是否運行。Android6.0，也稱為AndroidM，在6.0之前的系統是在App第一次安裝時，會將整個App所涉及的所有許可權一次詢問，只要留意看會發現很多App根本用不上通信錄和簡訊，但在這一次性許可權許可權時會包含進去，讓用戶拒絕不得，因為拒絕後App無法正常使用，而一旦授權後，應用便可以胡作非為。針對這個問題，google在AndroidM做了調整，不再是安裝時一並詢問所有許可權，而是在App運行過程中，需要哪個許可權再彈框詢問用戶是否給相應的許可權，對許可權做了更細地控制，讓用戶有了的可控性，但同時也帶來了另一個用戶詬病的地方，那也就是許可權詢問的彈框的次數大幅度增多。對於AndroidM平台上，有些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以及各大手機廠商一直努力改善的地方之一。在Android6.0，google對於app的許可權問題作為較多的努力，大大收緊的應用許可權；另外，在Google舉的AndroidBootcamp2016大會中，google也表示在Android7.0（也叫AndroidN）的許可權隱私方面會進一步加強加固，比如SELinux，Memorysafelanguage(還在research中)等等，在今年的5月18日至5月20日，google將推出AndroidN。（4）從語言層面的角度大家多知道Linux是基於C語言(面向過程的語言)，而Android是基於Java語言(面向對象的語句)，而對於Binder恰恰也符合面向對象的思想，將進程間通信轉化為通過對某個Binder對象的引用調用該對象的方法，而其獨特之處在於Binder對象是一個可以跨進程引用的對象，它的實體位於一個進程中，而它的引用卻遍布於系統的各個進程之中。可以從一個進程傳給其它進程，讓大家都能訪問同一Server，就像將一個對象或引用賦值給另一個引用一樣。Binder模糊了進程邊界，淡化了進程間通信過程，整個系統彷彿運行於同一個面向對象的程序之中。從語言層面，Binder更適合基於面向對象語言的Android系統，對於Linux系統可能會有點「水土不服」。另外，Binder是為Android這類系統而生，而並非Linux社區沒有想到BinderIPC機制的存在，對於Linux社區的廣大開發人員，我還是表示深深佩服，讓世界有了如此精湛而美妙的開源系統。也並非Linux現有的IPC機制不夠好，相反地，經過這么多優秀工程師的不斷打磨，依然非常優秀，每種Linux的IPC機制都有存在的價值，同時在Android系統中也依然採用了大量Linux現有的IPC機制，根據每類IPC的原理特性，因時制宜，不同場景特性往往會採用其下最適宜的。比如在AndroidOS中的Zygote進程的IPC採用的是Socket（套接字）機制，Android中的KillProcess採用的signal（信號）機制等等。而Binder則用在system_server進程與上層App層的IPC交互。(5)從公司戰略的角度總所周知，Linux內核是開源的系統，所開放源代碼許可協議GPL保護，該協議具有「病毒式感染」的能力，怎麼理解這句話呢？受GPL保護的LinuxKernel是運行在內核空間，對於上層的任何類庫、服務、應用等運行在用戶空間，一旦進行SysCall（系統調用），調用到底層Kernel，那麼也必須遵循GPL協議。而Android之父AndyRubin對於GPL顯然是不能接受的，為此，Google巧妙地將GPL協議控制在內核空間，將用戶空間的協議採用Apache-2.0協議（允許基於Android的開發商不向社區反饋源碼），同時在GPL協議與Apache-2.0之間的Lib庫中採用BSD證授權方法，有效隔斷了GPL的傳染性，仍有較大爭議，但至少目前緩解Android，讓GPL止步於內核空間，這是Google在GPLLinux下開源與商業化共存的一個成功典範。