Android後臺殺死系列之二：ActivityManagerService與App現場恢復機制

時間  2019-11-16
標籤 android 後臺 殺死 系列 之二 activitymanagerservice app 現場 恢復 機制 欄目 Android 简体版
原文   原文鏈接

本篇是Android後臺殺死系列的第二篇，主要講解ActivityMangerService是如何恢復被後臺殺死的進程的（基於4.3 ），在開篇 FragmentActivity及PhoneWindow後臺殺死處理機制 中，簡述了後臺殺死所引發的一些常見問題，還有Android系統控件對後臺殺死所作的一些兼容，以及onSaveInstance跟onRestoreInstance的做用於執行時機，最後說了如何應對後臺殺死，可是對於被後臺殺死的進程如何恢復的並無講解，本篇不涉及後臺殺死，好比LowmemoryKiller機制，只講述被殺死的進程如何恢復的。假設，一個應用被後臺殺死，再次從最近的任務列表喚起App時候，系統是如何處理的呢？有這麼幾個問題可能須要解決：javascript

  • Android框架層（AMS）如何知道App被殺死了
  • App被殺前的場景是如何保存的
  • 系統（AMS）如何恢復被殺的App
  • 被後臺殺死的App的啓動流程跟普通的啓動有什麼區別
  • Activity的恢復順序爲何是倒序恢復

系統（AMS）如何知道App被殺死了

首先來看第一個問題，系統如何知道Application被殺死了，Android使用了Linux的oomKiller機制，只是簡單的作了個變種，採用分等級的LowmemoryKiller，但這個實際上是內核層面的，LowmemoryKiller殺死進程後，不會像用戶空間發送通知，也就是說框架層的ActivityMangerService沒法知道App是否被殺死，可是，只有知道App或者Activity是否被殺死，AMS（ActivityMangerService）才能正確的走喚起流程，那麼AMS到底是在何時知道App或者Activity被後臺殺死了呢？咱們先看一下從最近的任務列表進行喚起的時候，究竟發生了什麼。html

從最近的任務列表或者Icon再次喚起App的流程

在系統源碼systemUi的包裏，有個RecentActivity，這個其實就是最近的任務列表的入口，而其呈現界面是經過RecentsPanelView來展示的，點擊最近的App其執行代碼以下：java

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，看一下它的源碼，主要看一下加載：android

@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，來看一下它的意義：git

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喚起App的時候，AMS偵測App或者Activity是否被異常殺死

接着往下看moveTaskToFrontLocked，這個函數在ActivityStack中，ActivityStack主要用來管理ActivityRecord棧的，全部start的Activity都在ActivityStack中保留一個ActivityRecord，這個也是AMS管理Activity的一個依據，ActivityStack最終moveTaskToFrontLocked會調用resumeTopActivityLocked來喚起Activity，AMS獲取即將resume的Activity信息的方式主要是經過ActivityRecord，它並不知道Activity自己是否存活，獲取以後，AMS知道喚醒Activity的環節才知道App或者Activity被殺死，具體看一下resumeTopActivityLocked源碼：架構

final boolean resumeTopActivityLocked(ActivityRecord prev, Bundle options) {

     // This activity is now becoming visible.
        mService.mWindowManager.setAppVisibility(next.appToken, true);

     ....    恢復邏輯  
    if (next.app != null && next.app.thread != null) {
      // 正常恢復
        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!
            // 這裏須要重啓，難道被後臺殺死，走的是異常分支嗎？？？？ 異常殺死
            if (DEBUG_STATES) Slog.v(TAG, "Resume failed; resetting state to "
                    + lastState + ": " + next);
            next.state = lastState;
            mResumedActivity = lastResumedActivity;
            <!--確實這裏是由於進程掛掉了--> Slog.i(TAG, "Restarting because process died: " + next); 。。。 startSpecificActivityLocked(next, true, false); return true; } ... }複製代碼

因爲沒有主動調用finish的，因此AMS並不會清理掉ActivityRecord與TaskRecord ，所以resume的時候走的就是上面的分支，能夠這裏會調用next.app.thread.scheduleSendResult或者next.app.thread.scheduleResumeActivity進行喚起上一個Activity，可是若是APP或者Activity被異常殺死，那麼喚起的操做必定是失敗，會拋出異常，首先假設APP整個被殺死，那麼APP端同AMS通訊的Binder線程也不復存在，這個時候經過Binder進行通訊就會拋出RemoteException，如此，就會走下面的catch部分，經過startSpecificActivityLocked再次將APP重建，而且將最後的Activity重建，其實你能夠本地利用AIDL寫一個C/S通訊，在將一端關閉，而後用另外一端訪問，就會拋出RemoteException異常，以下圖：app

Binder訪問已經被殺死的進程

還有一種可能，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是爲了讓避免後面的清空邏輯。ide

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的呢？ 經過上面兩點分析，就知道了兩個關鍵點

  1. ActivityRecord沒有動HistoryRecord列表中移除
  2. 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

流程大概是以下樣子：

新Activity加載以及前Activity保存流程

如今咱們經過源碼一步一步跟一下，看看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 後臺殺死系列之一：FragmentActivity 及 PhoneWindow 後臺殺死處理機制
Android後臺殺死系列之二：ActivityManagerService與App現場恢復機制 Android後臺殺死系列之三：後臺殺死原理LowMemoryKiller（4.3-6.0）
Android後臺殺死系列之四：Binder訃告原理
Android後臺殺死系列之五：Android進程保活-自「裁」或者耍流氓

僅供參考，歡迎指正

參考文檔

Android應用程序啓動過程源代碼分析
Android Framework架構淺析之【近期任務】
Android Low Memory Killer介紹
Android開發之InstanceState詳解
對Android近期任務列表（Recent Applications）的簡單分析
Android——內存管理-lowmemorykiller 機制
Android 操做系統的內存回收機制
Android LowMemoryKiller原理分析
Android進程生命週期與ADJ
Linux下/proc目錄簡介
startActivity啓動過程分析 精
Activity銷燬流程

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程