官方视频翻译，如需转载，请注明作者：Yuloran (t.cn/EGU6c76)
演讲人介绍
Rechard Uhler，Android Runtime 开发工程师。为便于写作，笔者将以第一人称视角对视频内容进行概述。
视频地址
前言
想要进行内存优化，就必须对 Android 内存管理机制有比较深入的了解，这样才能保证应用在低端机上也能有良好的表现。不同的内存类型，包括 Shared Memory，Dex Memory 以及 GPU Memory， 都会对用户体验产生影响。
我在过去的三年时间里，都在致力于深入理解 Android 应用内存管理机制。那么，为什么 App 开发工程师也要关注内存占用呢？于我而言，主要是因为 Android 生态系统。如果一个 Android 应用在低端设备上用户体验不好（比如经常卡顿），那么 OEM(Original Entrusted Manufacture) 就不愿再生产这样的设备，进而导致这部分用户被排除在 Android 生态系统之外。
本次课题主要讨论三点内容：
-
低内存时 Android 系统的工作机制
-
如何评估应用内存使用情况
-
如何减少应用内存占用
低内存时 Android 系统的工作机制
首先，需要介绍物理内存的概念，然后引入 Android Low Memory Killer。
物理内存
设备的物理内存被分为很多页（Page），每页 4KB。不同的页用来做不同的事情：
橘黄色的是已使用页，黄色的是缓存页（数据在磁盘上有备份，所以 Cache Pages 是可以被回收的），绿色的是空闲页。
用于回收 Cached pages 的 kswapd 进程：
这是一个 2G 内存的手机，X 轴表示使用时间，Y 轴表示内存使用情况。随着打开的应用越来越多，Used Pages 也越来越多，而 Cached Pages 和 Free Pages 则越来越少。当 Free Pages 低于 kswapd 的阈值时，Linux 内核就会通过 kswapd 进程对 Cached Pages 进行回收。当应用再次访问 Cached Pages 上的内容时，就需要从磁盘上重新加载。如果 Cached Pages 太少的话，设备就可能死机：
所以，在 Android 上我们有个机制叫 Low Memory Killer，当 Cached Pages 太少时，就会被触发。它的工作方式是根据进程的优先级，选择性地杀死某个进程，释放该进程占用的所有资源以满足内存分配需要：
如上图所示，当 Cached Pages 低于 LMK 阈值时，将会触发低内存杀死机制。
LMK（Low Memory Killer）
如果 LMK 杀掉的是用户正在交互或可以感知的进程，将会导致非常不友好的用户体验。所以 Android SystemServer 进程维护了一张进程优先级列表，LMK 根据这张表来决定先杀死哪个进程：
- Perceptible 指的是非用户直接交互的进程，比如在后台播放音乐的音乐播放器进程；
- Previous 指的是切换至当前前台应用前的应用进程；
- Cached 指缓存的进程，这可能是退至后台的应用进程，也可能是已经退出的应用进程，目的是为了实现应用间的快速切换。所以，Cached 进程也是优先级最低的进程：
如上图所示，当已用内存超过 LMK 阈值时，LMK 将从 Cached 列表底部开始杀死进程。如果可用内存还是不满足分配需要，那么将会按照上表所示优先级自底向上杀死进程，直到准备 Kill SystemServer 进程，这将导致手机重启。
所以，你可以想象 LMK 在低内存手机上的情景：
如上图所示，LMK 将一直处于活跃状态，具体表现就是应用卡顿、桌面黑屏重启，手机死机等等。如此，OEM 将不愿生产这些设备。
评估应用内存使用情况
那么，我们怎么知道 App 使用了多少内存呢？
物理内存追踪
之前提到，设备的物理内存被分为很多页（Page），Linux Kernel 将会持续跟踪每个进程使用的 Pages，所以只要对进程使用的 Pages 进行计数即可：
但实际情况远比这要复杂的多，因为有些 Pages 是进程间共享的：
共享内存页计数方法：
（1）RSS（Resident Set Size）：App 完全负责：
（2）PSS（Proportional Set Size）：App 按比例负责，比如下图所示两个进程共享，那就负责一半。如果三个进程共享，那就负责三分之一：
（3）USS（Unique Set Size）：App 无责：
但实际上，至少需要系统级别的上下文才能知道识别 RSS 与 USS。所以通常都是使用 PSS 来计算，这也可以避免多计或者少计 Shared Pages。你可以使用：
adb shell dumpsys meminfo -s [process]
复制代码命令来查看一个进程的 PSS 使用情况：
最底部的 TOTAL 代表的就是应用按比例占用的总内存大小。
应用内存占用分析
如果想要应用支持的功能越多，UI 越炫酷，那就需要更多的内存分配。既想马儿跑，又想马儿不吃草的事情是不存在的：
内存占用影响因素：
（1）应用使用场景：很好理解，哪个页面比较炫、动效多、或者使用了 webview，那这个时候 App 占用的内存就高：
（2）平台配置：很好理解，比如手机的分辨率越高，相同 dp 的图片占用的内存就越大，所以高档手机上，App 的内存占用肯定比低档手机高：
（3）设备内存压力：设备内存越紧张，越可能触发 GC，导致 App 占用内存比设备内存充裕时低：
所以，你应当在相同的内存压力下评估你的 App 内存占用：
由于内存压力不好控制，所以建议评估前，先一键清理所有进程，然后再测试。
减少应用内存占用
使用 Android Studio 的 Memory Profiler，可以查看当前 Java 堆上分配了哪些对象、对象大小以及对象引用链和被引用链等很多信息。Live Allocation 中有 image heap、zygote heap、app heap 等可以选择，但是我建议你只关注 app heap。因为 image heap 和 zygote heap 是 App 启动时从系统继承过来的，对于这部分内存占用，我们基本上无能为力：
关于 Memory Profiler 的细节我不会讲太多，因为明天中午 12:30 Esteban 将会详细讲解 Profiler 的用法，毕竟这是他们团队开发的。所以，我强力推荐你们也参加一下明天的宣讲会。
Java Heap 以外的内存占用分析
上面提到，TOTAL 是 PSS，那么这张图中，除了 Java Heap，其它的是什么意思呢？对于这部分内存占用，我们又能做什么呢？
这就比较好玩了，因为这部分大多是由 Android 平台产生的，如果你真的想理解他们，那么你需要学习很多专业知识。比如 Framework 是如何实现 View 系统及 Resource 管理的，Native Code 是如何执行的，WebView 是如何工作的，Android Runtime 是如何执行你的代码的，HAL 如何管理你的 Graphics 以及 Linux 内核的虚拟内存管理方式等等。
顺便说一下，我生活在这儿，这个橘黄色的方块里（Android Runtime）：
Android 平台产生的内存占用诊断
那么，对于平台产生的内存占用，我们需要使用工具来诊断吗？首先，我们可以使用：
adb shell dumpsys meminfo -a [process]
复制代码来查看更详细的信息（以下数据为笔者自己开发的 App 的内存占用情况）：
Applications Memory Usage (in Kilobytes):
Uptime: 498024399 Realtime: 1230430304
** MEMINFO in pid 10898 [com.yuloran.wanandroid_java] **
Pss Pss Shared Private Shared Private SwapPss Heap Heap Heap
Total Clean Dirty Dirty Clean Clean Dirty Size Alloc Free
------ ------ ------ ------ ------ ------ ------ ------ ------ ------
Native Heap 35822 0 824 35764 32 24 8740 75776 38786 36989
Dalvik Heap 4001 0 304 3552 72 412 240 6847 3424 3423
Dalvik Other 5256 0 48 5256 0 0 0
Stack 120 0 4 120 0 0 0
Ashmem 130 0 4 128 4 0 0
Gfx dev 2596 0 0 2596 0 0 0
Other dev 16 0 104 0 0 16 0
.so mmap 23782 22188 1132 504 13320 22188 15
.jar mmap 68 0 8 68 0 0 0
.apk mmap 8029 24 0 7684 1872 24 0
.ttf mmap 223 20 0 0 956 20 0
.dex mmap 21974 19864 0 20 13080 19864 0
.oat mmap 377 64 0 0 3620 64 0
.art mmap 6547 404 868 5852 7584 404 24
Other mmap 408 0 12 8 644 376 0
EGL mtrack 24660 0 0 24660 0 0 0
GL mtrack 4524 0 0 4524 0 0 0
Unknown 2130 0 184 2124 0 0 0
TOTAL 140702 42564 3492 92860 41184 43392 39 82623 42210 40412
Dalvik Details
.Heap 3308 0 0 3308 0 0 0
.LOS 42 0 16 12 4 28 4
.LinearAlloc 4020 0 20 4020 0 0 0
.GC 384 0 16 384 0 0 0
.JITCache 596 0 0 596 0 0 0
.Zygote 583 0 288 164 68 384 0
.NonMoving 68 0 0 68 0 0 0
.IndirectRef 256 0 12 256 0 0 0
App Summary
Pss(KB)
------
Java Heap: 9808
Native Heap: 35764
Code: 50436
Stack: 120
Graphics: 31780
Private Other: 8344
System: 4450
TOTAL: 140702 TOTAL SWAP PSS: 39
Objects
Views: 207 ViewRootImpl: 1
AppContexts: 3 Activities: 1
Assets: 18 AssetManagers: 3
Local Binders: 24 Proxy Binders: 23
Parcel memory: 8 Parcel count: 34
Death Recipients: 3 OpenSSL Sockets: 0
WebViews: 0
SQL
MEMORY_USED: 345
PAGECACHE_OVERFLOW: 55 MALLOC_SIZE: 117
DATABASES
pgsz dbsz Lookaside(b) cache Dbname
4 20 41 17/38/5 /data/user/0/com.yuloran.wanandroid_java/databases/app_database.db
4 12 0/0/0 (attached) temp
4 20 40 3/19/4 /data/user/0/com.yuloran.wanandroid_java/databases/app_database.db (1)
复制代码- Private Dirty Memory 类似于之前说过的 Used Memory；
- Private Clean Memory 类似于 之前说过的 Cached Memory。
下面又介绍了几种工具，showmap、ahat、debug malloc等，略。。。因为他下面说到：
总的来说就是：可以，但没必要。因为这需要了解很多专业知识，而且很多数据是可见但不可控的。
内存优化建议
（1）优化 Java 堆上的对象：
很多内存虽然不在 Java 堆分配，但是其生命周期跟 Java 堆上分配的对象相绑定：
所以，优化 Java Heap 上的对象，也有助于其它类型内存的回收。
（2）减小 apk 体积：
因为很多在 apk 中占据磁盘空间的文件，在运行期也会占据内存空间：
因为 apk 占据的磁盘空间大小是固定的，所以压缩 apk 大小比降低内存占用更容易。更多 apk 大小优化方法请查看 Best Practices to Slim Down Your App Size。
结语
本期视频主要讲述了 Android 的 Low Memory Killer 机制、如何评估应用的内存使用情况以及如何减少应用内存占用，来源于 Google Android Runtime 开发工程师 Rechard Uhler 的经验总结，可以说很靠谱了。
就笔者自身的开发经验来看，内存泄露比较容易解决，只是有的泄露是由于第三方 SDK 或者 Framework 导致的，此时只能通过反射来修复。如果反射也修复不了，但是不存在持续泄露，即仅泄露一次，也可以不作处理，或者通过商务推动去解决。而减少内存占用则比较困难，毕竟要想 App 功能丰富，那势必会占用更多的内存。而且现在很多项目是多人团队开发，每个人可能只负责一小块，对整个应用的掌控能力不足，进行内存调休就更困难了。所以，内存调优工作需要丰富的编程经验及架构经验，除了 Java 以外，还需要对 Android 的很多 UI 控件有比较深入的理解，因为在 Android 平台上，内存占用大头永远是 UI，主要是 Bitmap。
内存优化，任重而道远。