Study on Android【三】–Intent訊息傳遞

在前面寫Android的ContentProvider時候，可以看到那是基於觀察者模式的一個訊息傳遞方法。每一個Cursor、ContentResolver做為一個小的註冊中心，相關觀察者可以在這個中心註冊，更新訊息由註冊中心分發給各個觀察者。而在MFC或Winform中，都會形成一個訊息網，讓訊息在網中流動，被各節點使用、吃掉或者在出口死掉。

相比之下，我個人覺得基於Intent的Android核心訊息傳遞機制是有所不同的。它應該會有一個全域性的註冊中心，這個註冊中心是隱性的，整個Android系統中就那麼一個。所有的訊息接收者，都被隱形的註冊到這個中心。包括Activity，Service和IntentReceiver。其實說隱形註冊是不確切的，所有註冊都還是我們手動告訴註冊中心的，只是與傳統的方式不一樣，我們通常不是通過代碼，而是通過設定檔來做。在應用的Manifest中，我們會為一些Activity或Service添加上Intent-filter，或在設定檔中添加<receiver></receiver>項。這其實就相當於向系統的註冊中心，註冊了相關的Intent-filter和receiver（這個事情完全可以通過代碼來做，只是這樣就失去了修改的靈活性）。

當程式有一個訊息希望發出去的時候，它需要將訊息封裝成一個Intent，並發送。這時候，應該是有一個統一的中心（恩，有可能Android底層實現的時候不是，但簡單這樣看是沒問題的...）接受到這個訊息，並對它進行解析、判定訊息類型（這個步驟降低了耦合...），然後檢查註冊了相匹配的filter或receiver，並建立或喚醒接收者，將訊息分發給它。這樣做有很多好處。雖然這種傳遞有的時候不如點對點的傳遞快（這有些需要速度的地方，我們看到Android會通過直接通訊來做），但有時候又因為它只經過一跳（姑且這麼叫吧...），比複雜的流動又要更快。更重要的是，它耦合性低，在手機平台這種程式組件多變的條件下使用十分適合。並且它可以很容易實現訊息的精確或模糊比對，彈性很大。（我個人曾想在開發一個C++二次平台的時候引入這樣的機制，但在C++中，建立一套完整的資料marshal機制不容易，相比之下，用java來做會簡單很多...）

恩，廢話說了很多，具體講講Android中Intent的使用。當你有一個訊息需要傳遞，如果你明確知道你需要哪個Activity或者其他Class來響應的話，你可以指定這個類來接受該訊息，這被稱為顯性發送。你需要將Intent的class屬性設定成目標。這種情況很常見，比如startActivity的時候，會清楚當前Activity完了應該是哪個Activity，那就明確的發送這個訊息。

但是，有的時候你並不確定你的訊息是需要具體哪個類來執行，而只是知道接收者該符合哪些條件。比如你只需要有一個接收者能顯示使用者所選的資料，而不想制定某個具體的方法，這時候你就需要用到隱形發送（傳統上，我們可能會考慮用多態，但顯然這種方式更為靈活...）。在Android中，你可以為Intent指定一個action，表示你這個指令需要處理的事情。系統為我們定義了很多Action類型，這些類型使系統與我們通訊的語言（比如在Activity裡面加一個Main的filter，該activity就會做成該應用的進入點），當然你也可以用於你自己的應用之間的通訊（同樣當然，也可以自訂...）。強烈建議，在自己程式接收或發出一個系統action的時候，要名副其實。比如你響應一個view動作，做的確實edit的勾當，你發送一個pick訊息，其實你想讓別人做edit的事，這樣都會造成混亂。當然只有Action有時候是不夠的，在Android中我們還可以指定catalog資訊和type/data資訊，比如所有的顯示資料的Activity，可能都會響應View action。但很多與我們需要顯示的資料類型不一樣，可以加一個type資訊，明確的指出我們需要顯示的資料類型，甚至還可以加上一個catalog資訊，指明只有你只有按的是“中鍵”並發出這樣的訊息才響應。

從上面可以看出，Android的Intent可以添加上class, action, data/type, catalog等訊息，註冊中心會根據這些資訊幫你找到符合的接收者。其中class是點對點的指示，一旦指明，其他資訊都被忽略。Intent中還可以添加key/value的資料，發送方和接收方需要保持統一的key資訊和value類型資訊，這種資料的marshal在java裡做，是不費什麼力氣的。

Android的Intent發送，可以分成單播和廣播兩種。廣播的接收者是所有註冊了的合格IntentReceiver。在單播的情況下，即使有很多合格接收者，也只要有一個出來處理這個訊息就好（恩，個人看法，沒找到確切條款或抉擇的演算法，本來想實驗一下，沒來得及...），這樣的情況很容易理解，當你需要修改某個資料的時候，你肯定不會希望有十個編輯器輪流讓你來處理。當廣播不是這樣，一個receiver沒有辦法阻止其他receiver進行對廣播事件的處理。這種情況也很容易理解，比如時鐘改變了，鬧鐘、備忘錄等很多程式都需要分別進行處理。在自己的程式的使用中，應該分清楚區別，合理的使用。