Android后臺(tái)殺死系列之二：ActivityManagerService與App現(xiàn)場(chǎng)恢復(fù)機(jī)制
本篇是Android后臺(tái)殺死系列的第二篇，主要講解ActivityMangerService是如何恢復(fù)被后臺(tái)殺死的進(jìn)程的(基于4.3 )，在開篇FragmentActivity及PhoneWindow后臺(tái)殺死處理機(jī)制 中，簡(jiǎn)述了后臺(tái)殺死所引起的一些常見問題，還有Android系統(tǒng)控件對(duì)后臺(tái)殺死所做的一些兼容，以及onSaveInstance跟onRestoreInstance的作用于執(zhí)行時(shí)機(jī)，最后說了如何應(yīng)對(duì)后臺(tái)殺死，但是對(duì)于被后臺(tái)殺死的進(jìn)程如何恢復(fù)的并沒有講解，本篇不涉及后臺(tái)殺死，比如LowmemoryKiller機(jī)制，只講述被殺死的進(jìn)程如何恢復(fù)的。假設(shè)，一個(gè)應(yīng)用被后臺(tái)殺死，再次從最近的任務(wù)列表喚起App時(shí)候，系統(tǒng)是如何處理的呢?有這么幾個(gè)問題可能需要解決：
- Android框架層(AMS)如何知道App被殺死了
- App被殺前的場(chǎng)景是如何保存的
- 系統(tǒng)(AMS)如何恢復(fù)被殺的App
- 被后臺(tái)殺死的App的啟動(dòng)流程跟普通的啟動(dòng)有什么區(qū)別
- Activity的恢復(fù)順序?yàn)槭裁词堑剐蚧謴?fù)
系統(tǒng)(AMS)如何知道App被殺死了
首先來看第一個(gè)問題，系統(tǒng)如何知道Application被殺死了，Android使用了Linux的oomKiller機(jī)制，只是簡(jiǎn)單的做了個(gè)變種，采用分等級(jí)的LowmemoryKiller，但這個(gè)其實(shí)是內(nèi)核層面的，LowmemoryKiller殺死進(jìn)程后，不會(huì)像用戶空間發(fā)送通知，也就是說框架層的ActivityMangerService無法知道App是否被殺死，但是，只有知道App或者Activity是否被殺死，AMS(ActivityMangerService)才能正確的走喚起流程，那么AMS究竟是在什么時(shí)候知道App或者Activity被后臺(tái)殺死了呢?我們先看一下從最近的任務(wù)列表進(jìn)行喚起的時(shí)候，究竟發(fā)生了什么。
從最近的任務(wù)列表或者Icon再次喚起App的流程
在系統(tǒng)源碼systemUi的包里，有個(gè)RecentActivity，這個(gè)其實(shí)就是最近的任務(wù)列表的入口，而其呈現(xiàn)界面是通過RecentsPanelView來展現(xiàn)的，點(diǎn)擊最近的App其執(zhí)行代碼如下：
- 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;
- ...
- // 關(guān)鍵點(diǎn) 1 如果TaskDescription沒有被主動(dòng)關(guān)閉，正常關(guān)閉，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));
- }...
- }
在上面的代碼里面，有個(gè)判斷ad.taskId >= 0，如果滿足這個(gè)條件，就通過moveTaskToFront喚起APP，那么ad.taskId是如何獲取的?recent包里面有各類RecentTasksLoader，這個(gè)類就是用來加載最近任務(wù)列表的一個(gè)Loader，看一下它的源碼，主要看一下加載：
- @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);
- ....
- }
可以看到，其實(shí)就是通過ActivityManger的getRecentTasks向AMS請(qǐng)求最近的任務(wù)信息，然后通過createTaskDescription創(chuàng)建TaskDescription，這里傳遞的recentInfo.id其實(shí)就是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其實(shí)就是TaskRecode中記錄的ActivityRecord的數(shù)目，更具體的細(xì)節(jié)可以自行查看ActivityManagerService及ActivityStack，那么這里就容易解釋了，只要是存活的APP、或者被LowmemoryKiller殺死的APP，其AMS的ActivityRecord是完整保存的，這就是恢復(fù)的依據(jù)。RecentActivity獲取的數(shù)據(jù)其實(shí)就是AMS中的翻版，RecentActivity并不知道將要喚起的APP是否是存活的，只要TaskRecord告訴RecentActivity是存貨的，那么久直接走喚起流程，也就是通過ActivityManager的moveTaskToFront喚起App，至于后續(xù)的工作，就完全交給AMS來處理?，F(xiàn)看一下到這里的流程圖：
在喚起App的時(shí)候AMS偵測(cè)App或者Activity是否被異常殺死
接著往下看moveTaskToFrontLocked，這個(gè)函數(shù)在ActivityStack中，ActivityStack主要用來管理ActivityRecord棧的，所有start的Activity都在ActivityStack中保留一個(gè)ActivityRecord，這個(gè)也是AMS管理Activity的一個(gè)依據(jù)，ActivityStack最終moveTaskToFrontLocked會(huì)調(diào)用resumeTopActivityLocked來喚起Activity，AMS獲取即將resume的Activity信息的方式主要是通過ActivityRecord，它并不知道Activity本身是否存活，獲取之后，AMS知道喚醒Activity的環(huán)節(jié)才知道App或者Activity被殺死，具體看一下resumeTopActivityLocked源碼：
- final boolean resumeTopActivityLocked(ActivityRecord prev, Bundle options) {
- // This activity is now becoming visible.
- mService.mWindowManager.setAppVisibility(next.appToken, true);
- .... 恢復(fù)邏輯
- if (next.app != null && next.app.thread != null) {
- // 正?；謴?fù)
- try {
- // Deliver all pending results.
- ArrayList a = next.results;
- if (a != null) {
- final int N = a.size();
- if (!next.finishing && N > 0) {
- next.app.thread.scheduleSendResult(next.appToken, a);
- }
- }
- ...
- next.app.thread.scheduleResumeActivity(next.appToken,
- mService.isNextTransitionForward());
- ...
- } catch (Exception e) {
- // Whoops, need to restart this activity!
- // 這里需要重啟，難道被后臺(tái)殺死，走的是異常分支嗎？？？？ 異常殺死
- if (DEBUG_STATES) Slog.v(TAG, "Resume failed; resetting state to "
- + lastState + ": " + next);
- next.state = lastState;
- mResumedActivity = lastResumedActivity;
- <!--確實(shí)這里是因?yàn)檫M(jìn)程掛掉了-->
- Slog.i(TAG, "Restarting because process died: " + next);
- 。。。
- startSpecificActivityLocked(next, true, false);
- return true;
- }
- ...
- }
由于沒有主動(dòng)調(diào)用finish的，所以AMS并不會(huì)清理掉ActivityRecord與TaskRecord ，因此resume的時(shí)候走的就是上面的分支，可以這里會(huì)調(diào)用next.app.thread.scheduleSendResult或者next.app.thread.scheduleResumeActivity進(jìn)行喚起上一個(gè)Activity，但是如果APP或者Activity被異常殺死，那么喚起的操作一定是失敗，會(huì)拋出異常，首先假設(shè)APP整個(gè)被殺死，那么APP端同AMS通信的Binder線程也不復(fù)存在，這個(gè)時(shí)候通過Binder進(jìn)行通信就會(huì)拋出RemoteException，如此，就會(huì)走下面的catch部分，通過startSpecificActivityLocked再次將APP重建，并且將最后的Activity重建，其實(shí)你可以本地利用AIDL寫一個(gè)C/S通信，在將一端關(guān)閉，然后用另一端訪問，就會(huì)拋出RemoteException異常，如下圖：
還有一種可能，APP沒有被kill，但是Activity被Kill掉了，這個(gè)時(shí)候會(huì)怎么樣?首先，Activity的管理是一定通過AMS的，Activity的kill一定是是AMS操刀的，是有記錄的，嚴(yán)格來說，這種情況并不屬于后臺(tái)殺死，因?yàn)檫@屬于AMS正常的管理，在可控范圍，比如打開了開發(fā)者模式中的“不保留活動(dòng)”,這個(gè)時(shí)候，雖然會(huì)殺死Activity，但是仍然保留了ActivitRecord，所以再喚醒，或者回退的的時(shí)候仍然有跡可循,看一下ActivityStack的Destroy回調(diào)代碼，
- final boolean destroyActivityLocked(ActivityRecord r,
- boolean removeFromApp, boolean oomAdj, String reason) {
- ...
- if (hadApp) {
- ...
- boolean skipDestroy = false;
- try {
- 關(guān)鍵代碼 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 {
- 關(guān)鍵代碼 2
- r.state = ActivityState.DESTROYED;
- if (DEBUG_APP) Slog.v(TAG, "Clearing app during destroy for activity " + r);
- r.app = null;
- }
- }
- return removedFromHistory;
- }
這里有兩個(gè)關(guān)鍵啊你單，1是告訴客戶端的AcvitityThread清除Activity，2是標(biāo)記如果AMS自己非正常關(guān)閉的Activity，就將ActivityRecord的state設(shè)置為ActivityState.DESTROYED，并且清空它的ProcessRecord引用：r.app = null。這里是喚醒時(shí)候的一個(gè)重要標(biāo)志，通過這里AMS就能知道Activity被自己異常關(guān)閉了，設(shè)置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 <!--這里會(huì)是否從history列表移除ActivityRecord-->
- if (r.state == ActivityState.DESTROYING) {
- cleanUpActivityLocked(r, true, false);
- removeActivityFromHistoryLocked(r);
- }
- }
- resumeTopActivityLocked(null);
- } finally {
- Binder.restoreCallingIdentity(origId);
- }
- }
- }
看代碼關(guān)鍵點(diǎn)1，只有r.state == ActivityState.DESTROYING的時(shí)候，才會(huì)移除ActivityRecord，但是對(duì)于不非正常finish的Activity，其狀態(tài)是不會(huì)被設(shè)置成ActivityState.DESTROYING，是直接跳過了ActivityState.DESTROYING，被設(shè)置成了ActivityState.DESTROYED，所以不會(huì)removeActivityFromHistoryLocked，也就是保留了ActivityRecord現(xiàn)場(chǎng)，好像也是依靠異常來區(qū)分是否是正常的結(jié)束掉Activity。這種情況下是如何啟動(dòng)Activity的呢? 通過上面兩點(diǎn)分析，就知道了兩個(gè)關(guān)鍵點(diǎn)
- ActivityRecord沒有動(dòng)HistoryRecord列表中移除
- ActivityRecord 的ProcessRecord字段被置空，r.app = null
這樣就保證了在resumeTopActivityLocked的時(shí)候，走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就知道了這個(gè)APP或者Activity是不是被異常殺死過，從而，決定是走resume流程還是restore流程。
App被殺前的場(chǎng)景是如何保存的： 新Activity啟動(dòng)跟舊Activity的保存
App現(xiàn)場(chǎng)的保存流程相對(duì)是比較簡(jiǎn)單的，入口基本就是startActivity的時(shí)候，只要是界面的跳轉(zhuǎn)基本都牽扯到Activity的切換跟當(dāng)前Activity場(chǎng)景的保存：先畫個(gè)簡(jiǎn)單的圖形，開偏里面講FragmentActivity的時(shí)候，簡(jiǎn)單說了一些onSaveInstance的執(zhí)行時(shí)機(jī)，這里詳細(xì)看一下AMS是如何管理這些跳轉(zhuǎn)以及場(chǎng)景保存的，模擬場(chǎng)景：Activity A 啟動(dòng)Activity B的時(shí)候，這個(gè)時(shí)候A不可見，可能會(huì)被銷毀，需要保存A的現(xiàn)場(chǎng)，這個(gè)流程是什么樣的：簡(jiǎn)述如下
- ActivityA startActivity ActivityB
- ActivityA pause
- ActivityB create
- ActivityB start
- ActivityB resume
- ActivityA onSaveInstance
- ActivityA stop
流程大概是如下樣子：
現(xiàn)在我們通過源碼一步一步跟一下，看看AMS在新Activity啟動(dòng)跟舊Activity的保存的時(shí)候，到底做了什么：跳過簡(jiǎn)單的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啟動(dòng)新的APP，或者新Activity，這里只看簡(jiǎn)單的，至于從桌面啟動(dòng)App的流程，可以去參考更詳細(xì)的文章，比如老羅的startActivity流程，大概就是新建ActivityRecord，ProcessRecord之類，并加入AMS中相應(yīng)的堆棧等，resumeTopActivityLocked是界面切換的統(tǒng)一入口，第一次進(jìn)來的時(shí)候，由于ActivityA還在沒有pause，因此需要先暫停ActivityA，這些完成后，
ActivityStack
- final boolean resumeTopActivityLocked(ActivityRecord prev, Bundle options) {
- ...
- <!--必須將當(dāng)前Resume的Activity設(shè)置為pause 然后stop才能繼續(xù)-->
- // 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;
- }
- ....
其實(shí)這里就是暫停ActivityA，AMS通過Binder告訴ActivityThread需要暫停的ActivityA，ActivityThread完成后再通過Binder通知AMS，AMS會(huì)開始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發(fā)送過來的pause消息之后，就會(huì)喚起ActivityB，入口還是resumeTopActivityLocked，喚醒B，之后還會(huì)A給進(jìn)一步stop掉，這個(gè)時(shí)候就牽扯到現(xiàn)場(chǎng)的保存，
ActivityStack
- private final void completePauseLocked() {
- if (!mService.isSleeping()) {
- resumeTopActivityLocked(prev);
- } else {
- ...
ActivityB如何啟動(dòng)的，本文不關(guān)心，只看ActivityA如何保存現(xiàn)場(chǎng)的，ActivityB起來后，會(huì)通過ActivityStack的stopActivityLocked去stop ActivityA，
- private final void stopActivityLocked(ActivityRecord r) {
- ...
- if (mMainStack) {
- r.app.thread.scheduleStopActivity(r.appToken, r.visible, r.configChangeFlags);
- ...
- }
回看APP端，看一下ActivityThread中的調(diào)用：首先通過callActivityOnSaveInstanceState，將現(xiàn)場(chǎng)保存到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動(dòng)作完成，在通知的時(shí)候，還會(huì)將保存的現(xiàn)場(chǎng)數(shù)據(jù)帶過去。
- 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不僅啟動(dòng)了新的Activity，同時(shí)也將上一個(gè)Activity的現(xiàn)場(chǎng)進(jìn)行了保存，及時(shí)由于種種原因上一個(gè)Actiivity被殺死，在回退，或者重新喚醒的過程中AMS也能知道如何喚起Activiyt，并恢復(fù)。
現(xiàn)在解決兩個(gè)問題，1、如何保存現(xiàn)場(chǎng)，2、AMS怎么判斷知道APP或者Activity是否被異常殺死，那么就剩下最后一個(gè)問題了，AMS如何恢復(fù)被異常殺死的APP或者Activity呢。
整個(gè)Application被后臺(tái)殺死情況下的恢復(fù)邏輯
其實(shí)在講解AMS怎么判斷知道APP或者Activity是否被異常殺死的時(shí)候，就已經(jīng)涉及了恢復(fù)的邏輯，也知道了一旦AMS知道了APP被后臺(tái)殺死了，那就不是正常的resuem流程了，而是要重新laucher，先來看一下整個(gè)APP被干掉的會(huì)怎么處理，看resumeTopActivityLocked部分,從上面的分析已知，這種場(chǎng)景下，會(huì)因?yàn)锽inder通信拋異常走異常分支，如下：
- 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!
- 這里是知道整個(gè)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;
- }
從上面的代碼可以知道，其實(shí)就是走startSpecificActivityLocked，這根第一次從桌面喚起APP沒多大區(qū)別，只是有一點(diǎn)需要注意，那就是這種時(shí)候啟動(dòng)的Activity是有上一次的現(xiàn)場(chǎng)數(shù)據(jù)傳遞過得去的，因?yàn)樯洗卧谕说胶笈_(tái)的時(shí)候，所有Activity界面的現(xiàn)場(chǎng)都是被保存了，并且傳遞到AMS中去的，那么這次的恢復(fù)啟動(dòng)就會(huì)將這些數(shù)據(jù)返回給ActivityThread，再來仔細(xì)看一下performLaunchActivity里面關(guān)于恢復(fù)的特殊處理代碼：
- 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);
- ...
- 關(guān)鍵點(diǎn) 1
- mInstrumentation.callActivityOnCreate(activity, r.state);
- ...
- r.activity = activity;
- r.stopped = true;
- if (!r.activity.mFinished) {
- activity.performStart();
- r.stopped = false;
- }
- 關(guān)鍵點(diǎn) 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);
- ...
- }
看一下關(guān)鍵點(diǎn)1跟2，先看關(guān)鍵點(diǎn)1，mInstrumentation.callActivityOnCreate會(huì)回調(diào)Actiivyt的onCreate，這個(gè)函數(shù)里面其實(shí)主要針對(duì)FragmentActivity做一些Fragment恢復(fù)的工作，ActivityClientRecord中的r.state是AMS傳給APP用來恢復(fù)現(xiàn)場(chǎng)的，正常啟動(dòng)的時(shí)候，這些都是null。再來看關(guān)鍵點(diǎn)2 ，在r.state != null非空的時(shí)候執(zhí)行mInstrumentation.callActivityOnRestoreInstanceState，這個(gè)函數(shù)默認(rèn)主要就是針對(duì)Window做一些恢復(fù)工作，比如ViewPager恢復(fù)之前的顯示位置等，也可以用來恢復(fù)用戶保存數(shù)據(jù)。
Application沒有被后臺(tái)殺死，Activity被殺死的恢復(fù)
打開開發(fā)者模式”不保留活動(dòng)“，就是這種場(chǎng)景，在上面的分析中，知道，AMS主動(dòng)異常殺死Activity的時(shí)候，將AcitivityRecord的app字段置空，因此resumeTopActivityLocked同整個(gè)APP被殺死不同，會(huì)走下面的分支
- final boolean resumeTopActivityLocked(ActivityRecord prev, Bundle options) {
- ...
- if (next.app != null && next.app.thread != null) {
- ...
- } else {
- 關(guān)鍵點(diǎn) 1 只是重啟Activity，可見這里其實(shí)是知道的，進(jìn)程并沒死，
- // Whoops, need to restart this activity!
- startSpecificActivityLocked(next, true, true);
- }
- return true;
- }
雖然不太一樣，但是同樣走startSpecificActivityLocked流程，只是不新建APP進(jìn)程，其余的都是一樣的，不再講解。到這里，我們應(yīng)該就了解了，
- Android是如何在預(yù)防的情況下保存場(chǎng)景
- AMS如何知道APP是否被后臺(tái)殺死
- AMS如何根據(jù)ActivityStack重建APP被殺死時(shí)的場(chǎng)景
到這里ActivityManagerService恢復(fù)APP場(chǎng)景的邏輯就應(yīng)該講完了。再碎碎念一些問題，可能是一些面試的點(diǎn)。
- 主動(dòng)清除最近任務(wù)跟異常殺死的區(qū)別：ActivityStack是否正常清楚
- 恢復(fù)的時(shí)候，為什么是倒序恢復(fù)：因?yàn)檫@是ActivityStack中的HistoryRecord中棧的順序，嚴(yán)格按照AMS端來
- 一句話概括Android后臺(tái)殺死恢復(fù)原理：Application進(jìn)程被Kill，但現(xiàn)場(chǎng)被AMS保存，AMS能根據(jù)保存恢復(fù)Application現(xiàn)場(chǎng)
