深入探索Activity生命週期以及啟動過程
1.各個生命週期的作用
1.onCreate()
可以進行初始化操作，初始化元件以及佈局資源。此時Activity處於不可見狀態。
2.onStart()
表示Activity在啟動，前臺還沒有顯示。
3.onResume()
表示Activity已經在螢幕上顯示UI。
4.onPause()
此方法回撥時，Activity正在停止（Paused形態），通常接下來 onStop() 會被回撥 。但通過流程圖可見，另一種情況是onPause() 執行後直接執行了onResume方法，這可能是啟動了一個透明主題的Activity或者使用者點選Home鍵，讓程式退回到主介面，程式在後臺執行時又迅速地再回到到當前的Activity，此時onResume方法就會被回撥。我們可以在onPause方法中做一些資料儲存、動畫停止、資源回收等操作。另外，onPause方法執行完成後，新Activity的onResume方法才會被執行。所以onPause不能太耗時，因為這可能會影響到新的Activity的顯示。 ！
5.onStop()
不可見狀態。此方法回撥時，Activity即將停止或者完全被覆蓋（Stopped形態），此時Activity不可見，僅在後臺執行。同樣地，在onStop方法可以做一些資源釋放的操作，不能太耗時。
6.onRestart()
此方法回撥時，表示Activity正在重新啟動，由不可見狀態變為可見狀態。這種情況，一般發生在使用者打開了一個新的Activity時，之前的Activity就會被onStop，接著又回到之前Activity頁面時，之前的Activity的 onRestart方法就會被回撥。
7.onDestroy()
此方法回撥時，表示Activity正在被銷燬，也是生命週期最後一個執行的方法，一般我們可以在此方法中做一些回收工作和最終的資源釋放。
如果所有的初始化都在onCreate()中實現，會有什麼問題？
首先，Activity的onCreate()被呼叫時，Activity還不可見，如果要做一些動畫，既然檢視還不存在，在onCreate中來啟動動畫，明顯有問題； 其次，AActivity 切換到 BActivity，再切換到 AActivity，由於例項已經存在，所以onCreate不會再被呼叫，那問題就在於AActivity從後臺切換至前臺時，有可能需要一些初始化，就沒法被呼叫到了。
如果所有的初始化都在onStart()中實現，會有什麼問題？
首先，雖然 在onStart()中用 setContentView()、findViewById() 功能也是正常的，但是onCreate()註釋中，明確建議 setContentView()、findViewById() 要在 onCreate() 中被呼叫。 其次， onResume()的註釋中都明確地說了這不是 Activity 對使用者是可見的最好的指示器，如果在 onStart() 中做全部初始化，很有可能初始化還沒完成影響到使用者的互動體驗。
如果所有資源回收都在onStop()中實現，會有什麼問題？
首先，在 onResume() 的註釋中，建議是在onResume()中開啟獨佔裝置（比如相機），與onResume()對應的是onPause()，關閉相機的操作也應該在此方法中被呼叫；否則，考慮一下如下場景：如果AActivity打開了相機，我們點選某按鈕要跳轉到BActivity中，BActivity也想開啟相機；假設AActivity的onPause() 在 BActivity啟動後再被呼叫，那BActivity根本就無法再正常啟動相機。 在onPause() 的註釋中明確表示，應該在這個方法中執行停止動畫等比較耗CPU的操作，如果不先執行這些操作，就先啟動新應用，然後再來執行此操作，確實是不合邏輯；其次，onStop() 的註釋中也明確地寫了，在記憶體不足而導致系統自動回收程序情況下，onStop() 可能都不會被執行。
Activity間跳轉時，為什麼AActivity的onPause()被呼叫後，BActivity的初始化流程（onCreate() -> onStart() -> onResume()），然後AActivity的onStop()被呼叫？
從AActivity切換到BActivity的日誌如下：
10-17 20:54:46.997: I/com.example.servicetest.AActivity(5817): onPause()
10-17 20:54:47.021: I/com.example.servicetest.BActivity(5817): onCreate()
10-17 20:54:47.028: I/com.example.servicetest.BActivity(5817): onStart()
10-17 20:54:47.028: I/com.example.servicetest.BActivity(5817): onResume()
10-17 20:54:47.099: I/com.example.servicetest.AActivity(5817): onStop()
當用戶點選開啟新的Activity，肯定是想盡快進入新的檢視進行操作。而且上面的問題已經解釋了，在onResume()一般會開啟獨佔裝置，開啟動畫等，當需要從AActivity切換到BActivity時，先執行AActivity中的onPause()進行關閉獨佔裝置，關閉動畫等，以防止BActivity也需要使用這些資源，因為AActivity的資源回收，也有利於BActivity執行的流暢。
當AActivity中比較消耗資源的部分在onPause()中關閉後，再執行BActivity的初始化，顯示檢視與使用者互動。然後，系統在後臺默默執行AActivity的onStop()操作，去回收AActivity佔用的其餘資源。即使onStop()中會有些比較耗時的操作，也沒有關係，這是在後臺執行也不會影響到使用者的體驗。（設計的非常好!good！！！）
onSavedInstanceState()和onRestoreInstanceState()理解
大家在開發過程中可能遇到，當在頁面的EditText中輸入值，接著翻轉螢幕時，我輸入的內容清空了，但是當我給EditText定義了id屬性，再執行上訴操作時，EditText的內容仍然存在。另外，當我們點選Home鍵退回到主頁面，許久之後再次開啟程式進行操作，可能會崩潰。
下面解釋為什麼會出現這樣的情況:
(1）onSavedInstanceState()和onRestoreInstanceState()並不是activity生命週期的方法。
onSaveInstanceState()會在onPause()或onStop()之前執行； onRestoreInstanceState()會在onStart()和onResume()之間執行。
當應用遇到意外情況（記憶體不足，橫豎屏切換）由系統直接銷燬一個Activity時，onSaveInstanceState()就會呼叫，但是當用戶主動銷燬activity，如按back鍵，或直接執行finish(),這種情況下onSaveInstanceState()就不會執行，因為這種情況下，使用者的行為決定了不需要儲存Activity的狀態。
(2)那麼onRestoreInstanceState()會跟onSaveInstanceState()成對出現嗎？
答案是不會成對出現，onSaveInstanceState()需要呼叫的時，activity可能銷燬，也可能沒有銷燬，只有在activity銷燬重建的時候onRestoreInstanceState()才會呼叫。
(3)在onSaveInstanceState()中預設情況下具體幹些什麼？
預設情況下預設會自動儲存Activity中的某些狀態，比如activity中各種UI的狀態，因此在activity被“系統”銷燬和重建的時候，這些Ui的狀態會預設儲存，但是前提條件是Ui控制元件必須制定id,如果沒有指定id的話，UI的狀態是無法儲存 的。
(4)總結下Activity資料的儲存和恢復：
activity中儲存資料可以在onPause()，onSaveInstance(bundle)中儲存, 恢復資料也有兩種途徑onCreate(Bundle), onRestoreInstanceState(budle)，預設情況下onSaveInstanceSate()和onRestoreInstanceState()會對UI狀態進行儲存和恢復，如果需要儲存其他資料可以在onSaveInstanceState()、onPause()儲存。但是如果是持久化的資料，google推薦的是通過onPause()儲存。
2.Activity的啟動過程
android系統對四大元件進行了封裝，因此啟動一個Activity非常簡單，在顯示呼叫的情況下，通過以下程式碼就可以啟動：
Intent intent = new Intent(this, AnotherActivity.class);
startActivity(intent);
//或者
startActivityForResult(intent, 1);
我們從startActivity()方法開始分析，startActivity()方法有好幾種過載方式，但它們最終都會呼叫startActivityForResult方法，它的實現如下所示：
startActivityForResult()
public void startActivityForResult(@RequiresPermission Intent intent, int requestCode,
@Nullable Bundle options) {
if (mParent == null) {
options = transferSpringboardActivityOptions(options);
Instrumentation.ActivityResult ar =
mInstrumentation.execStartActivity(
this, mMainThread.getApplicationThread(), mToken, this,
intent, requestCode, options);
if (ar != null) {
mMainThread.sendActivityResult(
mToken, mEmbeddedID, requestCode, ar.getResultCode(),
ar.getResultData());
}
if (requestCode >= 0) {
// If this start is requesting a result, we can avoid making
// the activity visible until the result is received. Setting
// this code during onCreate(Bundle savedInstanceState) or onResume() will keep the
// activity hidden during this time, to avoid flickering.
// This can only be done when a result is requested because
// that guarantees we will get information back when the
// activity is finished, no matter what happens to it.
mStartedActivity = true;
}
cancelInputsAndStartExitTransition(options);
// TODO Consider clearing/flushing other event sources and events for child windows.
} else {
if (options != null) {
mParent.startActivityFromChild(this, intent, requestCode, options);
} else {
// Note we want to go through this method for compatibility with
// existing applications that may have overridden it.
mParent.startActivityFromChild(this, intent, requestCode);
}
}
}
上面程式碼中只需要關注mParent==null這部分就行，mParent代表的是ActivityGroup，ActivityGroup用來在一個介面中嵌入多個子Activity，但是在API13中已經廢棄了。系統推薦採用Fragment來代替ActivityGroup。 上面程式碼中， mMainThread.getApplicationThread()，execStartActivity方法 尤為重要。mMainThread.getApplicationThread()返回的引數是 ApplicationThread 型別，ApplicationThread是 ActivityThread 的一個內部類，這兩個類在Activity啟動過程中發揮了重要作用。接下來我們看看execStartActivity方法。
execStartActivity
public ActivityResult execStartActivity(
Context who, IBinder contextThread, IBinder token, Activity target,
Intent intent, int requestCode, Bundle options) {
IApplicationThread whoThread = (IApplicationThread) contextThread;
Uri referrer = target != null ? target.onProvideReferrer() : null;
if (referrer != null) {
intent.putExtra(Intent.EXTRA_REFERRER, referrer);
}
if (mActivityMonitors != null) {
synchronized (mSync) {
final int N = mActivityMonitors.size();
for (int i=0; i<N; i++) {
final ActivityMonitor am = mActivityMonitors.get(i);
if (am.match(who, null, intent)) {
am.mHits++;
if (am.isBlocking()) {
return requestCode >= 0 ? am.getResult() : null;
}
break;
}
}
}
}
try {
intent.migrateExtraStreamToClipData();
intent.prepareToLeaveProcess(who);
int result = ActivityManagerNative.getDefault()
.startActivity(whoThread, who.getBasePackageName(), intent,
intent.resolveTypeIfNeeded(who.getContentResolver()),
token, target != null ? target.mEmbeddedID : null,
requestCode, 0, null, options);
checkStartActivityResult(result, intent);
} catch (RemoteException e) {
throw new RuntimeException("Failure from system", e);
}
return null;
}
上面程式碼中，啟動Activity真正的實現是由 ActivityManagerNative.getDefault().startActivity() 方法實現的。 ActivityManagerService(簡稱AMS)繼承於ActivityManagerNative。而ActivityManagerNative繼承於Binder並實現 IActivityManager這個Binder介面，因此AMS也是一個Binder，它是IActivityManager的具體實現。 ActivityManagerNative.getDefault() 其實是一個IActivityManager型別的Binder物件，所以得到的是一個實現了IActivityManager這個Binder介面的類AMS。因此我們去AMS中追尋startActivity方法，解開謎團。
我們進去checkStartActivityResult(result, intent);方法檢視下可以得知，這個方法的作用就是檢查啟動Activity的結果。當無法正確啟動一個Activity，就會丟擲異常。接下來看看startActivity
AMS的startActivity方法
@Override
public final int startActivity(IApplicationThread caller, String callingPackage,
Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode,
int startFlags, ProfilerInfo profilerInfo, Bundle bOptions) {
return startActivityAsUser(caller, callingPackage, intent, resolvedType, resultTo,
resultWho, requestCode, startFlags, profilerInfo, bOptions,
UserHandle.getCallingUserId());
}
//startACtivity方法又會呼叫startActivityAsUser方法
@Override
public final int startActivityAsUser(IApplicationThread caller, String callingPackage,
Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode,
int startFlags, ProfilerInfo profilerInfo, Bundle bOptions, int userId) {
enforceNotIsolatedCaller("startActivity");
userId = mUserController.handleIncomingUser(Binder.getCallingPid(), Binder.getCallingUid(),
userId, false, ALLOW_FULL_ONLY, "startActivity", null);
// TODO: Switch to user app stacks here.
return mActivityStarter.startActivityMayWait(caller, -1, callingPackage, intent,
resolvedType, null, null, resultTo, resultWho, requestCode, startFlags,
profilerInfo, null, null, bOptions, false, userId, null, "startActivityAsUser");
}
從程式碼中可以看出，最終呼叫了 mActivityStarter.startActivityMayWait方法。接下來經過一系列複雜的呼叫方法，最終呼叫了ActivityStack的resumeTopActivityUncheckedLocked()方法，接著該方法又呼叫了resumeTopActivityInnerLocked方法，接著呼叫ActivityStackSupervisor的startSpecificActivityLocked方法，
boolean resumeTopActivityUncheckedLocked(ActivityRecord prev, ActivityOptions options) {
if (mStackSupervisor.inResumeTopActivity) {
// Don't even start recursing.
return false;
}
boolean result = false;
try {
// Protect against recursion.
mStackSupervisor.inResumeTopActivity = true;
result = resumeTopActivityInnerLocked(prev, options);
} finally {
mStackSupervisor.inResumeTopActivity = false;
}
// When resuming the top activity, it may be necessary to pause the top activity (for
// example, returning to the lock screen. We suppress the normal pause logic in
// {@link #resumeTopActivityUncheckedLocked}, since the top activity is resumed at the end.
// We call the {@link ActivityStackSupervisor#checkReadyForSleepLocked} again here to ensure
// any necessary pause logic occurs. In the case where the Activity will be shown regardless
// of the lock screen, the call to {@link ActivityStackSupervisor#checkReadyForSleepLocked}
// is skipped.
final ActivityRecord next = topRunningActivityLocked(true /* focusableOnly */);
if (next == null || !next.canTurnScreenOn()) {
checkReadyForSleep();
}
return result;
}
//ActivityStackSupervisor的startSpecificActivityLocked方法
void startSpecificActivityLocked(ActivityRecord r,
boolean andResume, boolean checkConfig) {
// Is this activity's application already running?
ProcessRecord app = mService.getProcessRecordLocked(r.processName,
r.info.applicationInfo.uid, true);
r.getStack().setLaunchTime(r);
if (app != null && app.thread != null) {
try {
if ((r.info.flags&ActivityInfo.FLAG_MULTIPROCESS) == 0
|| !"android".equals(r.info.packageName)) {
// Don't add this if it is a platform component that is marked
// to run in multiple processes, because this is actually
// part of the framework so doesn't make sense to track as a
// separate apk in the process.
app.addPackage(r.info.packageName, r.info.applicationInfo.versionCode,
mService.mProcessStats);
}
realStartActivityLocked(r, app, andResume, checkConfig);
return;
} catch (RemoteException e) {
Slog.w(TAG, "Exception when starting activity "
+ r.intent.getComponent().flattenToShortString(), e);
}
// If a dead object exception was thrown -- fall through to
// restart the application.
}
mService.startProcessLocked(r.processName, r.info.applicationInfo, true, 0,
"activity", r.intent.getComponent(), false, false, true);
}
接著我們看realStartActivityLocked(r, app, andResume, checkConfig);由名字就知道這是個真正啟動的方法。該方法內部有一段程式碼
app.thread.scheduleLaunchActivity(new Intent(r.intent), r.appToken,
System.identityHashCode(r), r.info,
// TODO: Have this take the merged configuration instead of separate global
// and override configs.
mergedConfiguration.getGlobalConfiguration(),
mergedConfiguration.getOverrideConfiguration(), r.compat,
r.launchedFromPackage, task.voiceInteractor, app.repProcState, r.icicle,
r.persistentState, results, newIntents, !andResume,
mService.isNextTransitionForward(), profilerInfo);
其中app.thread型別為IApplicationThread，那麼這個IApplicationThread是什麼呢？其實它是一個繼承了IInterface的一個介面，它也是一個Binder型別的介面，裡面定義了大量啟動，停止Activity的介面和方法，此外還包含了啟動和停止服務的介面。 IApplicationThread的實現者就是我們上文說到的ActivityThread的內部類ApplicationThread了
public final class ActivityThread {
private class ApplicationThread extends IApplicationThread.Stub {
private void updatePendingConfiguration(){}
public final void schedulePauseActivity(){}
public final void scheduleStopActivity(){}
public final void scheduleLaunchActivity(){}
...........
}
}
可以看到裡面定義了關於Activity的操作方法還有其它方法。繞了一大圈，Activity的啟動過程最終回到了ApplicationThread中，然後通過 scheduleLaunchActivity 方法來啟動Activity。那麼我們就來看看這個方法。
// we use token to identify this activity without having to send the
// activity itself back to the activity manager. (matters more with ipc)
@Override
public final void scheduleLaunchActivity(Intent intent, IBinder token, int ident,
ActivityInfo info, Configuration curConfig, Configuration overrideConfig,
CompatibilityInfo compatInfo, String referrer, IVoiceInteractor voiceInteractor,
int procState, Bundle state, PersistableBundle persistentState,
List<ResultInfo> pendingResults, List<ReferrerIntent> pendingNewIntents,
boolean notResumed, boolean isForward, ProfilerInfo profilerInfo) {
updateProcessState(procState, false);
ActivityClientRecord r = new ActivityClientRecord();
r.token = token;
r.ident = ident;
r.intent = intent;
r.referrer = referrer;
r.voiceInteractor = voiceInteractor;
r.activityInfo = info;
r.compatInfo = compatInfo;
r.state = state;
r.persistentState = persistentState;
r.pendingResults = pendingResults;
r.pendingIntents = pendingNewIntents;
r.startsNotResumed = notResumed;
r.isForward = isForward;
r.profilerInfo = profilerInfo;
r.overrideConfig = overrideConfig;
updatePendingConfiguration(curConfig);
sendMessage(H.LAUNCH_ACTIVITY, r);
}
scheduleLaunchActivity方法很容易看懂，前面的程式碼都是更新一些資料資訊，最後一行程式碼比較重要sendMessage(H.LAUNCH_ACTIVITY, r);這裡是傳送一個訊息給H處理，這個H是什麼呢？？這個H就是ActivityThread的一個內部類，它繼承了Handler。那麼來看看這個sendMessage方法內部實現。
private void sendMessage(int what, Object obj, int arg1, int arg2, boolean async) {
if (DEBUG_MESSAGES) Slog.v(
TAG, "SCHEDULE " + what + " " + mH.codeToString(what)
+ ": " + arg1 + " / " + obj);
Message msg = Message.obtain();
msg.what = what;
msg.obj = obj;
msg.arg1 = arg1;
msg.arg2 = arg2;
if (async) {
msg.setAsynchronous(true);
}
mH.sendMessage(msg);
}
那麼傳送了訊息肯定要處理啊。所以H裡面的handleMessage方法就進行訊息處理，該方法內部使用switch來進行訊息分類處理，我們擷取一部分來看看。
switch (msg.what) {
case LAUNCH_ACTIVITY: {
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityStart");
final ActivityClientRecord r = (ActivityClientRecord) msg.obj;
r.packageInfo = getPackageInfoNoCheck(
r.activityInfo.applicationInfo, r.compatInfo);
handleLaunchActivity(r, null, "LAUNCH_ACTIVITY");
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
} break;
case RELAUNCH_ACTIVITY: {
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityRestart");
ActivityClientRecord r = (ActivityClientRecord)msg.obj;
handleRelaunchActivity(r);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
} break;
case PAUSE_ACTIVITY: {
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityPause");
SomeArgs args = (SomeArgs) msg.obj;
handlePauseActivity((IBinder) args.arg1, false,
(args.argi1 & USER_LEAVING) != 0, args.argi2,
(args.argi1 & DONT_REPORT) != 0, args.argi3);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
} break;
可以