ǰλã >> Android >> Android查看内存和CPU
  ϸ

Android查看内存和CPU

ȶȣ443   ʱ䣺2016-05-01 11:00:18.0
Android查看内存和CPU~

.?、利用Android API函数查看
1.1 ActivityManager查看?内存?br>ActivityManager.MemoryInfo outInfo = new ActivityManager.MemoryInfo(); 
am.getMemoryInfo(outInfo); 
outInfo.availMem即为?空闲内存?br>1.2、android.os.Debug查?PSS,VSS,USS等单?程使用内存信?br>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文件进?解析查??br>/proc/cpuinfo系统CPU的类型等多?信息?br>/proc/meminfo 系统内存使用信息
?br>/proc/meminfo
MemTotal: 16344972 kB
MemFree: 13634064 kB
Buffers: 3656 kB
Cached: 1195708 kB
我们查看机器内存时,会发现MemFree的?很小?这主??为,在linux?这么?种?想,内存不用白不用,因此它尽可能的cache和buffer?些数?以方便下次使用?但实际上这些内存也?以立刻拿来使用的?br>??空闲内存=free+buffers+cached=total-used
通过读取文件/proc/meminfo的信?取Memory的?量?br>ActivityManager. getMemoryInfo(ActivityManager.MemoryInfo)获取当前的可用Memory量??/p>

 

三??过Android系统提供的Runtime类,执?adb 命令(top,procrank,ps...等命?查?
通过对执行结果的标准控制台输出进行解析?这样大大的扩展了Android查?功能.例??br>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 实际使用的物理内存(比例分配共享库占用的内存?br>?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.