本篇不針對于新手，而是對于Activity中一些常識或者問題進行總結。Activity是Android四大組件之一，為用戶提供與系統交互的界面，每一個應用都有一個或者多個Acticity，這樣會有各種各樣的細節問題需要查找，我將本人接觸到的知識點匯總到此篇文章。
Activity生命周期的回調主要有onCreate()、onRestart()、onStart()、onResume()、onPause()、onStop()、onDestory()這幾個方法，Activity的生命周期類別主要分為三種，如下。
Activity生命周期圖如下：
被啟動的Activity必須要在AndroidManifest.xml文件中聲明，否則會拋出異常。
正常啟動一個Activity的代碼如下：
啟動一個Activity并獲取其執行結果。
需要當前Activity重寫onActivityResult()方法以獲取結果。
finish()結束當前的Activity
finishActivity(int requestCode)結束當前Activity使用startActivityForResult()方法啟動的子Activity
當一個Activity A去啟動一個新的Activity B時候，A和B的生命周期并不是依次進行，也就是說它們的生命周期會有所重疊。在創建B的時候，A不會完全停止，更確切的說，啟動B的過程與A停止的過程會有重疊。所以A和B生命周期回調的順序就很重要了，回調順序如下。
在知道了從一個Activity到另一個Activity轉變時候生命周期的順序，平時研發時候就需要注意了。例如，當必須在個Activity停止之前存儲數據，以便下一個Activity能夠使用，應該在onPause()方法中儲存而不是onStop()方法中。
用戶與頁面交互過程中，會出現應用前后臺切換或者進入其他頁面等等的情況，也就是Activity調用暫停(onPause)或者停止(onStop)但是未調用(onDestroy)，此時Activity仍然在內存中，其有關狀態和成員信息處于活躍狀態，用戶在Activity中所作的任何更改都會得到保留，這樣一來，當Activity返回前臺繼續執行時候，這些更改信息依然存在，頁面能夠繼續顯示。
但是一旦系統需要內存而將某個Activity銷毀時，當再次回到這個Activity，系統需要重建這個Activity，但是用戶并不知道系統銷毀了這個Activity需要重建，他們希望返回頁面時候頁面還是保存之前的狀態。這種情況下，需要我們手動將一些信息給保存起來，可以實現Activity中的另一個回調方法onSaveInstanceState()，保存Activity狀態的一些重要信息。系統會向該方法傳遞一個Bundle，然后我們可以向這個Bundle里面儲存一些重要信息。當系統重建Activity時候，系統會將這個Bundle同時傳遞給onCreate()和onRestoreInstanceState()方法，我們可以在這兩個方法中恢復之前場景。
看一下狀態保存的介紹圖。
面試時候可能會問到onSaveInstanceState()調用時機，看一下官方源代碼的注釋。
Do not confuse this method with activity lifecycle callbacks such as {@link #onPause}, which is always called when an activity is being placed in the background or on its way to destruction, or {@link #onStop} which is called before destruction. One example of when {@link #onPause} and {@link #onStop} is called and not this method is when a user navigates back from activity B to activity A。
不要把
onSaveInstanceState()這個方法和Activity生命周期的幾個方法混淆了，這個方法只有在Activity切換到后臺或者即將被銷毀時候被調用。有一個例子是如果從Activity B返回到Activity A，這個方法是不會被調用的。
也許很難理解這段注釋的意思，我個人理解是，如果一個Activity失去了屏幕焦點后，失去屏幕焦點一般是指onPause()和onStop()方法被調用，onSaveInstanceState()方法就會被調用，有一種特殊情況是從一個Activity B返回到上一個Activity A，這個方法并不會被調用。
個人總結了一下，大體有以下幾種情況會調用onSaveInstanceState()
onSaveInstanceState()方法
為什么平時并沒有實現
onSaveInstanceState()和onRestoreInstanceState()方法，但是有些時候，Activity中的UI狀態依然得到了保存，是為什么？
在Android中，Activity類的onSaveInstanceState()方法默認實現會調用布局中每個View的onSaveInstanceState()方法去保存其本身的狀態信息，Android框架中幾乎每個控件都會實現這個方法。我們只需要為想要保存其狀態的每個控件提供一個的ID（在xml中設置 android:id屬性），如果控件沒有 ID，則系統無法保存其狀態。
我們可以通過將View的android:saveEnabled屬性設置為false或通過調用View的setSaveEnabled()方法顯式阻止布局內的視圖保存其狀態，通常不需要設置這些屬性，但如果想以不同方式恢復Activity UI的狀態，可以這樣做。
注：由于無法保證系統調用onSaveInstanceState()的時機，我們只用它來保存Activity的瞬間狀態，不要用它來儲存持久性數據，上面提到過，建議在onPause()中儲存持久性數據。
敲黑板敲黑板，劃重點來了，同學們快拿出筆和紙快做筆記。
一個應用一般包含很多Activity，它們按照各自打開的順序排列在返回棧（Back Stack）中，這些Activity統稱為Task。大多數Task的起點是用戶在屏幕中點擊應用圖標啟動應用，該應用的Task出現在前臺，如果該應用沒有Task，也就是近未被打開，則會新建一個Task，并且會將該應用的MainActivity加入返回棧中，作為返回棧中的根Activity。
通常情況下，當前一個Activity啟動一個新的Activity時候，新的Activity會被加入返回棧中，并處于棧頂，獲取屏幕焦點，而前一個Activity仍保留在返回棧中，處于停止(onStop)狀態。 Activity停止時，如上所說，系統會保存其頁面狀態。當用戶返回時候，當前處于棧頂的Activity會從返回棧中彈出，并被銷毀(onDestroy)，恢復前一個Activity的狀態。返回棧中的Activity永遠不會重新排列，遵循先進后出的原則。
上述講的只是標準的Activity與返回棧的關系，在Android中Activity有四種啟動模式，分別是standard、singleTop、singleTask、singleInstance。
我們可以通過在AndroidManifest.xml配置Activity的啟動模式。
或者在代碼中向Intent添加相應標志。
注：第二種方法設置啟動模式的優先級高于種，如果兩者都存在，以第二種為準。
默認的啟動模式，新啟動的Activity放入返回棧棧頂，遵循先進后出原則，同一個Activity可以被實例化多次。
onNewIntent()方法傳入Intent
onNewIntent()方法傳入Intent
默認情況下，所有Activity所需要的返回棧名稱為應用的包名，我們可以在AndroidManifest.xml中通過設置Activity的android:taskAffinity屬性來指定該Activity需要的返回棧名稱，這個名稱不能和應用包名相同，否則相當于沒有指定。taskAffinity翻譯過來是返回棧親和性，我個人理解這個屬性是指定與返回棧親和度或者優先級，并不是每次都會新建返回棧。注意一般android:taskAffinity屬性和singleTask一起使用才有意義，會新建返回棧，如果只是指定了android:taskAffinity屬性但是依然是singleTop和standard模式，新啟動的Activity依然會在原來的返回棧中。
系統創建一個新的Task并創建Activity的新實例置于新Task返回棧中，但是系統不會將任何其他Activity的實例放入這個新建的Task中。該Activity始終是其Task僅有的成員，由此Activity啟動的任何Activity，如果沒有指定返回棧名稱，則新啟動的Activity放入默認的返回棧；如果指定了返回棧名稱，則將新啟動的Activity放入指定的返回棧中。
Android中返回棧分為前臺返回棧和后臺返回棧，前臺返回棧是指返回棧棧頂的Activity正在和用戶進行交互。
上面說了幾種啟動模式，下面看一下幾種啟動模式混合時候返回棧調度情況，我個人的理解和官方有些不同，這個大家可以跳過，去看官方的介紹。
個人理解一個應用創建的默認返回棧為基準，按返回鍵時候，根據返回棧創建順序依次清空返回棧，當默認返回棧清空時候，應用也就關閉了，但是有些后臺返回棧中的Activity并不會立即銷毀。
下面列出幾種特殊情況的返回棧書序調用圖。
Activity A -> Activity B -> Activity C 
Activity A -> Activity C -> Activity D -> Activity B 
官方圖，這里注意一下，官方圖中在StartActivity Y后，Y與X所在返回棧和1與2所在的返回棧是不同的，他們并不在同一個返回棧：
Activity A -> Activity B -> Activity C 
注：按返回鍵和啟動Activity從返回棧A到返回棧B結果是不同的，按返回鍵時候，會首先彈出返回棧A中的Activity，等到返回棧沒有Activity時候，才會進入另一個返回棧，這個時候返回棧A已經沒有Activity了。
上面講到的四種啟動模式都是在Androidmanifest.xml中設置啟動模式，也提及了用Intent添加flags來設置啟動模式。下面針對兩種方法做一下對比。
FLAG_ACTIVITY_SINGLE_TOP，這個標記的作用是為Activity指定singleTop啟動模式，與在XML設置啟動模式相同
FLAG_ACTIVITY_NEW_TASK，這個標記的作用是為Activity指定singleTask啟動模式，與在XML中設置啟動模式相同。
FLAG_ACTIVITY_CLEAR_TOP，用這個標記啟動的Activity，當它啟動是，在同一個任務戰中所有位于它上面的Activity都要出棧。這個標記一般會和singleTask啟動模式一起出現，在這種情況下，被啟動的Activity的實力如果已經存在，那么系統就會調用它的onNewIntent。如果被啟動的Activity采用standard啟動模式，那么連同它和它之上的Activity都要出棧，系統會創建新的Activity實力并放入棧頂。singleTask啟動模式默認就具有此標記的效果。
FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS，用這個標記啟動的Activity不會出現在近期任務中，也就是在Android任務列表中隱藏了該Activity，和在XML設置android:excludeFromRecents="true"相同，這個屬性需要配合singleInstance啟動模式才有用
可以看到XML設置沒有類似FLAG_ACTIVITY_CLEAR_TOP標記這種效果的啟動模式，而標記中沒有singleInstance這種啟動模式的標記。
注：平時如果我們使用ApplicationContext.startActivity去啟動一個standard啟動模式的Activity時候，會報錯如下，這是因為standard模式的Activity會默認進入啟動它的Activity的返回棧中，但是由于非Activity類型的Context(如ApplicationContext)并沒有所謂的返回棧，所以拋出這個異常。解決這個問題的方法就是在Intent中添加FLAG_ACTIVITY_NEW_TASK的標記，這個時候啟動其實是以singleTask模式啟動的
在AndroidManifest.xml中可以為Activity同時設置這兩個屬性，taskAffinity這個屬性上面將結果，allowTaskReparenting這個屬性是標記Activity是否可以更換返回棧，也就是從一個返回棧轉移到另一個返回棧。當應用需要給其他應用提供頁面支持的時候，這兩者結合起來就很有意義。
B應用提供了一個對外的Activity C，taskAffinity屬性是應用B包名，allowTaskReparenting設置為true。
應用A調用了應用B的Activity C，然后按Home鍵退回到主屏幕，單擊應用B的桌面圖標。
如果用戶將應用長時間的切換到后臺，系統會清除返回棧中除了根Activity的所有Activity。當用戶再次回到應用時候，僅恢復根Activity。有幾個標簽能夠協助我們控制返回棧的清空。
alwaysRetainTaskState，如果根Activity的該屬性設置為True，系統會長時間的保存所有的Activity在返回棧中，并不會清空。（殺死應用除外）
clearTaskOnLaunch，如果根Activity的該屬性設置為True，每當用戶離開再返回時候，系統都會將返回棧清空只留下根Activity。這個屬性和alwaysRetainTaskState剛好相反，即時用戶只離開片刻，系統也會清空返回棧。
從開始學Android開始，就想對四大組件進行一些梳理，將自己的知識點細化并記錄下來，可能網上已經有很多關于Activity的文章，沒用的很多，還是自己來寫靠譜，溫故而知新，共勉。
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網站上部分文章為轉載，并不用于任何商業目的，我們已經盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯系我們，我們將根據著作權人的要求，立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。
