通过前面一系列文章的学习，我们知道了ART运行时既支持Mark-Sweep GC，又支持Compacting GC。其中，Mark-Sweep GC执行效率更高，但是存在内存碎片问题；而Compacting GC执行效率较低，但是不存在内存碎片问题。ART运行时通过引入Foreground GC和Background GC的概念来对这两种GC进行扬长避短。本文就详细分析它们的执行过程以及切换过程。
老罗的新浪微博：，欢迎关注！
在前面ART运行时Compacting GC简要介绍和学习计划和ART运行时Compacting GC堆创建过程分析这两篇文章中，我们都有提到了ART运行时的Foreground GC和Background GC。它们是在ART运行时启动通过-Xgc和-XX:BackgroundGC指定的。但是在某同一段时间，ART运行时只会执行Foreground GC或者Background GC。也就是说，Foreground GC和Background GC在整个应用程序的生命周期中是交替执行的。这就涉及到从Foreground GC切换到Background GC，或者从Background GC切换到Foreground GC的问题。
现在两个问题就来了：什么时候执行Foreground GC，什么时候执行Background GC？什么GC作为Foreground GC最合适，什么GC作为Background GC最合适？
顾名思义，Foreground指的就是应用程序在前台运行时，而Background就是应用程序在后台运行时。因此，Foreground GC就是应用程序在前台运行时执行的GC，而Background就是应用程序在后台运行时执行的GC。
应用程序在前台运行时，响应性是最重要的，因此也要求执行的GC是高效的。相反，应用程序在后台运行时，响应性不是最重要的，这时候就适合用来解决堆的内存碎片问题。因此，Mark-Sweep GC适合作为Foreground GC，而Compacting GC适合作为Background GC。
但是，ART运行时又是怎么知道应用程序目前是运行在前台还是后台呢？这就需要负责管理应用程序组件的系统服务ActivityManagerService闪亮登场了。因为ActivityManagerService清楚地知识应用程序的每一个组件的运行状态，也就是它们当前是在前台运行还是后台运行，从而得到应用程序是前台运行还是后台运行的结论。
我们通过图1来描述应用程序的运行状态与Foreground GC和Background GC的时序关系，如下所示：
图1 应用程序运行状态与Foreground GC和Background GC的时序关系
从图1还可以看到，当从Foreground GC切换到Background GC，或者从Background GC切换到Foreground GC，会发生一次Compacting GC的行为。这是由于Foreground GC和Background GC的底层堆空间结构是一样的，因此发生Foreground GC和Background GC切换时，需要将当前存活的对象从一个Space转移到另外一个Space上去。这个刚好就是Semi-Space GC和Generational Semi-Space GC合适干的事情。
图1中的显示了应用程序的两个状态：kProcessStateJankPerceptible和kProcessStateJankImperceptible。其中，kProcessStateJankPerceptible说的就是应用程序处于用户可感知的状态，这就相当于是前台状态；而kProcessStateJankImperceptible说的就是应用程序处于用户不可感知的状态，这就相当于是后台状态。
接下来，我们就结合ActivityManagerService来分析Foreground GC和Background GC的切换过程。
从前面Android应用程序的Activity启动过程简要介绍和学习计划这个系列的文章可以知道，应用程序组件是通过ActivityManagerService进行启动的。例如，当我们从Launcher启动一个应用程序时，实际的是在这个应用程序中Action和Category分别被配置为MAIN和LAUNCHER的Activity。这个Activity最终由ActivityManagerService通知其所在的进程进行启动工作的，也就是通过ApplicationThread类的成员函数scheduleLaunchActivity开始执行启动工作的。其它类型的组件的启动过程也是类似的，这里我们仅以Activity的启动过程作为示例，来说明ART运行时如何知道要进行Foreground GC和Background GC切换的。
ApplicationThread类的成员函数scheduleLaunchActivity的实现如下所示：
public final class ActivityThread {……private class ApplicationThread extends ApplicationThreadNative {……public final void scheduleLaunchActivity(Intent intent, IBinder token, int ident,ActivityInfo info, Configuration curConfig, CompatibilityInfo compatInfo,IVoiceInteractor voiceInteractor, int procState, Bundle state,PersistableBundle persistentState, List<ResultInfo> pendingResults,List<Intent> pendingNewIntents, boolean notResumed, boolean isForward,ProfilerInfo profilerInfo) {updateProcessState(procState, false);ActivityClientRecord r = new ActivityClientRecord();r.token = token;r.ident = ident;r.intent = intent;r.voiceInteractor = voiceInteractor;r.activityInfo = info;r.compatInfo = compatInfo;r.state = state;r.persistentState = persistentState;r.pendingResults = pendingResults;r.pendingIntents = pendingNewIntents;r.startsNotResumed = notResumed;r.isForward = isForward;r.profilerInfo = profilerInfo;updatePendingConfiguration(curConfig);sendMessage(H.LAUNCH_ACTIVITY, r);}……}……} 这个函数定义在文件frameworks/base/core/java/android/app/ActivityThread.java中。
ApplicationThread类的成员函数scheduleLaunchActivity首先是调用另外一个成员函数updateProcessState更新进程的当前状态，接着再将其余参数封装在一个ActivityClientRecord对象中，并且将这个ActivityClientRecord对象通过一个H.LAUNCH_ACTIVITY消息传递给应用程序主线程处理。应用程序主线程处理对这个消息的处理就是启动指定的Activity，这个过程可以参考前面Android应用程序的Activity启动过程简要介绍和学习计划这个系列的文章。ApplicationThread类的成员函数scheduleLaunchActivity还调用了另外一个成员函数updatePendingConfiguration将参数cureConfig描述的系统当前配置信息保存下来待后面处理。
你并不一定会从此拥有更美好的人生，
