内存经验分享

内存统计工具

/proc/meminfo

Buddy

Slub

Procrank

/proc/pid/smaps

Dumpsys meminfo

内存评估

内存泄漏

Lmk 水位调整

内存统计工具

/proc/meminfo

可以提供整体内存信息，各字段表示的意思如下：

字段

表示意思

MemTotal	系统可以使用的总内存
MemFree	buddy 里面所有 free 的 page 的数(不包括冷热页，目前也没有看见哪里统计有冷热页)
Buffers	块设备的缓存页(不属于某个具体文件的管理信息的缓存页)
Cached	属于具体某个文件的缓存页
SwapCached	swap cache 中的缓存页，其不包含在下面的 lru 中
Active	系统中正在使用中的且使用的较积极的页
Inactive	lru 系统中正在使用中的但是不太积极的页
Active(anon)	Active 的匿名页
Inactive(anon)	Inactive 的匿名页
Active(file)	Active 的文件缓存页
Inactive(file)	Inactive 的文件缓存页
Unevictable	隔离的，暂时不参与 active/Inactive 判断的匿名页和文件缓存页之和
SwapTotal	swap 分区总大小(对于 zram，是 zram 块设备的大小，而不是 zram 实际占用的大小)
SwapFree	swap 分区 free 空间(对于 zram，是 zram 块设备剩余空间)
Dirty	文件缓存中的脏页，如果这个地方很大，就要小心 IO 的配置或者 IO 有问题，比如之前有 Bug 将 dirty_ration 设置为 30%，就会出现这种情况
Writeback	文件缓存中正在写回的页
AnonPages	APP 所使用的匿名映射的 pages(没有被 swap 出去的部分)。基本就是 Active(anon)+ Inactive(anon)
Mapped	mapped 文件的部分，其应该是 cached 的一个子集
Slab	slab 占有的所有page. 如果user_debug 版本打开了slub 将显著的增大该项
SReclaimable	其中设置为 Reclaimable 的 slab 占用的部分
SUnreclaim	设置为 Unreclaim 的 slab 占用的部分
KernelStack	每个线程(无论用户线程还是内核线程)都有一个 8K（arm32）的内核空间线程栈
PageTables	用户进程的二级页表 pte 项(不包括内核进程的)，所以可以认为完全是用户态占用
VmallocTotal	内核 vmalloc 可以用的全部空间
VmallocUsed	已经使用了的空间(但不一定是 vmalloc 分配了物理内存的)
VmallocChunk	vmalloc 区域剩余的最大连续空间

Buddy

分别是各个Order 的块的个数。Buddy 之和就是proc/meminfo 中free 的大小。

Slub

root@XXXX:/ # cat /proc/slabinfo slabinfo - version: 2.1

# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables

<limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail> ext4_groupinfo_4k 61 156 104 39 1 : tunables 0 0 0 : slabdata

4 4 0

UDPLITEv6			0	0	768	21	4 : tunables		0		0	0 : slabdata
0 0	0
UDPv6			1	42	768	21	4 : tunables		0		0	0 : slabdata
2 2	0
...
kmalloc-4096		184		196	4096	4	4 : tunables	0		0		0 : slabdata
49 49	0
kmalloc-2048		95		136	2048	8	4 : tunables	0		0		0 : slabdata
17 17	0
kmalloc-1024		377		400	1024	16	4 : tunables	0		0		0 : slabdata
25 25	0
kmalloc-512		918		1072	512	16	2 : tunables	0		0		0 : slabdata
67 67	0
kmalloc-256		635		704	256	16	1 : tunables	0		0		0 : slabdata
44 44	0
kmalloc-192		4726		4893	192	21	1 : tunables	0		0		0 : slabdata
233 233	0
kmalloc-128		5501		6048	128	32	1 : tunables	0		0		0 : slabdata
189 189	0
kmalloc-64	47242		48640		64	64	1 : tunables	0	0		0 : slabdata

760 760 0

kmem_cache_node 76 256 64 64 1 : tunables 0 0 0 : slabdata 4 4 0

kmem_cache 76 160 128 32 1 : tunables 0 0 0 : slabdata 5 5 0

各项信息为：

<active_objs>：The number of objects (memory blocks) that are in use (allocated)

<num_objs>：总共现在有多少 memory blocks Objsize：The size of the objects.

Objperslab：每个 slab 有多少个 memory blocks Pagesperslab：每个 slab 占用多少个page(4096)。

Procrank

字段	表示意思
VSS(virtual set size)	单个进程全部可访问的用户虚拟地址空间
RSS(Resident set size)	单个进程实际占用的内存大小(所有共享库的全部内存大小)
PSS(proportional set size)	不同于 RSS，它只是按比例包含其所使用的共享库大小。
USS(Unique set size)	是单个进程的全部私有内存大小。
Swap	某个进程被交换出去的匿名页的大小就是 Swap(包括在 swap cache 中的和真正交换到 swap 分区的都算)。
Pswap	模仿 PSS 的概念，因为每个匿名页可能会被多个进程使用。因此 Swap 中的 page 按照目前还有多少进程使用它，按照比例分配得到 pswap。
Uswap	模仿 Uss 的概念，私有的且被 swap 出去的内存的大小。

127|root@XXXX:/ # procrank

PID	Vss	Rss		Pss	Uss	Swap PSwap cmdline
1237	1128200K	108136K		55922K	52196K	1388K 1388K system_server
1390	732552K	105912K		52002K	46884K	52K 52K
com.android.systemui
1977 1028756K			81440K	31869K	28868K	0K	0K
com.android.launcher3
3474 1058820K			75688K	22556K	17464K	0K	0K
com.sds.android.ttpod:channel
3343	1301320K	67968K		20864K	16336K	0K	0K com.tencent.mm
...
186	9172K	1448K		208K	160K	692K	692K	/system/bin/vold
224	4748K	928K		172K	160K	256K	256K
/system/bin/download
325	3092K	1100K		165K	20K	0K	0K	/system/xbin/srtd
362	3092K	460K		152K	20K	0K	0K	/system/xbin/srtd
207	3104K	928K		80K	64K	232K	232K	/system/bin/lmkd
252	3036K	804K		68K	12K	312K	312K	/system/bin/sh
213	7824K	844K		65K	52K	256K	256K
/system/bin/modemd
218	988K	96K		64K	64K	56K	56K	/bin/batterysrv
194	5284K	1192K		54K	24K	464K	464K
/system/bin/gatekeeperd
225	5108K	792K		40K	28K	228K	228K

/system/bin/gnss_download 212 4708K 792K 17K 4K 284K 284K

/system/bin/modem_control 219 4860K 748K 16K 4K 284K 284K

/system/bin/modemDriver_vpad_main 195 2800K 804K 15K 0K 308K 308K

/system/xbin/perfprofd 627540K 492360K 10772K 10619K TOTAL

RAM: 939244K total, 19076K free, 8768K buffers, 365548K cached, 4024K shmem, 34248K slab

/proc/pid/smaps

这个是对进程地址空间以及内存使用，最全面的展示。各项说明参考：

6f387000-6ff18000 rw-p 00000000 b3:15 7575 /data/dalvik-cache/arm/system@framework@boot.art

Size:	11844 kB	该段虚拟空间大小
Rss:	11828 kB	= Shared_Clean+ Shared_Dirty+ Private_Clean+ Private_Dirty= Filecache+
Anonymous Pss:	2179 kB	= Pss_Filecache+ Pss_Anonymous
Uss:	1304 kB	= Private_Filecache+Private_Anonymou
Shared_Clean:	7964 kB	和其它进程共享而且是干净的
Shared_Dirty:	2560 kB	和其它进程共享而且是脏的
Private_Clean:	616 kB	本进程私有而且是干净的
Private_Dirty: Referenced: Filecache:	688 kB 11544 kB 8580 kB	本进程私有而且是脏的文件缓存 = Shared_Filecache+ Private_Filecache
Pss_Filecache:	1344 kB	按比例共享的文件缓存
Shared_Filecache:	7964 kB	多进程共享的文件缓存
Private_Filecache:	616 kB	私有的文件缓存
Anonymous:	3248 kB	匿名内存 = Shared_Anonymous+ Private_Anonymous
Pss_Anonymous:	835 kB	按比例共享的匿名内存
Shared_Anonymous:	2560 kB	多进程共享的匿名内存
Private_Anonymous: AnonHugePages: Swap:	688 kB 0 kB 0 kB	私有的匿名内存进程被交换出去的匿名页
PSwap:	0 kB	按比例共享的被交换出去的匿名页
USwap: KernelPageSize: MMUPageSize: Locked:	0 kB 4 kB 4 kB 0 kB	私有的被交换出去的匿名页

VmFlags: rd wr mr mw me ac mg

Dumpsys meminfo

Dumpsys meminfo 是 android 提供的比较有用的内存信息统计工具，并且结合了进程的 adj，可以查看各组进程所占的内存情况。

各个数据的统计来自/proc/pid/smaps，对应关系请参考：

dumpsys meminfo

smaps line

特殊计算

Native Heap

[heap]

[anon:libc_malloc]XXX

Dalvik Heap

.Heap+.LOS+.NonMoving

+.Zygote

Dalvik Other

.LinearAlloc+.Indirec tRef+.JITCache+.GC

Stack

[stackXXX

Ashmem

/dev/ashmemXXX

(-/dev/ashmem/dalvik-XXX

-/dev/ashmem/CursonrWindowXXX

-/dev/ashmem/libc mallocXXX)

Gfx dev	/dev/kgsl-3d0XXX
Other dev	/dev/ (-/dev/kgsl-3d0 -/dev/ashmem)
.so mmap	XXX.so 共享库的 bss 段
.jar mmap	XXX.jar
.apk mmap	XXX.apk
.ttf mmap	XXX.ttf
.dex mmap	XXX.dex XXX.odex
.oat mmap	XXX.oat
.art mmap	XXX.art
Other mmap	namelen>0,已经统计的情况除外
EGL mtrack
GL mtrack
Other mtrack
Unknow	[anonXXX｜new mapping

Dalvik Details
.Heap	/dev/ashmem/dalvik-alloc space /dev/ashmem/dalvik-main space
.Los	/dev/ashmem/dalvik-large object space
.LinearAlloc	/dev/ashmem/dalvik-LinearAlloc
.GC	/dev/ashmem/dalvik-XXX (-heap_dalvik- （.LinearAlloc,.IndirectRef,.JitCache）)
.JITCache	/dev/ashmem/dalvik-jit-code-cache
.Zygote	/dev/ashmem/dalvik-zygote space
.NonMoving	/dev/ashmem/dalvik-non moving space
.IndirectRef	/dev/ashmem/dalvik-indirect ref

App Summary(主要是用来体现进程独占的那些内存）

Java Heap:

Private Dirty(Dalvik Heap) + Private Clean(.art) + Private Dirty(.art)

该进程独有 Java Heap

这个有点问题的, .art比较复杂也会包含文件缓存的（而从经验上看Private Clean(.art) 全部是Private_Filecache; 而Private Dirty(.art) 全部

是 Private_Anonymous）

Native Heap:

Private Dirty(Native Heap)

该进程独有的 Native Heap

Code:

Private(.so) + Private(.jar)+Private(.apk)+Private(. ttf)+Private(.dex)+Private(.oat)

该进程独有的代码占用的内存

.so 其实并不完全是

Code，其也包

含.data, .rodat .bss。这个参考意义有限，因为mmap 部分动态变化且不好统计的

Stack:

Private Dirty(Stack)

该进程独有的栈内存

Graphics:

Private(Gfx_dex) + Private(EGL mtrack) + Private(GL mtrack)

Private Other:

Private(Native Heap) + Private(Dalvik Heap) + Private(Unknow) -Java

Heap-Native Heap - Code -Stack - Graphics

剩余的独有的部分

即：TOTAL(private) - Java Heap - Native Heap

- Code - Stack - Graphics（应该就是Dalvik Other+Ashmem+Unkno

w）

System:

Pss(Dalvik Heap) + Pss(Native Heap)

+Pss(Unknow)-Private(Dalvik Heap)-Private(Native

Heap)-Private(Unknow)

和其它进程共享的，就算做系统的部分。

即：TOTAL(Pss)

-TOTAL(Private)。就是指和其他进程有共享的，就算系统占用的PSS 部分

dumpsys meminfo	smaps	备注
Pss Total	Pss:

Pss Clean	sharing_proportion=(pss-priv ate_clean-private_dirty)/(shar ed_clean+shared_dirty) sharing_proportion*shared_c lean + private_clean	前提条件： XXX.so\|\|XXX.jar\|\|XXX. apk\|XXX.ttf\|XXX.dex\|XX X.odex\|XXX.oat\|XXX.art pss>0 & (shared_clean>0\|shared_di rty>0)	这个就只统计这几部分，其它的不管。所以 heap 的都为 0
Shared Dirty	Shared_Dirty:	共享的脏的
Private Dirty	Private_Dirty:	独占的脏的
Shared Clean	Shared_Clean:	共享的干净的
Private Clean	Private_Clean	独占的干净的
Swapped Dirty	Swap:	被交换出去的
Private Swapped	Uswap	独有的，被交换出去的
Pss Swapped	Pswap	按比例被交换出去的
Heap Size(Native Heap)		mallinfo->usmblks	程序申请内存的最高值
Heap Alloc(Native Heap)		mallinfo->uordblks	当前正在使用的内存大小
Heap Free(Native Heap)		mallinfo->fordblks	当前空闲的内存大小
Heap Size(Dalvik Heap)		Runtime.totalMemory()	Xms 参数指定
Heap Alloc(Dalvik Heap)		Heap Size - Heap Free
Heap Free(Dalvik Heap)		Runtime.freeMemory()

内存评估

有时需要评估二个版本或者同一个版本二种场景下的系统内存情况。比如某公司项目发现，插 sim 比不插 sim，性能差，想看看这二种情况下的内存情况。

首先，可以收集信息，看看同样在开机５分钟的场景下，FreeRAM 的差异。下面的数据可以从/proc/meminfo 和 dumpsys meminfo 中获得。

其次，看下这多出的内存都用在哪里了。

从上面可以，看出，二种场景主要是 framework+app 的内存差异，那进一步看下，用户空间的内存使用情况。下面数据可以由dumpsys meminfo 与 procrank得出。

由上面的数据分析，可以得出结论：

插 sim 卡时，FreeRAM 少 40Ｍ。是因为上层 app 会多，从收集的数据看，会多占 60Ｍ内存。因此，会 drop 更多的file cache, swap 更多匿名页。而 Free RAM是强依赖 file cache，file cache 少，FreeRAM 也会少。

内存泄漏

当系统稳定性不好，或者 lmk 杀到 adj 很低时，一般会看下此时内存使用情况（同内存评估的表格），排查内存泄漏问题。这样整体上看，只能定位出哪个模块或者进程存在 memory leak，具体的 leak 点还需要各个 FO 排查。内核很少出现这类问题，一旦怀疑是内核出现 leak,就会采取很脏的方式，标记每个分配路径与回收路径，最终统计定位出问题的点，一般是 patch 形式 debug。

但是用户层的 memory leak 却很常见，一般泄漏的是 malloc 或者 new 后没有对应的 free 掉，导致Active(anon)+ Inactive(anon) + ZRAM 很大。

例：

从下面 LMK 杀进程时的 mem 情况，看到 Free memory 较小，而 swapfree为 0，swap 分区耗尽。

[82916.745910] c3 sprd thm: @@@D thm sensor id:0, cal_offset:-2, rawdata:0x3b4 
[82916.765411] c1 lowmemorykiller: Killing 'd.process.acore' (27571), adj 5, 
[82916.765411] c1	to free 11576kB on behalf of 'sdcard' (1590) because 
[82916.765411] c1	cache 17680kB is below limit 18432kB for oom_score_adj 3 
[82916.765411] c1	 Free memory is 4124kB above reserved
[82916.765411] c1	swaptotal is 409596kB, swapfree is 0kB

进程的 RSS 信息和 swap 信息如下，而此时 mediaserver 占用空间特别大，用户空间 RSS 为 50M, 而swap 空间为 379M。基本可以确认是 mediaserver 内存泄漏。

lowmemorykiller: [ pid ] uid tgid total_vm rss swap cpu oom_score_adj name

lowmemorykiller: [	130]	0	130	175	48	62	3	-1000 ueventd
lowmemorykiller: [	155]	1023	155	1028	51	45	0	-1000 sdcard
lowmemorykiller: [	156]	1036	156	1497	51	112	2	-1000 logd
lowmemorykiller: [	157]	0	157	395	44	2	3	-1000 healthd
lowmemorykiller: [	158]	0	158	592	58	50	0	-1000 lmkd
lowmemorykiller: [	159]	1000	159	309	58	30	0	-1000 servicemanager
lowmemorykiller: [	160]	0	160	1447	33	144	1	-1000 vold
lowmemorykiller: [	161]	0	161	545	48	175	0	-1000 debuggerd
lowmemorykiller: [	162]	1000	162	10559	207	173	3	-1000 surfaceflinger
lowmemorykiller: [	163]	0	163	782	10	43	0	-1000 modem_control
lowmemorykiller: [	164]	1000	164	1559	3	57	3	-1000 modemd
lowmemorykiller: [	165]	1000	165	1515	43	70	0	-1000 wcnd
lowmemorykiller: [	166]	1000	166	88	0	12	3	-1000 batterysrv
lowmemorykiller: [	173]	2000	173	278	21	41	1	-1000 sh
lowmemorykiller: [	174]	0	174	1444	41	66	1	-1000 collect_apr
lowmemorykiller: [	176]	0	176	2681	20	85	3	-1000 netd
lowmemorykiller: [	177]	1019	177	4535	92	278	1	-1000 drmserver
lowmemorykiller: [	178]	1013	178	146988	7926	92832	1	-1000 mediaserver

Lmk 水位调整

在低内存手机中，常常会涉及 lmk 水位的调整，因为 android 原生水位相对高，常会出现闪退问题或者 CTS 测试进程被 kill。Lmk 水位调整是一种权衡，不会解决所有问题，只能根据项目的性能&稳定性目标，做出均衡。

根据项目经验，以下是Tuning 的大体策略：

基本原则是以 Android 计算的原生值为基准，不建议偏差太多。但是我们实际发现原生计算值比较大，多后台性能不怎么好；而且运行大应用会出现闪退。
各 minfree 值档位差，最好依据原生的比例，尽量进行模仿。我们只是定最高水位 adj 15 对应的内存值。
当系统 ANR 较多时(注：并不是说 ANR 就一定和 LMK 参数相关；但是调节 LMK 参数可以缓解系统的 ANR 情况)
加大 oom_adj >= 9(HIDDEN_APP_MIN_ADJ)对应的 minfree 值
但该方法会降低多后台的性能(减少后台 APP 个数)
通过系统更为积极的 kill 进程来释放 mem；以降低内存回收所使用的 CPU，以及占用的 IO 带宽；加快进程获取 mem 的速度。
如果想提高多后台：

同时应注意与 HIDDEN_APP_MIN_ADJ（9）以下的 adj 对应的 minfree
调低 oom_adj >= 9(HIDDEN_APP_MIN_ADJ)对应 minfree 的值的值保持一定距离
该方法和上述需求 1 是矛盾的。多后台和减少 ANR 往往会不可兼得，请根据实际需求综合考虑。
如果要避免前台进程发生闪退：
1. 如果该值太低，系统内存极低时可能无法恢复过来，导致定屏黑屏等等。
2. 调低 FOREGROUND_APP_ADJ 0 对应的 minfree 值

如果觉得两个水位之间，间隔太大，没有积极的杀进程(主要是导致性能问题)，可以重新设定Oom_adj 数组，比如设定为：0,1,3,9,11,15(原生值为 0，1， 2，3，9，15)。
调节起点：如果 swapfree 相当小时(小于 5%)，但 ANON 页和 Filecache 都很大，而且由于 Filecache 很多，没有杀进程。则至少需要将最高杀 APP 水位调整到此时 Filecache 最大值。通过积极的杀进城来释放 swap 的空间，并减轻内存回收的压力。

下面是实际 tuning 的操作方法：

如果存在页颠簸的话，我们还是希望通过 lmk kill 进程来快速回收内存。而 lmk 参考的阀值是 file-cache，那我们可以大概估算出低于 adj 9 所有进程所需的总体 active file-cache，这值可以做为 adj9 的lmk 阀值。有了这个值，再根据原生水位的比例，就可以得出一组 lmk 水位。

一般将上面得到的水位做为系统最不积极的水位（水位再低点，就会出现页颠簸了），然后在这组水位与原生水位之间再设计出几套水位，再加一组比原生水位高点的水位。分别对设计出来的几套水位，进行性能与稳定性测试，选定表现最均衡的一组。

操作方法：

手机开机５分钟：

１）kill 所有后台进程（am kill-all）;

2 ) 回收内存（echo 1 > /proc/sys/vm/drop_caches）;

3）2 操作后，马上收集内存信息，/proc/meminfo, dumpsys meminfo -a;