activity的生命周期，作為Android的入門必備知識要領，activity的生命周期的重要性不言而喻。任何數據、交互都是由activity來呈現。
點這裡，這是官方文檔對activity生命周期的描述。如果嫌英文看起來費勁兒，那麼，下面的介紹或許對於快速的了解activity生命周期有所助益。
教程上對activity 的生命周期一般都相對死板、難記。這裡，我會結合自己的經驗，分 為什麼 ，是什麼 ， 雷區三個方面進行描述。
為什麼要了解activity 的生命周期？
這得從android應用開發的框架的宏觀層面說起。android應用android的應用程序有四大組件：
activity：通常展現為一個可視化的用戶界面，可以理解為UI展現的載體。一般能處理一些簡單的應用邏輯，但為了不阻礙界面交互的及時性，並不適用於大量的運算。
service：負責後台運行，沒有用戶界面，跟activity相輔相成。
broadcast reciver：不執行任何任務，僅僅是接受並響應廣播通知的一類組件。這是整個app framwork下，應用功能復用的基石。
content provider：android是基於linux內核的。android下每個app都擁有一個用戶名，獨立的執行自己的進程。content provider為不同進程間的數據訪問提供的可能。比如在app中加入通訊錄功能，都通過它來完成。
近幾年移動市場發展很快，但主流手機的資源配置仍然與電腦相比仍然相去甚遠。應用框架的特性也是著力與解決這種資源的緊缺。
經過上面的文字，大家已經知道，activity控制著界面的顯示。作為與用戶交互的門面，activity狀態控制是容不得半點馬虎的。android使用activity棧（stack）來控制activity。
當前運行的activity，也就是當前顯示並運行在屏幕上的activity，處於棧頂的位置。
當調用intent進入一個新的activity時，原先的activity就被新的activity壓到棧內。
有時候，手機開啟了多個app，內存資源緊缺，android為了保證當前app運行的良好，采用了銷毀暫時不用的activity的辦法。在這裡，那些被壓入activity棧內的不可見的activity就有危險了，系統可能犧牲它們來換取當前運行app的良好表現。注意，有種特殊情況，當正在運行的新activity並非全屏的或者半透明的時候，下面的activity依然可見，這時候那個作為背景的activity雖然已經停止運行，被從棧頂擠壓到棧裡，但卻是萬萬不能銷毀的啦，否則，就違背了android保證當前app運行的原則啦！（其實在app開發中為了達到好的視覺效果，這種狀態的activity是很常見的）。於是，為了管理的方便，將activity的狀態劃分為如下幾種： 當前運行的activity，未運行但可見的activity（前面這種特殊情況），未運行且不可見的activity，當然還有就是已經掛掉或者還未生成的activity（被解析掉了或者還不存在的activity）。
這或許就是生命周期存在的緣由。針對不同的狀態，執行不同的功能，以免亂套。
計算機界有句話，“計算機裡，任何問題都可以通過分層的方法來解決。” activity生命周期的劃分大概也是使用了這種思想。分而治之，不同生命狀態對應著不同的功能。
於是就有了下面這幅經典的activity lifecycle state 圖。
Activity生命周期是怎麼樣的？
結合上面的文字，仔細看圖。
看起來錯綜復雜，其實理解了上面那段話，也就基本掌握了脈絡。
常規的，activity的創建必須經歷 onCreate() --> onStart() --> onResume() 的過程，才能真正展現在你我眼前。
對應的“死亡”過程為onPause() --> onStop() --> onDestory().
回憶一下，根據之前的分析，activity的主要狀態為4種
1，當前運行的activity
2，未運行但可見的activity
3，未運行且不可見的activity
4，不存在的activity
對應的每種狀態之間的跳轉需要一個激發：
1 --> 2 onPause() ##### 2 --> 1 onResume()
2 --> 3 onStop() ##### 3 --> 2 onStart()
3 --> 4 onDestory() ##### 4 --> 3 onCreate()
對於最基礎的一個activity完全切換到另一個activity，一般會連環調用onPause(),onStop()，即舊的activity由狀態1變為狀態3.
對於有透明效果的activity的切換，舊activity沒有完全從屏幕中離開，此時只對舊activity調用了pnPause()，處於狀態2，未進入狀態3.
小心踩雷
1，activity中調用dialog，雖然dialog被放在最前面，但dialog並不是一個activity。原來的activity是不會onPause的。
2，橫豎屏切換的時候，activity是會被銷毀再重建的。這裡可用onSaveInstanceState方法儲存需要的狀態數據，並利用onRestoreInstanceState回復狀態（onRestoreInstanceState(Bundle)裡傳入的Bundle參數是由onSaveInstanceState封裝好的）。關於onSaveInstanceState的調用的詳細介紹，點這裡
3，如果activity中內容夠多，在切換時，可能產生延遲。如果同時原來的activity還有背景音樂的控制能時，在onPause , onStop,還是onDestory中暫停音樂就比較關鍵了。不同選擇有不同的用戶體驗效果。一般的，在哪個方法中存儲數據，就在對應的回復方法中恢復數據，是相對安全的（比如在onStop中存儲數據，在onStart中恢復數據），當然有特例。
4，一般來說，在重寫onResume()等方法的代碼時：如果是初始化一個activity，將自己的代碼寫在super方法的後面，讓系統完成基本資源的初始化後，再執行自己的初始化代碼。如果是結束一個activity，則將自己的代碼寫在super方法的前面，以免系統提前結束相應功能，妨礙自己的代碼執行。當然，也有特例（For example, the theme I wanted to apply to my PreferenceActivity wouldn't take effect unless I put it before the superclass's onCreate(). ）