android查看内存

A. android 内存分析怎么看

使用ActivityManager的getMemoryInfo(ActivityManager.MemoryInfo outInfo)
ActivityManager.getMemoryInfo()主要是用于得到当前系统剩余内存的及判断是否处于低内存运行。
实例1：

private void displayBriefMemory() {
final ActivityManager activityManager = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
ActivityManager.MemoryInfo info = new ActivityManager.MemoryInfo();
activityManager.getMemoryInfo(info);
Log.i(tag,"系统剩余内存:"+(info.availMem >> 10)+"k");
Log.i(tag,"系统是握败迅否处于低内存运行："+info.lowMemory);
Log.i(tag,"当系统剩余内存低于"+info.threshold+"时就看成低内存运行");
}
ActivityManager.getMemoryInfo()是用ActivityManager.MemoryInfo返回结果，而不是Debug.MemoryInfo，他们不一样的段此。
ActivityManager.MemoryInfo只有三个Field:
availMem:表示系统剩余内存
lowMemory：它是boolean值，表示系统是否处于低内存枯樱运行
hreshold：它表示当系统剩余内存低于好多时就看成低内存运行

B. 安卓系统平板怎么看运行多大

Android系统占用手机内存的大小随着版本的不同而不同，一般在100-1000M不等。
安卓系统的优化相比于IOS和WP要差一些，而且垃圾和碎片问题十分严重，另外安卓相比IOS是真后台，如果后台运行很多软件对内存占用是非常高的。
Android是一种基于Linux的自由及开放源代码的操作系统，主要使用于移动设备，如智能手机和平板电脑，由Google公司和开放手机联盟领导及开发。尚未有统一中文名称，中国大陆地区较多人使用“安卓”或“安致”。
Android操作系统最初由Andy Rubin开发，主要支持手机。2005年8月由Google收购注资。2007年11月，Google与84家硬件制造商、软件开发商及电信营运商组建开放手机联盟共同研发改良Android系统。随后Google以Apache开源许可证的授权方式，发布了Android的源代码。
第一部Android智能手机发布于2008年10月。Android逐渐扩展到平板电脑及其他领域上，如电视、数码相机、游戏机等。2011年第一季度，Android在全球的市场份额首次超过塞班系统，跃居全球第一。 2013年的第四季度，Android平台手机的全球市场份额已经达到78.1%。2013年09月24日谷歌开发的操作系统Android在迎来了5岁生日，全世界采用这款系统的设备数量已经达到10亿台。

C. 安卓系统怎么看手机内存

具体操作步骤如下：

1、在手机桌面点击“设置”图标，进入“设置”界面。

2、在“设置山中粗”界面，点击选择“存储空间”即可看到手机的内存的使用情况和内存的其他信息。

安卓系统是一种基于"Linux"的自由及开放源代码的操作系统，主要使用于移动设备，如培拍智能手机和平板电脑，由谷歌公司和开放手逗镇机联盟领导及开发。

D. android系统中查看内存信息

看下大致内存使用早团轿情况 （free+buffers+cached）

proc/meminfo 机器的内存使用信息

/proc/pid/maps pid为进程号，显示当前进程所占用的虚拟地址。

/proc/pid/statm 进程所占用的内存

df 查看 存储空间使用情况

ps -t |grep system_server （或 surfaceflinger， service manager， media server，zygote） ( 倒数第二个是不是 s) 异常情况有如’D’， ‘T’， ‘Z’ ， ‘R’等

mpsys meminfo com.android.mms 打印一个app的mem信息

从以上打印可以看出，一般来说内存占用大小有如下规律：VSS >= RSS >= PSS >= USS

VSS - Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）是单个进程全部可访问的地址空间

RSS - Resident Set Size 实际使用物理内存（包含共享库占用的内存）是单个进程实际占用的内存大小，对于单个共享库， 尽管无论多少个进程使用，实际该共享库只会被装入内存一次。

PSS - Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）

USS - Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）

USS 是或态针对某个进程开始有可疑内存泄露的情况，进行检测陆肆的最佳数字。怀疑某个程序有内存泄露可以查看这个值是否一直有增加

使用mpsys meminfo查看内存信息

脚本：

adb shell ps -t> tsq/ps.txt

adb shell top -t -m 5 -n 2 > tsq/top.txt

adb shell service list  > tsq/serviceList.txt

adb shell cat /proc/meminfo >tsq/meminfo

adb shell cat /proc/buddyinfo >tsq/buddyinfo

adb shell procrank > tsq/procrank.txt

adb shell cat proc/sched_debug >tsq/sched_debug.txt

adb shell cat proc/interrupts >tsq/interrupts.txt

adb shell mpstate > tsq/mpstate.txt

adb shell bugreport > tsq/bugreport.txt

@echo "finish."

pause

E. Android应用查看CPU与内存占用说明

命令中的"应用包名"应该替换为你需要查询的包名.
执行命令后, 在输出的内容中, 第二项即应用的进消昌程仿桥大名, 例如:

那么 22411 即为该应用当前的pid.

其中的"应用的pid"为上一步获取到的pid
执行命令后, 命令行工具即会打印应用运行信息

命令中的"应用包名"应该替换为你需要查询的包名.
命令备竖执行后过段时间即会打印内存占用大小.

F. 如何查看安卓手机运行内存

若使用的是vivo手机，您可以进入手机设置--运存与存储空间中查看手机的存储空间。（部分机型需进入设置--更多设置--存储中进行查看。）

G. Android性能测试（内存、cpu、fps、流量、GPU、电量）——adb篇

3）查看进程列表：adb shell "ps"，同时也能获取到应用的UID，方式如下（不需root权限）：

u0_a开头的都是Android的应用进程，Android的应用的UID是从10000开始，到19999结束，可以在Process.java中查看到（FIRST_APPLICATION_UID和LAST_APPLICATION_UID），u0_a后面的数字就是该应用的UID值减去FIRST_APPLICATION_UID所得的值，所以，对于截图这个应用进程，它是u0_a155，按前面的规制，它的UID就是155 + FIRST_APPLICATION_UID = 10155。

VSS - Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）
RSS - Resident Set Size 实际使用物理内存（包含共享库占用的内存）
PSS - Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）
USS - Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）
一般来说内存占用大小有如下规律：VSS >= RSS >= PSS >= USS

使用 adb shell "mpsys meminfo -s <pakagename | pid>"命令，输出结果分以下4部分:

PS：在apk内调用运行获取其他app的内存数据则需要root权限

adb命令：adb shell mpsys gfxinfo <package | pid>

正常情况下帧率应该在16.67ms左右，1秒60帧，执行结果如下：

详细计算方法如下：

还有一个命令是: adb shell mpsys SurfaceFlinger --latency LayerName

其中LayerName在各个不同系统中获取的命令是不一样的
在Android 6系统直接就是SurfaceView
在Android 7系统中可以通过 mpsys window windows | grep mSurface | grep SurfaceView 然后通过数据截取到
在Android 8系统中可以通过 mpsys SurfaceFlinger | grep android包名获取到

执行命令结果如下：

计算方法比较简单，一般打印出来的数据是129行（部分机型打印两次257行，但是第一部分是无效数据，取后半部分），取len-2的第一列数据为end_time，取len-128的第一列数据为start_time
fps = 127/((end_time - start_time) / 1000000.0)
至于为啥要取第一列数据，这里不做过多介绍，欢迎参看这两篇文章
老罗的文章SurfaceView原理
Android性能测试之fps获取
至于为啥要处于1000000，因为命令打印出来的是纳秒单位，要转为毫秒进行计算，127就是因为命令一次打印出来127帧的数据而已

有两种方法可以获取
1） adb shell "top -n 5 | grep <package | pid>" ，第三列就是实时监控的CPU占用率（-n 指定执行次数，不需root权限），这边top命令执行需要2到3s左右，一般可以采用busybox 的top命令执行，效率会快很多

2） adb shell "mpsys cpuinfo | grep <package | pid>"
两种方法直接区别在于，top是持续监控状态，而mpsys cpuinfo获取的实时CPU占用率数据

adb命令：adb shell "mpsys batterystats < package | pid>" (Android 5.0后引入)
获取单个应用的耗电量信息，具体返回结果待研究

adb命令：adb shell "mpsys battery"
出现信息解读：
AC powered：false 是否连接AC（电源）充电线
USB powered：true 是否连接USB（PC或笔记本USB插口）充电
Wireless powered：false 是否使用了无线电源
status: 1 电池状态，2为充电状态，其他为非充电状态
level：58 电量（%）
scale: 100. 电量最大数值
voltage: 3977 当前电压（mV）
current now: -335232. 当前电流（mA）
temperature:355 电池温度，单位为0.1摄氏度

adb 命令：adb shell "mpsys< package | pid> | grep UID" [通过ps命令，获取app的UID（安装后唯一且固定）]
adb shell cat /proc/uid_stat/UID/tcp_rcv [cat为查看命令，读取tcp_rcv获取应用接收流量信息（设备重启后清零）]
adb shell cat /proc/uid_stat/UID/tcp_snd [cat为查看命令，读取tcp_snd获取应用发送流量信息（设备重启后清零）]
计算流量消耗步骤：

或者还有一种方式获取应用流量消耗：

首先判断类型：
cat /sys/class/thermal/thermal_zone*/type

只有红框框出来的是有效的
cat /sys/class/thermal/thermal_zone*/temp
获取CPU温度

mpsys battery | grep temperature 单位0.1摄氏度

获取/proc/stat文件内容（无权限限制）

总的cpu时间片是 total = user+nice+system+idle+iowait+irq+softirq
忙碌时间为 notidle = user+nice+system +iowait+irq+softirq
cpu使用率计算方法为，先取开始的total值和忙碌时间notidle，隔一段时间片，再取一次计算total2，notidle2, cpuuse = (notidle2 – notidle) * 100 / (total2 - total)%

PS:由于Android 8权限收紧，在Android 8系统手机内apk内读取文件内容为空，需要shell权限才可获取文件内容，下同

读/sys/devices/system/cpu/cpuX/cpufreq/scaling_cur_freq文件的值，X不定，看是几核手机，scaling_cur_freq是否存在也不一定，需要判断

至于为啥不取cpuinfo_cur_freq文件的值，原因是android 6,7系统获取的时候，这个文件shell没有读取权限，需要root权限

参考文章： https://blog.csdn.net/long_meng/article/details/45934899

Android 6,7系统可执行
mpsys window windows | grep "mCurrentFocus"

执行结果一般为类似：
mCurrentFocus=Window{81caaa5 u0 com.tencent.mobileqq/com.tencent.mobileqq.activity.SplashActivity}
按照一定规则把com.tencent.mobileqq提取出来即可

直接apk内读取文件即可，不需要shell权限（支持到Android8）
Gpu使用率获取：会得到两个值，（前一个/后一个）*100%=使用率
adb shell cat /sys/class/kgsl/kgsl-3d0/gpubusy

Gpu工作频率：
adb shell cat /sys/class/kgsl/kgsl-3d0/gpuclk
adb shell cat /sys/class/kgsl/kgsl-3d0/devfreq/cur_freq

Gpu最大、最小工作频率：
adb shell cat /sys/class/kgsl/kgsl-3d0/devfreq/max_freq
adb shell cat /sys/class/kgsl/kgsl-3d0/devfreq/min_freq

Gpu可用频率
adb shell cat /sys/class/kgsl/kgsl-3d0/gpu_available_frequencies
adb shell cat /sys/class/kgsl/kgsl-3d0/devfreq/available_frequencies

Gpu可用工作模式：
adb shell cat /sys/class/kgsl/kgsl-3d0/devfreq/available_governors

Gpu当前工作模式：
adb shell cat /sys/class/kgsl/kgsl-3d0/devfreq/governor

H. Android内存的相关排查方法

mpsys meminfo 是Android系统提供的查询内存命令，用该命令可以看到：
每个进程占用的物理内存大小
系统内存分布状态，包括
总的可用物理内存 Total RAM
当前可用物理内存 Free RAM
已用物理内存 Used RAM
不岩察可见内存 Lost RAM

比如输入该命令后输出如下日志：

该命令打印的最后一部分，反应物哗系统级别的内存状况：
Total RAM: 1015868 kB
Free RAM: 638914 kB (105418 cached pss + 180168 cached + 353328 free)
Used RAM: 211428 kB (186096 used pss + 8008 buffers + 520 shmem + 16804 slab)
Lost RAM: 165526 kB
Tuning: 96 (large 256), oom 20480 kB, restore limit 6826 kB (high-end-gfx)
里面某些字段的意义需要注意：
mpsys meminfo

OOM Killer(Out Of Memory Killer) 是Linux当中，内存保护机制的一种。当物理内存几乎耗尽而又需要分配新内存时，会杀掉一些优先级低的进程，释放内存。
LowMemoryKiller 是Android的内存保护机制。当物理内存低于阈值，就会杀掉一些优先级低的进程，释放内存。

联系：LowMemoryKiller 用到了 OOM Killer 的评分机制
区别：LowMemoryKiller 是通过阈值触发，OOM Killer 是分配内存失败时触发

评分原理：
oom_adj，代表进程的优先级, 数值越大,优先级越低,越容易被杀。系统分16个级别（取值范围[-16, 15]整数，不连续）
通过 cat /proc/xxx/oom_adj 查看，其中xxx是进程号
oom_score_adj: 在 oom_adj 基础上的评分，取值范围[-1000, 1000]
通过 cat /proc/xxx/oom_score_adj 查看，其中xxx是进程号

阈值查看，以98mv100为例：
cat /sys/mole/lowmemorykiller/parameters/minfree
1024,1536,2048,3072,3584,4096
cat /sys/mole/lowmemorykiller/parameters/adj
0,58,117,176,529,1000
上诉数值表示：可用内存低于 4096 4K 时，杀掉 oom_score_adj>=1000 的应用；可用内存低于 3584 4K 时，杀掉 oom_score_adj>=529 的应用，以此类推。

因此，客户可以通过调整 minfree 的阈值来触发 LowMemoryKiller 更频繁地杀应用，从而为高优先级应用省下内存。

在 mpsys meminfo 中，GPU内存被统计到了 Lost RAM 里面罩枣行了。

因此，当应用占用GPU内存过高时，不会体现在 Used RAM 里面，而是体现在 Lost RAM 中。反过来，如果发现有问题的时候 Lost RAM 很高，就需要看看GPU内存使用情况了。用以下命令：�
mount -t debugfs debugfs /sys/kernel/debug/
cat /sys/kernel/debug/mali/gpu_memory

130|root@MR820:/ # cat /sys/kernel/debug/mali/gpu_memory
Name (:bytes) pid mali_mem max_mali_mem external_mem ump_mem dma_mem

其中mali_mem列就是应用占用的GPU内存

I. Android上如何查看CPU和内存信息

1.进入adb shell
2.输入top -m 10 -s cpu 可查看占用cpu最高的前10个程序（-t 显示进程名称，-s 按指定行排序，-n 在退出前刷新几次，-d 刷新间隔，-m 显示最大数量）
参数含义：
PID：progressidentification，应用程序ID
S: 进程的状态，其中S表示休眠，R表示正在运行，Z表示僵死状态，N表示该进程优先值是负数。
#THR：程序当前所用的线程数
VSS：Virtual Set Size虚拟耗用内存（包含共享库占用的内存）
RSS： Resident Set Size实际使用物理内存（包含共享库占用的内存）
PCY：不知道什么意思，期待解答
UID：UserIdentification，用户身份ID
Name:应用程序名称
查看内存消耗
1.进入adb shell ;
2.输入mpsys meminfo(PID或者是包名)

J. 如何检查 Android 应用的内存使用情况

解析日志信息
最简单的调查应用内存使用情况的地方就是Dalvik日志信息。可以在logcat（输出信息可以在Device Monitor或者IDE中查看到，例如Eclipse和Android Studio）中找到这些日志信息。每次有垃圾回收发生，logcat会打印出带有下面信息的日志消息：

Java

1

D/dalvikvm: <GC_Reason> <Amount_freed>, <Heap_stats>, <External_memory_stats>, <Pause_time>

GC原因
触发垃圾回收执行的原因和垃圾回收的类型。原因主要包括：
GC_CONCURRENT
并发垃圾回收，当堆开始填满时触发来释放内存。
GC_FOR_MALLOC
堆已经满了时应用再去尝试分配内存触发的垃圾回收，这时系统必须暂停应用运行来回收内存。
GC_HPROF_DUMP_HEAP
创建HPROF文件来分析应用时触发的垃圾回收。
GC_EXPLICIT
显式垃圾回收，例如当调用 gc()（应该避免手动调用而是要让垃圾回收器在需要时主动调用）时会触发。
GC_EXTERNAL_ALLOC
这种只会在API 10和更低的版本（新版本内存都只在Dalvik堆中分配）中会有。回收外部分配的内存（例如存储在本地内存或NIO字节缓冲区的像素数据）。
释放数量
执行垃圾回收后内存释放的数量。
堆状态
空闲的百分比和（活动对象的数量）/（总的堆大小）。
外部内存状态
API 10和更低版本中的外部分配的内存（分配的内存大小）/（回收发生时的限制值）。
暂停时间
越大的堆的暂停时间就越长。并发回收暂停时间分为两部分：一部分在回收开始时，另一部分在回收将近结束时。
例如：

Java

1

D/dalvikvm( 9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991K, external 4703K/K, paused 2ms+2ms

随着这些日志消息的增多，注意堆状态（上面例子中的3571K/9991K）的变化。如果值一直增大并且不会减小下来，那么就可能有内存泄露了。
查看堆的更新
为了得到应用内存的使用类型和时间，可以在Device Monitor中实时查看应用堆的更新：
1.打开Device Monitor。
从<sdk>/tools/路径下加载monitor工具。
2.在Debug Monitor窗口，从左边的进程列表中选择要查看的应用进程。
3.点击进程列表上面的Update Heap。
4.在右侧面板中选择Heap标签页。

Heap视图显示了堆内存使用的基本状况，每次垃圾回收后会更新。要看更新后的状态，点击Gause GC按钮。

图1.Device Monitor工具显示[1] Update Heap和 [2] Cause GC按钮。右边的Heap标签页显示堆的情况。
跟踪内存分配
当要减少内存问题时，应该使用Allocation Tracker来更好的了解内存消耗大户在哪分配。Allocation Tracker不仅在查看内存的具体使用上很有用，也可以分析应用中的关键代码路径，例如滑动。
例如，在应用中滑动列表时跟踪内存分配，可以看到内存分配的动作，包括在哪些线程上分配和哪里进行的分配。这对优化代码路径来减轻工作量和改善UI流畅性都极其有用。
使用Allocation Tracker：
1.打开Device Monitor 。
从<sdk>/tools/路径下加载monitor工具。
2.在DDMS窗口，从左侧面板选择应用进程。
3.在右侧面板中选择Allocation Tracker标签页。
4.点击Start Tracking。
5.执行应用到需要分析的代码路径处。
6.点击Get Allocations来更新分配列表。
列表显示了所有的当前分配和512大小限制的环形缓冲区的情况。点击行可以查看分配的堆栈跟踪信息。堆栈不只显示了分配的对象类型，还显示了属于哪个线程哪个类哪个文件和哪一行。

图2. Device Monitor工具显示了在Allocation Tracker中当前应用的内存分配和堆栈跟踪的情况。
注意：总会有一些分配是来自与 DdmVmInternal 和 allocation tracker本身。
尽管移除掉所有严重影响性能的代码是不必要的（也是不可能的），但是allocation tracker还是可以帮助定位代码中的严重问题。例如，应用可能在每个draw操作上创建新的Paint对象。把对象改成全局变量就是一个很简单的改善性能的修改。
查看总体内存分配
为了进一步的分析，查看应用内存中不同内存类型的分配情况，可以使用下面的 adb 命令：

Java

1

adb shell mpsys meminfo <package_name>

应用当前的内存分配输出列表，单位是千字节。
当查看这些信息时，应当熟悉下面的分配类型：
私有(Clean and Dirty) 内存
进程独占的内存。也就是应用进程销毁时系统可以直接回收的内存容量。通常来说，“private dirty”内存是其最重要的部分，因为只被自己的进程使用。它只在内存中存储，因此不能做分页存储到外存（Android不支持swap）。所有分配的Dalvik堆和本地堆都是“private dirty”内存；Dalvik堆和本地堆中和Zygote进程共享的部分是共享dirty内存。
实际使用内存 (PSS)
这是另一种应用内存使用的计算方式，把跨进程的共享页也计算在内。任何独占的内存页直接计算它的PSS值，而和其它进程共享的页则按照共享的比例计算PSS值。例如，在两个进程间共享的页，计算进每个进程PPS的值是它的一半大小。
PSS计算方式的一个好处是：把所有进程的PSS值加起来就可以确定所有进程总共占用的内存。这意味着用PSS来计算进程的实际内存使用、进程间对比内存使用和总共剩余内存大小是很好的方式。
例如，下面是平板设备中Gmail进程的输出信息。它显示了很多信息，但是具体要讲解的是下面列出的一些关键信息。
注意：实际看到的信息可能和这里的稍有不同，输出的详细信息可能会根据平台版本的不同而不同。

Java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

** MEMINFO in pid 9953 [com.google.android.gm] **
Pss Pss Shared Private Shared Private Heap Heap Heap
Total Clean Dirty Dirty Clean Clean Size Alloc Free
------ ------ ------ ------ ------ ------ ------ ------ ------
Native Heap 0 0 0 0 0 0 7800 7637(6) 126
Dalvik Heap 5110(3) 0 4136 4988(3) 0 0 9168 8958(6) 210
Dalvik Other 2850 0 2684 2772 0 0
Stack 36 0 8 36 0 0
Cursor 136 0 0 136 0 0
Ashmem 12 0 28 0 0 0
Other dev 380 0 24 376 0 4
.so mmap 5443(5) 1996 2584 2664(5) 5788 1996(5)
.apk mmap 235 32 0 0 1252 32
.ttf mmap 36 12 0 0 88 12
.dex mmap 3019(5) 2148 0 0 8936 2148(5)
Other mmap 107 0 8 8 324 68
Unknown 6994(4) 0 252 6992(4) 0 0
TOTAL 24358(1) 4188 9724 17972(2)16388 4260(2)16968 16595 336

Objects
Views: 426 ViewRootImpl: 3(8)
AppContexts: 6(7) Activities: 2(7)
Assets: 2 AssetManagers: 2
Local Binders: 64 Proxy Binders: 34
Death Recipients: 0
OpenSSL Sockets: 1

SQL
MEMORY_USED: 1739
PAGECACHE_OVERFLOW: 1164 MALLOC_SIZE: 62

通常来说，只需关心Pss Total列和Private Dirty列就可以了。在一些情况下，Private Clean列和Heap Alloc列也会提供很有用的信息。下面是一些应该查看的内存分配类型(行中列出的类型)：
Dalvik Heap
应用中Dalvik分配使用的内存。Pss Total包含所有的Zygote分配（如上面PSS定义所描述的，共享跨进程的加权）。Private Dirty是应用堆独占的内存大小，包含了独自分配的部分和应用进程从Zygote复制分裂时被修改的Zygote分配的内存页。
注意：新平台版本有Dalvik Other这一项。Dalvik Heap中的Pss Total和Private Dirty不包括Dalvik的开销，例如即时编译（JIT）和垃圾回收（GC），然而老版本都包含在Dalvik的开销里面。
Heap Alloc是应用中Dalvik堆和本地堆已经分配使用的大小。它的值比Pss Total和Private Dirty大，因为进程是从Zygote中复制分裂出来的，包含了进程共享的分配部分。
.so mmap和.dex mmap
mmap映射的.so(本地) 和.dex(Dalvik)代码使用的内存。Pss Total 包含了跨应用共享的平台代码；Private Clean是应用独享的代码。通常来说，实际映射的内存大小要大一点——这里显示的内存大小是执行了当前操作后应用使用的内存大小。然而，.so mmap 的private dirty比较大，这是由于在加载到最终地址时已经为本地代码分配好了内存空间。
Unknown
无法归类到其它项的内存页。目前，这主要包含大部分的本地分配，就是那些在工具收集数据时由于地址空间布局随机化(Address Space Layout Randomization ，ASLR)不能被计算在内的部分。和Dalvik堆一样， Unknown中的Pss Total把和Zygote共享的部分计算在内，Unknown中的Private Dirty只计算应用独自使用的内存。
TOTAL
进程总使用的实际使用内存(PSS)，是上面所有PSS项的总和。它表明了进程总的内存使用量，可以直接用来和其它进程或总的可以内存进行比较。
Private Dirty和Private Clean是进程独自占用的总内存，不会和其它进程共享。当进程销毁时，它们（特别是Private Dirty）占用的内存会重新释放回系统。Dirty内存是已经被修改的内存页，因此必须常驻内存（因为没有swap）；Clean内存是已经映射持久文件使用的内存页（例如正在被执行的代码），因此一段时间不使用的话就可以置换出去。
ViewRootImpl
进程中活动的根视图的数量。每个根视图与一个窗口关联，因此可以帮助确定涉及对话框和窗口的内存泄露。
AppContexts和Activities
当前驻留在进程中的Context和Activity对象的数量。可以很快的确认常见的由于静态引用而不能被垃圾回收的泄露的 Activity对象。这些对象通常有很多其它相关联的分配，因此这是追查大的内存泄露的很好办法。
注意：View 和 Drawable 对象也持有所在Activity的引用，因此，持有View 或 Drawable 对象也可能会导致应用Activity泄露。
获取堆转储
堆转储是应用堆中所有对象的快照，以二进制文件HPROF的形式存储。应用堆转储提供了应用堆的整体状态，因此在查看堆更新的同时，可以跟踪可能已经确认的问题。
检索堆转储：
1.打开Device Monitor。
从<sdk>/tools/路径下加载monitor工具。
2.在DDMS窗口，从左侧面板选择应用进程。
3.点击Dump HPROF file，显示见图3。
4.在弹出的窗口中，命名HPROF文件，选择存放位置，然后点击Save。

图3.Device Monitor工具显示了[1] Dump HPROF file按钮。
如果需要能更精确定位问题的堆转储，可以在应用代码中调用mpHprofData()来生成堆转储。
堆转储的格式基本相同，但与Java HPROF文件不完全相同。Android堆转储的主要不同是由于很多的内存分配是在Zygote进程中。但是由于Zygote的内存分配是所有应用进程共享的，这些对分析应用堆没什么关系。
为了分析堆转储，你需要像jhat或Eclipse内存分析工具(MAT)一样的标准工具。当然，第一步需要做的是把HPROF文件从Android的文件格式转换成J2SE HRPOF的文件格式。可以使用<sdk>/platform-tools/路径下的hprof-conv工具来转换。hprof-conv的使用很简单，只要带上两个参数就可以：原始的HPROF文件和转换后的HPROF文件的存放位置。例如：

Java

1

hprof-conv heap-original.hprof heap-converted.hprof

注意：如果使用的是集成在Eclipse中的DDMS，那么就不需要再执行HPROF转换操作——默认已经转换过了。
现在就可以在MAT中加载转换过的HPROF文件了，或者是在可以解析J2SE HPROF格式的其它堆分析工具中加载。
分析应用堆时，应该查找由下导致的内存泄露：
对Activity、Context、View、Drawable的长期引用，以及其它可能持有Activity或Context容器引用的对象
非静态内部类（例如持有Activity实例的Runnable）
不必要的长期持有对象的缓存
使用Eclipse内存分析工具
Eclipse内存分析工具（MAT）是一个可以分析堆转储的工具。它是一个功能相当强大的工具，功能远远超过这篇文档的介绍，这里只是一些入门的介绍。

在MAT中打开类型转换过的HPROF文件，在总览界面会看到一张饼状图，它展示了占用堆的最大对象。在图表下面是几个功能的链接：
Histogram view显示所有类的列表和每个类有多少实例。
正常来说类的实例的数量应该是确定的，可以用这个视图找到额外的类的实例。例如，一个常见的源码泄露就是Activity类有额外的实例，而正确的是在同一时间应该只有一个实例。要找到特定类的实例，在列表顶部的<Regex>域中输入类名查找。
当一个类有太多的实例时，右击选择List objects>with incoming references。在显示的列表中，通过右击选择Path To GC Roots> exclude weak references来确定保留的实例。
Dominator tree是按照保留堆大小来显示的对象列表。
应该注意的是那些保留的部分堆大小粗略等于通过GC logs、heap updates或allocation tracker观察到的泄露大小的对象。
当看到可疑项时，右击选择Path To GC Roots>exclude weak references。打开新的标签页，标签页中列出了可疑泄露的对象的引用。
注意：在靠近饼状图中大块堆的顶部，大部分应用会显示Resources的实例，但这通常只是因为在应用使用了很多res/路径下的资源。

图4.MAT显示了Histogram view和搜索”MainActivity”的结果。
想要获得更多关于MAT的信息，请观看2011年Google I/O大会的演讲–《Android 应用内存管理》（Memory management for Android apps），在大约21:10 的时候有关于MAT的实战演讲。也可以参考文档《Eclipse 内存分析文档》（Eclipse Memory Analyzer documentation）。
对比堆转储
为了查看内存分配的变化，比较不同时间点应用的堆状态是很有用的方法。对比两个堆转储可以使用MAT：
1.按照上面描述得到两个HPROF文件，具体查看获取堆转储章节。
2.在MAT中打开第一个HPROF文件（File>Open Heap Dump）。
3.在Navigation History视图（如果不可见，选择Window>Navigation History），右击Histogram，选择Add to Comp are Basket。
4.打开第二个HRPOF文件，重复步骤2和3。
5.切换到Compare Basket视图，点击Compare the Results（在视图右上角的红色“！”图标）。
触发内存泄露
使用上述描述工具的同时，还应该对应用代码做压力测试来尝试复现内存泄露。一个检查应用潜在内存泄露的方法，就是在检查堆之前先运行一会。泄露会慢慢达到分配堆的大小的上限值。当然，泄露越小，就要运行应用越长的时间来复现。
也可以使用下面的方法来触发内存泄露：
1.在不同Activity状态时，重复做横竖屏切换操作。旋转屏幕可能导致应用泄露 Activity、Context 或 View对象，因为系统会重新创建 Activity，如果应用在其它地方持有这些对象的引用，那么系统就不能回收它们。
2.在不同Activity状态时，做切换应用操作（切换到主屏幕，然后回到应用中）。
提示：也可以使用monkey测试来执行上述步骤。想要获得更多运行 monkey 测试的信息，请查阅 monkeyrunner 文档。