proc / stat空闲时间减少

时间:2014-12-23 20:01:52

标签: java android

我已经编写了一些代码来计算android设备上的cpu负载,通过读取proc / stat中的第一行,大部分时间都能正常工作,除非它现在又一次返回负值,经过进一步检查,我意识到空闲时间值有时会减少,我创建了一个虚拟的runnable类来演示这种行为:

public class MyRunnable implements Runnable{

    String[]cpuTimeInfo;
    long idle2;
    long idle1;
    @Override
    public void run() {

        if (new File("/proc/stat").exists()) {

            try{
                BufferedReader br = new BufferedReader(new FileReader(new File("/proc/stat")));
                String aLine;

                while ((aLine = br.readLine()) != null){

                    if(aLine.substring(0, 3).equals("cpu")){

                        cpuTimeInfo = aLine.split("\\s+");
                        idle1 = Long.parseLong(cpuTimeInfo[4]);;

                        try{
                            Thread.sleep(1000);
                            br = new BufferedReader(new FileReader(new File("/proc/stat")));
                            aLine = br.readLine();
                            cpuTimeInfo = aLine.split("\\s+");
                        }
                        catch(InterruptedException e){

                        }

                        idle2 = Long.parseLong(cpuTimeInfo[4]);;
                        if(idle2 < idle1)
                            Log.d("????", "Idle 1: " + idle1 + " Idle 2: " + idle2);
                        break;
                    }
                }
                if (br != null) {
                    br.close();
                }
            }
            catch (IOException | NumberFormatException e){
            }
        }
        new Thread(this).start();
    }

}
  1. 有人可以向我解释这是怎么回事。
  2. 是否有正确的解决方法或真正解决此问题的方法

1 个答案:

答案 0 :(得分:0)

我在Android设备上遇到了同样的问题。我的想法是,空闲列中的值实际上并没有随着时间的推移而减少,而是比以前更低了三分之一。我猜测它与每个CPU核心值的聚合有关。

但是我不知道如何解决这个问题。也许我们必须得到每个核心的价值并自己做加法。不知道,我还没走那么远,我认为这种做法过于缺乏建设性。

解决方法实际上非常简单:为每个获得的idleX更新一个空闲变量。如果新值低于idle,则跳过循环迭代。简单地说,它意味着跳过任何空闲不会逐渐增加的情况。

以下是一些可以很好地说明手头问题的痕迹。它是定期间隔的/ proc / stat第一行的转储。查看第5列,即从大约7M(错误)到10M(正确)的列。

Wed Mar 18 11:40:25 CET 2015,INFO,cpu: getSystemCpuUsage start=[cpu 392408 78027 265140 10190657 28775 74 3969 0 0 0]
Wed Mar 18 11:40:31 CET 2015,INFO,cpu: getSystemCpuUsage start=[cpu 392602 78031 265285 10195990 28794 74 3974 0 0 0]
Wed Mar 18 11:40:37 CET 2015,INFO,cpu: getSystemCpuUsage start=[cpu 392731 78049 265399 10197540 28804 74 3988 0 0 0]
Wed Mar 18 11:40:43 CET 2015,INFO,cpu: getSystemCpuUsage start=[cpu 392882 78058 265521 7938411 28655 74 4017 0 0 0]
Wed Mar 18 11:40:49 CET 2015,INFO,cpu: getSystemCpuUsage start=[cpu 392956 78058 265636 10199960 28827 74 4029 0 0 0]
Wed Mar 18 11:40:55 CET 2015,INFO,cpu: getSystemCpuUsage start=[cpu 393032 78058 265720 10201160 28836 74 4030 0 0 0]
Wed Mar 18 11:41:01 CET 2015,INFO,cpu: getSystemCpuUsage start=[cpu 393159 78059 265809 7941553 28668 74 4030 0 0 0]
Wed Mar 18 11:41:07 CET 2015,INFO,cpu: getSystemCpuUsage start=[cpu 393316 78070 265917 7942154 28679 74 4038 0 0 0]
Wed Mar 18 11:41:13 CET 2015,INFO,cpu: getSystemCpuUsage start=[cpu 393441 78085 266048 7943935 28691 75 4054 0 0 0]
Wed Mar 18 11:41:19 CET 2015,INFO,cpu: getSystemCpuUsage start=[cpu 393614 78086 266206 7950457 28704 75 4086 0 0 0]
Wed Mar 18 11:41:26 CET 2015,INFO,cpu: getSystemCpuUsage start=[cpu 393716 78086 266295 10213601 28875 75 4087 0 0 0]
Wed Mar 18 11:41:32 CET 2015,INFO,cpu: getSystemCpuUsage start=[cpu 393812 78086 266372 10214027 28875 75 4087 0 0 0]