Android中的常見通訊機制和Linux中的通訊機制

標籤：cat   內容   位置   使用者   優點   對象   nat   ESS   訪問共用   

Handler

Handler是Android系統中的一種訊息傳遞機制，起作用是應對多線程情境。將A進程的訊息傳遞給B線程，實現非同步訊息處理。很多情況是將背景工作執行緒中需要更新UI的操作訊息傳遞給UI主線程，而實現更新UI操作。
因為背景工作執行緒和主線程是共用地址空間，即Handler執行個體對象mHandler位於線程間共用的記憶體堆上，背景工作執行緒和主線程直接使用該對象，只需要注意多線程的同步問題。工作系統通過mHandler向其成員變數MessageQueue中添加Message，而主線程一直處於loop中，當收到新的message時，按照一定規則分發給相應的handlerMessage方法來處理。
Handler用於同進程的線程間通訊的核心是線程間共用記憶體空間，而不同矜持擁有不同的地址空間，也就無法使用handler來實現處理序間通訊。1所示，為Handler訊息通訊架構圖。
圖中，首先Handler通過sendMessage()發送Message到MessageQueue隊列，Looper通過looper()不斷提取出達到觸發條件的Message，並將Message交給target來處理；然後通過displatchMessage()分發給handlerMessage處理。
將Message添加到MessageQueue時，會往管道中寫入字元，這樣就回喚醒loop線程；如果MessageQueue中沒有Message，並處理idle狀態，則會執行idleHandler介面中的方法，往往用於做一些清理性的工作。關於訊息分發的優先順序：

• Message回調分發：message callback.run()優先順序最高。
• Handler回調分發：Handler.mCallback.handleMesage(msg)，優先順序次之。
• Handler預設分發：Handler.handlerMessage(msg)，優先順序最低。

Binder概述

Android中一般每個應用對於一個進程，而涉及到每個應用之間的通訊，即處理序間通訊，Android中採用的最多的IPC機製為Binder機制。首先我們介紹下IPC機制原理，2所示為從進程角度闡述了IPC機制。可以看出，每個Android進程只能運行在自己所有的虛擬位址空間中。對於一個4G的虛擬位址空間，假設使用者空間為3G，核心空間為1G（可修改）。進程在使用者空間的資料是不可共用的，在記憶體空間中則可共用。Client進程想server進程發送資訊，即利用核心空間可共用機制完成。

• 從IPC角度：Binder是Android中的一種跨進程通訊方法，該方法是Android系統專屬的。
• 從Android Driver層：Binder還可以理解為一種虛擬物理裝置，裝置驅動為/dev/binder。
• 從Android native層：Binder是建立Service Manager以及BpBinder/BBinder模型，大家與Binder驅動的橋樑。
• 從Android frameworks層：Binder是各種Manager（ActivityManager、WindowManager）和相應xxxManagerService的橋樑。
• 從APP層：Binder是用戶端和服務端進程通訊的媒介，當bindServicer時，服務端會返回一個包含了服務端業務調用的Binder對象，通過這個Binder對象，用戶端就可以獲得服務端提供的服務（包括普通服務和基於AIDL的服務）或資料。

架構

3所示，為Binder在Android不同層級的位置和關聯圖，是一種C/S架構的通訊機制。在Kernel層，Binder可以看成是一個驅動，其驅動架構與其他驅動相同。Native層中ServiceManager會啟動一個Binder的守護進程，ServiceManager功能簡單，包括擷取服務、註冊服務，大部分同行通過都存在於BpBinder和BBinder之間。Framework層的Binder邏輯是建立在Native層架構基礎上的，核心邏輯都是交給Native層來處理。但需要注意下frameworks層的Binder邏輯是建立在Native層架構基礎上的，核心邏輯都是交給Native層來處理。但需要注意下frameworks層的ServiceManager和Native層的ServiceManager功能並不對應，其最終實現是通過BinderProxy傳遞給Native層來完成的。

Socket

Socket通訊也是基於C/S架構，但相比Binder要簡單一些。首先我們來回顧下TCP/IP協議的知識。TCP/IP協議是一個四層的體繫結構：應用程式層、傳輸層、網路層、網路介面層。在傳輸層中又有TCP和UDP兩個協議。Socket是工作與TCP/IP協議中應用程式層和傳輸層之間的一種抽象。Android系統中，又分為流通訊端和資料通訊端。其中流通訊端將TCP協議作為其端對端協議，提供了一個可信賴的位元組流是服務；資料通訊端使用UDP協議，提供資料打包發送服務。在Android系統中使用Socket通訊的情境包括：

• Zygote：fork新進程，system_server向zygote發送fork新進程請求是使用socket通訊。
• Installd：使用者安裝app的守護進程，PMS安裝應用時向installd發送socket通訊來完成安裝過程。
• Adbd：用於服務adb操作。
• Logcatd：用於服務logcat操作
• Vold：儲存類守護進程，用於服務USD、sdcard等存放裝置的事件處理。（在Android9.0中已將這一進程通訊修改為Binder實現）

其他幾種通訊機制管道

Linux支援的最初Unix IPC機制之一，特點是：

• 管道是半雙工，資料只能向一個方向流動，需要雙方通訊時，建議使用兩個管道。
• 只能用於父子進程或者兄弟進程之間。
• 單獨構成一種獨立的檔案系統：管道對於管道兩端的進程而言，就是一個檔案，但它不是普通檔案，它不屬於某種檔案系統，而是自立門戶，單獨構成一種檔案系統，並且每次都是從緩衝區都不讀出資料。
• 資料讀出和寫入；一個進程向管道中寫的內容被管道另一端的進程讀出。寫入的內容每次都添加在管道緩衝區的末尾，並且每次都是從緩衝區頭部讀出資料。

訊息佇列

訊息佇列提供了一種從一個進程向另一個進程發送一個資料區塊的方法。每個資料區塊都被認為含有一個類型，接受進程可以獨立地接受含有不同類型的資料結構。通過發送訊息來避免明明管道的同步和阻塞問題。訊息佇列發送的訊息有最大長度限制。

共用記憶體

共用記憶體，顧名思義即允許兩個不相關的進程訪問同一個邏輯記憶體。共用記憶體是在兩個正在啟動並執行進程之間共用和傳遞的一種非常有效方法。不同進程之間共用的記憶體通常安排為同一段實體記憶體。進程可以講同一段共用記憶體連結到他們自己的地址空間中。所有進程都可以訪問共用記憶體中的地址。
需要注意的是：共用記憶體沒有使用同步機制，即進程A對共用記憶體進程寫操作時，並沒有對共用記憶體加鎖，進程B仍然可以讀取共用記憶體中的資料。所以通常我們需要使用其他的機制來同步共用記憶體的訪問。

訊號量

為了防止出現多個進程同步訪問一個共用資源而引發一系列問題，我們需要一種方法，它可以通常產生令牌來授權，在任何時刻只能有一個指向線程存取碼的臨界地區。臨界地區是指執行資料更新的代碼需要獨佔式執行。而訊號量就可以提供這樣的一種訪問機制，也就是說訊號量是用來協調進程對資源共用的訪問。
訊號量是一個特殊變數，程式對其訪問都是原子操作，且只允許對它進程等待和發送資訊操作。最簡單的訊號量是只能取0和1的變數。這也是訊號量最常見的形式。這就是二進位訊號量。而中可以取多個正整數的訊號量稱為通用訊號量。

訊號

訊號是UNIX和Linux系統響應某些條件而產生的一個事件，接收到該訊號的進程會響應地採取一些行動。通常訊號是由一個錯誤產生的。但他們還可以作為處理序間通訊或修改行為的一種形式，明確地由一個進程發送給另一個進程。訊號產生叫做產生，接收叫做訊號捕獲。

Android中幾種IPC機制對比

名稱	優點	缺點	適用情境
Bundle	簡單易用	只能傳輸Bundle支援的資料類型	組件間處理序間通訊
檔案分享權限設定	簡單易用	不適合并發情境，並且無法做到進程間即時通訊	無並發訪問情形，交換簡單資料即時性不高的情境
AIDL	功能強大，支援一對多並發通訊，支援即時通訊	使用複雜，需要處理好線程同步	一對多通訊且有RPC需求
Message	功能一般，支援一對多串列通訊，支援即時通訊	不能很好處理高並發情境，不支援RPC，資料通過Message進程傳輸，因此只能傳輸Bundle支援的資料類型	低並發的一對多即時通訊，無RPC需求，或者無需要返回結果的RPC需求
ContentProvider	在資料訪問方面功能強大，支援一對多並發資料共用，可通過Call方法擴充其他動作	可以理解為受約束AIDL，主要提供資料來源的CRUD操作	對多進程間的資料共用
socket	功能強大，可以使用網路傳輸位元組流，支援一對多並發即時通訊	實現細節稍微有點繁瑣，不支援直接RPC	網路資料交換，或少數進程間交換

Android中的常見通訊機制和Linux中的通訊機制