Android的内存分析

最近在帮助客户做gts测试遇到一个很奇怪的现象。

 在gts测试过程中，先测试media后然后测试playerstore时，会一直失败。但是如果不放在media测试后面就不会出问题。

经过2天的检查和log分析，终于找到问题啦。在测试playstore 时遇到调用launcher，在执行media测试时，由于media测试用例在内存占用很大，由于系统的低内存的机制会将停在后台的进程杀死，因此launcher此时也被kill掉啦。导致在在playerstore测试时，需要回到主页时，

validateTop...: activity in front not resumed r=ActivityRecord{21ba5ee8 u0 com.android.launcher/com.android.launcher2.Launcher t1} state=DESTROYED

此时的主页已经是destroyed状态，导致返回主页失败。

解决方案： 1.减少系统的内置的apk，减少内存占用量。2.在launcher增加防杀机制，添加android:persistent="true

在解决此问题的过程中，重点研究了ActivityManagerh和ActivityThread 代码和使用一些内存分析的方法，现在归纳一下。

1.内存分析常见的参数：

• VSS - Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）
• RSS - Resident Set Size 实际使用物理内存（包含共享库占用的内存）
• PSS - Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）
• USS - Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）

一般来说内存占用大小有如下规律：VSS >= RSS >= PSS >= USS

2.内存终端分析常用命令：

dumpsys meminfo ,cat /proc/meminfo  ,procrank, “adb shell ps -x”

下面是procank 使用方式。

如果你想查看所有进程的内存使用情况，可以使用"adb shell procrank"命令。命令返回将如下：

  PID      Vss      Rss      Pss      Uss  cmdline

  188   75832K   51628K   24824K   19028K  system_server

  308   50676K   26476K    9839K    6844K  system_server

 2834   35896K   31892K    9201K    6740K  com.sec.android.app.twlauncher

  265   28536K   28532K    7985K    5824K  com.android.phone

  100   29052K   29048K    7299K    4984K  zygote

  258   27128K   27124K    7067K    5248K  com.swype.android.inputmethod

  270   25820K   25816K    6752K    5420K  com.android.kineto

 1253   27004K   27000K    6489K    4880K  com.google.android.voicesearch

 2898   26620K   26616K    6204K    3408K  com.google.android.apps.maps:FriendService

  297   26180K   26176K    5886K    4548K  com.google.process.gapps

 3157   24140K   24136K    5191K    4272K  android.process.acore

 2854   23304K   23300K    4067K    2788K  com.android.vending

 3604   22844K   22840K    4036K    3060K  com.wssyncmldm

各个细节使用详细请参考：

http://blog.csdn.net/hudashi/article/details/7050897

•