一、垃圾回收（GC）：
Java垃圾回收器：
在C，C++或其他程序设计语言中，资源或内存都必须由程序员自行声明产生和回收，否则其中的资源将消耗，造成资源的浪费甚至崩溃。但手工回收内存往往是一项复杂而艰巨的工作。
于是，Java技术提供了一个系统级的线程，即垃圾收集器线程（Garbage Collection Thread），来跟踪每一块分配出去的内存空间，当Java 虚拟机（Java Virtual Machine）处于空闲循环时，垃圾收集器线程会自动检查每一快分配出去的内存空间，然后自动回收每一快可以回收的无用的内存块。
垃圾回收器优点：
1.减轻编程的负担，提高效率：
使程序员从手工回收内存空间的繁重工作中解脱了出来，因为在没有垃圾收集机制的时候，可能要花许多时间来解决一个难懂的存储器问题。在用Java语言编程的时候，靠垃圾收集机制可大大缩短时间。2.它保护程序的完整性：
因此垃圾收集是Java语言安全性策略的一个重要部份。
垃圾回收器缺点：
1.占用资源时间：
Java虚拟机必须追踪运行程序中有用的对象, 而且最终释放没用的对象。这一个过程需要花费处理器的时间。2.不可预知:
垃圾收集器线程虽然是作为低优先级的线程运行，但在系统可用内存量过低的时候，它可能会突发地执行来挽救内存资源。当然其执行与否也是不可预知的。3.不确定性：
不能保证一个无用的对象一定会被垃圾收集器收集，也不能保证垃圾收集器在一段Java语言代码中一定会执行。同样也没有办法预知在一组均符合垃圾收集器收集标准的对象中，哪一个会被首先收集。4.不可操作
垃圾收集器不可以被强制执行，但程序员可以通过调用System. gc方法来建议执行垃圾收集器。
垃圾回收算法：
1.引用计数（Reference Counting）
比较古老的回收算法。原理是此对象有一个引用，即增加一个计数，删除一个引用则减少一个计数。垃圾回收时，只用收集计数为0的对象。此算法最致命的是无法处理循环引用的问题。2.标记-清除（Mark-Sweep）
此算法执行分两阶段。第一阶段从引用根节点开始标记所有被引用的对象，第二阶段遍历整个堆，把未标记的对象清除。此算法需要暂停整个应用，同时，会产生内存碎片。3.复制（Copying）
此算法把内存空间划为两个相等的区域，每次只使用其中一个区域。垃圾回收时，遍历当前使用区域，把正在使用中的对象复制到另外一个区域中。次算法每次只处理正在使用中的对象，因此复制成本比较小，同时复制过去以后还能进行相应的内存整理，不过出现“碎片”问题。当然，此算法的缺点也是很明显的，就是需要两倍内存空间。4.标记-整理（Mark-Compact）
此算法结合了 “标记-清除”和“复制”两个算法的优点。也是分两阶段，第一阶段从根节点开始标记所有被引用对象，第二阶段遍历整个堆，把清除未标记对象并且把存活对象 “压缩”到堆的其中一块，按顺序排放。此算法避免了“标记-清除”的碎片问题，同时也避免了“复制”算法的空间问题。5.增量收集（Incremental Collecting）
实施垃圾回收算法，即：在应用进行的同时进行垃圾回收。不知道什么原因JDK5.0中的收集器没有使用这种算法的。6.分代（Generational Collecting）
基于对对象生命周期分析后得出的垃圾回收算法。把对象分为年青代、年老代、持久代，对不同生命周期的对象使用不同的算法（上述方式中的一个）进行回收。现在的垃圾回收器（从J2SE1.2开始）都是使用此算法的。
finalize（）:
每一个对象都有一个finalize方法，这个方法是从Object类继承来的。
当垃圾回收确定不存在对该对象的更多引用时，由对象的垃圾回收器调用此方法。
Java 技术允许使用finalize方法在垃圾收集器将对象从内存中清除出去之前做必要的清理工作。一旦垃圾回收器准备好释放对象占用的空间，将首先调用其finalize()方法，并且在下一次垃圾回收动作发生时，才会真正回收对象占用的内存。
简单的说finalize方法是在垃圾收集器删除对象之前对这个对象调用的
System.gc（）：
我们可以调用System.gc方法，建议虚拟机进行垃圾回收工作（注意，是建议，但虚拟机会不会这样干，我们也无法预知！）
一、Android APP 的运行环境
Android 是一款基于 Linux 内核，面向移动终端的操作系统。为适应其作为移动平台操作系统的特殊需要，谷歌对其做了特别的设计与优化，使得其进程调度与资源管理与其他平台的 Linux 有明显的区别。主要包含下面几个层次：
1、Application Framework
Application Framework 将整个操作系统分隔成两个部分。对应用开发者而言，所有 APP 都是运行在 Application Framework 之上，而并不需要关心系统底层的情况。Application Framework 层为应用开发者提供了丰富的应用编程接口，如 Activity Manager，Content Provider，Notification Manager，以及各种窗口 Widget 资源等。在 Application Framework 层，Activity 是一个 APP 最基本的组成部分。一般每个 Activity 对应于屏幕上的一个视图（或者说一屏），一个 APP 可以有一个或者多个 Activity。应用程序被打包成 .apk 格式的文件，由 Dalvik VM 解释执行。
2、Dalvik VM && Android Runtime（ART）
Dalvik 虚拟机采用寄存器架构，而不是 JVM 的栈结构。Java 程序编译后的 .class 文件并不能在 Dalvik 中解释执行。因此 Google 提供了一个 dx 工具，用于将 .class 文件转换成 Dalivk 能够识别的 .dex 格式。
Dalvik VM 效率并不是最高的。从 Android 4.4 开始，Google 开发者引进了新的 Android 运行环境 ART，从Android 5.0系统开始，安卓系统彻底从Dalvik转换到ART。
3、Linux kernel
由上所述，所有的 APP 都是由 Java 代码编写并在 Dalvik VM 中得到解释执行。在 Android 操作系统中，每个 Dalvik VM 的每个 Instance 都对应于 Linux 内核中的一个进程。可以使用 adb shell 工具查看系统中的当前进程。
二、Android 内存回收原则
下面将从 Application Framework 和 Linux kernel 两个层次分析 Android 操作系统的资源管理机制。
Android 之所以采用特殊的资源管理机制，原因在于其设计之初就是面向移动终端，所有可用的内存仅限于系统 RAM，必须针对这种限制设计相应的优化方案。当 Android 应用程序退出时，并不清理其所占用的内存，Linux 内核进程也相应的继续存在，所谓“退出但不关闭”。从而使得用户调用程序时能够在第一时间得到响应。当系统内存不足时，系统将激活内存回收过程。为了不因内存回收影响用户体验（如杀死当前的活动进程），Android 基于进程中运行的组件及其状态规定了默认的五个回收优先级：
- IMPORTANCE_FOREGROUND:前台进程
- IMPORTANCE_VISIBLE:可见进程
- IMPORTANCE_SERVICE:服务进程
- IMPORTANCE_BACKGROUND:后台进程
- IMPORTANCE_EMPTY:空进程
这几种优先级的回收顺序是 Empty process、Background process、Service process、Visible process、Foreground process。
ActivityManagerService 集中管理所有进程的内存资源分配。所有进程需要申请或释放内存之前必须调用 ActivityManagerService 对象，获得其“许可”之后才能进行下一步操作，或者 ActivityManagerService 将直接“代劳”。类 ActivityManagerService 中涉及到内存回收的几个重要的成员方法如下：trimApplications()，updateOomAdjLocked()，activityIdleInternal()。这几个成员方法主要负责 Android 默认的内存回收机制，若 Linux 内核中的内存回收机制没有被禁用，则跳过默认回收。
默认回收过程
Android 操作系统中的内存回收可分为两个层次，即默认内存回收与内核级内存回收。回收动作入口：activityIdleInternal()。
Android 系统中内存回收的触发点大致可分为三种情况。第一，用户程序调用 StartActivity(), 使当前活动的 Activity 被覆盖；第二，用户按 back 键，退出当前应用程序；第三，启动一个新的应用程序。这些能够触发内存回收的事件最终调用的函数接口就是 activityIdleInternal()。当 ActivityManagerService 接收到异步消息 IDLE_TIMEOUT_MSG 或者 IDLE_NOW_MSG 时，activityIdleInternal() 将会被调用。
清单 1. IDLE_NOW_MSG 的处理方式
case IDLE_NOW_MSG:{
IBinder token = (Ibinder)msg.obj;
activityIdle(token, null);
}
break;
清单 2. IDLE_TIMEOUT_MSG 的处理方式
case IDLE_TIMEOUT_MSG: {
if (mDidDexOpt) {
mDidDexOpt = false;
Message nmsg = mHandler.obtainMessage(IDLE_TIMEOUT_MSG);
nmsg.obj = msg.obj;
mHandler.sendMessageDelayed(nmsg, IDLE_TIMEOUT);
return;
}
IBinder token = (IBinder)msg.obj;
Slog.w(TAG, "Activity idle timeout for " + token);
activityIdleInternal(token, true, null);
}
break;
IDLE_NOW_MSG 由 Activity 的切换以及 Activiy 焦点的改变等事件引发，IDLE_TIMEOUT_MSG 在 Activity 启动超时的情况下引发，一般这个超时时间设为 10s，如果10s之内一个 Activity 依然没有成功启动，那么将发送异步消息 IDLE_TIMEOUT_MSG 进行资源回收。
activityIdleInternal() 的主要任务是改变系统中 Activity 的状态信息，并将其添加到不同状态列表中。其主要工作如下：
- 首先，调用
scheduleAppGcsLocked()方法通知所有进行中的任务进行垃圾回收。scheduleAppGcsLocked() 将进行调度 JVM 的 garbage collect，回收一部分内存空间，这里仅仅是通知每个进程自行进程垃圾检查并调度回收时间，而非同步回收。 - 然后，取出 mStoppingActivities 和 mFinishigActivities 列表中的所有内容，暂存在临时变量中。这两个列表分别存储了当前状态为 stop 和 finish 的 activity 对象。+ 对于 stop 列表，如果其中的 activity 的 finish 状态为 true，判断是不是要立即停止，如果要立即停止则调用 destroyActivityLocked() 通知目标进程调用 onDestroy() 方法，否则，先调用 resumeTopActivity() 运行下一个 Activity。如果 finish 状态为 false，则调用 stopActivityLocked() 通知客户进程停止该 Activity，这种情况一般发生在调用 startActivity() 后。对于 finish 列表，直接调用 destroyActivityLocked() 通知客户进程销毁目标 Activity。
这里的 destroyActivityLocked 等函数并没有真正意义上改变内存的使用，只是将其状态改变为“允许回收”，真正的回收在下面即将调用的 trimApplications() 函数中。
回收过程函数 trimApplications()
trimApplications() 函数的结构如下 :
清单 3. trimApplications 函数
private final void trimApplications() {
synchronized (this) {
// First remove any unused application processes whose package
// has been removed.
for (i=mRemovedProcesses.size()-1; i>=0; i--) {
(1)//kill process;
}
if (!updateOomAdjLocked()) {
(2)//do something default
}
// Finally, if there are too many activities now running, try to
// finish as many as we can to get back down to the limit. (3)do something
}
}
清单 3 中的三个标序号的位置分别负责如下工作：
（1）当程序执行到 trimApplications() 之后，首先检查 mRemovedProcesses 列表中的进程。mRemovedProcesses 列表中主要包含了 crash 的进程、5 秒内没有响应并被用户选在强制关闭的进程、以及应用开发这调用 killBackgroundProcess 想要杀死的进程。调用 Process.killProcess 将所有此类进程全部杀死。
（2）调用 updateOomAdjLocked() 函数，若成功返回，说明 Linux 内核支持 setOomAdj() 接口，updateOomAdjLocked 将修改 adj 的值并通知 linux 内核，内核根据 adj 值以及内存使用情况动态管理进程资源（lowmemorykiller 和 oom_killer）。若 updateOomAdjLocked() 返回为假，则表示当前系统不支持 setOomAdj() 接口，将在本地进行默认的资源回收。
（3）最后，如果当前依然运行了过多的 Activity，对多余的 Activity 进行回收。 trimApplications() 的大多数的代码都在处理 Oom_killer 不存在情况下的默认资源回收，下面对其默认回收过程（即代码清单中标记（2）的位置）进行进一步分析。其回收过程可大致描述如下。
步骤一，获取当前所有运行的进程 mLruProcesses，mLruProcesses 中的排序规则是按最近使用时间。对 mLruProcesses 中不能被关闭的进程进行计数，这些不能被关闭的进程包括运行 service 的进程，运行 broadcast receiver 的进程等，见如下代码。
清单 4. 计数不能被关闭的进程
if (app.persistent || app.services.size() != 0 || app.curReceiver != null || app.persistentActivities > 0) {
// Don't count processes holding services against our
// maximum process count. numServiceProcs++;
}
步骤二， 设当前最大运行进程数 curMaxProcs = curMaxProcs + numServiceProcs（即默认最大进程数与运行 Service 的进程数之和），如果当前进程的数量 mRemovedProcesses.size() 大于这个值，则遍历所有当前运行的进程，杀死符合条件的那些进程并释放内存。清理过程见清单 5（部分代码省略）。从清单 5 的代码中可以看出，进程被杀死的条件是：
必须是非 persistent 进程，即非系统进程；
必须是空进程，即进程中没有任何 activity 存在。如果杀死存在 Activity 的进程，有可能关闭用户正在使用的程序，或者使应用程序恢复的时延变大，从而影响用户体验；
必须无 broadcast receiver。运行 broadcast receiver 一般都在等待一个事件的发生，用户并不希望此类程序被系统强制关闭；
进程中 service 的数量必须为 0。存在 service 的进程很有可能在为一个或者多个程序提供某种服务，如 GPS 定位服务。杀死此类进程将使其他进程无法正常服务。
以上条件缺一不可。
清单 5. 清理过程
if (!app.persistent && app.activities.size() == 0 && app.curReceiver == null && app.services.size() == 0) {
if (app.pid > 0 && app.pid != MY_PID) {
Process.killProcess(app.pid);
} else {
try {
app.thread.scheduleExit();
} catch (Exception e) {
// Ignore exceptions.
}
}
// todo: For now we assume the application is not buggy
// or evil, and will quit as a result of our request.
// Eventually we need to drive this off of the death
// notification, and kill the process if it takes too long.
cleanUpApplicationRecordLocked(app, false, i);
i--;
}
步骤三，再次检查当前运行的进程，如果 mRemovedProcesses.size() 仍然大于 curMaxProcs，则放宽条件再次进行回收。判断条件见代码清单 6（部分代码省略）。下面代码中，布尔变量 canQuit 的值为真时，那么这个进程可以被回收。canQuit 的取值分两个步骤，首先是根据进程的属性赋值。
- 必须是非 persistent 进程，即非系统进程；
- 必须无 broadcast receiver；
- 进程中 service 的数量必须为 0；
- persistent 类型的 activity 数量为 0。
与步骤二唯一的不同在第 4 条，这里不要求进程是空进程，只要进程中没有 persistent 类型的 Activity 就可以（Activity 是否是 persistent 类型在开发阶段指定）。这些条件都满足时，再检查进程中每个 Activity 的属性，当该进程中所有的 Activity 都还必须满足三个条件：
- Activity 的状态已经保存，
- 当前处在不可见状态
- 并且 Activity 已经 Stop。
这时杀掉进程只会降低下次调用程序时的加载速度，下次启动时将恢复到关闭之前的状态，并不会在用户体验上造成致命的影响，所以，canQuit 置位为真。这种情况与步骤二的回收方式也有所不同，由于进程中 Activity 的数量不是 0，下一步需要对每个 activity 执行 destroyActivityLocked() 销毁，最后才杀死进程。
清单 6. 执行 destroyActivityLocked() 销毁
boolean canQuit = !app.persistent && app.curReceiver == null
&& app.services.size() == 0 && app.persistentActivities == 0;
int NUMA = app.activities.size();
for (j=0; j<NUMA && canQuit; j++) {
HistoryRecord r = (HistoryRecord)app.activities.get(j);
canQuit = (r.haveState || !r.stateNotNeeded) && !r.visible && r.stopped;
}
if (canQuit) {
// Finish all of the activities, and then the app itself.
for (j=0; j<NUMA; j++) {
HistoryRecord r = (HistoryRecord)app.activities.get(j);
if (!r.finishing) {
destroyActivityLocked(r, false);
}
r.resultTo = null;
}
if (app.pid > 0 && app.pid != MY_PID) {
Process.killProcess(app.pid);
}
cleanUpApplicationRecordLocked(app, false, i);
i--;
//dump();
}
步骤四，上面 3 个过程都是针对整个 process 进行的资源回收。在以上过程执行完毕之后，将在更小的粒度上对 Activity 的资源进行回收。与上面所述类似，列表 mLRUActivities 存储了当前所有运行中的 Activity，排序规则同样为最少访问原则。mLRUActivities.size() 返回系统中运行的 Activity 的数量，当其大于 MAX_ACTIVITIES（MAX_ACTIVITIES 是一个常量，一般值为 20，代表系统中最大允许同时存在的 Activity）时。将回收部分满足条件的 Activity 以减少内存的使用。回收条件代码清单 7 所示：
清单 7. 回收条件代码
//Finally, if there are too many activities now running, try to
// finish as many as we can to get back down to the limit.
for ( i=0; i<mLRUActivities.size() && mLRUActivities.size() > curMaxActivities; i++) {
final HistoryRecord r = (HistoryRecord)mLRUActivities.get(i);
// We can finish this one if we have its icicle saved and
// it is not persistent.
if ((r.haveState || !r.stateNotNeeded) && !r.visible && r.stopped && !r.persistent && !r.finishing) {
final int origSize = mLRUActivities.size();
destroyActivityLocked(r, true);
if (origSize > mLRUActivities.size()) {
i--;
}
}
}
这里回收的只是 Activity 的内存资源，并不会杀死进程，也不会影响进程的运行。当进程需要调用被杀掉的 Activity 时，可以从保存的状态中回复，当然可能需要相对长一点的时延。
