本文轉載自： 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