Android内存优化1 了解Android是如何管理App内存

1, Dalvik & ART

Android在4.4之前一直使用的Dalvik虚拟机作为App的运行VM的, 4.4中引入了ART作为开发者备选, 5.0起正式将ART作为默认VM了.

我们首先来简单了解下二者:

1.1 Dalvik

如果只是想简单了解, 个人觉得百度百科上这个Dalvik的介绍基本就满足要求了.

如果大家想深入, 可以看下老罗的Android之旅中Dalvik的相关博文, 从代码层面上分析了Dalvik的启动, 运行机制等. 值得一看.

需要说明的是, Dalvik采用的是JIT技术, 在应用程序启动时, JIT通过进行连续的性能分析来优化程序代码的执行, 在程序运行的过程中, Dalvik在不断的进行将字节码编译成机器码的工作.

1.2 ART

ART 取自 Android RunTime. Android用其取代Dalvik, 主要目的就是为了提升运行性能. 所以, ART相比Dalvik有几个关键的提升:

引入AOT(ahead-of-time)预编译技术

在安装apk的过程中, ART会使用dex2oat程序所有的字节码预编译成了机器码. 应用程序运行过程中无需进行实时的编译工作, 只需要进行直接调用. 故而提高了应用程序的运行效率.

GC效率

• 由原来的两次GC暂停减少为一次.
• 以较少的GC时间回收最近分配的, 短命的对象.
• 提升GC工程学, 使并发GC更及时.
• 压缩GC, 以减少后台内存使用和内存碎片.

开发和调试

• 支持内存/方法执行的采样分析.
• 支持更多的调试技.
• 在Crash report中提供更多信息.

2, Android的内存管理方式

ART和Dalvik都是使用paging和memory-mapping(mmapping)来管理内存的. 这就意味着, 任何被分配的内存都会持续存在, 唯一的释放这块内存的方式就是释放对象引用(让对象GC Root不可达), 故而让GC程序来回收内存.

2.1 App的内存分配和回收

对于每个App进程来说, Heap内存被限制在一个虚拟的内存区间内. 且定义了逻辑上的使用的Heap Size, 这个Heap Size在系统限制的最大值之内是随着应用的使用情况而变化的.

Heap内存的逻辑大小和实际物理内存的大小是不相同的. 后面我们在使用Memory Monitor等内存分析工具分析内存时, 会看到一个叫做Proportional Set Size (PSS)的值, 这个值才是系统认为的你的App所占用的物理内存大小.

这个PSS值也就是实际物理内存大小, 统计包括了你的应用进程所占用的内存大小, 和共享内存中占用的内存大小(比例分配方式计算).

Android VM不会压缩Heap内存的逻辑大小, 故而无法通过碎片整理的方式来释放Heap空间, 而只能通过回收Heap尾部的空内存块来压缩逻辑内存大小.

这时, 我们的GC就出场了, GC之后, VM会遍历Heap找到不被使用的pages, 通过madvise函数将其返回给内核, 从而释放这块被逻辑Heap使用的物理内存.

2.2 App内存限制

Android是一个多任务系统, 为了保证多任务的运行, Android给每个App可使用的Heap大小设定了一个限定值.

这个值是系统设置的prop值, 系统编译时内置的, 保存在system/build.prop中. 一般国内的手机厂商都会做修改, 根据手机配置不同而不同, 可以通过如下命令查看:

$ adb shell
shell@hwH60:/ $ cat /system/build.prop

以手头的Huawei 荣耀6为例, heap size相关的prop如下:

dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=192m
dalvik.vm.heapsize=512m
dalvik.vm.heaptargetutilization=0.75
dalvik.vm.heapminfree=2m
dalvik.vm.heapmaxfree=8m

其中:

dalvik.vm.heapstartsize

-- App启动后, 系统分配给它的Heap初始大小. 随着App使用可增加.

dalvik.vm.heapgrowthlimit

-- 默认情况下, App可使用的Heap的最大值, 超过这个值就会产生OOM.

dalvik.vm.heapsize

-- 如果App的manifest文件中配置了largeHeap属性, 如下.则App可使用的Heap的最大值为此项设定值.

<application
    android:largeHeap="true">
    ...
</application>

dalvik.vm.heaptargetutilization

-- 当前理想的堆内存利用率. GC后, Dalvik的Heap内存会进行相应的调整, 调整到当前存活的对象的大小和 / Heap大小 接近这个选项的值, 即这里的0.75. 注意, 这只是一个参考值.

dalvik.vm.heapminfree

-- 单次Heap内存调整的最小值.

dalvik.vm.heapmaxfree

-- 单次Heap内存调整的最大值.

也可以直接使用getprop查看单项prop:

$ adb shell getprop dalvik.vm.heapsize
512m

2.3 切换App时的内存管理机制

Android的进程级别

Android 系统会尽可能长时间地保持应用进程, 但为了新建进程或运行更重要的进程, 最终需要清除旧进程来回收内存. 为了确定保留或终止哪些进程, 系统会根据进程中正在运行的组件以及这些组件的状态, 将每个进程设定了一个重要级别. 必要时, 系统会首先消除重要性最低的进程, 然后是重要性略低的进程, 依此类推, 以回收系统资源.

依据重要程度从大到小依次分为5级:

前台进程

用户当前操作所必需的进程. 如果一个进程满足以下任一条件, 即视为前台进程：

• 托管用户正在交互的 Activity（已调用 Activity 的 onResume() 方法）
• 托管某个 Service，后者绑定到用户正在交互的 Activity
• 托管正在“前台”运行的 Service（服务已调用 startForeground()）
• 托管正执行一个生命周期回调的 * Service（onCreate()、onStart() 或 onDestroy()）
• 托管正执行其 onReceive() 方法的 BroadcastReceiver

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

可见进程

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

• 托管不在前台、但仍对用户可见的 Activity（已调用其 onPause() 方法）。例如，如果前台 Activity 启动了一个对话框，允许在其后显示上一 Activity，则有可能会发生这种情况
• 托管绑定到可见（或前台）Activity 的 Service
  可见进程被视为是极其重要的进程，除非为了维持所有前台进程同时运行而必须终止，否则系统不会终止这些进程。

服务进程

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

后台进程

包含目前对用户不可见的 Activity 的进程（已调用 Activity 的 onStop() 方法）。这些进程对用户体验没有直接影响，系统可能随时终止它们，以回收内存供前台进程、可见进程或服务进程使用。 通常会有很多后台进程在运行，因此它们会保存在 LRU （最近最少使用）列表中，以确保包含用户最近查看的 Activity 的进程最后一个被终止。如果某个 Activity 正确实现了生命周期方法，并保存了其当前状态，则终止其进程不会对用户体验产生明显影响，因为当用户导航回该 Activity 时，Activity 会恢复其所有可见状态。

空进程

不含任何活动应用组件的进程。保留这种进程的的唯一目的是用作缓存，以缩短下次在其中运行组件所需的启动时间。 为使总体系统资源在进程缓存和底层内核缓存之间保持平衡，系统往往会终止这些进程。

切换App的内存管理

当用户切换App时, 被切换到后台的App所使用的内存并未因此删除, 该App进程被缓存到一个LRU缓存中, 以便用户切换回来时, 能更快的启动App, 让多任务更流畅.

但是, 当系统内存不够用的时候, 就会根据LRU特性, 以及上面说到的进程级别(同时也会考虑该App进程占用的内存大小)来决定杀死哪些进程, 来回收内存, 以便执行当前任务.

所以, 如果我们为了不要让系统kill掉我们的App, 可以从进程级别, 内存消耗量等几个方面进行优化.

结语

本文加上GC那些事儿, 我们讲了两篇的理论知识, 相信大家对Android的内存管理有了个大体的了解, 后面将介绍一些内存分析工具以及使用, 结合实际来说明怎么分析内存问题.