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()保存。
以上內容轉載自:
Android 深刻理解Activity生命週期的作用及意義
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;
可以看到裏面調用了相對應的handlexxxxxxActivity方法，所以Activity的啓動就是該方法實現。接下來看看源碼的一部分。
Activity a = performLaunchActivity(r, customIntent);
if (a != null) {
r.createdConfig = new Configuration(mConfiguration);
reportSizeConfigurations(r);
Bundle oldState = r.state;
handleResumeActivity(r.token, false, r.isForward,
!r.activity.mFinished && !r.startsNotResumed, r.lastProcessedSeq, reason);
可以看出performLaunchActivity方法完成了Activity對象的創建和啓動過程。並且ActivityThread通過調用handleResumeActivity方法來調用被啓動的Activity的onResume()生命週期。
performLaunchActivity這個方法主要完成了如下事情：
總結一下：scheduleLaunchActivity方法通過sendMessage方法發送消息給H這個handler，接着handleMessage方法解析調用 handleLaunchActivity方法，接着該方法調用了performLaunchActivity方法創建了Activity對象，並且handleLaunchActivity方法還能調用被啓動的Activity的onResume()方法。可見這裏應用了handler通信。 此外前面提到的IApplicationThread，ActivityThread，ActivityManagerNative，IActivityManager，AMS等，大量應用了Binder機制。