### 1.3 IntentFilter的匹配規則
我們知道,啟動Activity分為兩種,顯式調用和隱式調用。二者的區別這里就不多說了,**顯式調用需要明確地指定被啟動對象的組件信息,包括包名和類名,而隱式調用則不需要明確指定組件信息**。原則上一個Intent不應該既是顯式調用又是隱式調用,如果二者共存的話**以顯式調用為主**。顯式調用很簡單,這里主要介紹一下隱式調用。
**隱式調用需要Intent能夠匹配目標組件的IntentFilter中所設置的過濾信息,如果不匹配將無法啟動目標Activity**。IntentFilter中的過濾信息有action、category、data,下面是一個過濾規則的示例:
<activity
android:name="com.ryg.chapter_1.ThirdActivity"
android:configChanges="screenLayout"
android:label="@string/app_name"
android:launchMode="singleTask"
android:taskAffinity="com.ryg.task1" >
<intent-filter >
<action android:name="com.ryg.charpter_1.c"/>
<action android:name="com.ryg.charpter_1.d"/>
<category android:name="com.ryg.category.c"/>
<category android:name="com.ryg.category.d"/>
<category android:name="android.intent.category.DEFAULT"/>
<data android:mimeType="text/plain"/>
</intent-filter>
</activity>
為了匹配過濾列表,**需要同時匹配過濾列表中的action、category、data信息,否則匹配失敗。一個過濾列表中的action、category和data可以有多個,所有的action、category、data分別構成不同類別,同一類別的信息共同約束當前類別的匹配過程。只有一個Intent同時匹配action類別、category類別、data類別才算完全匹配,只有完全匹配才能成功啟動目標Activity。另外一點,一個Activity中可以有多個intent-filter,一個Intent只要能匹配任何一組intent-filter即可成功啟動對應的Activity**,如下所示。
<activity android:name="ShareActivity">
<! -- This activity handles "SEND" actions with text data -->
<intent-filter>
<action android:name="android.intent.action.SEND"/>
<category android:name="android.intent.category.DEFAULT"/>
<data android:mimeType="text/plain"/>
</intent-filter>
<! -- This activity also handles "SEND" and "SEND_MULTIPLE" with media
data -->
<intent-filter>
<action android:name="android.intent.action.SEND"/>
<action android:name="android.intent.action.SEND_MULTIPLE"/>
<category android:name="android.intent.category.DEFAULT"/>
<data android:mimeType="application/vnd.google.panorama360+jpg"/>
<data android:mimeType="image/*"/>
<data android:mimeType="video/*"/>
</intent-filter>
</activity>
下面詳細分析各種屬性的匹配規則。
#### 1.action的匹配規則
action是一個字符串,**系統預定義了一些action,同時我們也可以在應用中定義自己的action。action的匹配規則是Intent中的action必須能夠和過濾規則中的action匹配,這里說的匹配是指action的字符串值完全一樣。一個過濾規則中可以有多個action,那么只要Intent中的action能夠和過濾規則中的任何一個action相同即可匹配成功**。針對上面的過濾規則,只要我們的Intent中action值為“`com.ryg.charpter_1.c`”或者“`com.ryg.charpter_ 1.d`”都能成功匹配。
需要注意的是,Intent中如果沒有指定action,那么匹配失敗。總結一下,**action的匹配要求Intent中的action存在且必須和過濾規則中的其中一個action相同,這里需要注意它和category匹配規則的不同**。另外,**action區分大小寫,大小寫不同字符串相同的action會匹配失敗**。
#### 2.category的匹配規則
category是一個字符串,**系統預定義了一些category,同時我們也可以在應用中定義自己的category**。category的匹配規則和action不同,它**要求Intent中如果含有category,那么所有的category都必須和過濾規則中的其中一個category相同**。換句話說,**Intent中如果出現了category,不管有幾個category,對于每個category來說,它必須是過濾規則中已經定義了的category。當然,Intent中可以沒有category,如果沒有category的話,按照上面的描述,這個Intent仍然可以匹配成功**。
這里要注意下它和action匹配過程的不同,**action是要求Intent中必須有一個action且必須能夠和過濾規則中的某個action相同,而category要求Intent可以沒有category,但是如果你一旦有category,不管有幾個,每個都要能夠和過濾規則中的任何一個category相同**。為了匹配前面的過濾規則中的category,我們可以寫出下面的Intent, `intent.addcategory (“com.ryg.category.c”)`或者`Intent. addcategory (“com.ryg. category.d”)`亦或者不設置category。
**為什么不設置category也可以匹配呢?原因是系統在調用startActivity或者startActivityForResult的時候會默認為Intent加上“`android.intent. category.DEFAULT`”這個category,所以這個category就可以匹配前面的過濾規則中的第三個category。同時,為了我們的activity能夠接收隱式調用,就必須在intent-filter中指定“`android.intent.category.DEFAULT`”這個category,原因剛才已經說明了,也就是說,不含有DEFAULT這個category的Activity是無法接收隱式Intent的**。
#### 3.[data](https://developer.android.google.cn/guide/topics/manifest/data-element)的匹配規則
data的匹配規則和action類似,**如果過濾規則中定義了data,那么Intent中必須也要定義可匹配的data**。在介紹data的匹配規則之前,我們需要先了解一下data的結構,因為data稍微有些復雜。
data的語法如下所示。
<data android:scheme="string"
android:host="string"
android:port="string"
android:path="string"
android:pathPattern="string"
android:pathPrefix="string"
android:mimeType="string" />
**data由兩部分組成,mimeType和URI。向 Intent 過濾器(過濾規則)添加數據規范。該規范可以是只有數據類型([mimeType](https://developer.android.google.cn/guide/topics/manifest/data-element#mime)屬性),可以是只有 URI,也可以是既有數據類型又有 URI。**
**mimeType指媒體類型,比如image/jpeg、audio/mpeg4-generic和video/等,可以表示圖片、文本、視頻等不同的媒體格式**,而**URI中包含的數據就比較多了,下面是URI的結構**:
**URI 由其各個部分的單獨屬性指定**:
```
<scheme>://<host>:<port>/[<path>|<pathPrefix>|<pathPattern>]
```
這里再給幾個實際的例子就比較好理解了,如下所示。
```
content://com.example.project:200/folder/subfolder/etc
http://www.baidu.com:80/search/info
```
看了上面的兩個示例應該就瞬間明白了,沒錯,就是這么簡單。不過下面還是要介紹一下每個數據的含義。
* **Scheme:URI的模式**,比如http、file、content等,**如果URI中沒有指定scheme,那么整個URI的其他參數無效,這也意味著URI是無效的**。
* **Host:URI的主機名**,比如`www.baidu.com`,**如果host未指定,那么整個URI中的其他參數無效,這也意味著URI是無效的**。
* **Port:URI中的端口號**,比如80,**僅當URI中指定了scheme和host參數的時候port參數才是有意義的**。
* Path、pathPattern和pathPrefix:這三個參數表述路徑信息,其中
* path表示**完整的路徑信息**;
* **pathPattern也表示完整的路徑信息**,但是它里面可以包含通配符“`*`”, “`*`”表示0個或多個任意字符,需要注意的是,由于正則表達式的規范,如果想表示真實的字符串,那么“`*`”要寫成“`\\*`”, “`\`”要寫成“`\\\\`”;
* pathPrefix表示路徑的前綴信息。
介紹完data的數據格式后,我們要說一下data的匹配規則了。前面說到,**data的匹配規則和action類似,它也要求Intent中必須含有data數據,并且data數據能夠完全匹配過濾規則中的某一個data**.這里的**完全匹配是指過濾規則中出現的data部分也出現在了Intent中的data中**。下面分情況說明。
(1)如下過濾規則:
<intent-filter>
<data android:mimeType="image/*" />
...
</intent-filter>
**這種規則指定了媒體類型為所有類型的圖片**,那么**Intent中的mimeType屬性必須為“image/*”才能匹配**,這種情況下**雖然過濾規則沒有指定URI,但是卻有默認值,URI的默認值為content和file。也就是說,雖然沒有指定URI,但是Intent中的URI部分的schema必須為content或者file才能匹配**,這點是需要尤其注意的。為了匹配(1)中規則,我們可以寫出如下示例:
```
intent.setDataAndType(Uri.parse("file://abc"), "image/png")
```
另外,**如果要為Intent指定完整的data,必須要調用setDataAndType方法,不能先調用setData再調用setType,因為這兩個方法彼此會清除對方的值**,這個看源碼就很容易理解,比如setData:
public Intent setData(Uri data) {
mData = data;
mType = null;
return this;
}
可以發現,**setData會把mimeType置為null,同理setType也會把URI置為null**。
(2)如下過濾規則:
<intent-filter>
<data android:mimeType="video/mpeg" android:scheme="http" ... />
<data android:mimeType="audio/mpeg" android:scheme="http" ... />
...
</intent-filter>
**這種規則指定了兩組data規則,且每個data都指定了完整的屬性值,既有URI又有mimeType**。為了匹配(2)中規則,我們可以寫出如下示例:
```
intent.setDataAndType(Uri.parse("http://abc"), "video/mpeg")
```
或者
```
intent. setDataAndType (Uri.parse("http://abc"), "audio/mpeg")
```
通過上面兩個示例,讀者應該已經明白了data的匹配規則,關于data還有一個特殊情況需要說明下,這也是**它和action不同的地方,如下兩種特殊的寫法(寫法不同),但它們的作用是一樣的**:
<intent-filter . . . >
<data android:scheme="file" android:host="www.baidu.com" />
. . .
</intent-filter>
<intent-filter . . . >
<data android:scheme="file" />
<data android:host="www.baidu.com" />
. . .
</intent-filter>
到這里我們已經把IntentFilter的過濾規則都講解了一遍,還記得本節前面給出的一個intent-filter的示例嗎?現在我們給出完全匹配它的Intent:
Intent intent = new Intent("com.ryg.charpter_1.c");
intent.addCategory("com.ryg.category.c");
intent.setDataAndType(Uri.parse("file://abc"), "text/plain");
startActivity(intent);
還記得URI的schema是有默認值的嗎?如果把上面的`intent.setDataAndType (Uri.parse("file://abc"), "text/plain")`這句改成`intent.setDataAndType(Uri.parse("http://abc"),"text/plain")`,打開Activity的時候就會報錯,提示無法找到Activity,如圖1-10所示。另外一點,**Intent-filter的匹配規則對于Service和BroadcastReceiver也是同樣的道理,不過系統對于Service的建議是盡量使用顯式調用方式來啟動服務,而且在Android8.0系統之后,所有隱式廣播都不允許使用靜態注冊的方式來接收了。隱式廣播指的是那些沒有具體制定發送給哪個應用程序的廣播,大多數系統廣播屬于隱式廣播,但是極少數特殊的系統廣播目前仍然允許使用靜態注冊的方式來接收。詳見——[隱式廣播例外情況](https://developer.android.google.cn/guide/components/broadcast-exceptions)**。
:-: 
圖1-10 系統日志
最后,當我們**通過隱式方式啟動一個Activity的時候,可以先做一下判斷,看是否有Activity能夠匹配我們的隱式Intent,如果不做判斷就有可能出現上述的錯誤了。判斷方法有兩種:
①、采用PackageManager的resolveActivity方法或者Intent的resolveActivity方法,如果它們找不到匹配的Activity就會返回null,我們通過判斷返回值就可以規避上述錯誤了。
②、另外,PackageManager還提供了queryIntentActivities方法,這個方法和resolveActivity方法不同的是:它不是返回最佳匹配的Activity信息而是返回所有成功匹配的Activity信息**。
我們看一下queryIntentActivities和resolveActivity的方法原型:
```
public abstract List<ResolveInfo> queryIntentActivities(Intent intent, int flags);
public abstract ResolveInfo resolveActivity(Intent intent, int flags);
```
上述兩個方法的第一個參數比較好理解,**第二個參數需要注意,我們要使用MATCH_DEFAULT_ONLY這個標記位,這個標記位的含義是僅僅匹配那些在intent-filter中聲明了`<category android:name="android.intent.category.DEFAULT"/>`這個category的Activity。使用這個標記位的意義在于,只要上述兩個方法不返回null,那么startActivity一定可以成功。如果不用這個標記位,就可以把intent-filter中category不含DEFAULT的那些Activity給匹配出來,從而導致startActivity可能失敗。因為不含有DEFAULT這個category的Activity是無法接收隱式Intent的**。
在action和category中,有一類action和category比較重要,它們是:
```
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
```
這二者**共同作用是用來標明這是一個入口Activity并且會出現在系統的應用列表中,少了任何一個都沒有實際意義,也無法出現在系統的應用列表中,也就是二者缺一不可**。
另外,針對Service和BroadcastReceiver, PackageManager同樣提供了類似的方法去獲取成功匹配的組件信息。
- 前言
- 第1章 Activity的生命周期和啟動模式
- 1.1 Activity的生命周期全面分析
- 1.1.1 典型情況下的生命周期分析
- 1.1.2 異常情況下的生命周期分析
- 1.2 Activity的啟動模式
- 1.2.1 Activity的LaunchMode
- 1.2.2 Activity的Flags
- 1.3 IntentFilter的匹配規則
- 第2章 IPC機制
- 2.1 Android IPC簡介
- 2.2 Android中的多進程模式
- 2.2.1 開啟多進程模式
- 2.2.2 多進程模式的運行機制
- 2.3 IPC基礎概念介紹
- 2.3.1 Serializable接口
- 2.3.2 Parcelable接口
- 2.3.3 Binder
- 2.4 Android中的IPC方式
- 2.4.1 使用Bundle
- 2.4.2 使用文件共享
- 2.4.3 使用Messenger
- 2.4.4 使用AIDL
- 2.4.5 使用ContentProvider
- 2.4.6 使用Socket
- 2.5 Binder連接池
- 2.6 選用合適的IPC方式
- 第3章 View的事件體系
- 3.1 View基礎知識
- 3.1.1 什么是View
- 3.1.2 View的位置參數
- 3.1.3 MotionEvent和TouchSlop
- 3.1.4 VelocityTracker、GestureDetector和Scroller
- 3.2 View的滑動
- 3.2.1 使用scrollTo/scrollBy
- 3.2.2 使用動畫
- 3.2.3 改變布局參數
- 3.2.4 各種滑動方式的對比
- 3.3 彈性滑動
- 3.3.1 使用Scroller7
- 3.3.2 通過動畫
- 3.3.3 使用延時策略
- 3.4 View的事件分發機制
- 3.4.1 點擊事件的傳遞規則
- 3.4.2 事件分發的源碼解析
- 3.5 View的滑動沖突
- 3.5.1 常見的滑動沖突場景
- 3.5.2 滑動沖突的處理規則
- 3.5.3 滑動沖突的解決方式
- 第4章 View的工作原理
- 4.1 初識ViewRoot和DecorView
- 4.2 理解MeasureSpec
- 4.2.1 MeasureSpec
- 4.2.2 MeasureSpec和LayoutParams的對應關系
- 4.3 View的工作流程
- 4.3.1 measure過程
- 4.3.2 layout過程
- 4.3.3 draw過程
- 4.4 自定義View
- 4.4.1 自定義View的分類
- 4.4.2 自定義View須知
- 4.4.3 自定義View示例
- 4.4.4 自定義View的思想
- 第5章 理解RemoteViews
- 5.1 RemoteViews的應用
- 5.1.1 RemoteViews在通知欄上的應用
- 5.1.2 RemoteViews在桌面小部件上的應用
- 5.1.3 PendingIntent概述
- 5.2 RemoteViews的內部機制
- 5.3 RemoteViews的意義
- 第6章 Android的Drawable
- 6.1 Drawable簡介
- 6.2 Drawable的分類
- 6.2.1 BitmapDrawable2
- 6.2.2 ShapeDrawable
- 6.2.3 LayerDrawable
- 6.2.4 StateListDrawable
- 6.2.5 LevelListDrawable
- 6.2.6 TransitionDrawable
- 6.2.7 InsetDrawable
- 6.2.8 ScaleDrawable
- 6.2.9 ClipDrawable
- 6.3 自定義Drawable
- 第7章 Android動畫深入分析
- 7.1 View動畫
- 7.1.1 View動畫的種類
- 7.1.2 自定義View動畫
- 7.1.3 幀動畫
- 7.2 View動畫的特殊使用場景
- 7.2.1 LayoutAnimation
- 7.2.2 Activity的切換效果
- 7.3 屬性動畫
- 7.3.1 使用屬性動畫
- 7.3.2 理解插值器和估值器 /
- 7.3.3 屬性動畫的監聽器
- 7.3.4 對任意屬性做動畫
- 7.3.5 屬性動畫的工作原理
- 7.4 使用動畫的注意事項
- 第8章 理解Window和WindowManager
- 8.1 Window和WindowManager
- 8.2 Window的內部機制
- 8.2.1 Window的添加過程
- 8.2.2 Window的刪除過程
- 8.2.3 Window的更新過程
- 8.3 Window的創建過程
- 8.3.1 Activity的Window創建過程
- 8.3.2 Dialog的Window創建過程
- 8.3.3 Toast的Window創建過程
- 第9章 四大組件的工作過程
- 9.1 四大組件的運行狀態
- 9.2 Activity的工作過程
- 9.3 Service的工作過程
- 9.3.1 Service的啟動過程
- 9.3.2 Service的綁定過程
- 9.4 BroadcastReceiver的工作過程
- 9.4.1 廣播的注冊過程
- 9.4.2 廣播的發送和接收過程
- 9.5 ContentProvider的工作過程
- 第10章 Android的消息機制
- 10.1 Android的消息機制概述
- 10.2 Android的消息機制分析
- 10.2.1 ThreadLocal的工作原理
- 10.2.2 消息隊列的工作原理
- 10.2.3 Looper的工作原理
- 10.2.4 Handler的工作原理
- 10.3 主線程的消息循環
- 第11章 Android的線程和線程池
- 11.1 主線程和子線程
- 11.2 Android中的線程形態
- 11.2.1 AsyncTask
- 11.2.2 AsyncTask的工作原理
- 11.2.3 HandlerThread
- 11.2.4 IntentService
- 11.3 Android中的線程池
- 11.3.1 ThreadPoolExecutor
- 11.3.2 線程池的分類
- 第12章 Bitmap的加載和Cache
- 12.1 Bitmap的高效加載
- 12.2 Android中的緩存策略
- 12.2.1 LruCache
- 12.2.2 DiskLruCache
- 12.2.3 ImageLoader的實現446
- 12.3 ImageLoader的使用
- 12.3.1 照片墻效果
- 12.3.2 優化列表的卡頓現象
- 第13章 綜合技術
- 13.1 使用CrashHandler來獲取應用的crash信息
- 13.2 使用multidex來解決方法數越界
- 13.3 Android的動態加載技術
- 13.4 反編譯初步
- 13.4.1 使用dex2jar和jd-gui反編譯apk
- 13.4.2 使用apktool對apk進行二次打包
- 第14章 JNI和NDK編程
- 14.1 JNI的開發流程
- 14.2 NDK的開發流程
- 14.3 JNI的數據類型和類型簽名
- 14.4 JNI調用Java方法的流程
- 第15章 Android性能優化
- 15.1 Android的性能優化方法
- 15.1.1 布局優化
- 15.1.2 繪制優化
- 15.1.3 內存泄露優化
- 15.1.4 響應速度優化和ANR日志分析
- 15.1.5 ListView和Bitmap優化
- 15.1.6 線程優化
- 15.1.7 一些性能優化建議
- 15.2 內存泄露分析之MAT工具
- 15.3 提高程序的可維護性