android的通信機制

❶ 在android中進程間通信機制是怎樣的

一般都是基於ARM處理器的吧 安卓的內核也是基於linux的吧。 網路實現依靠TCP/IP協議棧實現實行封包和解包以及連接的建立和控制，還涉及到你手機的硬體網卡等。 進程間通信方式一般採用的消息隊列，共享內存，套接字，還有管道了。 多線程是由操作系統來管理每個線程的CPU時間和資源的分配。也是比較復雜的，涉及到線程間通信，線程同步等。 內存管理是由操作系統進行分段，分頁。分配機制比較復雜的，涉及到碎片的減少，內存的回收等。 要想了解詳細內容，可以看看Linux操作系統原理。或者google提供的相關文檔。

❷ android 進程間的通信(IPC)方式有哪些

Android為了屏蔽進程的概念，利用不同的組件[Activity、Service]來表示進程之間的通信！組件間通信的核心機制是Intent，通過Intent可以開啟一個Activity或Service，不論這個Activity或Service是屬於當前應用還是其它應用的。
一、Intent包含兩部分：
1、目的[action]--要往哪裡去
2、內容[category、data]--路上帶了些什麼，區分性數據或內容性數據
二、Intent類型：
1、顯式--直接指定消息目的地，只適合同一進程內的不同組件之間通信
new Intent(this,Target.class)
2、隱式--AndroidMainifest.xml中注冊，一般用於跨進程通信
new Intent(String action)

IPC機制：有了Intent這種基於消息的進程內或進程間通信模型，我們就可以通過Intent去開啟一個Service，可以通過Intent跳轉到另一個Activity，不論上面的Service或Activity是在當前進程還是其它進程內即不論是當前應用還是其它應用的Service或Activity，通過消息機制都可以進行通信！

❸ android開發中跨進程通信有幾種方式

Android進程間通信的幾種方式 定義多進程
第一：Android應用中使用多進程只有一個辦法（用NDK的fork來做除外），就是在AndroidManifest.xml中聲明組件時，用android:process屬性來指定。
不知定process屬性，則默認運行在主進程中，主進程名字為包名。
android:process = package:remote，將運行在package:remote進程中，屬於全局進程，其他具有相同shareUID與簽名的APP可以跑在這個進程中。
android:process = :remote ，將運行在默認包名:remote進程中，而且是APP的私有進程，不允許其他APP的組件來訪問。
第二：多進程引發的問題
靜態成員和單例失效：每個進程保持各自的靜態成員和單例，相互獨立。
線程同步機制失效：每個進程有自己的線程鎖。
SharedPreferences可靠性下降：不支持並發寫，會出現臟數據。
Application多次創建：不同進程跑在不同虛擬機，每個虛擬機啟動會創建自己的Application，自定義Application時生命周期會混亂。
綜上，不同進程擁有各自獨立的虛擬機，Application，內存空間，由此引發一系列問題。
第三： 進程間通信
Bundle/Intent傳遞數據：
可傳遞基本類型，String，實現了Serializable或Parcellable介面的數據結構。Serializable是java的序列化方法，Parcellable是Android的序列化方法，前者代碼量少（僅一句），但I/O開銷較大，一般用於輸出到磁碟或網卡；後者實現代碼多，效率高，一般用戶內存間序列化和反序列化傳輸。
文件共享：
對同一個文件先後寫讀，從而實現傳輸，Linux機制下，可以對文件並發寫，所以要注意同步。順便一提，Windows下不支持並發讀或寫。
Messenger：
Messenger是基於AIDL實現的，服務端（被動方）提供一個Service來處理客戶端（主動方）連接，維護一個Handler來創建Messenger，在onBind時返回Messenger的binder。
雙方用Messenger來發送數據，用Handler來處理數據。Messenger處理數據依靠Handler，所以是串列的，也就是說，Handler接到多個message時，就要排隊依次處理。
AIDL：
AIDL通過定義服務端暴露的介面，以提供給客戶端來調用，AIDL使伺服器可以並行處理，而Messenger封裝了AIDL之後只能串列運行，所以Messenger一般用作消息傳遞。
通過編寫aidl文件來設計想要暴露的介面，編譯後會自動生成響應的java文件，伺服器將介面的具體實現寫在Stub中，用iBinder對象傳遞給客戶端，客戶端bindService的時候，用asInterface的形式將iBinder還原成介面，再調用其中的方法。
ContentProvider：
系統四大組件之一，底層也是Binder實現，主要用來為其他APP提供數據，可以說天生就是為進程通信而生的。自己實現一個ContentProvider需要實現6個方法，其中onCreate是主線程中回調的，其他方法是運行在Binder之中的。自定義的ContentProvider注冊時要提供authorities屬性，應用需要訪問的時候將屬性包裝成Uri.parse("content://authorities")。還可以設置permission，readPermission，writePermission來設置許可權。 ContentProvider有query，delete，insert等方法，看起來貌似是一個資料庫管理類，但其實可以用文件，內存數據等等一切來充當數據源，query返回的是一個Cursor，可以自定義繼承AbstractCursor的類來實現。
Socket：
學過計算機網路的對Socket不陌生，所以不需要詳細講述。只需要注意，Android不允許在主線程中請求網路，而且請求網路必須要注意聲明相應的permission。然後，在伺服器中定義ServerSocket來監聽埠，客戶端使用Socket來請求埠，連通後就可以進行通信。

❹ android線程間通信有哪些方式

進程：是具有一定獨立功能的程序關於某個數據集合上的一次運行活動，進程是系統進行資源分配和調度的一個獨立單位。
  線程：是進程的一個實體,是CPU調度和分派的基本單位,它是比進程更小的能獨立運行的基本單位。線程自己基本上不擁有系統資源,只擁有一些在運行中必不可少的資源(如程序計數器,一組寄存器和棧)，但是它可與同屬一個進程的其他的線程共享進程所擁有的全部資源。
  區別：
  （1）、一個程序至少有一個進程，一個進程至少有一個線程；
  （2）、線程的劃分尺度小於進程，使得多線程程序的並發性高；
  （3）、進程在執行過程中擁有獨立的內存單元，而多個線程共享內存，但線程之間沒有單獨的地址空間，一個線程死掉就等於整個進程死掉。
---------------------
一、Android進程間通信方式
1.Bundle
  由於Activity，Service，Receiver都是可以通過Intent來攜帶Bundle傳輸數據的，所以我們可以在一個進程中通過Intent將攜帶數據的Bundle發送到另一個進程的組件。
  缺點：無法傳輸Bundle不支持的數據類型。
2.ContentProvider
  ContentProvider是Android四大組件之一，以表格的方式來儲存數據，提供給外界，即Content Provider可以跨進程訪問其他應用程序中的數據。用法是繼承ContentProvider，實現onCreate,query,update,insert,delete和getType方法，onCreate是負責創建時做一些初始化的工作，增刪查改的方法就是對數據的查詢和修改，getType是返回一個String，表示Uri請求的類型。注冊完後就可以使用ContentResolver去請求指定的Uri。
3.文件
  兩個進程可以到同一個文件去交換數據，我們不僅可以保存文本文件，還可以將對象持久化到文件，從另一個文件恢復。要注意的是，當並發讀/寫時可能會出現並發的問題。
4.Broadcast
  Broadcast可以向android系統中所有應用程序發送廣播，而需要跨進程通訊的應用程序可以監聽這些廣播。
5.AIDL方式
  Service和Content Provider類似，也可以訪問其他應用程序中的數據，Content Provider返回的是Cursor對象，而Service返回的是Java對象，這種可以跨進程通訊的服務叫AIDL服務。
AIDL通過定義服務端暴露的介面，以提供給客戶端來調用，AIDL使伺服器可以並行處理，而Messenger封裝了AIDL之後只能串列運行，所以Messenger一般用作消息傳遞。
6.Messenger
  Messenger是基於AIDL實現的，服務端（被動方）提供一個Service來處理客戶端（主動方）連接，維護一個Handler來創建Messenger，在onBind時返回Messenger的binder。
  雙方用Messenger來發送數據，用Handler來處理數據。Messenger處理數據依靠Handler，所以是串列的，也就是說，Handler接到多個message時，就要排隊依次處理。
7.Socket
  Socket方法是通過網路來進行數據交換，注意的是要在子線程請求，不然會堵塞主線程。客戶端和服務端建立連接之後即可不斷傳輸數據，比較適合實時的數據傳輸
二、Android線程間通信方式
  一般說線程間通信主要是指主線程（也叫UI線程）和子線程之間的通信，主要有以下兩種方式：
1.AsyncTask機制
  AsyncTask，非同步任務，也就是說在UI線程運行的時候，可以在後台的執行一些非同步的操作；AsyncTask可以很容易且正確地使用UI線程，AsyncTask允許進行後台操作，並在不顯示使用工作線程或Handler機制的情況下，將結果反饋給UI線程。但是AsyncTask只能用於短時間的操作（最多幾秒就應該結束的操作），如果需要長時間運行在後台，就不適合使用AsyncTask了，只能去使用Java提供的其他API來實現。
2.Handler機制
  Handler，繼承自Object類，用來發送和處理Message對象或Runnable對象；Handler在創建時會與當前所在的線程的Looper對象相關聯(如果當前線程的Looper為空或不存在，則會拋出異常，此時需要在線程中主動調用Looper.prepare()來創建一個Looper對象)。使用Handler的主要作用就是在後面的過程中發送和處理Message對象和讓其他的線程完成某一個動作（如在工作線程中通過Handler對象發送一個Message對象，讓UI線程進行UI的更新，然後UI線程就會在MessageQueue中得到這個Message對象（取出Message對象是由其相關聯的Looper對象完成的），並作出相應的響應）。
三、Android兩個子線程之間通信
  面試的過程中，有些面試官可能會問Android子線程之間的通信方式，由於絕大部分程序員主要關注的是Android主線程和子線程之間的通信，所以這個問題很容易讓人懵逼。
  主線程和子線程之間的通信可以通過主線程中的handler把子線程中的message發給主線程中的looper，或者，主線程中的handler通過post向looper中發送一個runnable。但looper默認存在於main線程中，子線程中沒有Looper，該怎麼辦呢？其實原理很簡單，把looper綁定到子線程中，並且創建一個handler。在另一個線程中通過這個handler發送消息，就可以實現子線程之間的通信了。
  子線程創建handler的兩種方式：
  方式一：給子線程創建Looper對象：
new Thread(new Runnable() {
public void run() {
Looper.prepare(); // 給這個Thread創建Looper對象，一個Thead只有一個Looper對象
Handler handler = new Handler(){
@Override
public void handleMessage(Message msg) {
Toast.makeText(getApplicationContext(), "handleMessage", Toast.LENGTH_LONG).show();
}
};
handler.sendEmptyMessage(1);
Looper.loop(); // 不斷遍歷MessageQueue中是否有消息
};
}).start();
---------------------
方式二：獲取主線程的looper，或者說是UI線程的looper：
new Thread(new Runnable() {
public void run() {
Handler handler = new Handler(Looper.getMainLooper()){ // 區別在這！！！
@Override
public void handleMessage(Message msg) {
Toast.makeText(getApplicationContext(), "handleMessage", Toast.LENGTH_LONG).show();
}
};
handler.sendEmptyMessage(1);
};
}).start();

❺ android 四大組件是怎麼通訊的

底層採用tcp/ip協議通訊，各個模塊之間是弱耦合

❻ Android伺服器通信的幾種方式詳解

大 學學習網路基礎的時候老師講過，網路由下往上分為物理層、數據鏈路層、網路層、傳輸層、會話層、表示層和應用層。通過初步的了解，我知道IP協議對應於網 絡層，TCP協議對應於傳輸層，而HTTP協議對應於應用層，三者從本質上來說沒有可比性，socket則是對TCP/IP協議的封裝和應用（程序員層面 上）。也可以說，TPC/IP協議是傳輸層協議，主要解決數據如何在網路中傳輸，而HTTP是應用層協議，主要解決如何包裝數據。關於TCP/IP和 HTTP協議的關系，網路有一段比較容易理解的介紹： 「我們在傳輸數據時，可以只使用（傳輸層）TCP/IP協議，但是那樣的話，如果沒有應用層，便無法識別數據內容，如果想要使傳輸的數據有意義，則必須使 用到應用層協議，應用層協議有很多，比如HTTP、FTP、TELNET等，也可以自己定義應用層協議。WEB使用HTTP協議作應用層協議，以封裝 HTTP文本信息，然後使用TCP/IP做傳輸層協議將它發到網路上。」
而我們平時說的最多的socket是什麼呢，實際上socket是對TCP/IP協議的封裝，Socket本身並不是協議，而是一個調用介面（API）， 通過Socket，我們才能使用TCP/IP協議。實際上，Socket跟TCP/IP協議沒有必然的聯系。Socket編程介面在設計的時候，就希望也 能適應其他的網路協議。所以說，Socket的出現只是使得程序員更方便地使用TCP/IP協議棧而已，是對TCP/IP協議的抽象，從而形成了我們知道 的一些最基本的函數介面，比如create、listen、connect、accept、send、read和write等等。網路有一段關於 socket和TCP/IP協議關系的說法比較容易理解：「TCP/IP只是一個協議棧，就像操作系統的運行機制一樣，必須要具體實現，同時還要提供對外 的操作介面。這個就像操作系統會提供標準的編程介面，比如win32編程介面一樣，TCP/IP也要提供可供程序員做網路開發所用的介面，這就是 Socket編程介面。」
關於TCP/IP協議的相關只是，用博大精深來講我想也不為過，單單查一下網上關於此類只是的資料和書籍文獻的數量就知道，這個我打算會買一些經典的書籍 （比如《TCP/IP詳解：卷一、卷二、卷三》）進行學習，今天就先總結一些基於基於TCP/IP協議的應用和編程介面的知識，也就是剛才說了很多的 HTTP和Socket。
CSDN上有個比較形象的描述：HTTP是轎車，提供了封裝或者顯示數據的具體形式；Socket是發動機，提供了網路通信的能力。
實際上，傳輸層的TCP是基於網路層的IP協議的，而應用層的HTTP協議又是基於傳輸層的TCP協議的，而Socket本身不算是協議，就像上面所說，它只是提供了一個針對TCP或者UDP編程的介面。
下面是一些經常在筆試或者面試中碰到的重要的概念，特在此做摘抄和總結。
一。什麼是TCP連接的三次握手
第一次握手：客戶端發送syn包(syn=j)到伺服器，並進入SYN_SEND狀態，等待伺服器確認；
第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；
第三次握手：客戶端收到伺服器的SYN＋ACK包，向伺服器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手。
握手過程中傳送的包里不包含數據，三次握手完畢後，客戶端與伺服器才正式開始傳送數據。理想狀態下，TCP連接一旦建立，在通信雙方中的任何一方主動關閉 連接之前，TCP 連接都將被一直保持下去。斷開連接時伺服器和客戶端均可以主動發起斷開TCP連接的請求，斷開過程需要經過「四次握手」（過程就不細寫了，就是伺服器和客 戶端交互，最終確定斷開）
二。利用Socket建立網路連接的步驟
建立Socket連接至少需要一對套接字，其中一個運行於客戶端，稱為ClientSocket ，另一個運行於伺服器端，稱為ServerSocket 。
套接字之間的連接過程分為三個步驟：伺服器監聽，客戶端請求，連接確認。
1。伺服器監聽：伺服器端套接字並不定位具體的客戶端套接字，而是處於等待連接的狀態，實時監控網路狀態，等待客戶端的連接請求。
2。客戶端請求：指客戶端的套接字提出連接請求，要連接的目標是伺服器端的套接字。為此，客戶端的套接字必須首先描述它要連接的伺服器的套接字，指出伺服器端套接字的地址和埠號，然後就向伺服器端套接字提出連接請求。
3。 連接確認：當伺服器端套接字監聽到或者說接收到客戶端套接字的連接請求時，就響應客戶端套接字的請求，建立一個新的線程，把伺服器端套接字的描述發給客戶 端，一旦客戶端確認了此描述，雙方就正式建立連接。而伺服器端套接字繼續處於監聽狀態，繼續接收其他客戶端套接字的連接請求。
三。HTTP鏈接的特點
HTTP協議即超文本傳送協議(Hypertext Transfer Protocol )，是Web聯網的基礎，也是手機聯網常用的協議之一，HTTP協議是建立在TCP協議之上的一種應用。
HTTP連接最顯著的特點是客戶端發送的每次請求都需要伺服器回送響應，在請求結束後，會主動釋放連接。從建立連接到關閉連接的過程稱為「一次連接」。
四。TCP和UDP的區別（考得最多。。快被考爛了我覺得- -\\）
1。 TCP是面向鏈接的，雖然說網路的不安全不穩定特性決定了多少次握手都不能保證連接的可靠性，但TCP的三次握手在最低限度上（實際上也很大程度上保證 了）保證了連接的可靠性；而UDP不是面向連接的，UDP傳送數據前並不與對方建立連接，對接收到的數據也不發送確認信號，發送端不知道數據是否會正確接 收，當然也不用重發，所以說UDP是無連接的、不可靠的一種數據傳輸協議。
2。也正由於1所說的特點，使得UDP的開銷更小數據傳輸速率更高，因為不必進行收發數據的確認，所以UDP的實時性更好。
知 道了TCP和UDP的區別，就不難理解為何採用TCP傳輸協議的MSN比採用UDP的QQ傳輸文件慢了，但並不能說QQ的通信是不安全的，因為程序員可以 手動對UDP的數據收發進行驗證，比如發送方對每個數據包進行編號然後由接收方進行驗證啊什麼的，即使是這樣，UDP因為在底層協議的封裝上沒有採用類似 TCP的「三次握手」而實現了TCP所無法達到的傳輸效率。

❼ Android中線程與線程，進程與進程之間如何通信

使用handler發送message,消息隊列排隊

進程是一個具有獨立功能的程序關於某個數據集合的一次運行活動。它可以申請和擁有系統資源，是一個動態的概念，是一個活動的實體。它不只是程序的代碼，還包括當前的活動，通過程序計數器的值和處理寄存器的內容來表示。
進程是一個「執行中的程序」。程序是一個沒有生命的實體，只有處理器賦予程序生命時，它才能成為一個活動的實體，我們稱其為進程。
通常在一個進程中可以包含若干個線程，它們可以利用進程所擁有的資源。在引入線程的操作系統中，通常都是把進程作為分配資源的基本單位，而把線程作為獨立運行和獨立調度的基本單位。由於線程比進程更小，基本上不擁有系統資源，故對它的調度所付出的開銷就會小得多，能更高效的提高系統內多個程序間並發執行的程度。
線程和進程的區別在於，子進程和父進程有不同的代碼和數據空間，而多個線程則共享數據空間，每個線程有自己的執行堆棧和程序計數器為其執行上下文。多線程主要是為了節約CPU時間，發揮利用，根據具體情況而定。線程的運行中需要使用計算機的內存資源和CPU。

❽ Android 進程間通信的幾種實現方式

Android 進程間通信的幾種實現方式

主要有4種方式：

這4種方式正好對應於android系統中4種應用程序組件：Activity、Content Provider、Broadcast和Service。

主要實現原理：

由於應用程序之間不能共享內存。為了在不同應用程序之間交互數據（跨進程通訊），AndroidSDK中提供了4種用於跨進程通訊的方式進行交互數據，實現進程間通信主要是使用sdk中提供的4組組件根據實際開發情況進行實現數據交互。

詳細實現方式：

Acitivity實現方式

Activity的跨進程訪問與進程內訪問略有不同。雖然它們都需要Intent對象，但跨進程訪問並不需要指定Context對象和Activity的 Class對象，而需要指定的是要訪問的Activity所對應的Action（一個字元串）。有些Activity還需要指定一個Uri（通過 Intent構造方法的第2個參數指定）。 在android系統中有很多應用程序提供了可以跨進程訪問的Activity，例如，下面的代碼可以直接調用撥打電話的Activity。

IntentcallIntent=newIntent(Intent.ACTION_CALL,Uri.parse("tel:12345678");
startActivity(callIntent);

Content Provider實現方式

Android應用程序可以使用文件或SqlLite資料庫來存儲數據。Content Provider提供了一種在多個應用程序之間數據共享的方式（跨進程共享數據）

應用程序可以利用Content Provider完成下面的工作

1. 查詢數據
2. 修改數據
3. 添加數據
4. 刪除數據

Broadcast 廣播實現方式

廣播是一種被動跨進程通訊的方式。當某個程序向系統發送廣播時，其他的應用程序只能被動地接收廣播數據。這就象電台進行廣播一樣，聽眾只能被動地收聽，而不能主動與電台進行溝通。在應用程序中發送廣播比較簡單。只需要調用sendBroadcast方法即可。該方法需要一個Intent對象。通過Intent對象可以發送需要廣播的數據。

Service實現方式

常用的使用方式之一：利用AIDL Service實現跨進程通信

這是我個人比較推崇的方式，因為它相比Broadcast而言，雖然實現上稍微麻煩了一點，但是它的優勢就是不會像廣播那樣在手機中的廣播較多時會有明顯的時延，甚至有廣播發送不成功的情況出現。

注意普通的Service並不能實現跨進程操作，實際上普通的Service和它所在的應用處於同一個進程中，而且它也不會專門開一條新的線程，因此如果在普通的Service中實現在耗時的任務，需要新開線程。

要實現跨進程通信，需要藉助AIDL(Android Interface Definition Language)。Android中的跨進程服務其實是採用C/S的架構，因而AIDL的目的就是實現通信介面。

總結

跨進程通訊這個方面service方式的通訊遠遠復雜於其他幾種通訊方式，實際開發中Activity、Content Provider、Broadcast和Service。4種經常用到，學習過程中要對沒種實現方式有一定的了解。

❾ 篇文章會先對照binder機制與linux的通信機制的區別，了解為什麼android會另起爐灶

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。

（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下 開源與商業化共存的一個成功典範。

❿ Android的IPC機制

IPC是內部進程通信的簡稱， 是共享」命名管道」的資源。Android中的IPC機制是為了讓Activity和Service之間可以隨時的進行交互，故在Android中該機制，只適用於Activity和Service之間的通信，類似於遠程方法調用，類似於C/S模式的訪問。通過定義AIDL介面文件來定義IPC介面。Servier端實現IPC介面，Client端調用IPC介面本地代理。