本章主要學習Activity的生命周期和啟動模式以及IntentFilter的匹配規則分析；其中異常生命周期以及Activity的啟動模式和形形色色的Flags需要注意和細看。
1.1 Activity的生命周期全面分析
1.1.1 典型情況下的生命周期分析
- onStart和onResume都表示Activity可見了，但onStart的時候Activity還在后臺，onResume的時候Activity才顯示到前臺。onStart和onStop是從Activity是否可見這個角度來回調的，而onResume和onPause是從Activity是否位于前臺這個角度來回調的。
- onPause表示Activity正在停止，正常情況下，onStop就會調用，注意onPause不要做太耗時的操作，因為會影響新Activity的顯示，onPause必須先執行完，新的Activity的onResume才會執行。
- 當用戶打開一個新的Activity或者切換回桌面的時候，回調如下：onPause->onStop；但如果新Activity采用了透明主題，則當前Activity不會回調onStop（因為它依然可見）。
1.1.2 異常情況下的生命周期分析
- Activity在異常情況下終止的，系統會調用onSaveInstanceState來保存當前Activity的狀態，在onStop之前，和onPause沒有既定的時序關系；當這個Activity重新創建后，系統會調用onRestoreInstanceState方法并把銷毀前保存的信息傳回， onRestoreInstanceState的調用時機在onStart之后。
- 當Activity異常情況下的情況下需要重新創建時，系統會默認我們保存當前Activity的視圖結果，并在Activity重啟后為我們恢復這些數據，比如文本框用戶輸入的數據，ListView的滾動位置等，
具體可以查看相對應View的源碼，查看onSaveInstanceState和onRestoreInstanceState方法。 - 關于保存和恢復View的層次結構，系統的工作流程：首先Activity會調用onSaveInstanceState去保存數據，然后Activity會委托Window去保存數據，接著Window會委托它上面的頂級容器去保存數據，頂層容器一般是DecorView（ViewGroup)；最后頂層容器再去一一通知它的子元素保存數據，這樣整個數據的保存過程就完成了。
- 如果資源內存不足優先級低的Activity會被殺死，優先級從高到低：
- 前臺Activity-正在和用戶交互優先級最高；
- 可見但非前臺的Activity-比如Activity中彈了一個對話框，導致Activty可見但位于后臺；
- 后臺Activity-已經被暫停的Activity，已經執行了onStop，優先級最低。
- 如果我們不想配置發生改變就Activity重新創建，可以使用Activity的configChanges屬性；常用的有locale、orientation和keyboardHidden這三個選項；指定了configChanges后，Activity發生對應改變后，不會重啟Activity，只會調用onConfigurationChanged方法。
1.2 Activity的啟動模式
1.2.1 Activity的LaunchMode
任務棧是一個“后進先出”的棧結構，每次finish()處于前臺的Activity就會出棧，直到棧為空為止，當棧中無任何Activity的時候，系統就會回收這個任務棧。
四種啟動模式
standard：標準模式，系統默認模式，每次啟動都會創建一個新的實例；在這種模式下，誰啟動了這個Activity，這個Activity就在啟動它的那個Activity所在的棧中。當我們使用ApplicationContext去啟動standard模式的Activity就會報錯，因為standard模式的Activity會默認進入啟動它的Activity所屬的任務棧中，而非Activity類型的Context并沒有任務棧。解決的辦法是為這個待啟動的Activity指定FLAG_ACTIVITY_NEW_TASK標記位，這樣啟動的時候就會為它創建一個新的任務棧。
singleTop: 棧頂復用模式。這種模式下，如果新的Activity已經位于棧頂，那么此Activity不會創建，同時他的onNewIntent方法會被回調，onCreate、onStart不會被調用。如果新的Activity的實例存在但不是位于棧頂，那么新的Activty依然會重新創建。
singleTask: 棧內復用模式。這是一種單實例模式，這種模式下，Activity在一個棧中存在，那么多次啟動該Activity都不會重新創建實例，和sinleTop一樣，系統會回調其onNewIntent。如果啟動的Activity沒有所需要的任務棧，就會先創建任務棧再創建Activity。singleTask默認具有clearTop的效果，具有該模式的Activity會讓其之上的Activity全部出棧。
singleInstance: 單實例模式。這是一種加強的singleTask模式，除了具備singleTask的特性之外，具有該模式的Activity只能單獨位于一個任務棧中；比如Activity A是singleInstance模式的，當A啟動后，系統會為它創建一個新的任務棧，后續的啟動均不會創建新的Activity，除非這個任務棧被系統銷毀了。
參數TaskAffinity用于指定Activity棧，TaskAffinity屬性經常和singleTask啟動模式或allowTaskReparenting屬性配對使用，其他情況沒有意義。當應用A啟動了應用B的某個Activity后，如果這個Activity的allowTaskReparenting屬性為true的話，那么當應用B被啟動后，此Activity會直接從應用A的任務棧轉移到應用B的任務棧中。
Activity的啟動模式可以通過AndroidMenifest為其指定啟動模式
<activity
android:name=".MainActivity"
android:launchMode="singleTask" />
還可以通過在Intent中設置標記位來為Activity指定啟動模式
Intent intent = new Intent(this,MainActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
兩種方法都可以為Activity指定啟動模式，但還是有區別。第二種方式的優先級高于第一種，如果都設置了只有第二種會生效。第一種方式無法直接為Activity設置FLAG_ACTIVITY_CLEAR_TOP標記，而第二種方式無法為Activity指定singleInstance模式。
- 通過adb shell dumpsys activity命令可以詳細的了解當前任務棧情況。
1.2.2 Activity的Flags
- FLAG_ACTIVITY_NEW_TASK
為Activity指定“singleTask”啟動模式，其效果和xml中指定該啟動模式相同。 - FLAG_ACTIVITY_SINGLE_TOP
為Activity指定“singleTop”啟動模式，其效果和xml中指定該啟動模式相同。 - FLAG_ACTIVITY_CLEAR_TOP
具有此標記位的Activity，當他啟動時，在同一個任務棧中所有位于它上面的Activity都要出棧。這個模式一般與FLAG_ACTIVITY_NEW_TASK配合使用，singleTask啟動模式默認具有此標記為的效果。 - FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS
具有這個標記為的Activity不會出現在歷史Activity的列表中，當某些情況不希望用戶通過歷史列表回到我們Activity的時候這邊標記比較有用。等同于在XML中指定Activity的屬性android:excludeFromRecents="true"。
1.3 IntentFilter的匹配規則
啟動Activity分為兩種，顯式調用（明確地指定被啟動對象的組件信息，包括包名和類名）和隱式調用（不需要明確指定組件信息，需要Intent能匹配上目標組件的IntentFilter中所設置的過濾信息）。IntentFilter的過濾信息有action、category、data。為了匹配過濾列表，需同時匹配過濾列表中的action、category、data信息，否則匹配失敗；一個Activity中可以有多個intent-filter，一個Intent只要能匹配任何一組intent-filter即可成功啟動對應的Activity。
-
action的匹配規則
一個過濾規則中可以有多個action,Intent中的action能夠和過濾規則中的任何一個action相同即可匹配成功。如果Intent沒有指定action，那么匹配失敗。action區分大小寫。 -
category的匹配規則
Intent中可以沒有category;如果有，不管有幾個，每個都要能和過濾規則中的任何一個category相同；如果沒有，依然可以匹配成功，原因是因為如果沒有指定category，在調用startActivity或startActivityForResult時系統會默認加上“android.intent.category.DEFAULT”這個category。同時為了我們的Activity能夠支持隱式調用，就必須要在intent-filter中指定“android.intent.category.DEFAULT”這個category。 -
data的匹配規則
data的匹配規則和action類似，如果過濾規則定義了data，那么Intent必須定義可匹配的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。mimeType是指媒體類型，比如image/jpeg、audio/mpeg4-generic和video/等，可以表示圖片、文本、視頻等不同的媒體格式，而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的匹配規則
- 要求Intent中必須含有data數據，并且data數據能夠完全匹配過濾規則中的某一個data；這里的完全匹配是指過濾規則中出現的data部分也出現在了Intent中的data中。
- 如果沒有指定URI，是有默認值的，URI的默認值為content和file。也就是說，雖然沒有指定URI，但Intent中的URI部分的schema必須為content或者file才能匹配。
- 如果要為Intent指定完整的data，必須調用setDataAndType方法，不能先調用setData再調用setType，因為這兩個方法都會清除對方的值。
Tips:
- 當我們隱式啟動一個Activity的時候，可以做一下判斷，看是否能匹配到我們的隱式Intent，如果不做判斷沒找到對應的Activity系統就會拋出android.content.ActivityNotFoundException異常。
第一種：采用PackageManager的resolveActivity方法或者Intent的resolveActivity方法，如果找不到匹配的Activity就會返回null，我們通過判斷返回值就可以規避上述錯誤了。 - 在intent-filter中聲明了<category android:name="android.intent.category.DEFAULT"/>這個category的Activity，才可以接收隱式意圖。
- 有一類action和category的共同作用是標明這是一個入口Activity，并且會出現在系統的應用列表中，少一個都沒有任何意義，也不會出現在系統的應用列表中。
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
寫在最后，主席這本書真的很棒，能學到很多東西，了解系統組件運行原理的同時也不會在茫茫源碼中繞不出來。
最近安排：復習第二 第三 第四章，之后寫第五 第六章的筆記 [開心]。
