若想直接看有效方法，请阅读方法二，第一条。
最近因为一个需求，需要记录下当前的CPU使用率，在翻遍了API后，发现系统并没有给予一个方法，能够简单的获取相关CPU信息，没办法，只能自己写一个了。
在网上查阅了相关方法后，获取CPU使用率主要有两种方法。一个是利用adb top命令；另一个就是读取/proc/stat文件，然后解析相关参数，自己去计算。
方法一、解析top命令结果
这是执行adb shell top命令后的结果。
从图中可知，top命令的执行结果显示，在第一个非空白行上有各部分的CPU占用率，我们只要稍微整理下就行。
先上代码：
然而得到的结果显然不对，以下是从输入流中打印出来的命令执行结果：
显然，系统对于这个top命令动态的进行了修改，防止信息被App获取。正确的执行权限只留给了adbshell。
至此，此方法失效。
方法二、解析/proc/stat文件
/proc/stat文件动态记录所有CPU活动的信息，该文件中的所有值都是从系统启动开始累计到当前时刻。所以，计算系统当前的CPU占用率的方法就是，计算在间隔较短（ms级）的时间内，cpu的各活动信息的变化量，作为当前的实时CPU占用率。
下图是执行shell命令，获取文件的内容。
其中，以CPU开头的两行表示的信息就是，当前该CPI的一个总的使用情况，后面各个数值的单位为jiffies，可以简单理解为Linux中操作系统进程调度的最小时间片。具体含义如下（以CPU0为例）：
user(181596)从系统启动开始累计到当前时刻，处于用户态的运行时间，不包含 nice值为负进程。；
nice(85733)从系统启动开始累计到当前时刻，nice值为负的进程所占用的CPU时间；
system (197165)从系统启动开始累计到当前时刻，处于核心态的运行时间；
idle (1328127)从系统启动开始累计到当前时刻，除IO等待时间以外的其它等待时间；
iowait(11679)从系统启动开始累计到当前时刻，IO等待时间；
irq (5)从系统启动开始累计到当前时刻，硬中断时间；
softirq (5138)从系统启动开始累计到当前时刻，软中断时间。
这里，我们只需关心“idle”，它表示了系统的空闲时间，以及各项数值之和就是CPU的总消耗。
因此，我们以totalJiffies1表示第一次CPU总消耗，totalIdle1表示第一次的CPU空闲时间，同理，totalJiffies2、totalIdle2表示第二次的相关信息，则cpu的占用率如下：
double cpuRate=1.0*((totalIdle2-totalJiffies2)-(totalIdle1-totalJiffies1))/( totalIdle2- totalIdle1);
以下是根据这个思想实现的代码：
* 在实际测试中发现，有的手机会隐藏CPU状态，不会完全显示所有CPU信息，例如MX5，所有建议只做参考
* @return
*/
public static String getCPURateDesc(){
"/proc/stat";// 系统CPU信息文件
long totalJiffies[]=new long[2];
long totalIdle[]=new long[2];
int firstCPUNum=0;//设置这个参数，这要是防止两次读取文件获知的CPU数量不同，导致不能计算。这里统一以第一次的CPU数量为基准
null;
null;
" [0-9]+");
for(int i=0;i<2;i++) {
0;
0;
try {
new FileReader(path);
new BufferedReader(fileReader, 8192);
int currentCPUNum=0;
String str;
while ((str = bufferedReader.readLine()) != null&&(i==0||currentCPUNum<firstCPUNum)) {
if (str.toLowerCase().startsWith("cpu")) {
currentCPUNum++;
int index = 0;
Matcher matcher = pattern.matcher(str);
while (matcher.find()) {
try {
long tempJiffies = Long.parseLong(matcher.group(0).trim());
totalJiffies[i] += tempJiffies;
if (index == 3) {//空闲时间为该行第4条栏目
totalIdle[i] += tempJiffies;
}
index++;
catch (NumberFormatException e) {
e.printStackTrace();
}
}
}
if(i==0){
firstCPUNum=currentCPUNum;
try {//暂停50毫秒，等待系统更新信息。
50);
catch (InterruptedException e) {
e.printStackTrace();
}
}
}
catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
finally {
if (bufferedReader != null) {
try {
bufferedReader.close();
catch (IOException e) {
e.printStackTrace();
}
}
}
}
double rate=-1;
if (totalJiffies[0]>0&&totalJiffies[1]>0&&totalJiffies[0]!=totalJiffies[1]){
1.0*((totalJiffies[1]-totalIdle[1])-(totalJiffies[0]-totalIdle[0]))/(totalJiffies[1]-totalJiffies[0]);
}
return String.format("cpu:%.2f",rate);
}
</span>
思考：上述方法中，为了获取两次CPU信息，强制线程休眠了50ms，若实际文件内容的修改要比这个时间多怎么办？这样两次读取的信息就相同了；如果少于50ms，则白等了这么久。因此引入了FileObserve，当文件被修改时，系统回调相应的方法通知我们去读取新的内容，这样就可以避免上述问题。
方法很简单，就不全贴了，就附上变化的部分：
1、继承FileObserver类，并实现onEvent(int event, String path)方法，在执行该类的startWatching()方法后，系统会回调onEvent方法，告知该文件发生变化的情况，当判定为文件被修改时，就唤醒读取文件的线程，继续工作。
2、当第一次读取到文件输入流后，启动文件监听。
3、当第一次读取解析文件结束后，不再是执行sleep方法，而是执行wait方法，等待接收到系统的回调。
结果：第二次文件读取一直未进行。
通过日志发现，接收到的文件变化事件只有三类：
即：
即，文件只发生过访问数据、打开文件、关闭文件这三种操作。
这明显不可能，文件的内容一直在动态变化着！
通过上网查找资料发现：/proc文件系统是一个伪文件系统，它只存在内存当中，而不占用外存空间。它以文件系统的方式为内核与进程提供通信的接口。用户和应用程序可以通过/proc得到系统的信息，并可以改变内核的某些参数。由于系统的信息，如进程，是动态改变的，所以用户或应用程序读取/proc目录中的文件时，proc文件系统是动态从系统内核读出所需信息并提交的。
也就是说，这是一个特殊的文件，是收不到文件修改事件的，想通过文件观察对象进行监督文件的修改情况的方法也就失效了。
总结：获取CPU使用率信息，目前相对最可靠的方式就是两次获取并/proc/stat文件内容，然后计算。
