一、Intent和IntentFilter簡介

一個應用程序的三個核心組件（活動，服務和廣播接收器）都是通過消息即意圖（Intents）來激活的。Intent消息傳送是相同或不同應用中組件運行時晚綁定的一種機制。意圖本身（一個意圖對象）是一個包含被執(zhí)行操作抽象描述的被動的數(shù)據結構?；?，對于廣播而言，是某件已經發(fā)生并被聲明的事情的描述。存在如下幾種不同的機制來傳送意圖到每種組件中：

•  一個意圖對象是傳遞給Context.startActivity()或者Activity.startActivityForResult()來啟動一個活動或者讓一個存在的活動去做某些新的事情。
•  一個意圖對象是傳遞給Context.startService()來發(fā)起一個服務或者遞交新的指令給運行中的服務。類似的，一個意圖能被傳遞給Context.bindService() 來在調用組件和一個目標服務之間建立連接。作為一個可選項，它可以發(fā)起這個服務如果還沒運行的話。
•  傳遞給任意廣播方法(例如Context.sendBroadcast(),Context.sendOrderedBroadcast(),或者Context.sendStickyBroadcast()）的意圖對象被傳遞給所有感興趣的廣播接收者。許多種廣播產生于系統(tǒng)代碼。

在每個例子里，Android系統(tǒng)找到合適的活動、服務或者一組廣播接收者來回應這個意圖，必要時實例化它們。這些消息傳送系統(tǒng)沒有重疊：廣播意圖僅被傳遞給廣播接收者，永遠不會給活動或者服務。一個傳送給startActivity()的意圖是只會被傳遞給一個活動，永遠不會給一個服務或廣播接收者，如此類推。

為了通知系統(tǒng)它們可以處理哪些意圖，活動、服務和廣播接收器可以有一個或多個意圖過濾器。每個過濾器描述組件的一個能力，一系列組件想要接收的意圖。它實際上按照一個期望的類型來進行意圖濾入，同時濾出不想要的意圖-但是只有不想要的隱式意圖會被濾出（那些沒有命名目標的對象類）。一個顯式意圖總能夠被遞交給它的目標，而無論它包含什么。這種情況下過濾器不起作用。但是一個顯式意圖僅當它能通過組件的一個過濾器時才可以被遞交到這個組件。

組件為它能做的每項工作，每個呈現(xiàn)給用戶的不同方面分有不同的過濾器。比如，范例記事本應用程序中的主要活動有三個過濾器：一個是空白板，另一個是用戶可以查看、編輯、或選擇的一個指定的記事目錄，第三是在沒有初始目錄說明的情況下查找一個特定的記錄。一個意圖過濾器是IntentFilter類的一個實例。但是，由于Android系統(tǒng)在啟動一個組件前必須知道這個組件的能力，意圖過濾器通常不會用Java代碼來設置，而是在應用程序清單文件（AndroidManifest.xml）中設置<intent-filter>元素。（有一個例外，通過調用Context.registerReceiver()來注冊的廣播接收器的過濾器；它們是作為意圖過濾器對象而被直接創(chuàng)建的。

二 、過濾器與安全Filters and security

我們不能信賴一個意圖過濾器的安全性。當它打開一個組件來接收某些特定類型的隱式意圖，它并不能阻止以這個組件為目標的顯式意圖。即使過濾器對組件要處理的意圖限制某些動作和數(shù)據源，總有人能把一個顯式意圖和一個不同的動作及數(shù)據源組合在一起，然后命名該組件為目標。

一個過濾器和意圖對象有同樣的動作、數(shù)據以及類別字段。一個隱式意圖在過濾器的所有三個方面都被測試。為了遞交到擁有這個過濾器的組件，它必須通過所有這三項測試。即便只有一個不通過，Android系統(tǒng)都不會把它遞交給這個組件。不過，由于一個組件可以包含多個意圖過濾器，一個不能通過其中一個組件過濾器的意圖可能在另外的過濾器上獲得通過。

與之相關的三個測試詳細描述如下:

測試一：動作測試（Actiontest）

清單文件中的意圖過濾器元素里列舉了動作元素，比如：

<intent-filter. . . > 
<action android:name="com.example.project.SHOW_CURRENT" /> 
<action android:name="com.example.project.SHOW_RECENT" /> 
<action android:name="com.example.project.SHOW_PENDING" /> 
. . . 
</intent-filter> 

如同例子所示，一個意圖對象只對單個動作命名，而一個過濾器可能列舉多個。列表不能為空；一個過濾器必須包含至少一個動作元素，否則它將阻塞所有的意圖。

為了通過這個測試，在意圖對象中指定的動作必須匹配過濾器中所列舉的動作之一。如果意圖對象或過濾器不指定一個動作，結果將是：如果這個過濾器沒有列出任何動作，那意圖就沒有什么可匹配的，因此所有的意圖都會測試失敗。沒有意圖能夠通過這個過濾器。另一方面，一個未指定動作的意圖對象自動通過這個測試-只要過濾器包含至少一個動作。

測試二：類別測試（Categorytest）

一個意圖過濾器<intent-filter>元素也列舉了類別作為子元素。比如：

<intent-filter. . . > 
<category android:name="android.intent.category.DEFAULT" /> 
<category android:name="android.intent.category.BROWSABLE" /> 
. . . 
</intent-filter> 

注意前面描述的動作和類別常量沒有在清單文件中使用。相反使用了完整的字符串。比如，對應于前述CATEGORY_BROWSABLE常量，上面的例子里使用了"android.intent.category.BROWSABLE"字符串。類似的，字符串"android.intent.action.EDIT" 對應于ACTION_EDIT常量。

對一個通過類別測試的意圖，每個意圖對象中的類別必須匹配一個過濾器中的類別。這個過濾器可以列舉另外的類別，但它不能遺漏任何在這個意圖中的類別。

因此，原則上一個沒有類別的意圖對象應該總能夠通過測試，而不管過濾器里有什么。絕大部分情況下這個是對的。但有一個例外，Android把所有傳給startActivity()的隱式意圖當作他們包含至少一個類別："android.intent.category.DEFAULT"（CATEGORY_DEFAULT常量）。 因此，想要接收隱式意圖的活動必須在它們的意圖過濾器中包含"android.intent.category.DEFAULT"。，而帶"android.intent.action.MAIN"和"android.intent.category.LAUNCHER"設置的過濾器是例外。它們標記那些啟動新任務和呈現(xiàn)在啟動屏幕的活動。它們可以在類別列表中包含"android.intent.category.DEFAULT"，但不是必要的。

測試三：數(shù)據測試（Data test）

就像動作和類別，一個意圖過濾器的數(shù)據規(guī)格被包含在一個子元素中。而且這個子元素可以出現(xiàn)多次或一次都不出現(xiàn)。例如：

<intent-filter. . . > 
<data android:type="video/mpeg" android:scheme="http" .. . /> 
<data android:type="audio/mpeg" android:scheme="http" .. . /> 
. . . 
</intent-filter> 

每個數(shù)據<data>元素可以指定一個URI和一個數(shù)據類型（MIME媒體類型）。有一些單獨的屬性-模式，主機，端口和路徑-URI的每個部分：

比如，在下面的URI里面，

模式是"內容"，主機是"com.example.project"，端口是"200"，路經是"folder/subfolder/etc"。主機和端口一起組成URI鑒權（authority）；如果未指定主機，端口會被忽略。

這些屬性都是可選的，但彼此有依賴關系：一個授權要有意義，必須指定一個模式。一個路經要有意義，必須同時指定模式和鑒權。

當一個意圖對象中的URI被用來和一個過濾器中的URI規(guī)格比較時，它實際上比較的是上面提到的URI的各個部分。比如，如果過濾器僅指定了一個模式，所有那個模式的URIs和這個過濾器相匹配；如果過濾器指定了一個模式、鑒權但沒有路經，所有相同模式和鑒權的URIs可以匹配上，而不管它們的路經；如果過濾器指定了一個模式、鑒權和路經，只有相同模式、鑒權和路經的URIs可以匹配上。當然，一個過濾器中的路徑規(guī)格可以包含通配符，這樣只需要部分匹配即可。

數(shù)據<data>元素的類型屬性指定了數(shù)據的MIME類型。這在過濾器里比在URI里更為常見。意圖對象和過濾器都可以使用一個"*"通配符指定子類型字段-比如，"text/*"或者"audio/*"-指示任何匹配的子類型。

數(shù)據測試同時比較意圖對象和過濾器中指定的URI和數(shù)據類型。規(guī)則如下：

1) 一個既不包含URI也不包含數(shù)據類型的意圖對象僅在過濾器也同樣沒有指定任何URIs和數(shù)據類型的情況下才能通過測試。

2) 一個包含URI但沒有數(shù)據類型的意圖對象僅在它的URI和一個同樣沒有指定數(shù)據類型的過濾器里的URI匹配時才能通過測試。這通常發(fā)生在類似于mailto:和tel：這樣的URIs上：它們并不引用實際數(shù)據。

3) 一個包含數(shù)據類型但不包含URI的意圖對象僅在這個過濾器列舉了同樣的數(shù)據類型而且也沒有指定一個URI的情況下才能通過測試。

4) 一個同時包含URI和數(shù)據類型（或者可從URI推斷出數(shù)據類型）的意圖對象可以通過測試，如果它的類型和過濾器中列舉的類型相匹配的話。如果它的URI和這個過濾器中的一個URI相匹配或者它有一個內容content:或者文件file: URI而且這個過濾器沒有指定一個URI，那么它也能通過測試。換句話說，一個組件被假定為支持content:和file: 數(shù)據如果它的過濾器僅列舉了一個數(shù)據類型。

如果一個意圖可以通過不止一個活動或服務的過濾器，用戶可能會被詢問要激活那個組件，并且，如果沒有發(fā)現(xiàn)目標對象將會出現(xiàn)異常。