[转载]查看基于Android 系统单个进程内存、CPU使用情况的几种方法_移动开发_编程开发_程序员俱乐部

转载自： http://www.linuxidc.com/Linux/2011-11/47587.htm 

一、利用Android API函数查看
1.1 ActivityManager查看可用内存。

1 ActivityManager.MemoryInfo outInfo = new ActivityManager.MemoryInfo(); 
2 am.getMemoryInfo(outInfo); 
3 outInfo.availMem即为可用空闲内存。

1.2、android.os.Debug查询PSS，VSS，USS等单个进程使用内存信息
MemoryInfo[] memoryInfoArray = am.getProcessMemoryInfo(pids); 
MemoryInfo pidMemoryInfo=memoryInfoArray[0];
pidMemoryInfo.getTotalPrivateDirty();

getTotalPrivateDirty()
Return total private dirty memory usage in kB. USS

getTotalPss()
Return total PSS memory usage in kB. 
PSS
getTotalSharedDirty()
Return total shared dirty memory usage in kB. RSS

二、直接对Android文件进行解析查询，
/proc/cpuinfo系统CPU的类型等多种信息。
/proc/meminfo 系统内存使用信息
如
/proc/meminfo
MemTotal: 16344972 kB
MemFree: 13634064 kB
Buffers: 3656 kB
Cached: 1195708 kB
我们查看机器内存时，会发现MemFree的值很小。这主要是因为，在linux中有这么一种思想，内存不用白不用，因此它尽可能的cache和buffer一些数据，以方便下次使用。但实际上这些内存也是可以立刻拿来使用的。
所以 空闲内存=free+buffers+cached=total-used
通过读取文件/proc/meminfo的信息获取Memory的总量。
ActivityManager. getMemoryInfo(ActivityManager.MemoryInfo)获取当前的可用Memory量。

三、通过Android系统提供的Runtime类，执行adb 命令(top,procrank,ps...等命令)查询
通过对执行结果的标准控制台输出进行解析。这样大大的扩展了Android查询功能.例如：
final Process m_process = Runtime.getRuntime().exec("/system/bin/top -n 1");
final StringBuilder sbread = new StringBuilder();
BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(m_process.getInputStream()), 8192);

# procrank
Runtime.getRuntime().exec("/system/xbin/procrank");
内存耗用：VSS/RSS/PSS/USS
Terms
• VSS - Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）
• RSS - Resident Set Size 实际使用物理内存（包含共享库占用的内存）
• PSS - Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）
• USS - Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）
一般来说内存占用大小有如下规律：VSS >= RSS >= PSS >= USS
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.