Android后台杀死系列之二：ActivityManagerService与App现场恢复机制
本篇是Android后台杀死系列的第二篇，主要讲解ActivityMangerService是如何恢复被后台杀死的进程的（基于4.3 ），在开篇 FragmentActivity及PhoneWindow后台杀死处理机制 中，简述了后台杀死所引发的一些常见问题，还有Android系统控件对后台杀死所作的一些兼容，以及onSaveInstance跟onRestoreInstance的做用于执行时机，最后说了如何应对后台杀死，可是对于被后台杀死的进程如何恢复的并无讲解，本篇不涉及后台杀死，好比LowmemoryKiller机制，只讲述被杀死的进程如何恢复的。假设，一个应用被后台杀死，再次从最近的任务列表唤起App时候，系统是如何处理的呢？有这么几个问题可能须要解决：html
Android框架层（AMS）如何知道App被杀死了java
App被杀前的场景是如何保存的android
系统（AMS）如何恢复被杀的Appgit
被后台杀死的App的启动流程跟普通的启动有什么区别面试
Activity的恢复顺序为何是倒序恢复后端
系统（AMS）如何知道App被杀死了
首先来看第一个问题，系统如何知道Application被杀死了，Android使用了Linux的oomKiller机制，只是简单的作了个变种，采用分等级的LowmemoryKiller，但这个实际上是内核层面的，LowmemoryKiller杀死进程后，不会像用户空间发送通知，也就是说框架层的ActivityMangerService没法知道App是否被杀死，可是，只有知道App或者Activity是否被杀死，AMS（ActivityMangerService）才能正确的走唤起流程，那么AMS到底是在何时知道App或者Activity被后台杀死了呢？咱们先看一下从最近的任务列表进行唤起的时候，究竟发生了什么。服务器
从最近的任务列表或者Icon再次唤起App的流程
在系统源码systemUi的包里，有个RecentActivity，这个其实就是最近的任务列表的入口，而其呈现界面是经过RecentsPanelView来展示的，点击最近的App其执行代码以下：架构
public void handleOnClick(View view) {
ViewHolder holder = (ViewHolder)view.getTag();
TaskDescription ad = holder.taskDescription;
final Context context = view.getContext();
final ActivityManager am = (ActivityManager)
context.getSystemService(Context.ACTIVITY_SERVICE);
Bitmap bm = holder.thumbnailViewImageBitmap;
...
// 关键点 1 若是TaskDescription没有被主动关闭，正常关闭，ad.taskId就是>=0
if (ad.taskId >= 0) {
// This is an active task; it should just go to the foreground.
am.moveTaskToFront(ad.taskId, ActivityManager.MOVE_TASK_WITH_HOME,
opts);
} else {
Intent intent = ad.intent;
intent.addFlags(Intent.FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY
| Intent.FLAG_ACTIVITY_TASK_ON_HOME
| Intent.FLAG_ACTIVITY_NEW_TASK);
try {
context.startActivityAsUser(intent, opts,
new UserHandle(UserHandle.USER_CURRENT));
}...
}
在上面的代码里面，有个判断ad.taskId >= 0，若是知足这个条件，就经过moveTaskToFront唤起APP，那么ad.taskId是如何获取的？recent包里面有各种RecentTasksLoader，这个类就是用来加载最近任务列表的一个Loader，看一下它的源码，主要看一下加载：app
@Override
protected Void doInBackground(Void... params) {
// We load in two stages: first, we update progress with just the first screenful
// of items. Then, we update with the rest of the items
final int origPri = Process.getThreadPriority(Process.myTid());
Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);
final PackageManager pm = mContext.getPackageManager();
final ActivityManager am = (ActivityManager)
mContext.getSystemService(Context.ACTIVITY_SERVICE);
final List<ActivityManager.RecentTaskInfo> recentTasks =
am.getRecentTasks(MAX_TASKS, ActivityManager.RECENT_IGNORE_UNAVAILABLE);
....
TaskDescription item = createTaskDescription(recentInfo.id,
recentInfo.persistentId, recentInfo.baseIntent,
recentInfo.origActivity, recentInfo.description);
....
}
能够看到，其实就是经过ActivityManger的getRecentTasks向AMS请求最近的任务信息，而后经过createTaskDescription建立TaskDescription，这里传递的recentInfo.id其实就是TaskDescription的taskId，来看一下它的意义：框架
public List<ActivityManager.RecentTaskInfo> getRecentTasks(int maxNum,
int flags, int userId) {
...
IPackageManager pm = AppGlobals.getPackageManager();
final int N = mRecentTasks.size();
...
for (int i=0; i<N && maxNum > 0; i++) {
TaskRecord tr = mRecentTasks.get(i);
if (i == 0
|| ((flags&ActivityManager.RECENT_WITH_EXCLUDED) != 0)
|| (tr.intent == null)
|| ((tr.intent.getFlags()
&Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS) == 0)) {
ActivityManager.RecentTaskInfo rti
= new ActivityManager.RecentTaskInfo();
rti.id = tr.numActivities > 0 ? tr.taskId : -1;
rti.persistentId = tr.taskId;
rti.baseIntent = new Intent(
tr.intent != null ? tr.intent : tr.affinityIntent);
if (!detailed) {
rti.baseIntent.replaceExtras((Bundle)null);
}
能够看出RecentTaskInfo的id是由TaskRecord决定的，若是TaskRecord中numActivities > 0就去TaskRecord的Id，不然就取-1，这里的numActivities其实就是TaskRecode中记录的ActivityRecord的数目，更具体的细节能够自行查看ActivityManagerService及ActivityStack，那么这里就容易解释了，只要是存活的APP、或者被LowmemoryKiller杀死的APP，其AMS的ActivityRecord是完整保存的，这就是恢复的依据。RecentActivity获取的数据其实就是AMS中的翻版，RecentActivity并不知道将要唤起的APP是不是存活的，只要TaskRecord告诉RecentActivity是存货的，那么久直接走唤起流程，也就是经过ActivityManager的moveTaskToFront唤起App，至于后续的工做，就彻底交给AMS来处理。现看一下到这里的流程图：
整个APP被后台杀死的状况下AMS是如何恢复现场的
AMS与客户端的通讯是经过Binder来进行的，而且通讯是”全双工“的，且互为客户端跟服务器，也就说AMS向客户端发命令的时候，AMS是客户端，反之亦然。注意 Binder有个讣告的功能的：若是基于Binder通讯的服务端（S）若是挂掉了，客户端（C）可以收到Binder驱动发送的一份讣告，告知客户端Binder服务挂了，能够把Binder驱动看做是第三方不死邮政机构，专门向客户端发偶像死亡通知。对于APP被异常杀死的状况下，这份讣告是发送给AMS的，AMS在收到通知后，就会针对APP被异常杀死的状况做出整理，这里牵扯到Binder驱动的代码有兴趣能够本身翻一下。之类直接冲讣告接受后端处理逻辑来分析,在AMS源码中，入口其实就是appDiedLocked.
final void appDiedLocked(ProcessRecord app, int pid,
IApplicationThread thread) {
...
if (app.pid == pid && app.thread != null &&
app.thread.asBinder() == thread.asBinder()) {
boolean doLowMem = app.instrumentationClass == null;
关键点1
handleAppDiedLocked(app, false, true);
// 若是是被后台杀了，怎么处理
关键点2
if (doLowMem) {
boolean haveBg = false;
for (int i=mLruProcesses.size()-1; i>=0; i--) {
ProcessRecord rec = mLruProcesses.get(i);
if (rec.thread != null && rec.setAdj >= ProcessList.HIDDEN_APP_MIN_ADJ) {
haveBg = true;
break;
}
}
if (!haveBg) {
<!--若是被LowmemoryKiller杀了，就说明内存紧张，这个时候就会通知其余后台APP，当心了，赶忙释放资源-->
EventLog.writeEvent(EventLogTags.AM_LOW_MEMORY, mLruProcesses.size());
long now = SystemClock.uptimeMillis();
for (int i=mLruProcesses.size()-1; i>=0; i--) {
ProcessRecord rec = mLruProcesses.get(i);
if (rec != app && rec.thread != null &&
(rec.lastLowMemory+GC_MIN_INTERVAL) <= now) {
if (rec.setAdj <= ProcessList.HEAVY_WEIGHT_APP_ADJ) {
rec.lastRequestedGc = 0;
} else {
rec.lastRequestedGc = rec.lastLowMemory;
}
rec.reportLowMemory = true;
rec.lastLowMemory = now;
mProcessesToGc.remove(rec);
addProcessToGcListLocked(rec);
}
}
mHandler.sendEmptyMessage(REPORT_MEM_USAGE);
<!--缩减资源-->
scheduleAppGcsLocked();
}
}
}
...
}
先看关键点1：在进程被杀死后，AMS端要选择性清理进程相关信息，清理后，再根据是否是内存低引发的后台杀死，决定是否是须要清理其余后台进程。接着看handleAppDiedLocked如何清理的，这里有重建时的依据：ActivityRecord不清理，可是为它设置个APP未绑定的标识
private final void handleAppDiedLocked(ProcessRecord app,
boolean restarting, boolean allowRestart) {
关键点1
cleanUpApplicationRecordLocked(app, restarting, allowRestart, -1);
...
关键点2
// Remove this application's activities from active lists.
boolean hasVisibleActivities = mMainStack.removeHistoryRecordsForAppLocked(app);
app.activities.clear();
...
关键点3
if (!restarting) {
if (!mMainStack.resumeTopActivityLocked(null)) {
// If there was nothing to resume, and we are not already
// restarting this process, but there is a visible activity that
// is hosted by the process... then make sure all visible
// activities are running, taking care of restarting this
// process.
if (hasVisibleActivities) {
mMainStack.ensureActivitiesVisibleLocked(null, 0);
}
}
}
}
看关键点1，cleanUpApplicationRecordLocked，主要负责清理一些Providers，receivers，service之类的信息，而且在清理过程当中根据配置的一些信息决定是否须要重建进程并启动，关键点2 就是关系到唤起流程的判断，关键点3，主要是被杀的进程是不是当前前台进程，若是是，须要重建，并当即显示：先简单看cleanUpApplicationRecordLocked的清理流程
private final void cleanUpApplicationRecordLocked(ProcessRecord app,
boolean restarting, boolean allowRestart, int index) {
<!--清理service-->
mServices.killServicesLocked(app, allowRestart);
...
boolean restart = false;
<!--清理Providers.-->
if (!app.pubProviders.isEmpty()) {
Iterator<ContentProviderRecord> it = app.pubProviders.values().iterator();
while (it.hasNext()) {
ContentProviderRecord cpr = it.next();
。。。
app.pubProviders.clear();
} ...
<!--清理receivers.-->
// Unregister any receivers.
if (app.receivers.size() > 0) {
Iterator<ReceiverList> it = app.receivers.iterator();
while (it.hasNext()) {
removeReceiverLocked(it.next());
}
app.receivers.clear();
}
... 关键点1，进程是够须要重启，
if (restart && !app.isolated) {
// We have components that still need to be running in the
// process, so re-launch it.
mProcessNames.put(app.processName, app.uid, app);
startProcessLocked(app, "restart", app.processName);
}
...
}
从关键点1就能知道，这里是隐藏了进程是否须要重启的逻辑，好比一个Service设置了START_STICKY，被杀后，就须要从新唤起，这里也是流氓软件肆虐的缘由。再接着看mMainStack.removeHistoryRecordsForAppLocked(app)，对于直观理解APP重建
，这句代码处于核心的地位，
boolean removeHistoryRecordsForAppLocked(ProcessRecord app) {
...
while (i > 0) {
i--;
ActivityRecord r = (ActivityRecord)mHistory.get(i);
if (r.app == app) {
boolean remove;
<!--关键点1-->
if ((!r.haveState && !r.stateNotNeeded) || r.finishing) {
remove = true;
} else if (r.launchCount > 2 &&
remove = true;
} else {
//通常来说，走false
remove = false;
}
<!--关键点2-->
if (remove) {
...
removeActivityFromHistoryLocked(r);
} else {
...
r.app = null;
...
}
return hasVisibleActivities;
}
在Activity跳转的时候，准确的说，在stopActivity以前，会保存Activity的现场，这样在AMS端r.haveState==true，也就是说，其ActivityRecord不会被从ActivityStack中移除，同时ActivityRecord的app字段被置空，这里在恢复的时候，是决定resume仍是重建的关键。接着往下看moveTaskToFrontLocked，这个函数在ActivityStack中，主要管理ActivityRecord栈的，全部start的Activity都在ActivityStack中保留一个ActivityRecord，这个也是AMS管理Activiyt的一个依据，最终moveTaskToFrontLocked会调用resumeTopActivityLocked来唤起Activity，AMS获取即将resume的Activity信息的方式主要是经过ActivityRecord，它并不知道Activity自己是否存活，获取以后，AMS在唤醒Activity的环节才知道App或者Activity被杀死，具体看一下resumeTopActivityLocked源码：
final boolean resumeTopActivityLocked(ActivityRecord prev, Bundle options) {
...
关键点1
if (next.app != null && next.app.thread != null) {
...
} else {
// Whoops, need to restart this activity!
...
startSpecificActivityLocked(next, true, true);
}
return true;
}
看关键点1的判断条件，因为已经将ActivityRecord的app字段置空，AMS就知道了这个APP或者Activity被异常杀死过，所以，就会走startSpecificActivityLocked进行重建。 其实仔细想一想很简单，对于主动调用finish的，AMS并不会清理掉ActivitRecord，在唤起APP的时候，若是AMS检测到APP还存活，就走scheduleResumeActivity进行唤起上一个Activity，可是若是APP或者Activity被异常杀死过，那么AMS就经过startSpecificActivityLocked再次将APP重建，而且将最后的Activity重建。
APP存活，可是Activity被后台杀死的状况下AMS是如何恢复现场的
还有一种可能，APP没有被kill，可是Activity被Kill掉了，这个时候会怎么样？首先，Activity的管理是必定经过AMS的，Activity的kill必定是是AMS操刀的，是有记录的，严格来讲，这种状况并不属于后台杀死，由于这属于AMS正常的管理，在可控范围，好比打开了开发者模式中的“不保留活动”,这个时候，虽然会杀死Activity，可是仍然保留了ActivitRecord，因此再唤醒，或者回退的的时候仍然有迹可循,看一下ActivityStack的Destroy回调代码，
final boolean destroyActivityLocked(ActivityRecord r,
boolean removeFromApp, boolean oomAdj, String reason) {
...
if (hadApp) {
...
boolean skipDestroy = false;
try {
关键代码 1
r.app.thread.scheduleDestroyActivity(r.appToken, r.finishing,
r.configChangeFlags);
...
if (r.finishing && !skipDestroy) {
if (DEBUG_STATES) Slog.v(TAG, "Moving to DESTROYING: " + r
+ " (destroy requested)");
r.state = ActivityState.DESTROYING;
Message msg = mHandler.obtainMessage(DESTROY_TIMEOUT_MSG);
msg.obj = r;
mHandler.sendMessageDelayed(msg, DESTROY_TIMEOUT);
} else {
关键代码 2
r.state = ActivityState.DESTROYED;
if (DEBUG_APP) Slog.v(TAG, "Clearing app during destroy for activity " + r);
r.app = null;
}
}
return removedFromHistory;
}
这里有两个关键啊你单，1是告诉客户端的AcvitityThread清除Activity，2是标记若是AMS本身非正常关闭的Activity，就将ActivityRecord的state设置为ActivityState.DESTROYED，而且清空它的ProcessRecord引用：r.app = null。这里是唤醒时候的一个重要标志，经过这里AMS就能知道Activity被本身异常关闭了，设置ActivityState.DESTROYED是为了让避免后面的清空逻辑。
final void activityDestroyed(IBinder token) {
synchronized (mService) {
final long origId = Binder.clearCallingIdentity();
try {
ActivityRecord r = ActivityRecord.forToken(token);
if (r != null) {
mHandler.removeMessages(DESTROY_TIMEOUT_MSG, r);
}
int index = indexOfActivityLocked(r);
if (index >= 0) {
1 <!--这里会是否从history列表移除ActivityRecord-->
if (r.state == ActivityState.DESTROYING) {
cleanUpActivityLocked(r, true, false);
removeActivityFromHistoryLocked(r);
}
}
resumeTopActivityLocked(null);
} finally {
Binder.restoreCallingIdentity(origId);
}
}
}
看代码关键点1，只有r.state == ActivityState.DESTROYING的时候，才会移除ActivityRecord，可是对于不非正常finish的Activity，其状态是不会被设置成ActivityState.DESTROYING，是直接跳过了ActivityState.DESTROYING，被设置成了ActivityState.DESTROYED，因此不会removeActivityFromHistoryLocked，也就是保留了ActivityRecord现场，好像也是依靠异常来区分是不是正常的结束掉Activity。这种状况下是如何启动Activity的呢？ 经过上面两点分析，就知道了两个关键点
ActivityRecord没有动HistoryRecord列表中移除
ActivityRecord 的ProcessRecord字段被置空，r.app = null
这样就保证了在resumeTopActivityLocked的时候，走startSpecificActivityLocked分支
final boolean resumeTopActivityLocked(ActivityRecord prev, Bundle options) {
...
if (next.app != null && next.app.thread != null) {
...
} else {
// Whoops, need to restart this activity!
...
startSpecificActivityLocked(next, true, true);
}
return true;
}
到这里，AMS就知道了这个APP或者Activity是否是被异常杀死过，从而，决定是走resume流程仍是restore流程。
App被杀前的场景是如何保存的： 新Activity启动跟旧Activity的保存
App现场的保存流程相对是比较简单的，入口基本就是startActivity的时候，只要是界面的跳转基本都牵扯到Activity的切换跟当前Activity场景的保存：先画个简单的图形，开偏里面讲FragmentActivity的时候，简单说了一些onSaveInstance的执行时机，这里详细看一下AMS是如何管理这些跳转以及场景保存的，模拟场景：Activity A 启动Activity B的时候，这个时候A不可见，可能会被销毁，须要保存A的现场，这个流程是什么样的：简述以下
ActivityA startActivity ActivityB
ActivityA pause
ActivityB create
ActivityB start
ActivityB resume
ActivityA onSaveInstance
ActivityA stop
流程大概是以下样子：
如今咱们经过源码一步一步跟一下，看看AMS在新Activity启动跟旧Activity的保存的时候，到底作了什么：跳过简单的startActivity,直接去AMS中去看
ActivityManagerService
public final int startActivityAsUser(IApplicationThread caller, String callingPackage, Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode, int startFlags, String profileFile, ParcelFileDescriptor profileFd, Bundle options, int userId) { enforceNotIsolatedCaller("startActivity"); ... return mMainStack.startActivityMayWait(caller, -1, callingPackage, intent, resolvedType, resultTo, resultWho, requestCode, startFlags, profileFile, profileFd, null, null, options, userId); }ActivityStack
final int startActivityMayWait(IApplicationThread caller, int callingUid, int res = startActivityLocked(caller, intent, resolvedType, aInfo, resultTo, resultWho, requestCode, callingPid, callingUid, callingPackage, startFlags, options, componentSpecified, null); 。。。 }
这里经过startActivityMayWait启动新的APP，或者新Activity，这里只看简单的，至于从桌面启动App的流程，能够去参考更详细的文章，好比老罗的startActivity流程，大概就是新建ActivityRecord，ProcessRecord之类，并加入AMS中相应的堆栈等，resumeTopActivityLocked是界面切换的统一入口，第一次进来的时候，因为ActivityA还在没有pause，所以须要先暂停ActivityA，这些完成后，
ActivityStack
final boolean resumeTopActivityLocked(ActivityRecord prev, Bundle options) { ... <!--必须将当前Resume的Activity设置为pause 而后stop才能继续--> // We need to start pausing the current activity so the top one // can be resumed... if (mResumedActivity != null) { if (next.app != null && next.app.thread != null) { mService.updateLruProcessLocked(next.app, false); } startPausingLocked(userLeaving, false); return true; } .... }
其实这里就是暂停ActivityA，AMS经过Binder告诉ActivityThread须要暂停的ActivityA，ActivityThread完成后再经过Binder通知AMS，AMS会开始resume ActivityB，
private final void startPausingLocked(boolean userLeaving, boolean uiSleeping) {
if (prev.app != null && prev.app.thread != null) {
...
try {
prev.app.thread.schedulePauseActivity(prev.appToken, prev.finishing,
userLeaving, prev.configChangeFlags);
ActivityThread
private void handlePauseActivity(IBinder token, boolean finished, boolean userLeaving, int configChanges) { ActivityClientRecord r = mActivities.get(token); if (r != null) { ... performPauseActivity(token, finished, r.isPreHoneycomb()); ... // Tell the activity manager we have paused. try { ActivityManagerNative.getDefault().activityPaused(token); } catch (RemoteException ex) { } } }
AMS收到ActivityA发送过来的pause消息以后，就会唤起ActivityB，入口仍是resumeTopActivityLocked，唤醒B，以后还会A给进一步stop掉，这个时候就牵扯到现场的保存，
ActivityStack
private final void completePauseLocked() {
if (!mService.isSleeping()) {
resumeTopActivityLocked(prev);
} else {
...
}
ActivityB如何启动的，本文不关心，只看ActivityA如何保存现场的，ActivityB起来后，会经过ActivityStack的stopActivityLocked去stop ActivityA，
private final void stopActivityLocked(ActivityRecord r) {
...
if (mMainStack) {
r.app.thread.scheduleStopActivity(r.appToken, r.visible, r.configChangeFlags);
...
}
回看APP端，看一下ActivityThread中的调用：首先经过callActivityOnSaveInstanceState，将现场保存到Bundle中去，
private void performStopActivityInner(ActivityClientRecord r,
StopInfo info, boolean keepShown, boolean saveState) {
...
// Next have the activity save its current state and managed dialogs...
if (!r.activity.mFinished && saveState) {
if (r.state == null) {
state = new Bundle();
state.setAllowFds(false);
mInstrumentation.callActivityOnSaveInstanceState(r.activity, state);
r.state = state;
。。。
}
以后，经过ActivityManagerNative.getDefault().activityStopped，通知AMS Stop动做完成，在通知的时候，还会将保存的现场数据带过去。
private static class StopInfo implements Runnable {
ActivityClientRecord activity;
Bundle state;
Bitmap thumbnail;
CharSequence description;
@Override public void run() {
// Tell activity manager we have been stopped.
try {
ActivityManagerNative.getDefault().activityStopped(
activity.token, state, thumbnail, description);
} catch (RemoteException ex) {
}
}
}
经过上面流程，AMS不只启动了新的Activity，同时也将上一个Activity的现场进行了保存，及时因为种种缘由上一个Actiivity被杀死，在回退，或者从新唤醒的过程当中AMS也能知道如何唤起Activiyt，并恢复。
如今解决两个问题，一、如何保存现场，二、AMS怎么判断知道APP或者Activity是否被异常杀死，那么就剩下最后一个问题了，AMS如何恢复被异常杀死的APP或者Activity呢。
整个Application被后台杀死状况下的恢复逻辑
其实在讲解AMS怎么判断知道APP或者Activity是否被异常杀死的时候，就已经涉及了恢复的逻辑，也知道了一旦AMS知道了APP被后台杀死了，那就不是正常的resuem流程了，而是要从新laucher，先来看一下整个APP被干掉的会怎么处理，看resumeTopActivityLocked部分,从上面的分析已知，这种场景下，会由于Binder通讯抛异常走异常分支，以下：
final boolean resumeTopActivityLocked(ActivityRecord prev, Bundle options) {
....
if (next.app != null && next.app.thread != null) {
if (DEBUG_SWITCH) Slog.v(TAG, "Resume running: " + next);
...
try {
...
} catch (Exception e) {
// Whoops, need to restart this activity!
这里是知道整个app被杀死的
Slog.i(TAG, "Restarting because process died: " + next);
next.state = lastState;
mResumedActivity = lastResumedActivity;
Slog.i(TAG, "Restarting because process died: " + next);
startSpecificActivityLocked(next, true, false);
return true;
}
从上面的代码能够知道，其实就是走startSpecificActivityLocked，这根第一次从桌面唤起APP没多大区别，只是有一点须要注意，那就是这种时候启动的Activity是有上一次的现场数据传递过得去的，由于上次在退到后台的时候，全部Activity界面的现场都是被保存了，而且传递到AMS中去的，那么此次的恢复启动就会将这些数据返回给ActivityThread，再来仔细看一下performLaunchActivity里面关于恢复的特殊处理代码：
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
ActivityInfo aInfo = r.activityInfo;
Activity activity = null;
try {
java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
StrictMode.incrementExpectedActivityCount(activity.getClass());
r.intent.setExtrasClassLoader(cl);
if (r.state != null) {
r.state.setClassLoader(cl);
}
} catch (Exception e) {
...
}
try {
Application app = r.packageInfo.makeApplication(false, mInstrumentation);
...
关键点 1
mInstrumentation.callActivityOnCreate(activity, r.state);
...
r.activity = activity;
r.stopped = true;
if (!r.activity.mFinished) {
activity.performStart();
r.stopped = false;
}
关键点 1
if (!r.activity.mFinished) {
if (r.state != null) {
mInstrumentation.callActivityOnRestoreInstanceState(activity, r.state);
}
}
if (!r.activity.mFinished) {
activity.mCalled = false;
mInstrumentation.callActivityOnPostCreate(activity, r.state);
...
}
看一下关键点1跟2，先看关键点1，mInstrumentation.callActivityOnCreate会回调Actiivyt的onCreate，这个函数里面其实主要针对FragmentActivity作一些Fragment恢复的工做，ActivityClientRecord中的r.state是AMS传给APP用来恢复现场的，正常启动的时候，这些都是null。再来看关键点2 ，在r.state != null非空的时候执行mInstrumentation.callActivityOnRestoreInstanceState，这个函数默认主要就是针对Window作一些恢复工做，好比ViewPager恢复以前的显示位置等，也能够用来恢复用户保存数据。
Application没有被后台杀死，Activity被杀死的恢复
打开开发者模式”不保留活动“，就是这种场景，在上面的分析中，知道，AMS主动异常杀死Activity的时候，将AcitivityRecord的app字段置空，所以resumeTopActivityLocked同整个APP被杀死不一样，会走下面的分支
final boolean resumeTopActivityLocked(ActivityRecord prev, Bundle options) {
...
if (next.app != null && next.app.thread != null) {
...
} else {
关键点 1 只是重启Activity，可见这里实际上是知道的，进程并没死，
// Whoops, need to restart this activity!
startSpecificActivityLocked(next, true, true);
}
return true;
}
虽然不太同样，可是一样走startSpecificActivityLocked流程，只是不新建APP进程，其他的都是同样的，再也不讲解。到这里，咱们应该就了解了，
Android是如何在预防的状况下保存场景
AMS如何知道APP是否被后台杀死
AMS如何根据ActivityStack重建APP被杀死时的场景
到这里ActivityManagerService恢复APP场景的逻辑就应该讲完了。再碎碎念一些问题，多是一些面试的点。
主动清除最近任务跟异常杀死的区别：ActivityStack是否正常清楚
恢复的时候，为何是倒序恢复：由于这是ActivityStack中的HistoryRecord中栈的顺序，严格按照AMS端来
一句话归纳Android后台杀死恢复原理：Application进程被Kill，但现场被AMS保存，AMS能根据保存恢复Application现场
仅供参考，欢迎指正
参考文档
Android应用程序启动过程源代码分析
Android Framework架构浅析之【近期任务】
Android Low Memory Killer介绍
Android开发之InstanceState详解
对Android近期任务列表（Recent Applications）的简单分析
Android——内存管理-lowmemorykiller 机制
Android 操做系统的内存回收机制
Android LowMemoryKiller原理分析
Android进程生命周期与ADJ
Linux下/proc目录简介
startActivity启动过程分析 精
Activity销毁流程
- 1. Android后台杀死系列之二：ActivityManagerService与App现场恢复机制
- 2. Android后台杀死系列之一：FragmentActivity及PhoneWindow后台杀死处理机制
- 3. Android 后台杀死及恢复的机制
- 4. Android app 后台被杀恢复
- 5. Android后台杀死系列之三：后台杀死原理LowMemoryKiller（4.3-6.0）
- 6. Android后台杀死系列之三：LowMemoryKiller原理（4.3-6.0）
- 7. Android后台杀死系列之四：Binder讣告原理
- 8. android杀死app
- 9. 死锁处理之【二】---------死锁检测与死锁恢复
- 10. android 杀死三方app
- 更多相关文章...
- • MySQL数据库恢复（LOAD DATA） - MySQL教程
- • 操作系统（OS）平台 统计 - 浏览器信息
- • 漫谈MySQL的锁机制
- • Docker容器实战(六) - 容器的隔离与限制
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. Android后台杀死系列之二：ActivityManagerService与App现场恢复机制
- 2. Android后台杀死系列之一：FragmentActivity及PhoneWindow后台杀死处理机制
- 3. Android 后台杀死及恢复的机制
- 4. Android app 后台被杀恢复
- 5. Android后台杀死系列之三：后台杀死原理LowMemoryKiller（4.3-6.0）
- 6. Android后台杀死系列之三：LowMemoryKiller原理（4.3-6.0）
- 7. Android后台杀死系列之四：Binder讣告原理
- 8. android杀死app
- 9. 死锁处理之【二】---------死锁检测与死锁恢复
- 10. android 杀死三方app