Android对内存的使用方式同样是“尽最大限度的使用”，这一点继承了Linux的优点。只不过有所不同的是，Linux侧重于尽可能多的缓存磁盘数据以降低磁盘IO进而提高系统的数据访问性能，而 Android侧重于尽可能多的缓存进程以提高应用启动和切换速度。Linux系统在进程活动停止后就结束该进程，而Android系统则会在内存中尽量长时间的保持应用进程，直到系统需要更多内存为止 。这些保留在内存中的进程，通常情况下不会影响系统整体运行速度，反而会在用户再次激活这些进程时，加快进程的启动速度，因为不用重新加载界面资源了，这是Android标榜的特性之一。所以，Android现在不推荐显式的“退出”应用。

那为什么内存少的时候运行大型程序会慢呢，原因是：在内存剩余不多时打开大型程序会触发系统自身的进程调度策略，这是十分消耗系统资源的操作，特别是在一个程序频繁向系统申请内存的时候。这种情况下系统并不会关闭所有打开的进程，而是选择性关闭，频繁的调度自然会拖慢系统。 

Android中的进程管理

说到Android的内存管理，就不得不提到进程管理，因为进程管理确确切切的影响着系统内存。在了解进程管理之前，我们首先了解一些基础概念。

当某个应用组件启动且该应用没有运行其他任何组件时，Android 系统会使用单个执行线程为应用启动新的 Linux 进程。默认情况下，同一应用的所有组件在相同的进程和线程（称为“主”线程） 中运行。如果某个应用组件启动且该应用已存在进程（因为存在该应用的其他组件），则该组件会在此进程内启动并使用相同的执行线程。但是，你也可以安排应用中的其他组件在单独的进程中运行，并为任何进程创建额外的线程。

Android应用模型的设计思想取自Web 2.0的Mashup概念，是 基于组件的应用设计模式。在该模型下，每个应用都由一系列的组件搭建而成，组件通过应用的配置文件描述功能。Android系统依照组件的配置信息，了解各个组件的功能并进行统一调度。这就意味着，来自不同应用的组件可以有机地结合在一起，共同完成任务，各个Android应用，只有明确的组件边界，而不再有明确的进程边界和应用边界。这种设计，也令得开发者无需耗费精力去重新开发一些附属功能，而是可以全身心地投入到核心功能的开发中。这样不但提高了应用开发的效率，也增强了用户体验（比如电子邮件中选择图片作为附件的功能，可以直接调用专门的图片应用的功能，不用自己从头开发）。

系统不会为每个组件实例创建单独的线程。运行于同一进程的所有组件均在 UI 线程中实例化，并且对每个组件的系统调用均由该线程进行分派。 因此，响应系统回调的方法（例如，报告用户操作的 onKeyDown() 或生命周期回调方法）始终在进程的 UI 线程中运行（四大组件的各个生命周期回调方法都是在UI线程中触发的）。 

进程的生命周期

Android的一个不寻常的基本特征是应用程序进程的生命周期并非是由应用本身直接控制的。相反，进程的生命周期是由系统决定的，系统会权衡每个进程对用户的相对重要程度，以及系统的可用内存总量来确定。 比如说相对于终止一个托管了正在与用户交互的Activity的进程，系统更可能终止一个托管了屏幕上不再可见的Activity的进程，否则这种后果是可怕的。因此，是否终止某个进程取决于该进程中所运行组件的状态 。Android会有限清理那些已经不再使用的进程，以保证最小的副作用。

作为应用开发者，了解各个应用组件（特别是Activity、Service和BroadcastReceiver）如何影响应用进程的生命周期非常重要。不正确的使用这些组件，有可能导致系统在应用执行重要工作时终止进程。

举个常见的例子， BroadcastReceiver 在其 onReceive() 方法中接收到Intent时启动一个线程，然后从该函数返回。而一旦返回，系统就认为该 BroadcastReceiver 不再处于活动状态，因此也就不再需要其托管进程（除非该进程中还有其他组件处于活动状态）。这样一来，系统就有可能随时终止进程以回收内存，而这也最终会导致运行在进程中的线程被终止。此问题的解决方案通常是从 BroadcastReceiver 中安排一个 JobService ，以便系统知道在该进程中仍有活动的工作。

为了确定在内存不足时终止哪些进程，Android会根据进程中正在运行的组件以及这些组件的状态，将每个进程放入 “重要性层次结构” 中。必要时，系统会首先杀死重要性最低的进程，以此类推，以回收系统资源。这就相当于为进程分配了优先级的概念。 

进程优先级

Foreground Process：前台进程（正常不会被杀死）

用户当前操作所必需的进程。有很多组件能以不同的方式使得其所在进程被判定为前台进程。如果一个进程满足以下任一条件，即视为前台进程：

• 托管用户正在交互的 Activity（已调用 Activity 的 onResume() 方法）

• 托管某个 Service，后者绑定到用户正在交互的 Activity

• 托管正执行一个生命周期回调的 Service（onCreate()、onStart() 或 onDestroy()）

• 托管正执行其 onReceive() 方法的 BroadcastReceiver

通常，在任意给定时间前台进程都为数不多。只有在内存不足以支持它们同时继续运行这一万不得已的情况下，系统才会终止它们。此时，设备往往已达到内存分页状态，因此需要终止一些前台进程来确保用户界面正常响应。

Visible Process：可见进程（正常不会被杀死

没有任何前台组件、但仍会影响用户在屏幕上所见内容的进程。杀死这类进程也会明显影响用户体验。如果一个进程满足以下任一条件，即视为可见进程：

• 托管不在前台、但仍对用户可见的 Activity（已调用其 onPause() 方法）。例如，启动了一个对话框样式的前台 activity ，此时在其后面仍然可以看到前一个Activity。

运行时权限对话框就属于此类。考虑一下，还有哪种情况会导致只触发onPause而不触发onStop?

• 托管通过 Service.startForeground() 启动的前台Service。

Service.startForeground()：它要求系统将它视为用户可察觉到的服务，或者基本上对用户是可见的。

• 托管系统用于某个用户可察觉的特定功能的Service，比如动态壁纸、输入法服务等等。

可见进程被视为是极其重要的进程，除非为了维持所有前台进程同时运行而必须终止，否则系统不会终止这些进程。如果这类进程被杀死，从用户的角度看，这意味着当前 activity 背后的可见 activity 会被黑屏代替。

Service Process：服务进程（正常不会被杀死）

正在运行已使用 startService() 方法启动的服务且不属于上述两个更高类别进程的进程。尽管服务进程与用户所见内容没有直接关联，但是它们通常在执行一些用户关心的操作（例如，后台网络上传或下载数据）。因此，除非内存不足以维持所有前台进程和可见进程同时运行，否则系统会让服务进程保持运行状态。

已经运行很久（例如30分钟或更久）的Service，有可能被降级，这样一来它们所在的进程就可以被放入Cached LRU列表中。这有助于避免一些长时间运行的Service由于内存泄漏或其他问题而消耗过多的RAM，进而导致系统无法有效使用缓存进程的情况。

Background / Cached Process：后台进程（可能随时被杀死）

这类进程一般会持有一个或多个目前对用户不可见的 Activity （已调用 Activity 的 onStop() 方法）。它们不是当前所必须的，因此当其他更高优先级的进程需要内存时，系统可能 随时终止 它们以回收内存。但如果正确实现了Activity的生命周期，即便系统终止了进程，当用户再次返回应用时也不会影响用户体验：关联Activity在新的进程中被重新创建时可以恢复之前保存的状态。

在一个正常运行的系统中，缓存进程是内存管理中 唯一 涉及到的进程：一个运行良好的系统将始终具有多个缓存进程（为了更高效的切换应用），并根据需要定期终止最旧的进程。只有在非常严重（并且不可取）的情况下，系统才会到达这样一个点，此时所有的缓存进程都已被终止，并且必须开始终止服务进程。

Android系统回收后台进程的参考条件：

• LRU算法：自下而上开始终止，先回收最老的进程。越老的进程近期内被用户再次使用的几率越低。杀死的进程越老，对用户体验的影响就越小。

• 回收收益：系统总是倾向于杀死一个能回收更多内存的进程，因为在它被杀时会为系统提供更多内存增益，从而可以杀死更少的进程。杀死的进程越少，对用户体验的影响就越小。换句话说，应用进程在整个LRU列表中消耗的内存越少，保留在列表中并且能够快速恢复的机会就越大。

这类进程会被保存在一个伪LRU列表中，系统会优先杀死处于列表尾部（最老）的进程，以确保包含用户最近查看的 Activity 的进程最后一个被终止。这个LRU列表排序的确切策略是平台的实现细节，但通常情况下，相对于其他类型的进程，系统会优先尝试保留更有用的进程（比如托管用户主应用程序的进程，或者托管用户看到的最后一个Activity的进程，等等）。还有其他一些用于终止进程的策略：对允许的进程数量硬限制，对进程可以持续缓存的时间量的硬限制，等等。

在一个健康的系统中，只有缓存进程或者空进程会被系统随时终止，如果服务进程，或者更高优先级的可见进程以及前台进程也开始被系统终止（不包括应用本身糟糕的内存使用导致OOM），那就说明系统运行已经处于一个亚健康甚至极不健康的状态，可用内存已经吃紧。

Empty Process：空进程（可以随时杀死）

不含任何活跃组件的进程。保留这种进程的的唯一目的是用作缓存（为了更加有效的使用内存而不是完全释放掉），以缩短下次启动应用程序所需的时间，因为启动一个新的进程也是需要代价的。只要有需要，Android会随时杀死这些进程。

内存管理中对于前台/后台应用的定义，与用于Service限制目的的后台应用定义不同。从Android 8.0开始，出于节省系统资源、优化用户体验、提高电池续航能力的考量，系统进行了前台/后台应用的区分，对于后台service进行了一些限制。在该定义中，如果满足以下任意条件，应用将被视为处于前台：

>

• 具有可见 Activity（不管该 Activity 已启动还是已暂停）。

• 具有前台 Service。

• 另一个前台应用已关联到该应用（不管是通过绑定到其中一个 Service，还是通过使用其中一个内容提供程序）。例如，如果另一个应用绑定到该应用的 Service，那么该应用处于前台：IME 壁纸 Service 通知侦听器 语音或文本 Service 如果以上条件均不满足，应用将被视为处于后台。 

Android系统如何评定进程的优先级

根据进程中当前活动组件的重要程度，Android 会将进程评定为它可能达到的最高级别。 例如，如果某进程同时托管着 Service 和可见 Activity，则会将此进程评定为可见进程，而不是服务进程。

此外，一个进程的级别可能会因其他进程对它的依赖而有所提高，即服务于另一进程的进程其级别永远不会低于其所服务的进程。 例如，如果进程 A 中的内容提供程序为进程 B 中的客户端提供服务，或者如果进程 A 中的服务绑定到进程 B 中的组件，则进程 A 始终被视为至少与进程 B 同样重要。

由于运行服务的进程其级别高于托管后台 Activity 的进程，因此，在 Activity 中启动一个长时间运行的操作时，最好为该操作启动服务，而不是简单地创建工作线程，当操作有可能比 Activity 更加持久时尤要如此。例如，一个文件上传的操作就可以考虑使用服务来完成，这样一来，即使用户退出 Activity，仍可在后台继续执行上传操作。使用服务可以保证，无论 Activity 发生什么情况，该操作至少具备“服务进程”优先级。同理， BroadcastReceiver 也应使用服务，而不是简单地将耗时冗长的操作放入线程中。 

Home键退出和返回键退出的区别

Home键退出，程序保留状态为后台进程；而返回键退出，程序保留状态为空进程，空进程更容易被系统回收。Home键其实主要用于进程间切换，返回键则是真正的退出程序。

从理论上来讲，无论是哪种情况，在没有任何后台工作线程（即便应用处于后台，工作线程仍然可以执行）的前提下，被置于后台的进程都只是保留他们的运行状态，并不会占用CPU资源，所以也不耗电。只有音乐播放软件之类的应用需要在后台运行Service，而Service是需要占用CPU时间的，此时才会耗电。所以说没有带后台服务的应用是不耗电也不占用CPU时间的，没必要关闭，这种设计本身就是Android的优势之一，可以让应用下次启动时更快。然而现实是，很多应用多多少少都会有一些后台工作线程，这可能是开发人员经验不足导致（比如线程未关闭或者循环发送的Handler消息未停止），也可能是为了需求而有意为之，导致整个Android应用的生态环境并不是一片干净。