本文主要讲述了App的启动流程、Application的生命周期以及进程的回收机制。

在绝大多数情况下，每一个Android应用都在自己的Linux进程中运行。当需要运行某些代码时，进程就会被创建。进程将保持运行直到不再需要，当其他应用有需要的时候，系统会释放该进程的内存。

一个不常见但很基础的Android特性是，一个应用进程的生命周期并不是由应用本身直接控制的。它是由系统根据正在运行的程序，对用户的重要程度以及所占用的内存，综合去管理的。

1. App启动流程

此处讨论的是第一次启动App。在讲解App启动流程的时候，有两点需要知晓：

1. 每一个App都运行在一个独立空间里，也可以称之为沙盒，这意味着它是在独立的线程中，拥有自己的虚拟机实例，被分配一个唯一的用户ID。
2. App由很多不同组建组成，这些组件还可以调用其他App的组建，并没有一个单独的类似于main函数的入口。

总体来说，App启动分为三个步骤，创建进程、绑定Application以及启动Activity。当用户点击Android桌面一个App图标，启动一个应用的时候，整个流程如下所示：

点击事件通过Binder IPC机制最终被转换成startActivity(intent)，而App相关信息的解析以及处理则在安装的时候就已经完毕。当startActivity的时候，ActivityManagerService（AMS）的操作如下：

• 第一步是intent解析。通过PackageManager的resolveIntent()方法，收集目标intent对象的信息。
• 第二步是权限检查。通过grantUriPermissionLocked()方法，检查用户是否有足够的权限去调用intent的目标组件。
• 第三步是创建新的任务。如果用户有足够的权限，ActivityManagerService就会检查目标Activity是否需要被加载在新的任务中。这个任务是根据Intent Flag来进行创建的。

最后检测进程记录表（ProgressRecord）是否存在。如果不存在，则需要通过ActivityManagerService来创建新的进程。

1.1 进程创建

ActivityManagerService通过调用startProcessLocked()方法来创建一个新的进程，这个方法会通过socket连接发送参数到Zygote进程。Zygote创建ActivityThread对象并返回新创建进程的pid。ActivityThread通过依次调用Looper.prepareLoop()和Looper.loop()方法开启消息循环。

1.2 绑定Application

当进程创建完毕后，需要将其与Application绑定起来。ActivityThread通过发送BIND_APPLICATION消息执行绑定，会执行makeApplication()方法将App的类加载进内存。

1.3 启动Activity

经过前面两步，系统拥有了与application相关联的进程，应用中相关的类被加载到进程的内存区域。在新创建或者已经存在的进程中启动Activity的步骤是一样的。ActivityThread通过发送LAUNCH_ACTIVITY消息进行启动操作。

大致梳理一下上面的过程，当用户点击应用图标的时候，系统会去检测进程是否存在，如果不存在，则通过Zygote创建进程，创建完进程后，则需要将进程与App进行绑定，将App的资源加载到内存中，当加载完毕，各种条件准备就绪，接下来就是启动Activity了，如此，App的界面就展示出来了。

2. Application生命周期

此处讨论的是Application类，而非应用生命周期。Application的作用，用官方文档的话说。

Base class for maintaining global application state.

它的作用是维护全局的应用状态的基类。Application类是应用中最先被初始化的类，先于Activity等组件。它的生命周期与Activity有几分相似，都经历了创建销毁过程，只不过它是一个线性的过程，不存在一些恢复过程。

2.1 onCreate

Called when the application is starting, before any activity, service, or receiver objects (excluding content providers) have been created.

当应用启动的时候调用，除了content providers之外，早于其他任何组件的创建。

2.2 onLowMemory

This is called when the overall system is running low on memory, and actively running processes should trim their memory usage.

当整个系统内存不足的时候，活跃的进程需要减少它们的内存使用的时候，回调会被调用。系统调用此回调过后，会产生一次GC操作。

2.3 onTerminate

This method is for use in emulated process environments.It will never be called on a production Android device, where processes are removed by simply killing them; no user code (including this callback) is executed when doing so.

在正式环境的真实设备上，不会被调用。由于系统结束进程采用的是kill的方法，因此不会产生相关的回调。

2.4 onTrimMemory

Called when the operating system has determined that it is a good time for a process to trim unneeded memory from its process.

当系统检测到应用可以回收不需要的内存时，会产生此回调。例如应用处于后台，系统内存不足的时候。

3. 回收机制

当系统出现低内存状况的时候，会根据不同进程的优先级进行内存回收。系统根据进程的状态，将进程分为四个等级。

3.1 Foreground Process

前台进程是优先级最高的进程，用户当前操作交互的必须是前台进程。当一个进程包含以下条件的时候，可以认为是前台进程。

1. 用户正在交互的，处在屏幕最上层的Activity（onResume被调用过后）。
2. 包含一个正在运行的BroadcastReceiver（onReceive正在执行）。
3. 包含一个正在运行它的回调（onCreate、onStart、onDestroy）的service。

在一般状况下，杀死前台进程需要用户交互。当被系统杀死的时候，说明此时系统连该进程所需要的内存都无法满足，是最后才被杀死的。

3.2 Visible Process

可见进程是当前用户关心但是杀掉它会显著的影响用户体验的进程。当包含如下情况时，该进程可以被当做可见进程。

1. 包含一个对用户可见但不在前台（onPause被调用过后）的Activity。
2. 包含一个