深入了解Messenger的實現細節

作者：D_clock愛吃蔥花 2016-10-20 08:46:17

Android 上實現 IPC （進程間通訊）的方式有好幾種，其中有一種就是使用 AIDL 方式實現。對于使用 AIDL 方式通訊，其關鍵就在于創建 aidl 文件，系統會自動為 aidl 文件生成相應的 Java 類，其關鍵實現在于生成的 Java 類中。

近一個半月因為工作變動的緣故，忙著交接工作和復習面試。沒有多少時間來寫博客，連一周三次的健身都有幾個星期沒練了，好多同事問我是胖了還是壯了(我迅速就岔開話題了，機智boy)。上周離職，這周主要在處理一些私事、做些入職準備工作、看點書之類的，下周入職YY(上周才知道原來大神羅升陽也在YY)。好啦，說了這么多，要開始進入 Messenger 的正題了。

前言

看這篇文章前，需要對 Android 的進程間通訊方式有所了解，不然可能會云里霧里。

從使用 Messenger 說起

Android 上實現 IPC (進程間通訊)的方式有好幾種，其中有一種就是使用 AIDL 方式實現，對使用 AIDL 不了解的童鞋可以看下方的官方文檔(需要梯子)。

https://developer.android.com...

對于使用 AIDL 方式通訊，其關鍵就在于創建 aidl 文件，系統會自動為 aidl 文件生成相應的 Java 類，其關鍵實現在于生成的 Java 類中。

系統提供了一個更方便我們進行 IPC 的類 —— Messenger，先來看看如何使用 Messenger(熟悉的童鞋完全可以跳過這一部分)。

第一步：客戶端進程創建兩個 Messenger，一個 Sender ，一個 Receiver;

//客戶端進程發消息給服務進程 
   private Messenger mSender; 
   //客戶端進程接收服務進程回調 
   private Messenger mReceiver = new Messenger(new Handler() { 
       @Override 
       public void handleMessage(Message msg) { 
           super.handleMessage(msg); 
           Bundle data = msg.getData(); 
           if (data != null) { 
               String response = data.getString("body"); 
               Toast.makeText(MainActivity.this, response, Toast.LENGTH_SHORT).show(); 
           } 
       } 
   });

第二步：編寫Service類，并需要在 AndroidManifest.xml 配置多進程;

public class IPCService extends Service { 
 
    private Messenger messenger = new Messenger(new Handler() { 
        @Override 
        public void handleMessage(Message msg) { 
            super.handleMessage(msg); 
            try { 
                Thread.sleep(2 * 1000); 
            } catch (InterruptedException e) { 
                e.printStackTrace(); 
            } 
            Message response = Message.obtain(); 
            Bundle data = new Bundle(); 
            data.putString("body", "response"); 
            response.setData(data); 
            try { 
                msg.replyTo.send(response);//回調客戶端 
            } catch (RemoteException e) { 
                e.printStackTrace(); 
            } 
        } 
    }); 
 
    @Override 
    public IBinder onBind(Intent intent) { 
        return messenger.getBinder();//將Binder返回給請求綁定的進程 
    } 
 
}

第三步：綁定Service進程，并在 ServiceConnection 中初始化 Sender;

Intent intent = new Intent(this, IPCService.class); 
    startService(intent); 
    bindService(intent, conn, Context.BIND_AUTO_CREATE);//啟動綁定Service進程 
 
    private ServiceConnection conn = new ServiceConnection() { 
        @Override 
        public void onServiceConnected(ComponentName name, IBinder service) { 
            mSender = new Messenger(service); //用Binder初始化Sender 
        } 
 
        @Override 
        public void onServiceDisconnected(ComponentName name) { 
 
        } 
    };

第四步：用 Sender 和 Receiver 完成客戶端進程和服務進程的交互。

if (mSender != null) { 
        Message message = Message.obtain(); 
        message.replyTo = mReceiver;//將 Receiver 一并發送給服務進程 
        try { 
             mSender.send(message); 
        } catch (RemoteException e) { 
             e.printStackTrace(); 
        } 
     }

至此，在綁定服務進程初始化 Sender 后，即可以做多進程間的交互工作了。使用 Messenger 來實現多進程的交互相比我們用 aidl 來要方便得多，但是 Messenger 的內部也是采用 aidl 實現的，只不過為了方便開發者調用而進行一些封裝，使得開發者們可以忽略 aidl 的實現細節。簡單的了解了 Messenger 的基本使用后，下面我們就來看看 Messenger 的源代碼，了解一些內部的實現細節。

Messenger 源代碼通讀

Messenger 類位于 android.os 包下，代碼量不是很多，所以看起來難度不大，只有如下這么幾個方法。

在上面的示例代碼中可以看到，客戶端進程有 Sender 和 Receiver 兩個 Messenger，如果不需要實現服務進程回調客戶端進程，那么 Receiver 完全可以不要。當需要服務進程回調客戶端進程時，則需要傳入 Receiver 了。由于需要在進程間傳遞 Messenger 對象，那么 Messenger 類就必須要繼承 Serializable 或者 Parcelable 接口。按照 Android 系統一向的風格，都是偏向于推薦繼承 Parcelable 來實現。

所以，上面看到的 describeContents、writeToParcel 方法和 CREATOR 對象實際上繼承 Parcelable 的實現。不明白的童鞋可以參照 Parcelable 的官方文檔(需要梯子)

https://developer.android.com...

而 equals 和 hashCode 方法自然不用多說啦，大家熟悉得很。而 writeMessengerOrNullToParcel 和 readMessengerOrNullFromParcel 這對靜態方法主要是實現 Messenger 在 Parcel 中的讀寫操作的，實現比較簡單，大家參見下面代碼就可以理解了。

當然，Messenger 除了繼承 Parcelable 外，還需要聲明一個同名的 Messenger.aidl 文件，可以在 framework 層源碼下 android.os 包中找到 Messenger.aidl 文件，對于寫過 aidl 的童鞋，肯定不陌生了。

排除掉上面提到的方法，剩下的主要是 Messenger 的兩個構造方法以及 getBinder 和 send 方法。客戶端調用服務進程方法時，是通過 Messenger 中的 send 方法，所以我們先直接看 send 方法中的內部實現

其內部是調用了 mTarget 的 send 方法，那么 mTarget 又是何物呢?

從上面可以看到 mTarget 是一個 IMessenger 實例，作為 Messenger 唯一的成員變量。初始化 mTarget 是在 public Messenger(Handler target) 構造函數中，利用 Handler 的 getIMessenger 方法來獲取一個 IMessenger 的實例。

從上圖可以看到 getIMessenger 前面是沒有修飾符的，這樣控制了該方法的作用域僅限于 android.os 包內給其他類使用，我們日常開發是無法使用該方法的，所以在 API 文檔中也沒有提供相應接口文檔。在倒數第二行中可以看到 new MessengerImpl() 并在最后 return 給調用者。所以實際上， mTarget 具體實現是在 MessengerImpl 中。

MessengerImpl 實際上是 Handler 的一個私有內部類，它繼承了 IMessenger.Stub 并實現 send 方法。用過 aidl 的童鞋 IMessenger.Stub 的身影想必就明白了，實際上 IMessenger 就是系統提供的 IMessenger.aidl 文件，而 IMessenger.Stub 就是由 IMessenger.aidl 生成的類。 IMessenger.aidl 在 framework 層代碼的 android.os 包中可以找到，而關于 IMessenger 的 Java 實現，則可以看下面的鏈接。

http://grepcode.com/file/repo...

MessengerImpl 的 send 實現相對也比較簡單，只有兩行代碼

public void send(Message msg) { 
       msg.sendingUid = Binder.getCallingUid(); 
       Handler.this.sendMessage(msg); 
   }

首先是將發起調用的客戶端進程的 Linux Uid 存儲在我們傳入的 Message 對象中，服務進程收到 Message 可以通過 msg.sendingUid 得知發起調用的進程的 Linux Uid。接著通過 Handler 的 sendMessage 方法發送給服務進程，這意味著 Messenger 與服務進程間的操作是串行的，因此，在有并行需求的場景下 Messenger 就不適用了。

了解完了 send 方法后，最后就只剩下 getBinder 了，其內部實現也簡單。

參照前面的示例代碼，這里主要還是在 Service 的 onBind 方法中返回 Binder 對象給客戶端調用，實現同樣是 IMessenger 的 Java 實現中。

至此，基本上看完了整個 Messenger 的內部代碼，從上面的分析上看，內部實現確實非常簡單，基于 aidl 的基礎上做的封裝實現，又對開發者屏蔽了底層 aidl 的實現細節。當然個人認為有兩點不足之處：

一個前面提到的 send 操作串行，并行場景則無法用 Messenger;
Messenger 內部沒有做 Binder 鍵斷裂重連的處理(個人認為內部處理了會更好，更加屏蔽底層的實現細節);

遠程調用的阻塞與非阻塞

Android 系統跨進程通訊的底層實現都是通過 Binder 實現，正常情況下客戶端進程發起一個遠程方法調用的流程大致如下：

客戶端線程發起調用;
客戶端線程將遠程調用操作交給 Binder 線程池，并阻塞等待返回遠程方法執行完畢返回;

這也就意味著，我們不能在客戶端進程的 UI 線程中發起遠程方法調用，不然如果遠程方法執行了耗時操作，客戶端的 UI 線程將會被阻塞，從而造成 ANR 的問題存在。讀者可以自行嘗試自定義 aidl 并發起一個耗時的遠程方法調用進行驗證。但是，如果你使用系統提供的 Messenger ，則不會出現這樣的問題，無論你的遠程方法執行多么耗時，客戶端 Messenger 發起調用后會繼續執行接下來的代碼，并不會進行阻塞等待。這里讓我百思不得其解，為什么呢?前面我們可以看到 Messenger 的 send 方法實現是在 MessengerImpl 中

并且，發送 Messeage 的操作是利用主線程的 Handler ，并沒有其他的異步操作，為何執行的過程中不阻塞?這點我也完全沒有想明白，最后折騰半天無果向任玉剛老師求助才得到答案。原來，默認情況下發起的遠程方法調用都是阻塞式的，但也可以是非阻塞式的。 Messenger 就是采用非阻塞的方式通訊，其關鍵就在于 IMessenger.aidl 的實現