提起android的进程回收机制，大家所熟知的是Android的lowmemroykiller的机制。当系统可用内存低于某个阀值时，即会杀死这个阀值对应的Adj值的所有应用。但是本篇文章并为是要介绍Lowmemorykiller的机制，而是要搞清楚在未触发Android低杀机制时，Android是否有某种策略对进程进行回收。因为随着硬件成本低降低，各品牌手机低配置也是越来越高，4G及6G内存的手机层出不穷，在这类高内存配置的手机下，按照lowmemorykiller的默认参数来看，低杀出现的概率也小了很多。通过对AMS中的updateOomAdjLocked()方法的分析即可了解Android在lowmemorykiller之外的Android进程回收机制。

那我们按顺序来介绍updateOomAdjLocked方法。首先时初始化一些变量用以后续的操作。TOP_ACT和TOP_APP表示当前处于前台的app（若无app 处于前台则是TASK栈栈顶的应用）；根据LRU列表得到当前系统的存在的进程数量N；重置用户组中的进程状态的动作。TOP_ACT，rankTaskLayersIfNeeded方法，mAdjSeq这些变量主要是用于后面方法中会待调用的computateOomAdjLocked()方法，这不是我们本篇的重点，所以不再展开进行详解。

  1.         final ActivityRecord TOP_ACT = resumedAppLocked();
  2.         final ProcessRecord TOP_APP = TOP_ACT != null ? TOP_ACT.app : null;
  3.         final long now = SystemClock.uptimeMillis();
  4.         final long nowElapsed = SystemClock.elapsedRealtime();
  5.         final long oldTime = now - ProcessList.MAX_EMPTY_TIME;
  6.         final int N = mLruProcesses.size();
  7.  
  8.         ...
  9.  
  10.         // Reset state in all uid records.
  11.         for (int i=mActiveUids.size()-1; i>=0; i--) {
  12.             final UidRecord uidRec = mActiveUids.valueAt(i);
  13.             if (false && DEBUG_UID_OBSERVERS) Slog.i(TAG_UID_OBSERVERS,
  14.                     "Starting update of " + uidRec);
  15.             uidRec.reset();
  16.         }
  17.  
  18.         mStackSupervisor.rankTaskLayersIfNeeded();
  19.  
  20.         mAdjSeq++;
  21.         mNewNumServiceProcs = 0;
  22.         mNewNumAServiceProcs = 0;

mProcessLimit表示的是系统允许保留的后台进程和empty进程的总和，初始化为ProcessList.MAX_CACHED_APPS常量，默认为32。Android自身的机制在运行中不会主动修改这个值，但用户可以在“开发者选项”的“后台进程限制”这一项来修改该值。emptyProcessLimit和cachedProcessLimit分别为根据mProcessLimit的值计算出的允许的后台进程和empty进程的最大数量。当mProcessLimit不小于0且不等于1时，后台进程和empty进程和后台进程的数量各占mProcessLimit的一半。 本文讲的后台进程是指cached进程里的非empty的进程，而不包含后台服务进程。

  1.         final int emptyProcessLimit;
  2.         final int cachedProcessLimit;
  3.         if (mProcessLimit <= 0) {
  4.             emptyProcessLimit = cachedProcessLimit = 0;
  5.         } else if (mProcessLimit == 1) {
  6.             emptyProcessLimit = 1;
  7.             cachedProcessLimit = 0;
  8.         } else {
  9.             emptyProcessLimit = ProcessList.computeEmptyProcessLimit(mProcessLimit);
  10.             cachedProcessLimit = mProcessLimit - emptyProcessLimit;
  11.         }

再往下是初始化一些变量的操作，这里要重点注意numSlots所表达的意思。ProcessList.CACHED_APP_MAX_ADJ和Process.CACHED_APP_MIN_ADJ常量系统默认的值分别为906和900，表示的是后台进程和empty进程分配的值是在900至906之间，共有7个值。numSloas计算过程中除以2是因为每个槽配置到进程包含后台进程和empty进程两种，两种进程需用不同adj值表示，所以每个槽包含两个adj值的分配空间，所以需要除以二，计算出来的numSlots值为3。emptyFactor表示每个槽中需要放置几个empty进程，是根据当前empty进程总数决定的，cachedFactor即是表示需要放置几个后台进程到每个槽中。

为便于理解，结合后面代码逻辑举例来讲，比如后台此时有15个cahcedProcess（后台进程）和12个emptyProcess，则会将15/3＝5个cachedProcess设置到在第一个槽（可分配900，901这两个oom_adj值）中，oom_adj设置为900；将12/4=4个emptyProcess设置在第一槽，oom_adj值设置为901；然后再设置5个cachedProcess和4个emptyProcess的oom_adj值分别为902和903，即第二个槽。

  1.         // Let's determine how many processes we have running vs.
  2.         // how many slots we have for background processes; we may want
  3.         // to put multiple processes in a slot of there are enough of
  4.         // them.
  5.         int numSlots = (ProcessList.CACHED_APP_MAX_ADJ
  6.                 - ProcessList.CACHED_APP_MIN_ADJ + 1) / 2;
  7.         int numEmptyProcs = N - mNumNonCachedProcs - mNumCachedHiddenProcs;
  8.         if (numEmptyProcs > cachedProcessLimit) {
  9.             // If there are more empty processes than our limit on cached
  10.             // processes, then use the cached process limit for the factor.
  11.             // This ensures that the really old empty processes get pushed
  12.             // down to the bottom, so if we are running low on memory we will
  13.             // have a better chance at keeping around more cached processes
  14.             // instead of a gazillion empty processes.
  15.             numEmptyProcs = cachedProcessLimit;
  16.         }
  17.         int emptyFactor = numEmptyProcs/numSlots;
  18.         if (emptyFactor < 1) emptyFactor = 1;
  19.         int cachedFactor = (mNumCachedHiddenProcs > 0 ? mNumCachedHiddenProcs : 1)/numSlots;
  20.         if (cachedFactor < 1) cachedFactor = 1;
  21.         int stepCached = 0;
  22.         int stepEmpty = 0;
  23.         int numCached = 0;
  24.         int numEmpty = 0;
  25.         int numTrimming = 0;
  26.  
  27.         mNumNonCachedProcs = 0;
  28.         mNumCachedHiddenProcs = 0;

接下来是对mLruProcesses列表进行遍历，通过遍历的过程会更新每一个进程的Adj值。遍历过程中首先会先调用computOomAdjLocked方法进行oom_adj的计算，在该方法中其实已经完成了cachedProcess和emptyProcess进程以外的进程的oom_adj值的计算，而对于未完成计算的这两类进程会进入到下面的if (app.curAdj >= ProcessList.UNKNOWN_ADJ)的逻辑中，该图中已省略去，后文再讲。再往下调用了applyOomAdjLocked的逻辑来更新计算好的oom_adj值。再往下进入switch循环，这个循环里的逻辑即可解答我们在文中开头提出的问题。最后是一个针对isolated进程的特殊的处理。

  1.         // First update the OOM adjustment for each of the
  2.         // application processes based on their current state.
  3.         int curCachedAdj = ProcessList.CACHED_APP_MIN_ADJ;
  4.         int nextCachedAdj = curCachedAdj+1;
  5.         int curEmptyAdj = ProcessList.CACHED_APP_MIN_ADJ;
  6.         int nextEmptyAdj = curEmptyAdj+2;
  7.         for (int i=N-1; i>=0; i--) {
  8.             ProcessRecord app = mLruProcesses.get(i);
  9.             if (!app.killedByAm && app.thread != null) {
  10.                 app.procStateChanged = false;
  11.                 computeOomAdjLocked(app, ProcessList.UNKNOWN_ADJ, TOP_APP, true, now);
  12.  
  13.                 // If we haven't yet assigned the final cached adj
  14.                 // to the process, do that now.
  15.                 if (app.curAdj >= ProcessList.UNKNOWN_ADJ) {
  16.                     ...
  17.                 }
  18.  
  19.                 applyOomAdjLocked(app, true, now, nowElapsed);
  20.  
  21.                 // Count the number of process types.
  22.                 switch (app.curProcState) {
  23.                     ...
  24.                 }
  25.  
  26.                 if (app.isolated && app.services.size() <= 0) {
  27.                     ...
  28.                 }
  29.  
  30.                 if (app.curProcState >= ActivityManager.PROCESS_STATE_HOME
  31.                         && !app.killedByAm) {
  32.                     numTrimming++;
  33.                 }
  34.             }
  35.         } 

首先来看if (app.curAdj >= ProcessList.UNKNOWN_ADJ)里的逻辑，即是对cachedProcess和emptyProcess进程的oom_adj计算的过程。当进程为包含activity的cached进程即文中所表达的后台进程或者其客户端进程时，设置该进程的adj值为curCachedAdj，curAdj初始为Process.CACHED_APP_MIN_ADJ，即900。分配的逻辑前文已经提到过，如果时15个CachedProcess，则cachedFactor为15，分配5个cachedProcess进程的oom_adj值为900后，增加curCachedAdj值到902，再分配5个cachedProcess的oom_adj值为902，依次类推到分配完。在该switch的逻辑中default处理的是emptyProcess进程的oom_adj计算方式，与cachedProcess相似，这里不再贴出叙述了。

  1.                    switch (app.curProcState) {
  2.                         case ActivityManager.PROCESS_STATE_CACHED_ACTIVITY:
  3.                         case ActivityManager.PROCESS_STATE_CACHED_ACTIVITY_CLIENT:
  4.                             // This process is a cached process holding activities...
  5.                             // assign it the next cached value for that type, and then
  6.                             // step that cached level.
  7.                             app.curRawAdj = curCachedAdj;
  8.                             app.curAdj = app.modifyRawOomAdj(curCachedAdj);
  9.                             if (DEBUG_LRU && false) Slog.d(TAG_LRU, "Assigning activity LRU #" + i
  10.                                     + " adj: " + app.curAdj + " (curCachedAdj=" + curCachedAdj
  11.                                     + ")");
  12.                             if (curCachedAdj != nextCachedAdj) {
  13.                                 stepCached++;
  14.                                 if (stepCached >= cachedFactor) {
  15.                                     stepCached = 0;
  16.                                     curCachedAdj = nextCachedAdj;
  17.                                     nextCachedAdj += 2;
  18.                                     if (nextCachedAdj > ProcessList.CACHED_APP_MAX_ADJ) {
  19.                                         nextCachedAdj = ProcessList.CACHED_APP_MAX_ADJ;
  20.                                     }
  21.                                 }
  22.                             }
  23.                             break;
  24.                         default:
  25.                             ...//处理empty进程，方式与上面的cachedProcess相似
  26.                             break;
  27.                     }

再来看switch (app.curProcState)逻辑中的处理，这里完成的主要就是对比当前cachedProcess和emptyProcess的数量是否超过这两类进程的限制值，如果超过了则调用kill方法杀掉该进程。由于这是在便利LruProcesses列表中完成的，遍历过程是由最近的进程到最远的进程的顺序来完成的，所以当遍历到越久远到进程时numCached的值越大，则越容易超过限制值。

由此，我们可以了解到Android系统在Lowmemeorykill之外的回收机制是：

1.只会对于后台进程和空进程进行回收

2.后台进程和空进程的系统允许的最大限制值为ProcessList.MAX_CACHED_APPS常量的一半

3.当后台进程数或空进程数超过限制值时会对最久不使用的进程进行回收（调用kill方法），直到这两类进程数量不多于各自的进程限制值。

  1.                 // Count the number of process types.
  2.                 switch (app.curProcState) {
  3.                     case ActivityManager.PROCESS_STATE_CACHED_ACTIVITY:
  4.                     case ActivityManager.PROCESS_STATE_CACHED_ACTIVITY_CLIENT:
  5.                         mNumCachedHiddenProcs++;
  6.                         numCached++;
  7.                         if (numCached > cachedProcessLimit) {
  8.                             app.kill("cached #" + numCached, true);
  9.                         }
  10.                         break;
  11.                     case ActivityManager.PROCESS_STATE_CACHED_EMPTY:
  12.                         if (numEmpty > ProcessList.TRIM_EMPTY_APPS
  13.                                 && app.lastActivityTime < oldTime) {
  14.                             app.kill("empty for "
  15.                                     + ((oldTime + ProcessList.MAX_EMPTY_TIME - app.lastActivityTime)
  16.                                     / 1000) + "s", true);
  17.                         } else {
  18.                             numEmpty++;
  19.                             if (numEmpty > emptyProcessLimit) {
  20.                                 app.kill("empty #" + numEmpty, true);
  21.                             }
  22.                         }
  23.                         break;
  24.                     default:
  25.                         mNumNonCachedProcs++;
  26.                         break;
  27.                 }

在LruProcess遍历的最后是对isolated process单独的处理，对于设置了isolated属性的进程为true的进程如果已经不包含服务了，则立刻kill掉该进程，最后是记录当前adj值大于等于桌面进程的所有进程数量，保存到numTrimming中。

  1.                 if (app.isolated && app.services.size() <= 0) {
  2.                     // If this is an isolated process, and there are no
  3.                     // services running in it, then the process is no longer
  4.                     // needed.  We agressively kill these because we can by
  5.                     // definition not re-use the same process again, and it is
  6.                     // good to avoid having whatever code was running in them
  7.                     // left sitting around after no longer needed.
  8.                     app.kill("isolated not needed", true);
  9.                 } else {
  10.                     // Keeping this process, update its uid.
  11.                     final UidRecord uidRec = app.uidRecord;
  12.                     if (uidRec != null && uidRec.curProcState > app.curProcState) {
  13.                         uidRec.curProcState = app.curProcState;
  14.                     }
  15.                 }
  16.  
  17.                 if (app.curProcState >= ActivityManager.PROCESS_STATE_HOME
  18.                         && !app.killedByAm) {
  19.                     numTrimming++;
  20.                 }

虽然已经了解完android在非lowmemory情况下的内存回收机制，我们继续来看完updateOomAdjLocked方法在更新完adj值后续的动作。首先根据当前的cachedProcess和emptyProcess进程的数量来综合判定当前进程的等级，这两类进程的数量越少，表示系统内存越紧张，内存等级越高。由低至高（对应的数值也是由低至高）分别为ADJ_MEM_FACTOR_NORMAL、ADJ_MEM_FACTOR_MODERATE、ADJ_MEM_FACTOR_LOW、ADJ_MEM_FACTOR_CRITICAL这四个等级。

为什么能根据后台进程和空进程数量来判断出系统的内存等级呢？因为根据之前的分析可以知道，Android系统在后台进程和空进程不超过数量上限时总是尽可能多的保留后台进程和空进程，这样用户便可再再次启动这些进程时减少启动时间从而提高了用户体验；而lowmemeorykiller的机制又会在系统可用内存不足时杀死这些进程，所以在后台进程和空进程数量少于一定数量时，便表示了系统以及触发了lowmemrorykiller的机制，而剩余的后台进程和空进程的数量则正好体现了Lowmemroykiller杀进程的程度，即表示当前系统内存的紧张程度。

  1.         // Now determine the memory trimming level of background processes.
  2.         // Unfortunately we need to start at the back of the list to do this
  3.         // properly.  We only do this if the number of background apps we
  4.         // are managing to keep around is less than half the maximum we desire;
  5.         // if we are keeping a good number around, we'll let them use whatever
  6.         // memory they want.
  7.         final int numCachedAndEmpty = numCached + numEmpty;
  8.         int memFactor;
  9.         if (numCached <= ProcessList.TRIM_CACHED_APPS
  10.                 && numEmpty <= ProcessList.TRIM_EMPTY_APPS) {
  11.             if (numCachedAndEmpty <= ProcessList.TRIM_CRITICAL_THRESHOLD) {
  12.                 memFactor = ProcessStats.ADJ_MEM_FACTOR_CRITICAL;
  13.             } else if (numCachedAndEmpty <= ProcessList.TRIM_LOW_THRESHOLD) {
  14.                 memFactor = ProcessStats.ADJ_MEM_FACTOR_LOW;
  15.             } else {
  16.                 memFactor = ProcessStats.ADJ_MEM_FACTOR_MODERATE;
  17.             }
  18.         } else {
  19.             memFactor = ProcessStats.ADJ_MEM_FACTOR_NORMAL;
  20.         }
  21.         // We always allow the memory level to go up (better).  We only allow it to go
  22.         // down if we are in a state where that is allowed, *and* the total number of processes
  23.         // has gone down since last time.
  24.         if (DEBUG_OOM_ADJ) Slog.d(TAG_OOM_ADJ, "oom: memFactor=" + memFactor
  25.                 + " last=" + mLastMemoryLevel + " allowLow=" + mAllowLowerMemLevel
  26.                 + " numProcs=" + mLruProcesses.size() + " last=" + mLastNumProcesses);
  27.         if (memFactor > mLastMemoryLevel) {
  28.             if (!mAllowLowerMemLevel || mLruProcesses.size() >= mLastNumProcesses) {
  29.                 memFactor = mLastMemoryLevel;
  30.                 if (DEBUG_OOM_ADJ) Slog.d(TAG_OOM_ADJ, "Keeping last mem factor!");
  31.             }
  32.         }

接下来是系统内存等级不为ADJ_MEM_FACTOR_NORMAL时的处理，此时所有的进程都需要进行内存回收操作，后面的处理就是针对不同的进程得到对应的进程内存回收等级，并按照该等级执行进程内的内存回收操作。判定完进程的回收等级之后，计算出factor变量。这里的factor的计算方式与之前计算oom_adj时的槽的方式相似。则后面遍历时前四个进程属于同一个槽使用同一等级进行回收，之后四个再使用下一个等级进行回收。

  1.         mLastMemoryLevel = memFactor;
  2.         mLastNumProcesses = mLruProcesses.size();
  3.         boolean allChanged = mProcessStats.setMemFactorLocked(memFactor, !isSleepingLocked(), now);
  4.         final int trackerMemFactor = mProcessStats.getMemFactorLocked();
  5.         if (memFactor != ProcessStats.ADJ_MEM_FACTOR_NORMAL) {
  6.             if (mLowRamStartTime == 0) {
  7.                 mLowRamStartTime = now;
  8.             }
  9.             int step = 0;
  10.             int fgTrimLevel;
  11.             switch (memFactor) {
  12.                 case ProcessStats.ADJ_MEM_FACTOR_CRITICAL:
  13.                     fgTrimLevel = ComponentCallbacks2.TRIM_MEMORY_RUNNING_CRITICAL;
  14.                     break;
  15.                 case ProcessStats.ADJ_MEM_FACTOR_LOW:
  16.                     fgTrimLevel = ComponentCallbacks2.TRIM_MEMORY_RUNNING_LOW;
  17.                     break;
  18.                 default:
  19.                     fgTrimLevel = ComponentCallbacks2.TRIM_MEMORY_RUNNING_MODERATE;
  20.                     break;
  21.             }
  22.             int factor = numTrimming/3;
  23.             int minFactor = 2;
  24.             if (mHomeProcess != null) minFactor++;
  25.             if (mPreviousProcess != null) minFactor++;
  26.             if (factor < minFactor) factor = minFactor;
  27.             int curLevel = ComponentCallbacks2.TRIM_MEMORY_COMPLETE;
  28.             for (int i=N-1; i>=0; i--) {
                  ...
                }
  29.         }

展开for (int i=N-1; i>=0; i--)循环，里面是对mLruProcesses进程遍历，顺序是从最近的进程向最久远的进程进行遍历。

首先是遍历过程中重要性低于ActivityManager.PROCESS_STATE_HOME的进程的处理，包括B-Service进程、cachedProcess和emptyProcess。由于curLevel设置的初始值为最高等级，而在遍历mLruProcess过程中curLevel会逐渐减少，结合遍历是由近至远这里涵盖的思想就是越近的进程adj值会越高（相同类别），而adj值越高的进程越不容易被lowmemroykiller机制杀死，这样这类越不容易杀死的进程就越应该执行高回收等级的回收动作。

  1.             for (int i=N-1; i>=0; i--) {
  2.                 ProcessRecord app = mLruProcesses.get(i);
  3.                 if (allChanged || app.procStateChanged) {
  4.                     setProcessTrackerStateLocked(app, trackerMemFactor, now);
  5.                     app.procStateChanged = false;
  6.                 }
  7.                 if (app.curProcState >= ActivityManager.PROCESS_STATE_HOME
  8.                         && !app.killedByAm) {
  9.                     if (app.trimMemoryLevel < curLevel && app.thread != null) {
  10.                         try {
  11.                             if (DEBUG_SWITCH || DEBUG_OOM_ADJ) Slog.v(TAG_OOM_ADJ,
  12.                                     "Trimming memory of " + app.processName + " to " + curLevel);
  13.                             app.thread.scheduleTrimMemory(curLevel);
  14.                         } catch (RemoteException e) {
  15.                         }
  16.                         if (false) {
  17.                             // For now we won't do this; our memory trimming seems
  18.                             // to be good enough at this point that destroying
  19.                             // activities causes more harm than good.
  20.                             if (curLevel >= ComponentCallbacks2.TRIM_MEMORY_COMPLETE
  21.                                     && app != mHomeProcess && app != mPreviousProcess) {
  22.                                 // Need to do this on its own message because the stack may not
  23.                                 // be in a consistent state at this point.
  24.                                 // For these apps we will also finish their activities
  25.                                 // to help them free memory.
  26.                                 mStackSupervisor.scheduleDestroyAllActivities(app, "trim");
  27.                             }
  28.                         }
  29.                     }
  30.                     app.trimMemoryLevel = curLevel;
  31.                     step++;
  32.                     if (step >= factor) {
  33.                         step = 0;
  34.                         switch (curLevel) {
  35.                             case ComponentCallbacks2.TRIM_MEMORY_COMPLETE:
  36.                                 curLevel = ComponentCallbacks2.TRIM_MEMORY_MODERATE;
  37.                                 break;
  38.                             case ComponentCallbacks2.TRIM_MEMORY_MODERATE:
  39.                                 curLevel = ComponentCallbacks2.TRIM_MEMORY_BACKGROUND;
  40.                                 break;
  41.                         }
  42.                     }
  43.                 } else if (app.curProcState == ActivityManager.PROCESS_STATE_HEAVY_WEIGHT) {
  44.                     ...
  45.                 } else {
  46.                     ...
  47.                 }
  48.             }

之后是对重要性大于PROCESS_STATE_HOME的PROCESS_STATE_HEAVY_WEIGHT进程的处理，只有当进程本身的回收等级低于TRIM_MEMORY_BACKGROUND时，才再执行TRIM_MEMORY_BACKGROUND的等级的回收

  1.         else if (app.curProcState == ActivityManager.PROCESS_STATE_HEAVY_WEIGHT) {
  2.                     if (app.trimMemoryLevel < ComponentCallbacks2.TRIM_MEMORY_BACKGROUND
  3.                             && app.thread != null) {
  4.                         try {
  5.                             if (DEBUG_SWITCH || DEBUG_OOM_ADJ) Slog.v(TAG_OOM_ADJ,
  6.                                     "Trimming memory of heavy-weight " + app.processName
  7.                                     + " to " + ComponentCallbacks2.TRIM_MEMORY_BACKGROUND);
  8.                             app.thread.scheduleTrimMemory(
  9.                                     ComponentCallbacks2.TRIM_MEMORY_BACKGROUND);
  10.                         } catch (RemoteException e) {
  11.                         }
  12.                     }
  13.                     app.trimMemoryLevel = ComponentCallbacks2.TRIM_MEMORY_BACKGROUND;
  14.                 }

对于重要性高于PROCESS_STATE_HOME的其他类别的进程，其中如果重要性低于PROCESS_STATE_IMPORTANT_BACKGROUND则以TRIM_MEMORY_UI_HIDDEN的等级进行进程内的回收；如果进程自身的回收等级低于当前回收等级fgTrimLevel，则对该进程以当前回收等级进行回收。这里的意思是，避免多次执行回收，这类重要性高于HOME的进程，只有在内存变得更紧时，才以更高的等级进行回收一次。

  1.           else {
  2.                     if ((app.curProcState >= ActivityManager.PROCESS_STATE_IMPORTANT_BACKGROUND
  3.                             || app.systemNoUi) && app.pendingUiClean) {
  4.                         // If this application is now in the background and it
  5.                         // had done UI, then give it the special trim level to
  6.                         // have it free UI resources.
  7.                         final int level = ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN;
  8.                         if (app.trimMemoryLevel < level && app.thread != null) {
  9.                             try {
  10.                                 if (DEBUG_SWITCH || DEBUG_OOM_ADJ) Slog.v(TAG_OOM_ADJ,
  11.                                         "Trimming memory of bg-ui " + app.processName
  12.                                         + " to " + level);
  13.                                 app.thread.scheduleTrimMemory(level);
  14.                             } catch (RemoteException e) {
  15.                             }
  16.                         }
  17.                         app.pendingUiClean = false;
  18.                     }
  19.                     if (app.trimMemoryLevel < fgTrimLevel && app.thread != null) {
  20.                         try {
  21.                             if (DEBUG_SWITCH || DEBUG_OOM_ADJ) Slog.v(TAG_OOM_ADJ,
  22.                                     "Trimming memory of fg " + app.processName
  23.                                     + " to " + fgTrimLevel);
  24.                             app.thread.scheduleTrimMemory(fgTrimLevel);
  25.                         } catch (RemoteException e) {
  26.                         }
  27.                     }
  28.                     app.trimMemoryLevel = fgTrimLevel;
  29.                 }

再来看，如果根据cachedProcess和emptyProcess数量计算出的系统内存等级为正常时候的处理。简单来说，此时只需要让重要性低于PROCESS_STATE_IMPORTANT_BACKGROUND以TRIM_MEMORY_UI_HIDDEN进行回收即可。

  1.         if (memFactor != ProcessStats.ADJ_MEM_FACTOR_NORMAL) {
  2.             ...
  3.         } else {
  4.             if (mLowRamStartTime != 0) {
  5.                 mLowRamTimeSinceLastIdle += now - mLowRamStartTime;
  6.                 mLowRamStartTime = 0;
  7.             }
  8.             for (int i=N-1; i>=0; i--) {
  9.                 ProcessRecord app = mLruProcesses.get(i);
  10.                 if (allChanged || app.procStateChanged) {
  11.                     setProcessTrackerStateLocked(app, trackerMemFactor, now);
  12.                     app.procStateChanged = false;
  13.                 }
  14.                 if ((app.curProcState >= ActivityManager.PROCESS_STATE_IMPORTANT_BACKGROUND
  15.                         || app.systemNoUi) && app.pendingUiClean) {
  16.                     if (app.trimMemoryLevel < ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN
  17.                             && app.thread != null) {
  18.                         try {
  19.                             if (DEBUG_SWITCH || DEBUG_OOM_ADJ) Slog.v(TAG_OOM_ADJ,
  20.                                     "Trimming memory of ui hidden " + app.processName
  21.                                     + " to " + ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN);
  22.                             app.thread.scheduleTrimMemory(
  23.                                     ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN);
  24.                         } catch (RemoteException e) {
  25.                         }
  26.                     }
  27.                     app.pendingUiClean = false;
  28.                 }
  29.                 app.trimMemoryLevel = 0;
  30.             }
  31.         }　　

方法的最后是一些扫尾和保存相关状态变化的工作，比如配合开发者模式的选项判断时候执行activity等，这里不再展开介绍。

总结一下，updateOomAdjLocked方法主要完成了三个动作：

一、更新所有应用等oom_adj值，其中非cachedProcess和emptyProcess进程等oom_adj值的计算通过调用computeOomAdjLocked方法完成，而cachedProcess和emptyProcess进程则按照由近至远的方式交替从小至大的分配oom_adj值

二、根据cachedPrcess和emptyProcess的数量判断是否超过数量上限，超过则杀死进程，越久远的进程在超过时优先被杀死，这也回答了我们本文开头提出的问题。

三、根据cachedPrcess和emptyProcess的数量判断当前内存的紧张程度生成对应等级，根据当前系统内存等级，来要求进程做对应的进程内的回收。

Android内存管理篇 - 从updateOomAdjLocked看lowmemorykiller之外的Android进程回收机制的更多相关文章

  1. Android进程回收机制LMK(Low Memory Killer)

    熟悉Android系统的童鞋都知道,系统出于体验和性能上的考虑,app在退到后台时系统并不会真正的kill掉这个进程,而是将其缓存起来.打开的应用越多,后台缓存的进程也越多.在系统内存不足的情况下,系 ...

  2. Android进程回收机制LMK(Low Memory Killer)【转】

    本文转载自:http://www.cnblogs.com/wytiger/p/5744752.html 熟悉Android系统的童鞋都知道,系统出于体验和性能上的考虑,app在退到后台时系统并不会真正 ...

  3. Android内存管理篇 - adj的概念与进程adj级别控制

    本文主要介绍Android的lowmemorykiller的oom_adj的相关概念,以及根据一些案例来阐述了解oom_adj对于做Android应用开发的重要意义. 一.lowmeorykiller ...

  4. Android 内存泄漏优化汇总

    android内存泄漏优化摘要 博客分类: android android内存溢出OutOfMemoryError . android移动应用程序的内存分配一般是8凯瑟琳约,不正确地假定处理内存处理非 ...

  5. Android内存优化总结【整理】

    http://blog.csdn.net/tiantangrenjian/article/details/39182293 [前段时间接到任务着手进行app的内存优化,从各种各样的渠道搜索相关资料,最 ...

  6. 【转载】Android 内存溢出如何发生的。

    [转载]Android 内存溢出如何发生的. 且谈Android内存溢出 前言 关于android的内存溢出在创新文档库中也有不少,网络上也有很多这方面的资料.所以这遍文章不算是正真意义上的创新,仅仅 ...

  7. jvm大局观之内存管理篇(二):当java中new一个对象,背后发生了什么

    https://zhuanlan.zhihu.com/p/257863129?utm_source=ZHShareTargetIDMore 番茄番茄我是西瓜 那是我日夜思念深深爱着的人啊~ 已关注   ...

  8. Android内存优化（一）DVM和ART原理初探

    相关文章 Android内存优化系列 Java虚拟机系列 前言 要学习Android的内存优化,首先要了解Java虚拟机,此前我用了多篇文章来介绍Java虚拟机的知识,就是为了这个系列做铺垫.在And ...

  9. 【朝花夕拾】Android性能篇之（六）Android进程管理机制

    前言        Android系统与其他操作系统有个很不一样的地方,就是其他操作系统尽可能移除不再活动的进程,从而尽可能保证多的内存空间,而Android系统却是反其道而行之,尽可能保留进程.An ...

随机推荐

  1. python 基础_ 数组的 增删改查3

    数组是运用在多个数据存在一个变量中的,而在调用的时候可以调用所需要的数组. 创建数组 a = ['a','b','c','d','f'] #创建一个数组a其中有5个元素分别是abcdf 1.查询.所谓 ...

  2. c#+web下载文件夹

    最近公司在做工程项目,实现文件夹下载. 网上找了很久,发现网上的代码都有相似的问题,不过最终还是让我找到了一个符合的项目. 工程: 进行项目文件夹下载功能分析,弄清楚文件夹下载的原理,提供的数据支持. ...

  3. uwsgi_read_timeout超时处理

    最近发现一服务器一个奇怪的现象: Django的视图函数在浏览器一个请求的情况下,竟然做了两个请求的函数处理.不可思议,找了几天也不知道为什么, 只发现只要用uwsgi_read_timeout之后, ...

  4. redis状态监控可视化工具RedisLive使用

    首先,别人写的工具,赞一下  github地址 https://github.com/nkrode/RedisLive 然后,fork一下,自己加点功能 gui介绍(直接copy的github图片) ...

  5. (spfa) Highway Project (zoj 3946 )

    http://acm.zju.edu.cn/onlinejudge/showProblem.do?problemId=5718   Highway Project Time Limit: 2 Seco ...

  6. Northwind测试学习用数据库

    下载地址: https://northwinddatabase.codeplex.com/

  7. hdu 4937 base进制只含3456的base数

    http://acm.hdu.edu.cn/showproblem.php?pid=4937 给定一个数n,若这个数在base进制下全由3,4,5,6组成的话,则称base为n的幸运进制,给定n,求有 ...

  8. iOS笔记之UIKit_UIButton

    //UIButton的基本属性 _btn = [UIButton buttonWithType:UIButtonTypeCustom]; _btn.frame = CGRectMake(0, 200, ...

  9. [Erlang02] 那些经历过的Erlang小坑1-10

    1. 保护式(guard)中如果出错,不会报错,只会返回false! case 1=:1 of true when not erlang:length(t) =:= 1 orelse true -&g ...

  10. ASP.NET MVC5 高级编程-学习日记-第二章 控制器

    2.1 控制器的角色 MVC模式中的控制器(Controller)主要负责响应用户的输入,冰球在响应时修改模型(Model).通过这种方式,MVC模式中的控制器主要关注的是应用程序流.输入数据的处理, ...