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机制。