本文转载自： https://blog.csdn.net/l460133921/article/details/51134213
为了方便以后阅读，直接全文复制，感谢原创，尊重原创！
前言：在一次app优化过程中，发现CPU对某些功能模块有一定的影响，例如我的场景是在其他APP之上用WindwManager作为载体加载一个页面，发现之后页面所在APP有些模块进行的非常慢，于是换成activity作为载体加载页面，并在页面进行到特定时间后进行功能加载，发现要比之前快很多，于是猜想WindowManager加载的页面并不会让处于的app切换到前台，也就不会让cpu更优先的调度。最终通过原创的以下方法和原理进行验证，得出结论。
cgroups的定义
维基百科的解释为：cgroups，其名称源自控制组群（control groups）的简写，是Linux内核的一个功能，用来限制，控制与分离一个进程组群的资源（如CPU、内存、磁盘输入输出等）。
Android中的cgroups
Android中的cgroups关于cpu的一般有两个，分别位于：
dev/cpuctl/ --位于前台的app
dev/cpuctl/bg_non_interactive --进入后台的app
其内部的各个文件的作用介绍如下：
1. cpu.shares
cpu.shares文件中保存了整数值，用来设置cgroup分组任务获得CPU时间的相对值。举例来说，cgroup A和cgroup B的cpu.shares值都是1024，那么cgroup A 与cgroup B中的任务分配到的CPU时间相同，如果cgroup C的cpu.shares为512，那么cgroup C中的任务获得的CPU时间是A或B的一半。前台app的cpu.shares值如下：
root@XXXX:/dev/cpuctl # cat cpu.shares
cat cpu.shares
1024
而bg_non_interactive下的cpu.shares值为52
也就是说apps分组与bg_non_interactive分组cpu.share值相比接近于20:1。由于Android中只有这两个cgroup，也就是说apps分组中的应用可以利用95%的CPU，而处于bg_non_interactive分组中的应用则只能获得5%的CPU利用率。
2. cpu.rt_period_us与cpu.rt_runtime_us
cpu.rt_period_us用来设置cgroup获得CPU资源的周期，单位为微秒。 cpu.rt_runtime_us用来设置cgroup中的任务可以最长获得CPU资源的时间，单位为微秒。最长的获取CPU资源时间取决于逻辑CPU的数量。比如cpu.rt_runtime_us设置为200000（0.2秒），cpu.rt_period_us设置为1000000（1秒）。在单个逻辑CPU上的获得时间为每秒为0.2秒。 2个逻辑CPU，获得的时间则是0.4秒。
在Android中，一个应用（进程）既可以由前台进程切换到bg_non_interactive，也可以切换回来。
Activity：当一个Activity处于可见的状态下，那么这个应用进程就属于apps分组。
Service：当Service调用startForeground方法后，那么这个应用进程则是归类于前台进程。
如何确定进程所属的cgroups
步骤１: adb shell进入已经root的Android设备终端，获得进程的pid，如
root@XXXX:/proc/6566 # ps | grep -i "video"
u0_a70 6566 498 1514624 79340 SyS_epoll_ 7f9ea9cba4 S com.android.videoplayer
我们获得了一个视频播放器的进程pid为6566
步骤2: adb shell cat proc/6566/cgroup
结果若为：
cat cgroup
2:cpu:/bg_non_interactive（后台非交互进程）
1:cpuacct:/uid_10070/pid_6566
若结果为：
2:cpu:/（前台进程）
1:cpuacct:/uid_10070/pid_6566