Understanding Intent and IntentFilter--理解Intent和IntentFilter
Intent(意圖)在Android中是一個十分重要的組件，它是連接不同應用的橋梁和紐帶，也是讓組件級復用(Activity和 Service)成為可能的一個重要原因。Intent的使用分為二個方面一個是發(fā)出Intent，另一個則是接收Intent用官方的說法就是Intent Resolving。本主將對Intent和IntentFilter進行一些介紹。
Intent和IntentFilter是Android和一種消息通信機制，可以讓系統(tǒng)的組件之間進行通信。信息的載體就是Intent，它可以是一個要完成的動作請求，也可以一般性的消息廣播，它可以由任意一個組件發(fā)出。消息，也就是Intent，最終也是要被組件來進行處理和消化。消息由組件發(fā)出，通常在消息的里面也會有會標記有目標組件的相關信息，另外目標組件也需要告訴系統(tǒng)，哪些消息是它所感興趣的，它需要設置一些過濾器，以過濾掉無關的消息。

其實這里就好比學校里的廣播，廣播有時會播放通知，但有時也會播放要執(zhí)行的動作，比如打掃衛(wèi)生。消息中通常都會說明消息的目標對象，可能是計算機學院，可能是老師，也可能是英語系的人才需要關注。而每個人，或是學院組織，也只關心與他們有關的消息，當然這里就要他們自己去判斷哪些是與他們有關的消息了。在Android當中消息就是Intent，過濾器就是IntentFilter。發(fā)出消息的組件可以在消息中設置目標組件的相關信息，目標組件也可以設置過濾器，然后系統(tǒng)會進行過濾，只把組件所感興趣的消息，傳遞給組件。這里假設讀者已經(jīng)了解Intent和IntentFilter的基本使用方法，且并不會進行全面的介紹，如果不了解，可以先讀讀官方文檔，這里重點講講IntentFilter在使用時的一些注意事項。
Intent消息機制通常有二種，一個是顯式Intent（Explicit Intent），另一個是隱式Intent（Implicit Intent）。
•顯式Intent--需要在Intent中明確指定目標組件，也就是在Intent中明確寫明目標組件的名稱（Component name），需要指定完整的包名和類名。因為對于本程序以外的其他應用程序，你很難知道它的組件名字，所以顯式的Intent通常用于應用程序內部通信，更確切的說，顯示Intent是用于應用程序內部啟動組件，通常又是Activity或Service。還沒有見用顯式Intent來給BroadcastReceiver發(fā)送廣播的。
•隱式Intent--也就是不在Intent中指定目標組件，在Intent中不能含有目標的名字。系統(tǒng)是根據(jù)其他的信息，比如Data，Type和Category去尋找目標組件。
隱式Intent通常用于與應用程序外部的組件進行通信。應用程序級別的組件復用也主要是靠隱式Intent來完成的。而IntentFilter也是只有隱式Intent才用的著，顯式Intent都是直接把Intent傳遞給目標組件，根本不會理會組件的IntentFilter。
顯式Intent（Explicit Intent)
顯示Intent使用起來比較簡單，只需要在Intent中指定目標組件的名字即可，也就是通過Intent的方法設置Component屬性。如前所述，顯式Intent通常用于應用程序內部啟動Activity或Service。事實上，并不完全局限在應用程序內部，對于外部應用的Activity和Service，也可以用顯式Intent來啟動，但你必須知道它們的名字。
設置組件的名字的方法有：

事實上雖然設置的方法有這么多，但Intent內部標識目標組件的屬性只有一個Component，所以這么設置方法的目的也只是設置目標組件的Component，事實上有這么多的方法原因在于ComponentName的構造是多重載了的。在解析Intent時，系統(tǒng)也是取得這個Component屬性，然后去啟動它。
ComponentName Intent.getComponent();
對于應用程序內部啟動Activity通常是這樣子設置Intent：

因為應用程序內部的組件類，都是可以訪問到的，所以要盡可能少寫字串常量，以減少拼寫錯誤，如果一定要使用包名和類名，也要注意，類名必須是全稱，也就是從包名開始，如“com.hilton.networks.WifiManagerActivity"。
但是對于外部應用程序的Activity，通常只能通過以下方法：

首先，帶有Context為參數(shù)的是不能夠用的，因為通常你無法拿到其他應用程序的Context，你只能拿到你所在應用程序的Context，所以用你所在的應用程序的Context去啟動外部的Activity肯定會報錯的。其次，不參再像上面那樣通過Class.getName()去指定類名，你為你無法導入外部的類，會有編譯錯誤的。另外，千萬要注意不要拼錯，否則會有RuntimeException拋出的。
對于Service組件，也是一樣，Intent的寫法與Activity組件一致，但是對于BroadcastReceiver組件通常都用顯式Intent。
隱式Intent的消息過濾器--IntentFilter
IntentFilter是用來解析隱式Intent(Implicit Intent)的，也就是說告訴系統(tǒng)你的組件(Activity, Service, BroadcastReceiver)能夠處理哪些隱式的Intent。在使用的時候我們通常是這樣子的：

在Manifest中使用IntentFilter時要注意以下三點：
1. 千萬注意拼寫錯誤
這里有一個需要十分小心和注意的地方那就是對于IntentFilter里面的Action和Data字串常量不要寫錯，因為這個在編譯時是不會被檢查，在運行時又不會拋出異常，如果你拼寫錯了，比如大小寫拼錯了，在編譯時和運行時都不會有錯誤，但是你的程序卻不能正常工作，你的程序無法收到相應的Intent。曾有一個同事在IntentFilter中寫了一些Action，但把其中一個的大小寫拼錯了，結果花了他一個下午的時間來調試，最后還是另外一個同事到他那聊天才發(fā)現(xiàn)了是大小寫的拼寫錯誤。
這里也可以發(fā)現(xiàn)Android在Manifest文件中的IntentFilter這塊的封裝性很差。如果，僅僅是如果，這些Action常量也可以通過引用的方式來寫，就可以在編譯時做些檢查和匹配，可以大大的減少出錯的機率，同時也加強了封裝和信息隱藏。比如，對于上面的可以寫成這樣：

雖然這種拼寫錯誤很低級，但是因為它低級所以當程序不能正常工作時沒有人會想到是因為拼寫錯誤，所以這種拼寫錯誤通常會耗費不少的調試時間。另外一種避免此種錯誤的方法就是在代碼中通過Context.registerReceiver(BroadcastReceiver,IntentFilter)來注冊BroadcastReceiver，就可以直接寫入常量，而非具體字串。但這只能是接收Broadcast的時候，對于那些想作為公開接口的組件，還是需要在Manifest里面聲明，比如Email，它要能處理Intent.ACTION_SEND_TO，就需要在Manifest中聲明。
2. 要注意Data字段除了上面討論的之外，對于IntentFilter還有另外的一點需要注意，就是對于某些Action是需要加上Data字段信息，否則有可能接收不到。比如：

對于手機外部存儲卡的狀態(tài)變化的Broadcast，在注冊監(jiān)聽器的時候就需要加上DataScheme，否則就會接收不到。這個也花費了我?guī)讉€小時的調試時間，改在代碼中用Context.registerReceiver(BroadcastReceiver,IntentFilter)注冊也不行，最后參考了Music中的做法，加上了DataScheme才能在onReceive()中接收到Intent。同樣對于后面的Package相關的Broadcast，也是要加上DataScheme否則也是接收不到Broadcast?？杀氖菍τ谙襁@樣的系統(tǒng)公共的Broadcast
Intent，在Intent的文檔中并沒有說明如何使用，如果沒有參考事例，相信需要一定的時間才能夠找出為什么接收不到Intent。
除了DataScheme還有一個是MimeType，這個對于系統(tǒng)公共接口是必須加上的，比如Email要處理Intent.ACTION_SENTTO，就需要這樣聲明：

3. 同時也要注意Category字段
如果沒有對IntentFilter寫正確的Category字段，也是收不到Intent。比如：

如果把Category去掉，死活也接收不到Intent，當然這要取決于Intent是如何發(fā)出的，如果Intent發(fā)出時沒有加Category，那就沒有必須在IntentFilter加上Category。
總之，對于Intent，要保證發(fā)出和接收完全一致，否則系統(tǒng)就無法找到相應的匹配，程序也就無法接收Intent。
有關于 DEFAULT category，也要注意，如果是針對Activity的Implicit Intent隱式Intent，如果在沒有其他Category的情況下，一定要加上DEFAULT Category。因為系統(tǒng)會在Context.startActivity(Intent)和Context.startActivityForResult(
Intent)時給Intent加上DEFAULT category。而對于Context.sendBroadcast(Intent)，Context.sendOrderedBroadcast(Intent)，Contxt.sendStickyBroadcast(Intent)和Context.bindService(Intent)Context.startService(Intent)就不會加DEFAULT Category。
另外要注意，盡量把Action進行合并寫進一個IntentFilter中。因為對于每個IntentFilter標簽都會創(chuàng)建一個IntentFilter對象，所以如果寫幾個就會有幾個對象在那，不但耗費資源而且在匹配的時候也會耗費更多的時間，因為在查詢匹配的時候是要一個IntentFilter對象接著一個IntentFilter對象進行檢查的。直到找到最佳匹配或是到所有的IntentFilter都檢查完為止。
IntentFilter的匹配規(guī)則
1. 通過Action字段來匹配這個是Intent中比較基本的一個字段，也比較簡單，就是一個字串，如果相等就匹配成功，否則證明還沒找到目標。但要注意，如果IntentFilter沒有指定Action，那么它不會匹配到任何的隱式Intent，它只能被顯式的Intent匹配上。反過來，如果Intent自己沒有指定Action，那么它能匹配上含有任何Action的IntentFilter，但不能匹配上沒有指定Action的IntentFilter。對于Action，平時要注意拼寫錯誤，因為在AndroidManifest文件中聲明Action都是字串，并且在編譯時不會做檢查，運行時，如果Action拼錯了導致匹配不上，要么是程序不能正常工作，要么會有異常拋出。
2. 通過Category字段來匹配對于Activity來講，如果想處理隱式Intent，并且除了Intent.ACTION_MAIN以外，必須指定Category為DEFAULT，否則不會被匹配到。因為Context.startActivity()和Context.startActivityForResult()會自動加上DEFAULT Category。其他情況，Service和BroadcastReceiver則不會，對于Service和BroadcastReceiver，如果Intent中沒有指定Category，那么在其IntentFilter中也不必指定。
3. 通過Data字段來匹配這個相對來講比較復雜，通常Data包含uri, scheme(content, file, http)和type(mimeType)對于Intent來講有二個方法：

對于IntentFilter來講，需要設置的是Scheme和Type，Scheme是對Uri的限制，目標需要限制Scheme是因為Scheme能告訴目錄能從哪里拿到Uri所指向的文件，Type是MimeType對類型的限制。

Data匹配時的規(guī)則一共有四條：
a.如果Intent沒有指定Data相關的字段，只能匹配上沒有指定Data的IntentFilter。也就是說如果一個Intent沒有指定任何的Data（Uri和Type），它只能匹配到?jīng)]有指定任何Data（Scheme和Type）的IntentFilter。
b.如果一個Intent只指定了Uri但是沒有Type（并且Type也不能夠從Uri中分析出）只能匹配到僅指定了相應Scheme且沒有指定Type的IntentFilter。實際的例子有如果一個Intent是想要發(fā)郵件，或是打電話，它們的Intent是類似這樣的："mailto:someone@sb.com"和"tel:1234567"。換句話說，這些Uri本身就是數(shù)據(jù)，而不再是一個指向數(shù)據(jù)的地址。比如：Phone中的Dialer就有如下的IntentFilter：

再如，要處理SD狀態(tài)變化的IntentFilter：

再如，要處理Package狀態(tài)變化的IntentFilter：

但是注意，對于想對數(shù)據(jù)進行操作的Intent，最好不要只指定Uri，而不指定類型。因為如果這樣做通常會匹配到一大堆
c. 如果一個Intent只指定了Type，但是沒有指定Uri，它只能匹配到只指定了相應Type且沒有指定Scheme的IntentFitler
d. 如果一個Intent即有Uri又有Type，那么它會匹配上：1).Uri和Type都匹配的IntentFilter；2).首先Type要匹配，另外如果Intent的Uri是content:或file:，且IntentFilter沒有指定Scheme的IntentFilter。因為對于Android來講content和file這二種Scheme是系統(tǒng)最常見也是用的最多的，所以就當成缺省值來對待。
另外需要注意，Type，因為是MimeType，所以是允許使用通配符的，比如'image/*'，能匹配上所有以'image'為開頭的類型，也說是說能匹配上所有的圖像。
根據(jù)Data匹配的例子
假如系統(tǒng)中有四個Activity，A的IntentFilter是這樣子的：

這表明A可以發(fā)送一切圖片類型，并且內容必須是由ContentProvider提供的，也就是Uri必須是以"content://"開頭的
而另外一個Activity B是這樣子聲明的：

這表明B可以發(fā)送一切圖片，但內容必須是單獨的一個文件，也就是Uri必須是由"file://"開頭的
還有一個C是這樣子聲明的：

這表明C只能接收那些沒有指定任何Uri和Type的Action是SEND的Intent。
而D是這樣子聲明的：

這表明D可以發(fā)送一切圖片，無論是數(shù)據(jù)庫內的(content)，還是單獨的文件(file)。
如果一個Intent是這樣寫的：

那么它只能匹配C，因為C沒有指定數(shù)據(jù)和類型，Action是SEND，根據(jù)規(guī)則a，它只能匹配Activity A。但如果給Intent加上額外的條件

那么如果uri是數(shù)據(jù)庫內容，它會匹配到A，如果它是一個文件，會匹配到B。但無論是content還是file都會匹配到D，因為它能處理以任何形式存儲的圖片。但始終不會匹配到C，因為C沒有聲明Data字段，所以不會匹配上。
所以，通常想把組件作為系統(tǒng)公用接口時都是這樣子來寫：

Intent和IntentFilter對于組件Activity來講注意事項比較多，但是對于Service和BroadcastReceiver來說就沒有那么多的注意事項了，因為對于Service和BroadcastReceiver通常都不用設置Category和Data。但也有例外，比如前面所講到的SD相關廣播和應用程序安裝相關廣播。
另外要注意，如果使用Context.startActivity()或Context.startActivityForResult()，Context.bindService()和Context.startService()，如果系統(tǒng)沒有為Intent匹配到目標Activity和Service那么會有RuntimeException(ActivityNotFoundException)拋出;如果有多個目標同時匹配，會以列表的方式來讓用戶選擇使用哪個。
使用IntentFilter匹配來進行查詢可用的組件
Intent和IntentFilter不但可以用來進行組件復用，還可以用于查詢系統(tǒng)內都有哪里組件能做哪些事情。比如Launcher上面會列出很多的應用，其實這種說法不準確，應該是上面列出了所有的能啟動一個應用的組件（比如，Dialer和Contacts同屬于一個應用程序Contacts中，但是在Launcher里面卻有二個，一個是Dialer一個是Contacts。那么Launcher是如何做到的呢？它不可能是去檢查系統(tǒng)文件，看看哪些應用程序文件存在，然后再列出來。它是通過查詢Intent的方式，把所有含有"android.intent.action.MAIN"和"android.intent.category. LAUNCHER"的Activity的相關信息都取出來，然后列出它們的名稱和Icon。同樣，我們也可這樣來獲得具體相應特征的組件