Android运行时和Dalvik虚拟机使用分页和内存映射两种方式来管理内存。这些意味着App对内存的任何修改-不论是分配新的对象或者引用了映射页，都意味着这部分内存会一直存在于RAM中，而且不会被移出分页。从App中释放内存的唯一方法就是释放App引用的对象引用，让这些内存能够被垃圾回收器回收。只有在一种情况下例外，被映射的文件没有发生任何修改，例如代码等，当系统想在其他地方使用中的时候，这部分的内存可以被以分页的方式移出内存。
这篇文章主要解释了Android是如何管理App的进程和内存分配的。更多的信息可以参见管理App的内存.
垃圾回收
一个托管式的内存环境，例如ART(Android Runtime)或者Dalvik虚拟机，会记录下任何内存的分配。一旦发现程序不需要使用某块内存，就会将内存放回堆中，这个过程不需要程序员的介入。这个在托管环境下回收不再使用的内存机制被成为垃圾回收。垃圾回收主要有两个目的：找到程序不需要再使用的数据对象；并且回收掉这些对象使用的资源。
Android的内存堆是分代式的，意味着它会基于对象的周期和大小使用不同的分配桶来记录。例如，最近分配的对象会处在“更年轻”的代中。当某个对象存在的周期足够长时，它就会被放在更老的代中，仅次于永久的代。
不同代堆中对象占据的内存上限是不一样的。只有某一个代的内存快满的时候，系统就会执行垃圾回收事件来尝试释放内存。垃圾回收的时间取决于回收的代以及每个代中活跃的对象。
尽管垃圾回收非常快，它也会影响App的性能。通常情况下，你不需要代码来控制何时发生垃圾回收事件。系统具有一组运行中的标准，用于确定何时执行垃圾回收。当满足条件时，系统停止当前进程，开始垃圾回收。如果垃圾回收发生在性能密集处，例如动画播放或者音乐回放，就可能增加处理的整个时间。增加的时间可能会让你应用中的代码执行超过保证高效和平滑帧渲染的16 ms的阈值。
此外，您的代码流可能执行各种工作，这些工作会迫使垃圾回收事件发生得更频繁，或者使它们发生的时间比正常情况长。例如，如果在alpha混合动画的每一帧中，在for循环的最内部分配多个对象，这样就会用分配很多对象污染了内存堆。在这种情况下，垃圾收集器会执行多次垃圾回收事件，并可能降低App的性能。
有关垃圾收集的更多常规信息，请参阅垃圾收集。
共享内存
为了将所需的所有内容都放入RAM，Android尝试跨进程共享RAM内存页。它可以通过以下方式进行操作：
- 每个App进程都来自一个称为Zygote的现有进程。当系统启动并加载通用框架代码和资源（例如活动主题）时，Zygote进程便开始启动。当开始新的App进程，系统会派生Zygote进程，然后再新进程中加载并运行App的代码。这种方法允许分配给框架代码和资源的大多数RAM页面在所有应用进程之间共享。
- 大多数的静态数据被映射到一个进程中，此技术允许在进程之间共享数据，并允许在需要的时候可以将它们分页置换出去。静态数据示例包括：Dalvik代码（通过将其放置在预链接的.odex文件中用来直接映射），App资源（通过将资源表设计成可以进行映射的结果并对齐APK的zip入口）,以及传统的工程元素如
.so文件中的原生代码。 - 在很多情况下，Android会使用显式分配的共享内存区域（使用ashmem或gralloc）在进程间共享相同的动态RAM。例如，窗口Surface在App和屏幕合成器之间共享内存，而光标缓冲区在内容提供者和客户端之间使用共享内存。
由于共享内存的广泛使用，确定您的App使用的内存量非常重要。正确确定你的App内存使用量的技术可以参见调查您的RAM使用。
分配和回收App内存
对于每个App进程，Dalvik堆都被限制在单个虚拟内存内。这样定义了逻辑堆大小，该大小可以根据需要增加，但是不能超过系统定义的限制。
堆使用的逻辑大小与堆使用的物理内存量不同。在检查App的堆时，Android计算一个称为“比例集大小”（PSS）的值，该值说明了与其他进程共享的脏页和干净页，但其数量与共享该RAM的App的数量成正比。该（PSS）总数就是系统认为是您的物理内存占用量。有关PSS的更多信息，请参阅调查您的RAM使用指南。
Dalvik堆不会压缩堆的逻辑大小，这意味着Android不会对堆进行碎片整理来释放空间。仅当堆末尾有未使用的空间时，Android才能缩小逻辑堆大小。但是，系统仍然可以减少堆使用的物理内存。在垃圾回收后，Dalvik遍历堆并找到未使用的内存页，然后使用madvise将这些页面返回到内核。因此，大块的成对分配和解除分配应该导致回收所有（或几乎所有）使用的物理内存。但是，从小内存分配中回收内存的效率可能会低得多，因为用于小分配的页面仍会与尚未释放的其他内容共享。
限制App内存
为了维持功能正常的多任务环境，Android对每个App的堆大小设置了硬件限制。确切的堆大小限制在设备之间会有所不同，具体取决于设备总体上有多少可用的RAM。如果您的App已经达到堆限制并且尝试分配更多的内存，它就会收到OutofMemoryError。
在某些情况下，您可能想查询系统来确定在当前的设备上有多少可用的堆空间-例如，你想要确定在缓存中可以安全存储多少数据。你可以调用getMemoryClass()来获取。这个方法返回一个整数，指示可用于您的App堆的兆字节数。
切换App
当用户在App之间切换时，Android会将不处于前台状态的App(对用户不可见，或者运行诸如音乐播放的前台服务)保留在LRU（Least Recently Used）缓存中。例如，当用户首次启动App时，会为其创建一个进程；但是当用户离开App时，该进程不会退出。系统会缓存当前进程。如果用户返回到App时，系统会重用这个进程，让App切换的速度更快。
如果您的App有缓存的进程并且保存了当前不需要使用的内存-即使用户没有在使用这个App-也会影响整个系统的性能。当系统内存不足的时候，它将终止LRU缓存中的进程，从最近最少使用的进程开始。系统还会考虑占用最多内存的进程，并可以终止这些进程来释放RAM。
当系统开始终止LRU缓存中的进程时，它主要是从下而上进行。系统会考虑到那些进程消耗更多的内存，从而在杀掉这些进程的时候获得更多的内存释放空间。总的来讲，您在LRU中消耗的内存越少，则保留在列表中并且能够快速恢复的机会也就越大。
有关如何在不运行前台的情况下如何缓存进程以及Android如何确定哪些进程可以被杀掉的更多信息，可以参阅进程与线程指南。
