在分析内存优化的过程中,其中一个最重要的是我们如何查看cpu的占用率和内存的占用率呢,这在一定程度上很重要,经过查询资料,研究了一下,暂时了解到大概有以下几种方式,如果哪位高手有更好的办法,或者文中描述有错误,还望高手在下面留言,非常感谢!
一、 通过eclipse,ADT开发工具的DDMS来查看(Heap)
在“Devices”窗口中选择模拟器中的一个需要查看的程序,从工具条中选“Update heap”按钮,给这个程序设置上“heap Updates”,然后在Heap视图中点击Cause GC就可以实时显示这个程序的一些内存和cpu的使用情况了。
然后就会出现如下界面:
说明:
a) 点击“Cause GC”按钮相当于向虚拟机请求了一次gc操作;
b) 当内存使用信息第一次显示以后,无须再不断的点击“Cause GC”,Heap视图界面会定时刷新,在对应用的不断的操作过程中就可以看到内存使用的变化;
c) 内存使用信息的各项参数根据名称即可知道其意思,在此不再赘述。
大致解析如下:
这个就是当前应用的内存占用,allocated 是已经分配的内存 free是空闲内存,
heap size 是虚拟机分配的 不是固定值
heap size 的最大值跟手机相关的
有网友说,
一般看1byte的大部分就是图片占用的
如何判断应用是否有内存泄漏的可能性呢?
如何才能知道我们的程序是否有内存泄漏的可能性呢。这里需要注意一个值:Heap视图中部有一个Type叫做data object,即数据对象,也就是我们的程序中大量存在的类类型的对象。在data object一行中有一列是“Total Size”,其值就是当前进程中所有Java数据对象的内存总量,一般情况下,这个值的大小决定了是否会有内存泄漏。可以这样判断:
a) 不断的操作当前应用,同时注意观察data object的Total Size值;
b) 正常情况下Total Size值都会稳定在一个有限的范围内,也就是说由于程序中的的代码良好,没有造成对象不被垃圾回收的情况,所以说虽然我们不断的操作会不断的生成很多对 象,而在虚拟机不断的进行GC的过程中,这些对象都被回收了,内存占用量会会落到一个稳定的水平;
c) 反之如果代码中存在没有释放对象引用的情况,则data object的Total Size值在每次GC后不会有明显的回落,随着操作次数的增多Total Size的值会越来越大,
直到到达一个上限后导致进程被kill掉。
d) 此处已system_process进程为例,在我的测试环境中system_process进程所占用的内存的data object的Total Size正常情况下会稳定在2.2~2.8之间,而当其值超过3.55后进程就会被kill。
在如下的位置:
二、通过linux命令来查看
常用的命令有
adb shell
ps 是看进程的
top命令是看占用率的
3.获取最大内存的方法
ActivityManager am = (ActivityManager) getSystemService(Context.ACTIVITY_SERVICE);
am.getMemoryClass();
这个是最大内存,如果超过这个内存就OOM了
---------------------------------------
内存耗用:VSS/RSS/PSS/USS 的介绍
- VSS - Virtual Set Size 虚拟耗用内存(包含共享库占用的内存)
- RSS - Resident Set Size 实际使用物理内存(包含共享库占用的内存)
- PSS - Proportional Set Size 实际使用的物理内存(比例分配共享库占用的内存)
- USS - Unique Set Size 进程独自占用的物理内存(不包含共享库占用的内存)
一般来说内存占用大小有如下规律:VSS >= RSS >= PSS >= USS
The aim of this post is to provide information that will assist in interpreting memory reports from various tools so the true memory usage for Linux processes and the system can be determined.
Android has a tool called procrank (/system/xbin/procrank), which lists out the memory usage of Linux processes in order from highest to lowest usage. The sizes reported per process are VSS, RSS, PSS, and USS.
For the sake of simplicity in this description, memory will be expressed in terms of pages, rather than bytes. Linux systems like ours manage memory in 4096 byte pages at the lowest level.
VSS (reported as VSZ from ps) is the total accessible address space of a process. This size also includes memory that may not be resident in RAM like mallocs that have been allocated but not written to. VSS is of very little use for determing real memory usage of a process.
RSS is the total memory actually held in RAM for a process. RSS can be misleading, because it reports the total all of the shared libraries that the process uses, even though a shared library is only loaded into memory once regardless of how many processes use it. RSS is not an accurate representation of the memory usage for a single process.
PSS differs from RSS in that it reports the proportional size of its shared libraries, i.e. if three processes all use a shared library that has 30 pages, that library will only contribute 10 pages to the PSS that is reported for each of the three processes. PSS is a very useful number because when the PSS for all processes in the system are summed together, that is a good representation for the total memory usage in the system. When a process is killed, the shared libraries that contributed to its PSS will be proportionally distributed to the PSS totals for the remaining processes still using that library. In this way PSS can be slightly misleading, because when a process is killed, PSS does not accurately represent the memory returned to the overall system.
USS is the total private memory for a process, i.e. that memory that is completely unique to that process. USS is an extremely useful number because it indicates the true incremental cost of running a particular process. When a process is killed, the USS is the total memory that is actually returned to the system. USS is the best number to watch when initially suspicious of memory leaks in a process.
For systems that have Python available, there is also a nice tool called smem that will report memory statistics including all of these categories.
# procrank
procrank
PID Vss Rss Pss Uss cmdline
481 31536K 30936K 14337K 9956K system_server
475 26128K 26128K 10046K 5992K zygote
526 25108K 25108K 9225K 5384K android.process.acore
523 22388K 22388K 7166K 3432K com.android.phone
574 21632K 21632K 6109K 2468K com.android.settings
521 20816K 20816K 6050K 2776K jp.co.omronsoft.openwnn
474 3304K 3304K 1097K 624K /system/bin/mediaserver
37 304K 304K 289K 288K /sbin/adbd
29 720K 720K 261K 212K /system/bin/rild
601 412K 412K 225K 216K procrank
1 204K 204K 185K 184K /init
35 388K 388K 182K 172K /system/bin/qemud
284 384K 384K 160K 148K top
27 376K 376K 148K 136K /system/bin/vold
261 332K 332K 123K 112K logcat
33 396K 396K 105K 80K /system/bin/keystore
32 316K 316K 100K 88K /system/bin/installd
269 328K 328K 95K 72K /system/bin/sh
26 280K 280K 93K 84K /system/bin/servicemanager
45 304K 304K 91K 80K /system/bin/qemu-props
34 324K 324K 91K 68K /system/bin/sh
260 324K 324K 91K 68K /system/bin/sh
600 324K 324K 91K 68K /system/bin/sh
25 308K 308K 88K 68K /system/bin/sh
28 232K 232K 67K 60K /system/bin/debuggerd
#
说明:
Native内存泄漏 --- 泛指底层库文件中的代码存在的内存泄漏,在我们的项目里是指 NavSDK底层so文件中存在的内存泄漏 .
Valgrind --- 一款开源的跨平台的支持多种语言的描绘和检测内存操作相关问题的监 测工具 , 在我们的项目目前只检测内存泄漏 ,内存操作错误以及调用堆栈 .
使用流程 --- 通过NDK交叉编译把Android版的Valgrind 编译好并拷贝到Android设 备的某目录下, 在Android 设备的某个目录下编写一个sh脚本,在这个脚 本中去设置Valgrind的内存检测参数和启动Valgrind , 最后设置App的启 动配置项 , 让App在启动的同时调用之前编写的sh脚本 .
前提条件 --- 一个已经root了的Android 设备 , 一个已经用NDK交叉编译好了的 Valgrind (编译过程参考Valgrind源码目录下的README.android)
注意事项 --- Valgrind检测的库文件必须是带调试符号的库文件才能看到行信息和调 用堆栈 , 而在一般我们在Eclipse开发的Native项目中,虽然我们使用的是ndk-build NDK_DEBUG=1 , 但是我们的App打包到Android 系统里的 so文件并不是有调试符号的 ,因为Android Native调试是基于gdb-server 和gdb-client 这种CS模式的 . 有调试符号的so文件是放在里本地系统 的project/obj/local/armeabi/下,而打包进apk的是libs/armeabi/下的so文件, 这些so文件是不带调试符号的. 所以我们必须用有符号的so文件替换掉 无符号的so文件 . 详细步骤后面会说明 .
操作:
1 准备
root一台Android设备 , SVN check Valgrind 源代码 , 参考README.android 用NDK交叉编译Valgrind 并拷贝到Android /data/local/目录下
其中Inst是交叉编译后会产生的一个文件夹
2 设置
在/data/local目录下编写一个sh脚本 .内容:
#!/system/bin/sh
VGPARAMS='--leak-check=yes --trace-children=yes --num-callers=100 --log-file=/sdcard/valgrind.log'
export TMPDIR=/data/data/com.msd.followme
exec /data/local/Inst/bin/valgrind $VGPARAMS $*
其中VGPARAMS是valgrind的设置参数 参数解释参考官方文档
http://valgrind.org/docs/manual/manual-core.html#manual-core.options
修改val.sh的控制权限 :
命令 : chmod 777 val.sh
修改 com.msd.followme的启动项 ,让它启动的时候去调用val.sh 并且把日志输出的logcat
命令 : setprop wrap.com.msd.followme “logwrapper /data/local/val.sh”
验证设置启动项是否设置成功:打印出 ” /data/local/val.sh ” 则设置成功, 否则失败.
命令 : echo $(getprop wrap.com.msd.followme)
3 使用
在eclipse中run as Android Appllication 我们的followme项目,在followme项目的apk 成功部署到Android 设备并启动主Activity后 ,退出followme应用 ,然后
替换无符号的so文件 (其中的 /project 应为我们的NavSDK项目根目录)
使用adb 把/project/obj/local/armeabi/下的带调试符号的so文件拷贝到Android sdcard/ 下
命令 : adb push /project/obj/local/armeabi/ /sdcard/lib/
在Android 下使用root shell (因为只有root权限才能对data/data/下的文件进行读写)
命令androidShell #: cp -p /sdcard/lib/ /data/data/com.msd.followme/
到此 , com.msd.followme 下的so文件已经被替换成带调试符号的so文件
可以通过ls -al 命令查看so文件大小来判断是否替换成功 ,带符号的so文件会比无符号的大很多 .
替换成功后我们使用adb shell 启动followme的主Activity
命令 : adb shell start -a android.intent.action.MAIN -n com.msd.followme/.ui.FMAppStartActivity
启动成功后就可以进行测试需要测试的功能模块了, 测试完成后推出整个followme应用,此时Valgrind的会将Native内存使用情况的描述和总结输出到/sdcard/valgrind.log中,使用adb shell 可以将日志文件pull到本地系统里面来,方便查看
命令 : adb pull /sdcard/valgrind.log /root/ ( windows下改其他盘符 )
通过查看valgrind.log 就能知道哪些地方存在内存操作错误和调用堆栈了