Activity的生命周期分析
- 典型情況下的生命周期。是指在用戶參與的情況下，Activity所經過的生命周期的改變。
- 異常情況下的生命周期。是指Activity被系統回收或者由于當前設備的Configuration發生改變從而導致Activity被銷毀重建，異常情況下的生命周期的關注點和典型情況略有不同。
典型情況下的生命周期
onCreate：表示Activity正在被創建。
onRestart：表示Activity正在重新啟動。
onStart：表示Activity正在被啟動，即將開始，這時Activity已經可見，但是還沒出現在前臺。
onResume：表示Activity已經可見，并且出現在前臺并開始活動。
onPause：表示Activity正在停止，正常情況下，緊接著onStop就會被調用。
onStop：表示Activity即將停止，可以做一些稍微重量級的回收工作，同樣不能太耗時。
onDestroy：表示Activity即將被銷毀，這是Activity生命周期中的最后一個回調，可以做一些回收工作和最終的資源釋放。
注意點：
1，當用戶打開新的Activity或者切換到桌面的時候，回調如下：onPause -> onStop，這里有一種特殊情況，如果新的Activity采用了透明的主題，那么當前Activity不會回調onStop。
2，onStart和onResume、onPause和onStop，有什么實質不同呢。
從Activity是否可見的角度看，onStart和onStop配對，從Activity是否位于前臺這個角度，onResume和onPause配對。
3，假設當前Activity為A，如果這時用戶打卡一個新的Activity B，那么B的onResume和A的onPause哪個先執行。
先會執行A的onPause后，新的Activity才能啟動。官方文檔中有這么一句，不能在onPause中做重量級的操作，因為必須onPause執行完成以后，新的Activity才能Resume。
異常情況下的生命周期分析
1，資源相關的系統配置發生改變導致Activity被殺死并重新創建。
比如當前Activity處于豎屏狀態，突然橫屏了，那么此時系統配置發生了改變，在默認情況下，Activity就會被銷毀并且重新創建，拿的資源圖片就會不一樣，當系統配置發生變化之后，Activity會被銷毀，其中onPause、onStop、onDestroy均會被調用，由于Activity是在異常情況下終止的，系統就會調用onSaveInstanceState來保存當前的Activity狀態，這個方法是在onStop之前，它和onPause沒有既定的時序關系，可能在onPause之前，也可能在onPause之后調用，需要強調下， 這個方法只會在Activity背異常終止的情況下調用，正常情況下系統不會回調這個方法。當Activity重新創建后，系統會調用onRestoreInstanceSate，并且把之前保存的數據恢復回來。
關于保存和恢復View層次結構，系統的工作流程是這樣的：首先Activity被意外終止時，Activity會調用onSaveInstanceState去保存數據，然后Activity會委托Window去保存數據，接著Window再委托它上面的頂級容器去保存數據，頂級容器是一個ViewGroup，一般來說它很可能是DecorView。最后頂層容器再去一一通知它的子元素來保存。這是一種典型的委托思想，上層委托下層，父容器委托子元素去處理一件事，這種思想在Android中很常見，比如View的繪制過程，事件分發等等。
總之，系統只有在Activity異常終止的情況下才會調用onSaveInstanceState和onRestoreInstanceSate來存儲和恢復數據，其他情況下不會觸發這個過程。
2，資源內存不足導致優先級低的Activity被殺死
Activity按照優先級從高到低，可以分為三種。
- 前臺Activity—正在和用戶交互的Activity，優先級最高
- 可見但非前臺Activity—比如Activity中彈出了一個對話框，導致Activity可見但是位于后臺無法和用戶直接交互
- 后臺Activity—已經被暫停的Activity，比如執行了onStop，優先級最低
當系統內存不足時，系統就會按照上述優先級去殺死目標Activity所在的進程，并后續通過onSaveInstanceState和onRestoreInstanceSate來存儲和恢復數據，如果一個進程中沒有四大組件在執行，那么這個進程將很快被系統殺死，因此，比較好的方法是將后臺工作放入Service中從而保證進程有一定的優先級，這樣就不會輕易地被系統殺死。
Activity的啟動模式
Activity的LaunchMode
- standard：標準模式，系統默認模式。每次啟動一個Activity都會重新創建一個新的實例，不管這個實例是否已經存在。在這個模式下，誰啟動了Activity，那么這個Activity就運行在啟動它的那個Activity所在棧中。
- singleTop：棧頂復用模式。在這種模式下，如果新的Activity已經位于任務棧頂，那么此Activity不會被重新創建，同時它的onNewIntent方法會被回調，通過此方法的參數我們可以取出當前的請求信息
- singleTask：棧內復用模式。這是一種單例模式，在這種模式下，只要Activity在一個棧中存在，那么多次啟動此Activity都不會創建實例，和singleTop是一樣，系統也會調用onNewIntent。還有一點，就是singleTask有clearTop的效果，會導致棧內已有的Activity全部出棧。
- singleInstance：單一實例模式。這是一種加強的singleTask模式，它除了具有singleTask的所有特性以外，還加強了一點，那就是具有此模式的Activity只能單獨位于一個任務棧中，比如Activity A是singleInstance模式，當A啟動后，系統會為它創建一個新的任務棧，然后A獨自在這個新的任務棧中，由于棧內復用的特性，后續均不會創建新的Activity，除非這個獨特的任務棧被系統銷毀。整個手機操作系統里面只有一個實例存在。不同的應用去打開這個activity 共享公用的同一個activity。他會運行在自己單獨，獨立的任務棧里面，并且任務棧里面只有他一個實例存在。
如何給Activity指定啟動模式，有兩種方法，第一種是通過AndroidMenifest.xml
<activity
android:name="com.ryg.chapter_1.SecondActivity"
android:configChanges="screenLayout"
android:label="@string/app_name"
android:launchMode="standard"
android:taskAffinity="com.ryg.task1" />
另外一種情況是通過Intent中設置標志位來為Activity指定啟動模式。
Intent intent = new Intent();
intent.setClass(MainActivity.this, SecondActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
這兩者是有區別的，首先，在優先級上，第一種方式優先級要高于第一種，當兩種同時存在的時候，以第二種方式為準，第一種方式無法直接為Activity設為FLAG_ACTIVITY_CLEAR_TOP標識，而第二種方式無法為Activity指定singleInstance模式。
standard使用場景：
- 郵件客戶端，在新建一個郵件的時候，適合新建一個新的實例
singleTop使用場景：
- 消息推送，通知欄彈出Notification，點擊Notification跳轉到指定Activity，使用singleTop避免生成重復的頁面。
- 登錄的時候，登錄成功跳轉到主頁，按下兩次登錄按鈕，使用singleTask避免生成兩個主頁。
- 從activity A啟動了個service進行耗時操作，或者某種監聽，這個時候你home鍵了，service收集到信息，要返回activityA。
singleTask使用場景：
- 提供給第三方應用調用的頁面，做瀏覽器、微博之類的應用，瀏覽器的主界面等等。
- 程序的主界面，進入多層嵌套之后，一鍵退回，之前打開的Activity全部出棧。
singleInstance使用場景：
- 呼叫來電界面，打電話、發短信功能。
- 鬧鈴提醒，將鬧鈴提醒與鬧鈴設置分離。
Activity的Flags
FLAG_ACTIVITY_NEW_TASK：這個標記位的作用是為Activity指定“singleTask”啟動模式，其效果和在XML中指定該模式相同。
FLAG_ACTIVITY_SINGLE_TOP：這個標記位的作用是為Activity指定“singleTop”啟動模式，其效果和在XML中指定該模式相同。
FLAG_ACTIVITY_CLEAR_TOP：具有次標記位的Activity，當它啟動時，在同一個任務棧中所有位于它上面的Activity都要出棧，這個標記位一般會和singleTask啟動模式一起出現。如果被啟動的Activity的實例已經存在，那么系統就會調用它的onNewIntent
