一個好的性能測試指標應該滿足 2 個條件:
對過去發生的事情做總結.
對未來做預期.
Settings->Memory就很好地實現了這 2 個條件:
[3 hours]: 表示統計過去 3 小時 RAM 的使用情況. 使用者還可以選擇 6 小時, 12 小時, 1 天.
[Performance]: 表示手機當前的性能情況. 這裏有一套 Google 的性能評價標準.
[Total memory]/[Average used]/[Free]: 統計時間內 RAM 的平均使用情況. 特別是 Free, 這裏也有一套 Google 的性能評價標準.
—— 這 2 個評價標準是本次的重點.
[Performance] —— 該指標的評價標準.
這是 Google 的即時指標. 僅表示打開 memory 這個頁面時, 手機的 RAM 情況.
Google 的理念仍然是: RAM 不使用就是浪費, 與其浪費, 不如用來做 Cached. 所以, 當 Cached 數量少於一定數值的時候, 就表示內存不足了. 在 Kernel Space, 使用 minfree 來做衡量 Cached 是否充足的指標; 在 User Space, 使用 memFactor 來做衡量 Cached 是否充足的指標.
memFactor是這樣定義的:
android/platform/frameworks/base/nougat-release/./services/core/java/com/android/server/am/ActivityManagerService.java |
// Now determine the memory trimming level of background processes. // Unfortunately we need to start at the back of the list to do this // properly. We only do this if the number of background apps we // are managing to keep around is less than half the maximum we desire; // if we are keeping a good number around, we'll let them use whatever // memory they want. final int numCachedAndEmpty = numCached + numEmpty; int memFactor; if (numCached <= ProcessList.TRIM_CACHED_APPS && numEmpty <= ProcessList.TRIM_EMPTY_APPS) { if (numCachedAndEmpty <= ProcessList.TRIM_CRITICAL_THRESHOLD) { memFactor = ProcessStats.ADJ_MEM_FACTOR_CRITICAL; } else if (numCachedAndEmpty <= ProcessList.TRIM_LOW_THRESHOLD) { memFactor = ProcessStats.ADJ_MEM_FACTOR_LOW; } else { memFactor = ProcessStats.ADJ_MEM_FACTOR_MODERATE; } } else { memFactor = ProcessStats.ADJ_MEM_FACTOR_NORMAL; } |
也就是:
Cached Process + Empty Process <= 3 個, 則認爲 Critical Memory
Cached Process + Empty Process <= 5 個, 則認爲 Low Memory
Cached Process <= 5 個, 而且 Empty Process <= 8 個, 則認爲 Moderate Memory
其他情況則認爲 Normal Memory
如果修改了 MAX_CACHED_APPS, 如上的 Threshold 也會被重新計算.
// The maximum number of cached processes we will keep around before killing them. // NOTE: this constant is *only* a control to not let us go too crazy with // keeping around processes on devices with large amounts of RAM. For devices that // are tighter on RAM, the out of memory killer is responsible for killing background // processes as RAM is needed, and we should *never* be relying on this limit to // kill them. Also note that this limit only applies to cached background processes; // we have no limit on the number of service, visible, foreground, or other such // processes and the number of those processes does not count against the cached // process limit. static final int MAX_CACHED_APPS = 32; |
[Free] —— 該指標的評價標準.
這是 Google 在 M 上加入的歷史指標. 該指標不僅僅計算了過去一段時間的 Free RAM 情況, 而且特別在算法上加入了 Safe RAM 對未來的手機性能做預測.
android/platform/packages/apps/Settings/nougat-release/./src/com/android/settings/applications/ProcStatsData.java |
if (memInfo.hiddenAppThreshold >= realFreeRam) { realUsedRam = freeRam; realFreeRam = 0; baseCacheRam = (long) realFreeRam; } else { realUsedRam += memInfo.hiddenAppThreshold; realFreeRam -= memInfo.hiddenAppThreshold; baseCacheRam = memInfo.hiddenAppThreshold; } |
在這裏有 2 個點需要注意:
memInfo.hiddenAppThreshold. 這是 ADJ=9 對應的水位. 也就是如下的 55296 x 4K = 216M
>adb shell cat /sys/module/lowmemorykiller/parameters/minfree 18432,23040,27648,32256,55296,80640 |
realFreeRam. 它包括 4 個部分, 分別是 Free + Cached + Buffer – Mapped.
如果統計得到的 realFreeRam 多於216M, 就在 realFreeRam 中扣除 216M, 獲得的就是 App 可以使用的 Free RAM.
如果統計得到的 realFreeRam 少於216M, 那麼表示 safe 空間已經被用完, App 可以使用的 Free RAM 就是 0.
會有這樣的聲音: 當 Free 爲 0 時, 手機還是可以正常運行啊? 這個數據是不是錯誤的?
Google 之所以設計這個算法, 是因爲有這樣一個事實: 當 LMK 殺到 ADJ<9 的進程後, 手機性能會開始下降. 一開始並不明顯, 但隨着使用時間的增加, 下降會越來越明顯, 越來越快.
所以 Google 使用 ADJ=9 的 minfree 做 Safe RAM, 是有價值並且很明智的.
對於使用者, 通過這個指標, 可以很簡單知道自己的操作習慣對手機性能的影響.
因爲這套指標會讓數據變得很不漂亮, 很多產品會排斥. 但是作爲 PM, 這套指標會讓你的產品變得更 safe.
爲了數據漂亮, 減少 minfree 會是一個做法. 但是另一個事實是, 調低水位, 會讓 RAM 變得緊張, 增加 swap, 從而使得手機變慢. 如果使用的 eMMC 性能並不好, 請不要這樣做. 增加 RAM, 減少預置功能, 積極做進程清理纔是王道.