基于 Handler 的 IPC 進程間通信, android 提供了一種 組件 service, 可以 作為單獨的 進程 為 應用程序 提供服務.?
大家都知道 handler 是 用來完成 線程間的 通信, 但其實 Handler 提供了 進程間 通信的支持.?
一. 先舉個 例子:
一. ? service 端代碼為: ?
? ? ? 在處理 客戶端 請求的時候我們 可以看出來 進程 交互的 非 基本數(shù)據(jù)都被 存儲到了 Bundle 中, 因此 如果我們 想傳一些 定義的 對象, 可以讓這些 對象 實現(xiàn) Parcelable接口, 以便 放到 Bundle 中 , 進行進程間 交互.
? ? ?第二點 可以注意的是:當 Service 進程 處理好 請求后, 會 封裝好 要返回的數(shù)據(jù), 調(diào)用 message 的 replyTo 這個 Messenger 對象的 send 方法 把 Service 進程端 封裝的 Message 傳給 客戶端. ( 下面會解釋 replyTo 是啥).
二. ? ?客戶端 代碼又 如下:
1. 創(chuàng)建 ServiceConnection 對象: ?通過 onServiceConnected 方法, 我們 創(chuàng)建了 可以向 Service 發(fā) 請求的 Messenger 對象 ,其 引用為 server.
2. ?于是乎, 我們 可以 調(diào)用 server 向 前面提到的 Service 進程 發(fā)出請求, 我們 創(chuàng)建一個 Message 消息 把 命令字 賦值給 msg.what, 然后 就可以 調(diào)用 server.send() 方法 把 這個 Message 發(fā)給 Service 進程處理, 但 如果 Service 進程想 通知 客戶端一些 消息 應該怎么處理呢, 所以 我們 傳給 Service 進程的消息 要 帶上 replyTo 這個值, replyTo 是一個 處理 Service 進程數(shù)據(jù)返回的 Messenger.
3. 創(chuàng)建 用于 處理 service 進程返回 數(shù)據(jù)的 Messenger,說白了就是 創(chuàng)建 一個 可以暴漏給 Service 進程 調(diào)用的 遠程 binder 對象,
二. 再講一下原理:
? ? 概述:?
? ? ? ? ? ? 在 Service 端 創(chuàng)建 一個 Messenger 對象, 構造函數(shù)的入?yún)?Handler, 則 在 當前進程 中 創(chuàng)建一個 IMessenger.Stub 對應的 子類 MessengerImpl 的 Binder 對象, 這個 Binder 為 本地Binder. 在 Service 中的 onBinder() 回調(diào)方法中 調(diào)用 Messenger 對象的 getBinder() 進行返回( 實際上調(diào)用的是 MessengerImpl.asBinder() 方法),?
? ? ? ? ? ? 在 Client 端中的 ServiceConnection 接口的實現(xiàn)類 中的 onServiceConnected() 方法的第二個參數(shù) 為 Service 返回的 代理 Binder, 則 使用 Messenger 構造函數(shù) 中 入?yún)?IBinder 的 創(chuàng)建一個 Messenger 對象, ?在 Client 端 創(chuàng)建的 這個 Messenger 是 用來 向 ?Service 端 發(fā)送 Messager 消息的, Messager 消息 對應的 處理 邏輯 是在 Service 端 的 Messenger 對象中的 handleMessage(){} 方法中實現(xiàn)的.
? ? ? ? ? ? 在前面只講到了 從 Client 端發(fā)送 Message 消息 給 Service 端, 但如果 想 通過 Service 端返回 消息 給 Client 端呢, 則 在 Client 端 創(chuàng)建一個 構造函數(shù)入?yún)?為 Handler 的 Messenger 對象 delReturn , 然后 將 Client端發(fā)給 Service 端 對應的 Message 的 ?replyTo 字段 賦值為 delReturn 指向的對象, 則 Service 端就可以 通過 Message.replyTo 對應的 Messenger 向 Client端發(fā)送 Message.
? ? ? ? ? ? 小結一下 : ?通過 Messenger 來 實現(xiàn) 進程間通信的 好處是:
? ? ? ? ? ? ? ? ? ? ? ? 1. 不用煩惱 前后臺 約定的 進程間通信協(xié)議的變換(aidl文件) , ?因為 Messenger 機制里 可以通過 修改 handleMessage() 的實現(xiàn)就可以了,不用修改 遠程調(diào)用 接口
? ? ? ? ? ? ? ? ? ? ? ? 2. ?避免客戶端調(diào)用 Service 遠程 方法 的線程會被阻塞. ?, Binder機制中 Client端 調(diào)用 Service 端 時, Client端對應的線程會等到 Service 端 線程返回才開始繼續(xù)執(zhí)行,, 由于 Messenger 在 ipc 通信上 借鑒了 Handler 機制,因此 可以把 方法執(zhí)行 和方法返回分開 , Messenger 機制下的 client 端 對應的線程 無需 等待 消息 執(zhí)行完成.
-------------------------------------------------------------------------------------------------------------------------------------------------
? ? ? ? 1. ?首先, 我們看到 IMessenger 對應的 aidl 文件: 可以知道 IMessenger 對應的是 一個 有 send(Message msg) 方法的Binder 對象.
? ? ? ? 2. 在 Handler.MessengerImpl ?類 中 我們可以看到 IMessenger.Stub 本地 binder 端 的代碼實現(xiàn)為 : 通過 Handler 的 sendMessage() 方法把 獲取到的Message 消息 發(fā)給對應的線程的looper中.
? ? ? ? 3. 在 上面代碼截圖中, 我們可以看到 Handler 中 有一個 方法 getIMessenger(), 其作用是 返回一個 MessengerImpl() 對象實例. 在使用的時候 我們會 創(chuàng)建 Messenger 對象, 則 從 Messenger 的構造函數(shù)中 我們可以看到:
? ? ? ? --> Messenger 有 兩個構造函數(shù), 其中 一個 入?yún)?為 Handler對象, 則 mTarget 對應的 是 IMessenger ?aidl 接口 對應的 實體類.
? ? ? ? --> ?下面是 入?yún)?為 IBinder 對象, 則 target 為 IMessenger aidl 接口 對應的 代理類, 用來 把 消息 Messenger 從當前 進程 發(fā)到 IMessenger 對應的 實體類 所在的進程 進行處理: