Activity的生命週期
通俗易懂的講解activity的生命週期和啓動模式，
Activity的生命週期全面分析
1.1 典型情況下的生命週期分析
onCreate: 表示activity正在被創建，這是生命週期的第一個方法。這個方法中我們可以做一些初始化操作。
onRestart : 表示Activity正在重新啓動。一般情況下，噹噹前的activity從不可見變爲可見狀態，onRestart就會被重新調用。
onStart: 表示Activity正在被啓動，即將開始，這時Activity已經可見了，但是還沒有出現在前臺，還無法和用戶交互。這個時候其實可以理解爲Activity已經顯示出來了，但是我們還看不到。
onResume: 表示Activity已經可見了，並且出現在前臺並開始活動。要注意這個和onStart的對比，onStart和onResume都表示Activity已經可見，但是onStart的時候Activity還在後臺，onResume的時候Activity才顯示到前臺。
onPause： 表示Activity正在停止。
onStop: 表示Activity即將停止，可以做一些稍微重量級的回收工作，不能太耗時。
onDestroy: 表示Activity即將被銷燬，這是Activity生命週期中的最後一個回調，在這裏，我們可以做一些回收工作和最終的資源釋放。
Activity生命週期過程圖
針對上圖，分幾種情況：
針對一個特定的Activity，第一次啓動，回調如下：onCreate -> onStart -> onResume.
當用戶打開新的Activity或者切換到桌面的時候，回調如下：onPuser-> onStop.這裏有一種特殊情況，如果新Activity採用了透明主題，那麼當前Activity不會回調onStop。
當用戶再次回到原Activity時，回調如下：onRestart -> onStart -> onResume.
當用戶按back鍵回退時，回調如下：onPause -> onStop -> onDestory
當Activity被系統回收再次打開，生命週期方法 回調過程和1 一樣，注意只是生命週期方法一樣，不代表所有過程都一樣。
從整個生命週期來說，onCreate和onDestroy 是配對的，分別標識着Activity的創建和銷燬，並且只可能有一次調用。從Activity 是否可見來說，onStart 和 onStop 是配對的，隨着用戶操作或者設備屏幕的點亮和熄滅，這兩個方法可能被調用多次；從Activity 是否在前臺來說，onResume 和 onPause 是配對的，隨着用戶或者設備屏幕的點亮和熄滅，這兩個方法可能被調用多次。
1.2 異常情況下的生命週期
我們知道，Activity 除了受用戶所導致的正常生命週期方法和調度，還有一些異常情況，比如資源相關的系統配置發生改變以及系統內存不足時，Activity就可能被殺死。下面我們就具體的分析一下這兩種情況。
情況1：資源相關的系統配置發生改變導致Activity被殺死並重新創建
對activity 橫豎屏旋轉，在默認情況下Activity 就會被銷燬重建，我們看一下異常情況下的Activity 重建過程 如下:
Activity -------意外情況-----------> onSaveInstanceState -------------------->onPause、 onStop 、 onDestory ---------------> onCreate ---------> onRestoreInstanceState
當系統配置發生改變後，Activity 會被銷燬，其onPause、 onStop 、 onDestory 均會被調用，同時由於
activity 是在異常情況下終止的，系統會調用onSaveInstanceState 來保存當前Activity 的狀態。這個方法調用時機是在onStop 之前，它和onPause 沒有既定的時序關係，它即可能在onPause 之前調用，也可能在onPause 之後調用。需要強調的一點是，這個方法只會出現在Activity 異常終止的情況下，正常情況下不會回調這個方法。
當Activity 被重新創建後，系統會調用onRestoreInstanceState ，並且把Activity 銷燬時onSaveInstanceState 方法所保存的Bundle 對象作爲參數同時傳遞給onRestoreInstanceState 和 onCreate 方法，因此，我們可以通過onRestoreInstanceState 和 Oncreate 方法來判斷Activity 是否被重建了，如果被重建了，那麼我們就可以取出之前保存的數據並恢復，從時序上來說，onRestoreInstanceState 的調用時機在onStart 之後。
下面我們寫一段代碼，來更好的理解：
@Override
protected void onCreate(Bundle savedInstanceState){
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
if(savedInstanceState !=null){
String test = savedInstanceState.getString("extra_test");
}
}
@Override
protected void onSaveInstanceState(Bundle outState){
super.onSaveInstanceState(outState);
outState.putString("extra_test","test");
}
@Override
protected void onRestoreInstanceState(Bundle savedInstanceState){
super.onRestoreInstanceState(savedInstanceState);
savedInstanceState.getString("extra_test");
}
上面的代碼很簡單，記住 ：只有在Activity 異常終止的時候onSaveInstanceState、onRestoreInstanceState這兩個方法纔會調用
其他情況不會出發這個過程。
情況2：資源內存不足導致低優先級的Activity被殺死
Activity 按照優先級從高到底，可以分爲如下三種：
（1） 前臺Activity ------------ 正在和用戶交互的Activity ，優先級最高。
（2）可見但非前臺Activity ------------比如Activity 中彈出了一個對話框，導致Activity 可見但是位於後臺無法和用戶直接交互。
（3）後臺Activity --------------已經被暫停的Activity ，比如執行了onStop ,優先級最低。
當系統內存不足時，系統就會按照上述優先級去殺死目標Activity 所在的進程，並在後續通過onSaveInstanceState 和 onRestoreInstanceState來存儲和恢復數據。如果一個進程中沒有四大組件在執行，那麼這個進程將很快被系統殺死，因此，一些後臺工作不適合脫離四大組件而獨自運行在後臺中，這樣進程很容易被殺死。比較好的方法是將後臺工作放入Service中從而保證進程有一定的優先級，這樣就不會輕易地被系統殺死。
除了上面的方法，存儲和恢復數據，我們還可以給Activity 指定configChanges 屬性 如：android：configChanges=”orientation|keybordHidden”
如下圖，configChanges的項目和含義
下一章我們 講解Activity的啓動模式
