Android學習筆記之Intent消息傳遞

  在前面寫Android的ContentProvider時候,可以看到那是基于觀察者模式的一個消息傳遞方法。每一個Cursor、ContentResolver做為一個小的注冊中心,相關觀察者可以在這個中心注冊,更新消息由注冊中心分發給各個觀察者。而在MFC或Winform中,都會形成一個消息網,讓消息在網中流動,被各節點使用、吃掉或者在出口死掉。
  相比之下,我個人覺得基于Intent的Android核心消息傳遞機制是有所不同的。它應該會有一個全局性的注冊中心,這個注冊中心是隱性的,整個Android系統中就那么一個。所有的消息接收者,都被隱形的注冊到這個中心。包括Activity,Service和IntentReceiver。其實說隱形注冊是不確切的,所有注冊都還是我們手動告訴注冊中心的,只是與傳統的方式不一樣,我們通常不是通過代碼,而是通過配置文件來做。在應用的Manifest中,我們會為一些Activity或Service添加上Intent-filter,或在配置文件中添加項。這其實就相當于向系統的注冊中心,注冊了相關的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進行對廣播事件的處理。這種情況也很容易理解,比如時鐘改變了,鬧鐘、備忘錄等很多程序都需要分別進行處理。在自己的程序的使用中,應該分清楚區別,合理的使用。


來源:百度文庫

上一篇: Android的底層庫libutils介紹

下一篇: 沒有符合條件的記錄

分享到: 更多
百赢棋牌二人麻将棋牌 必富备用网址 快速时时正规吗 云顶娱乐安卓版1.8.0 不限ip注册优惠体验金 二八杠推筒子安卓游戏 送38 老时时彩走势图乐彩网 北京塞车开奖直播 双色球近3000期走势图 玩彩倍投计划 三个色子玩法 天天斗地主棋牌游戏 欢乐麻将游戏下载 足球单场结果 江西时时历史开奖号码