一. 正常的生命周期
相關提問：
- onStart和onResume、onPause和onStop從描述上看差不多，對我們來說有什么實質不同？
答：在使用過程中，onStart和onResume、onPause和onStop看起來的確差不多，我們一般都只保留其中一對。Android系統之所以提供這些看起來重復的接口，是因為這兩個配對的回調分別表示不同的意義。onStart和onStop是從Activity是否可見這個角度來回調的，而onResume和onPause是從Activity是否位于前臺這個角度回調的。除了這種區別，在實際使用中沒有其他明顯區別。
onStart：表示Activity正在被啟動，此時Activity已經可見但是還沒有出現在前臺，還在后臺，不能和用戶進行交互。可以理解為Activity已經顯示出來了，但是我們還看不到；
onResume：表示Activity已經可見并且出現在前臺并開始活動；
它兩都表示Activity已經可見，但onStart的時候Activity還在后臺，onResume的時候Activity才顯示到前臺。
- FirstActivity -> SecondActivity，那么SecondActivity的onResume和FirstActivity的onPause哪個先執行？
答：當新啟動一個Activity的時候，舊Activity的onPause會先執行，然后才會啟動新的Activity。onPause和onStop中都不能進行耗時操作，尤其是onPause，所以我們應當盡量在onStop中做操作，使新Activity盡快顯示出來并切換到前臺。如果新啟動的Activity是透明主題，那么當前Activity不會回調onStop。
FirstActivity：onPause
SecondActivity：onCreate
SecondActivity：onStart
SecondActivity：onResume
FirstActivity：onStop
二. 異常情況下的生命周期
異常情況分類：
- 資源相關的系統配置發生改變（比如橫豎屏切換且不做處理）導致Activity被殺死并重新創建
- 資源內存不足導致低優先級的Activity被殺死
注意：
- 由于Activity是在異常情況下終止的，系統會調用onSaveInstanceState來保存當前Activity的狀態。當Activity被重新創建后，可以從onRestoreInstanceState和onCreate中取出之前保存的數據進行恢復。
- 關于保存和恢復View層次結構，系統的工作流程如下：首先Activity被意外終止時，Activity會調用onSaveInstanceState去保存數據，然后Activity委托Window去保存數據，接著Window再委托它上面的頂級容器去保存數據。最后頂層容器再去一一通知它的子元素來保存數據。
onSaveInstanceState方法的調用時機：在onStop之前，和onPause沒有既定的時序關系。這個方法只會出現在Activity異常終止的情況下，正常情況不會回調該方法。
onRestoreInstanceState方法的調用時機：在onStart之后
三. 四種啟動模式
-
standard：標準模式，也是系統的默認模式。每次啟動一個Activity都會創建一個新的實例，不管這個實例是否已經存在。在這種模式下，誰啟動了這個Activity，這個Activity就運行在啟動它的那個Activity所在的棧中。
注意：當用ApplicationContext去啟動這個模式的Activity的時候，會報錯AndroidRuntimeException，因為非Activity類型的Context并沒有所謂的任務棧。解決方法是為待啟動的Activity指定FLAG_ACTIVITY_NEW_TASK標記位，這樣啟動的時候就會為它創建一個新的任務棧，這個時候待啟動Activity實際上是以singleTask模式啟動的。 -
singleTop：棧頂復用模式。在這種模式下，如果新Activity已經位于任務棧的棧頂位置，那么此Activity不會被重新創建，同時它的onNewIntent方法會被回調，通過此方法的參數我們可以取出當前請求的信息。
注意：上述情況下，onCreate、onStart不會被調用。 - singleTask：棧內復用模式。在這種模式下，只要Activity在一個棧中存在，那么多次啟動該Activity都不會重新創建實例，系統也會回調其onNewIntent方法。
- singleInstance：單實例模式。他除了具有singleTask模式的所有特性外，該模式下的Activity只能單獨位于一個任務棧中。解決了共享Activity實例的問題。
TaskAffinity參數：這個參數標識了一個Activity所需要的任務棧的名字，默認情況下，所有Activity所需的任務棧的名字為應用的包名。該屬性主要和singleTask啟動模式或者allowTaskReparenting屬性配對使用，在其他情況下沒有意義。
當TaskAffinity和allowTaskReparenting結合的時候，情況比較復雜。當一個應用A啟動了應用B的某個Activity后，如果這個Activity的allowTaskReparenting屬性為true，那么當應用B被啟動后，此Activity會直接從應用A的任務棧轉移到應用B的任務棧中。
指定啟動模式的方式：
- AndroidMenifest中指定Activity的launchMode。不能直接為Activity設定FLAG_ACTIVITY_CLEAR_TOP標識。
- 在Intent中設置標記位，這種方式優先級高，兩種方式同時存在時，以這種方式為主。無法為Activity指定singleInstance模式。
四. 啟動Activity的方式
- 顯式Intent
- 隱式Intent
隱式調用需要Intent能夠匹配目標組件的IntentFilter中所設置的過濾信息，如果不匹配，將無法啟動目標組件。IntentFilter中的過濾信息有action、category、data。一個Activity中可以有多個IntentFilter，一個IntentFilter中的action、category、data可以有多個，只有一個Intent同時匹配任何一組IntentFilter中的action、category、data類別才算完全匹配，只有完全匹配才能啟動目標組件。
- action匹配規則：區分大小寫，Intent中有一個action和過濾規則中的任何一個action相同即可匹配成功；
- category匹配規則：Intent中的所有category都必須和過濾規則中的一個category相同。為了activity可以接受隱式Intent，就必須在intent-filter中指定"android.intent.category.DEFAULT"這個category，因為系統調用startActivity或startActivityForResult的時候會默認為Intent加上"android.intent.category.DEFAULT"這個category。
- data匹配規則：由兩部分組成，mimeType和URI。匹配規則和action類似。
注意：
當Manifest中有多個Activity與Intent所指定的匹配時，App會彈框出來讓用戶選擇打開方式，每個Activity對應一個App的logo和名稱，并沒有Activity的相關信息。
為了避免找不到匹配的Activity而報錯，可以先判斷一下是否有可匹配的Activity。判斷方法有如下幾種，如果找不到匹配的Activity就會返回null。
- PackageManager的resolveActivity方法：返回最佳匹配的Activity信息
- PackageManager的queryIntentActivities方法：返回所有匹配的Activity信息
- Intent的resolveActivityInfo方法，也是內部調用PackageManager的resolveActivity方法
- Intent的resolveActivity方法，也是內部調用PackageManager的resolveActivity方法
上述方法中，第二個參數需要注意，我們一般使用PackageManager.MATCH_DEFAULT_ONLY這個標記位，這個標記位的含義是僅僅匹配那些在intent-filter中聲明了"android.intent.category.DEFAULT"這個category的Activity。這個標記位的意義在于，只要方法不返回null，就一定可以成功啟動新Activity。原因在category匹配規則中講過。
五. 常用標記位
- FALG_ACTIVITY_EXCLUDE_FROM_RECENTS：具有這個標記位的Activity不會出現在歷史Activity的列表中。相當于xml中指定Activity的屬性android:excludeFromRecents="true"。
