android通信機制

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

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

Ⅱ android中的進程通信和Binder機制

如果統觀Binder中的各個組成元素，就會驚奇的發現它和TCP/IP網路有很多相似之處：

首先Binder是android進程間通信的一種方式，
基本原理：binder定義了4個角色：client，server，serviceManager ，binder驅動
server會創建一個binder實體並起一個名字，然後將名字一塊以數據包的形式通過binder驅動發送給serviceManager ，通知servicemanager注冊一個名字為xx的Binder，然後client通過名字查詢到該Binder 的引用。

注意

Ⅲ Android跨進程通信

Android 為我們提供了以下幾種進程通信機制（供開發者使用的進程通信 API）對應的文章鏈接如下：

Android 進階：進程通信之 Binder 機制淺析
Android 進階：進程通信之 AIDL 解析

Ⅳ [Android源碼分析] － 非同步通信Handler機制

一、問題：在Android啟動後會在新進程里創建一個主線程，也叫UI線程（ 非線程安全 ）這個線程主要負責監聽屏幕點擊事件與界面繪制。當Application需要進行耗時操作如網路請求等，如直接在主線程進行容易發生ANR錯誤。所以會創建子線程來執行耗時任務，當子線程執行完畢需要通知UI線程並修改界面時，不可以直接在子線程修改UI，怎麼辦？

解決方法：Message Queue機制可以實現子線程與UI線程的通信。

該機制包括Handler、Message Queue、Looper。Handler可以把消息/ Runnable對象 發給Looper，由它把消息放入所屬線程的消息隊列中，然後Looper又會自動把消息隊列里的消息/Runnable對象 廣播 到所屬線程里的Handler，由Handler處理接收到的消息或Runnable對象。

1、Handler

每次創建Handler對象時，它會自動綁定到創建它的線程上。如果是主線程則默認包含一個Message Queue，否則需要自己創建一個消息隊列來存儲。

Handler是多個線程通信的信使。比如在線程A中創建AHandler，給它綁定一個ALooper，同時創建屬於A的消息隊列AMessageQueue。然後在線程B中使用AHandler發送消息給ALooper，ALooper會把消息存入到AMessageQueue，然後再把AMessageQueue廣播給A線程里的AHandler，它接收到消息會進行處理。從而實現通信。

2、Message Queue

在主線程里默認包含了一個消息隊列不需要手動創建。在子線程里，使用Looper.prepare()方法後，會先檢查子線程是否已有一個looper對象，如果有則無法創建，因為每個線程只能擁有一個消息隊列。沒有的話就為子線程創建一個消息隊列。

Handler類包含Looper指針和MessageQueue指針，而Looper里包含實際MessageQueue與當前線程指針。

下面分別就UI線程和worker線程講解handler創建過程：

首先，創建handler時，會自動檢查當前線程是否包含looper對象，如果包含，則將handler內的消息隊列指向looper內部的消息隊列，否則，拋出異常請求執行looper.prepare()方法。

 － 在 UI線程 中，系統自動創建了Looper 對象，所以，直接new一個handler即可使用該機制；

－ 在 worker線程 中，如果直接創建handler會拋出運行時異常－即通過查『線程－value』映射表發現當前線程無looper對象。所以需要先調用Looper.prepare()方法。在prepare方法里，利用ThreadLocal<Looper>對象為當前線程創建一個Looper（利用了一個Values類，即一個Map映射表，專為thread存儲value，此處為當前thread存儲一個looper對象）。然後繼續創建handler， 讓handler內部的消息隊列指向該looper的消息隊列（這個很重要，讓handler指向looper里的消息隊列，即二者共享同一個消息隊列，然後handler向這個消息隊列發送消息，looper從這個消息隊列獲取消息） 。然後looper循環消息隊列即可。當獲取到message消息，會找出message對象里的target，即原始發送handler，從而回調handler的handleMessage() 方法進行處理。

 － handler與looper共享消息隊列 ，所以handler發送消息只要入列，looper直接取消息即可。

 － 線程與looper映射表 ：一個線程最多可以映射一個looper對象。通過查表可知當前線程是否包含looper，如果已經包含則不再創建新looper。

5、基於這樣的機制是怎樣實現線程隔離的，即在線程中通信呢。 

核心在於 每一個線程擁有自己的handler、message queue、looper體系 。而 每個線程的Handler是公開 的。B線程可以調用A線程的handler發送消息到A的共享消息隊列去，然後A的looper會自動從共享消息隊列取出消息進行處理。反之一樣。

二、上面是基於子線程中利用主線程提供的Handler發送消息出去，然後主線程的Looper從消息隊列中獲取並處理。那麼還有另外兩種情況：

1、主線程發送消息到子線程中；

採用的方法和前面類似。要在子線程中實例化AHandler並設定處理消息的方法，同時由於子線程沒有消息隊列和Looper的輪詢，所以要加上Looper.prepare(),Looper.loop()分別創建消息隊列和開啟輪詢。然後在主線程中使用該AHandler去發送消息即可。

2、子線程A與子線程B之間的通信。

1、 Handler為什麼能夠實現不同線程的通信？核心點在哪？

不同線程之間，每個線程擁有自己的Handler、消息隊列和Looper。Handler是公共的，線程可以通過使用目標線程的Handler對象來發送消息，這個消息會自動發送到所屬線程的消息隊列中去，線程自帶的Looper對象會不斷循環從裡面取出消息並把消息發送給Handler，回調自身Handler的handlerMessage方法，從而實現了消息的線程間傳遞。

2、 Handler的核心是一種事件激活式（類似傳遞一個中斷）的還是主要是用於傳遞大量數據的？重點在Message的內容，偏向於數據傳輸還是事件傳輸。

目前的理解，它所依賴的是消息隊列，發送的自然是消息，即類似事件中斷。

0、 Android消息處理機制(Handler、Looper、MessageQueue與Message)

1、 Handler、Looper源碼閱讀

2、 Android非同步消息處理機制完全解析，帶你從源碼的角度徹底理解

謝謝！

wingjay


Ⅳ Android跨進程通信

本文整理和引用他人的筆記，旨在個人復習使用。

參考鏈接：

https://blog.csdn.net/fanleiym/article/details/83894399

https://github.com/274942954/AndroidCollection/blob/master/Docs/Android%E7%9F%A5%E8%AF%86%E7%82%B9%E6%B1%87%E6%80%BB.md#%E8%BF%9B%E7%A8%8B%E7%94%9F%E5%91%BD%E5%91%A8%E6%9C%9F

https://www.kaelli.com/4.html

https://carsonho.blog.csdn.net/article/details/73560642?utm_medium=distribute.pc_relevant.none-task-blog--1.e_weight&depth_1-utm_source=distribute.pc_relevant.none-task-blog--1.e_weight

默認情況下，一個app只會運行在一個進程中，進程名為app的包名。

1. 分散內存的佔用

Android系統對每個應用進程的內存佔用是有限制的，佔用內存越大的進程，被系統殺死的可能性就越大。使用多進程可以減少主進程佔用的內存，避免OOM問題，降低被系統殺死的概率。

2. 實現多模塊

一個成熟的應用一定是多模塊化的。項目解耦，模塊化，意味著開辟新的進程，有獨立的JVM，帶來數據解耦。模塊之間互不幹預，團隊並行開發，同時責任分工也很明確。

3. 降低程序奔潰率

子進程崩潰不會影響主進程的運行，能降低程序的崩潰率。

4. 實現一些特殊功能

比如可以實現推送進程，使得主進程退出後，能離線完成消息推送服務。還可以實現守護進程，來喚醒主進程達到保活目的。還可以實現監控進程專門負責上報bug，進而提升用戶體驗。

android:process 屬性的值以冒號開頭的就是 私有進程 ，否則就是 公有進程 。當然命名還需要符合規范，不能以數字開頭等等。

1. 前台進程

2. 可見進程

3. 服務進程

4. 後台進程

5. 空進程

Android 會將進程評定為它可能達到的最高級別。另外服務於另一進程的進程其級別永遠不會低於其所服務的進程。

創建新的進程時會創建新的Application對象，而我們通常在Application的onCreate方法中只是完成一些全局的初始化操作，不需要多次執行。

解決思路：獲取當前進程名，判斷是否為主進程，只有主進程的時候才執行初始化操作

獲取當前進程名的兩種方法：

Application中判斷是否是主進程（方法1例子）：

Serializable 和 Parcelable是數據序列化的兩種方式，Android中只有進行序列化過後的對象才能通過intent和Binder傳遞。

通常序列化後的對象完成傳輸後，通過反序列化獲得的是一個新對象，而不是原來的對象。

Serializable是java介面，位於java.io的路徑下。Serializable的原理就是把Java對象序列化為二進制文件後進行傳遞。Serializable使用起來非常簡單，只需直接實現該介面就可以了。

Parcelable是Google為了解決Serializable效率低下的問題，為Android特意設計的一個介面。Parcelable的原理是將一個對象完全分解，分解成可以傳輸的數據類型（如基本數據類型）再進行傳遞。

通常需要存到本地磁碟的數據就使用Serializable，其他情況就使用效率更高的Parcelable。

IPC 即 Inter-Process Communication (進程間通信)。Android 基於 Linux，而 Linux 出於安全考慮，不同進程間不能之間操作對方的數據，這叫做「進程隔離」。

每個進程的虛擬內存空間（進程空間）又被分為了 用戶空間和內核空間 ， 進程只能訪問自身用戶空間，只有操作系統能訪問內核空間。

由於進程只能訪問自身用戶空間，因此在傳統的IPC中，發送進程需要通過_from_user（系統調用）將數據從自身用戶空間拷貝到內核空間，再由接受進程通過_to_user從內核空間復拷貝到自身用戶空間，共需要拷貝2次，效率十分低下。Android採用的是Binder作為IPC的機制，只需復制一次。

Binder翻譯過來是粘合劑，是進程之間的粘合劑。

Binder IPC通信的底層原理是 通過內存映射（mmap），將接收進程的用戶空間映射到內核空間 ，有了這個映射關系，接收進程就能通過用戶空間的地址獲得內核空間的數據，這樣只需發送進程將數據拷貝到內核空間就可完成通訊。

一次完整的Binder IPC通信：

從IPC的角度看，Binder是一種跨進程通信機制（一種模型），Binder 是基於 C/S 架構的，這個通信機制中主要涉及四個角色：Client、Server、ServiceManager和Binder驅動。

Client、Server、ServiceManager都是運行在用戶空間的進程，他們通過系統調用（open、mmap 和 ioctl）來訪問設備文件/dev/binder，從而實現與Binder驅動的交互。Binder驅動提供進程間通信的能力（負責完成一些底層操作，比如開辟數據接受緩存區等），是Client、Server和ServiceManager之間的橋梁。

Client、Server就是需要進行通信兩個的進程，通信流程：

細心的你一定發現了，注冊服務和獲得服務本身就是和ServiceManager進行跨進程通信。其實和ServiceManager的通信的過程也是獲取Binder對象（早已創建在Binder驅動中，攜帶了注冊和查詢服務等介面方法）來使用，所有需要和ServiceManager通信的進程，只需通過0號引用，就可以獲得這個Binder對象了。

AIDL內部原理就是基於Binder的，可以藉此來分析Binder的使用。

AIDL是介面定義語言，簡短的幾句話就能定義好一個復雜的、內部有一定功能的java介面。

先看看ICallBack.aidl文件，這里定義了一個介面，表示了服務端提供的功能。

被定義出來的java介面繼承了IInterface介面，並且內部提供了一個Stub抽象類給服務端（相當於封裝了一下，服務端只需繼承這個類，然後完成功能的裡面具體的實現）。

參考： https://www.cnblogs.com/sqchen/p/10660939.html

（以下是添加了回調的最終實現，可以看參考鏈接一步一步來）

為需要使用的類，創建aidl文件。

系統會自動在main文件下生成aidl文件夾，並在該文件夾下創建相應目錄。

在java相同路徑下創建Student類，這里不能使用@Parcelize註解，否則會報錯

創建IStudentService.aidl，定義了一個介面，該介面定義了服務端提供的功能。創建完後rebuild一下項目 （每次創建和修改定義介面文件都要rebuild一下）

創建在服務端的StudentService

可以看見有回調，說明客戶端也提供了介面給服務端來回調（雙向通信，此時客戶端的變成了服務端），即ICallBack.aidl

客戶端是通過Binder驅動返回的Binder調用StudentService里的具體實現方法

AIDL使用注意：

Messenger可以在不同進程中傳遞 Message 對象，在Message中放入我們需要傳遞的數據，就可以輕松地實現數據的進程間傳遞了。Messenger 是一種輕量級的 IPC 方案，是對AIDL的封裝，底層實現是 AIDL。

使用詳見： https://blog.csdn.net/qq951127336/article/details/90678698

Ⅵ Carson帶你學Android：全面剖析Binder跨進程通信原理

從而全方位地介紹 Binder ，希望你們會喜歡。

在本文的講解中，按照 大角度 -> 小角度 去分析 Binder ，即：

從而全方位地介紹 Binder ，希望你們會喜歡。

在講解 Binder 前，我們先了解一些 Linux 的基礎知識

具體請看文章： 操作系統：圖文詳解 內存映射

Binder 跨進程通信機制 模型 基於 Client - Server 模式

此處重點講解 Binder 驅動作用中的跨進程通信的原理：

原因：

所以，原理圖可表示為以下：

所以，在進行跨進程通信時，開發者只需自定義 Client & Server 進程 並 顯式使用上述3個步驟，最終藉助 Android 的基本架構功能就可完成進程間通信

注冊服務後， Binder 驅動持有 Server 進程創建的 Binder 實體

此時， Client 進程與 Server 進程已經建立了連接

Client 進程 根據獲取到的 Service 信息（ Binder 代理對象），通過 Binder 驅動 建立與 該 Service 所在 Server 進程通信的鏈路，並開始使用服務

步驟1： Client 進程 將參數（整數a和b）發送到 Server 進程

步驟2： Server 進程根據 Client 進要求 調用 目標方法（即加法函數）

步驟3： Server 進程 將目標方法的結果（即加法後的結果）返回給 Client 進程

對比 Linux （ Android 基於 Linux ）上的其他進程通信方式（管道、消息隊列、共享內存、
信號量、 Socket ）， Binder 機制的優點有：

特別地，對於從模型結構組成的Binder驅動來說：

不定期分享關於 安卓開發 的干貨，追求 短、平、快 ，但 卻不缺深度 。

Ⅶ Android 跨進程通信--Binder篇

話說Binder 其實是由George Hoffman 老哥，在1991年Be公司啟動了一個「openBinder」的項目，該項目的宗旨是研究一個高效的信號傳遞工具，允許多個軟體相互合作，構成一個軟體系統。在BE被parmSource收購以後，openBinder由hackborn繼續開發。在Hackborn加入google之後，他繼續開發出了Android Binder。

而Android系統是基於Linux內核實現的，Linux已經提供了多種進程間通信機制，比如：管道、消息隊列、共享內存和套接字（Socket）等等。

講它們優缺點前先補充說明：
「進程隔離」--這個技術是為了避免進程A寫入進程B的情況發生。 進程的隔離實現，使用了虛擬地址空間進程A的虛擬地址和進程B的虛擬地址不同，這樣就防止進程A將數據信息寫入進程B。進程隔離的安全性通過禁止進程間內存的訪問可以方便實現。相比之下，一些不安全的操作系統DOS能夠允許任何進程對其他進程的內存進行寫操作。

「虛擬內存」-- 是計算機系統內存管理的一種技術。它使得應用程序認為它擁有連續可用的內存（一個連續完整的地址空間），而實際上，它通常是被分隔成多個物理內存碎片，還有部分暫時存儲在外部磁碟存儲器上，在需要時進行數據交換。與沒有使用虛擬內存技術的系統相比，使用這種技術的系統使得大型程序的編寫變得更容易，對真正的物理內存的使用也更有效率。

注意： 虛擬內存 不只是「用磁碟空間來擴展物理內存」的意思——這只是擴充內存級別以使其包含硬碟驅動器而已。把內存擴展到磁碟只是使用虛擬內存技術的一個結果，它的作用也可以通過覆蓋或者把處於不活動狀態的程序以及它們的數據全部交換到磁碟上等方式來實現。對虛擬內存的定義是基於對地址空間的重定義的，即把地址空間定義為「連續的虛擬內存地址」，以藉此「欺騙」程序，使它們以為自己正在使用一大塊的「連續」地址。

Ⅷ 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機制（Native層（下））

本篇文章針對向ServiceManager注冊服務 和 獲取服務兩個流程來做總結。在這兩個過程中，ServiceManager都扮演的是服務端，與客戶端之間的通信也是通過Binder IPC。

在此之前先了解下Binder的進程與線程的關系：

用戶空間 :ProcessState描述一個進程，IPCThreadState對應一個進程中的一個線程。
內核空間 ：binder_proc描述一個進程，統一由binder_procs全局鏈表保存，binder_thread對應進程的一個線程。
ProcessState與binder_proc是一一對應的。

Binder線程池 ：每個Server進程在啟動時會創建一個binder線程池，並向其中注冊一個Binder線程；之後Server進程也可以向binder線程池注冊新的線程，或者Binder驅動在探測到沒有空閑binder線程時會主動向Server進程注冊新的的binder線程。對於一個Server進程有一個最大Binder線程數限制15，(#define DEFAULT_MAX_BINDER_THREADS 15)。對於所有Client端進程的binder請求都是交由Server端進程的binder線程來處理的。我的理解是：binder線程是進程進行binder ipc時的一條數據處理路徑。

MediaPlayerService向ServiceManager注冊過程如下：

相關類：

整個過程總結如下：
1 獲取BpServiceManager 與 BpBinder
由defaultServiceManager()返回的是BpServiceManager，同時會創建ProcessState對象和BpBinder對象。然後通過BpBinder執行transact，把真正工作交給IPCThreadState來處理。

2 BpBinder transact
Binder代理類調用transact()方法，真正工作還是交給IPCThreadState來進行transact工作。

3 通過IPCThreadState 包裝並轉換數據並進行transact事務處理
每個線程都有一個IPCThreadState，每個IPCThreadState中都有一對Parcel變數：mIn、mOut。相當於兩根數據管道：

最後執行talkWithDriver。

writeTransactionData：將BC Protocol + binder_transaction_data結構體 寫入mOut， 然後執行waitForResponse：

由talkWithDriver將數據進一步封裝到binder_write_read結構體，通過ioctl（BINDER_WRITE_READ）與驅動通信。同時等待驅動返回的接收BR命令，從mIn取出返回的數據。

mIn包裝的數據結構(注冊服務handle = 0 ，code 為ADD_SERVICE_TRANSACTION)：

4 Binder Driver
把binder_write_read結構體write_buffer里數據取出來，分別得到BC命令和封裝好數據的事務binder_transaction_data, 然後根據handler，在當前binder_proc中，找到相應的binder_ref，由binder_ref再找到目標binder_node實體，由目標binder_node再找到目標進程binder_proc。然後就是插入數據：當binder驅動可以找到合適的線程，就會把binder_transaction節點插入到servciemanager的線程的todo隊列中，如果找不到合適的線程，就把節點之間插入servciemanager的binder_proc的todo隊列。

5 ServiceManager
經過Binder Driver的處理，數據已經到了ServiceManager進程，在BR_TRANSACTION的引導下，在binder_loop（）中執行binder_parser（）取出數據，執行do_add_service（）操作，最終向 svcinfo 列表中添加已經注冊的服務（沒有數據的返回）。最後發送 BR_REPLY 命令喚醒等待的線程，通知注冊成功。結束MediaPlayerService進程 waitForResponse()的狀態，整個注冊過程結束。

獲取服務的過程與注冊類似，首先 ServiceManager 向 Binder 驅動發送 BC_TRANSACTION 命令攜帶 CHECK_SERVICE_TRANSACTION 命令，同時獲取服務的線程進入等待狀態 waitForResponse()。Binder 驅動收到請求命令向 ServiceManager 的發送 BC_TRANSACTION 查詢已注冊的服務，會區分請求服務所屬進程情況。

查詢到直接響應 BR_REPLY 喚醒等待的線程。若查詢不到將與 binder_procs 鏈表中的服務進行一次通訊再響應。

以startService為例來簡單總結下執行流程：

3.1 從方法執行流程來看：

Client ：

1 AMP.startService 標記方法以及通過Parcel包裝數據；

2 BinderProxy.transact 實際調用native的 android_os_BinderProxy_transact 傳遞數據；

3 獲取BpServiceManager 與 BpBinder 同時會創建ProcessState。然後通過BpBinder執行transact，把真正工作交給IPCThreadState來處理；

4 IPC.transact 主要執行writeTransactionData，將上層傳來的數據重新包裝成binder_transaction_data，並將BC Protocol + binder_transaction_data結構體 寫入mOut；

5 IPC waitForResponse talkWithDriver + 等待返回數據；

6 talkWithDriver 將數據進一步封裝成binder_write_read，通過ioctl（BINDER_WRITE_READ）與驅動通信；

Kernel :

7 binder ioctl 接收BINDER_WRITE_READ ioctl命令；

8 binder_ioctl_write_read 把用戶空間數據ubuf拷貝到內核空間bwr；

9 binder_thread_write 當bwr寫緩存有數據，則執行binder_thread_write；當寫失敗則將bwr數據寫回用戶空間並退出；

10 binder_transaction 找到目標進程binder_proc並插入數據到目標進程的線程todo隊列，最終執行到它
時，將發起端數據拷貝到接收端進程的buffer結構體；

11 binder_thread_read 根據binder_transaction結構體和binder_buffer結構體數據生成新的binder_transaction_data結構體，寫入bwr的read_buffer，當bwr讀緩存有數據，則執行binder_thread_read；當讀失敗則再將bwr數據寫回用戶空間並退出；最後，把內核數據bwr拷貝到用戶空間ubuf。

12 binder_thread_write + binder_ioctl BR命令和數據傳遞

Server:

13 IPC.executeCommand 解析kernel傳過來的binder_transaction_data數據，找到目標BBinder並調用其transact()方法;

14 IPC.joinThreadPool 採用循環不斷地執行getAndExecuteCommand()方法, 處理事務。當bwr的讀寫buffer都沒有數據時,則阻塞在binder_thread_read的wait_event過程. 另外,正常情況下binder線程一旦創建則不會退出.

15 BBinder.transact 到Binder.exeTransact 調用 AMN.onTransact

16 AMN.onTransact 把數據傳遞到AMS.starService去執行

17 AMS.starService Server處理了Client的請求了

然後原路replay回去，talkWithDriver 到Kernel ，然後找到Client進程，把數據拷貝到read_buffer里，最終喚醒IPC，把反饋傳遞回AMP.startService。完成啟動服務。

3.2 從通信協議流程來看：

非oneWay:

oneway:

oneway與非oneway區別: 都是需要等待Binder Driver的回應消息BR_TRANSACTION_COMPLETE. 主要區別在於oneway的通信收到BR_TRANSACTION_COMPLETE則返回,而不會再等待BR_REPLY消息的到來. 另外，oneway的binder IPC則接收端無法獲取對方的pid.

3.3 從數據流來看

從用戶空間開始：

進入驅動後：

回到用戶空間：

參考：
http://gityuan.com/2016/09/04/binder-start-service/
http://gityuan.com/2015/11/28/binder-summary/
http://gityuan.com/2015/11/14/binder-add-service/
http://gityuan.com/2015/11/15/binder-get-service/

Ⅹ Android——消息分發機制

什麼是 Handler 機制 ？
Handler 機制是 Android 中用於 線程間通信 的一套通信機制。

為什麼是 Handler ？Handler 機制為什麼被那麼多次的提及 ？
從Android4.0開始，Android 中網路請求強制不允許在主線程中操作，而更新UI的操作則不允許在子線程中執行。當在子線程中執行網路請求，拿到伺服器返回的數據之後，要更新UI。由於系統的要求，勢必會產生一種矛盾：數據在子線程，更新UI要在主線程。此時我們必須要把數據返回到主線程中才行，Handler機制應運而生。

Android 中針對耗時的操作，放在主線程操作，輕者會造成 UI 卡頓，重則會直接無響應，造成 Force Close。同時在 Android 3.0 以後，禁止在主線程進行網路請求。

針對耗時或者網路操作，那就不能在主線程進行直接操作了，需要放在子線程或者是工作線程中進行操作，操作完成以後，再更新主線程即 UI 線程。這里就涉及到一個問題了，在子線程執行完成以後，怎麼能更新到主線程即 UI 線程呢，針對以上問題，就需要用到 Android 的消息機制了，即： Handler, Message, MessageQueue, Looper 全家桶

Handler機制中最重要的四個對象

Handler的構造方法:

Looper :

Handler的使用：

MessageQueue：

Looper.loop()

Handler.dispatchMessage()

handler導致activity內存泄露的原因：
handler發送的消息在當前handler的消息隊列中，如果此時activity finish掉了，那麼消息隊列的消息依舊會由handler進行處理，若此時handler聲明為內部類（非靜態內部類），我們知道內部類天然持有外部類的實例引用，這樣在GC垃圾回收機制進行回收時發現這個Activity居然還有其他引用存在，因而就不會去回收這個Activity，進而導致activity泄露。

假如在子線程執行了耗時操作，這時用戶操作進入了其他的 acitvity， 那麼 MainActivity 就會被內存回收的，但是這個時候發現 Handler 還在引用著 MainActivity，內存無法及時回收，造成內存泄漏。

Handler 防止內存泄漏常見方法：

為什麼通過 Handler 可以把子線程的結果通知或者攜帶給 UI 線程 ？
這里的 Handler 指的是主線程的 Handler ,同時與 Handler 配套的 Looper ， MessageQueue 是在 UI 線程初始化的，所以在子線程中調用 Handler 發送消息可以更新 UI 線程。
Looper 在 UI 線程源碼, 在 ActivityThread 類：