dumpsys meminfo
唯讀哪些行程最吃記憶體，量的是 PSS（按比例分攤的用量）。
- 指令
- adb shell dumpsys meminfo
- 指令
- 系統服務（dumpsys）
- 風險
- 唯讀
語法
dumpsys meminfo範例
dumpsys meminfo摘要段落：各行程的用量與整機 RAM 總量。
top -b -n 1 -m 10比較便宜，而且給的是常駐用量而不是分攤後的用量。
輸出怎麼讀
輸出範例
Applications Memory Usage (in Kilobytes):
Uptime: 5178721 Realtime: 5178721
Total PSS by process:
353,876K: com.google.android.gms.persistent (pid 3062 / activities)
215,668K: system (pid 1650)
94,952K: surfaceflinger (pid 842)每一列已經是由大到小排好的，數字是以逗號分組的千位元組——`1,234,567K` 是一個數字，遇到第一個逗號就停下來的讀法，會把一個 1.2 GB 的行程報成 1 MB。PSS 會把共享分頁除以映射它的行程數，所以這些數字加起來接近真實的占用量，而 RSS 不會。
輸出欄位
| 欄位 | 意義 |
|---|---|
| N,NNNK: | 以千位元組表示的 PSS，用逗號分組。 |
| (pid N / activities) | 行程 id 與一個修飾詞——`activities`、`services`、`cached`。這是你分辨一個活著的 app 與一個抱著同樣記憶體的快取殘骸的方法。 |
| Total RAM / Free RAM / Used RAM | 整機的總量，同樣是以逗號分組的千位元組。 |
需要什麼權限
兩個權限，而且都已經在手上：記憶體的 binder 用字面標籤 `meminfo` 呼叫 `DumpUtils.checkDumpAndUsageStatsPermission`，所以被拒絕時指名的是那個小寫的字而不是某個類別，而它要的是 `android.permission.DUMP` 加上 `android.permission.PACKAGE_USAGE_STATS`。Shell 的資訊清單兩個都宣告了，而 usage stats 那條路在碰到 app-op 之前就對 `SHELL_UID` 放行，所以一條授權過的 `adb` 連線就夠——不用 root、不用 `adb root`，也不用去設定裡授予「使用情況存取權」。你要規劃的是成本而不是權限，而且它比「逐行程走一遍」聽起來更糟。這個 binder 的 `dump` 把整份 dump 包在 `enableFreezer(false)` … `enableFreezer(true)` 之間，所以只要這個指令還在跑，**裝置上每一個被凍結的快取 app 都是解凍的**，要等它結束才會被凍回去。在那之上，每一個活著的行程都會收到一次 binder 交易，並自己走過自己的記憶體映射算出自己的數字。所以把它掛在計時器上不只是在量這台手機，而是在改變被量的那個東西：原本不花成本的快取 app 醒過來，而你正在追的 CPU 尖峰裡多了一份你自己工具的貢獻。Android System Monitor 就是為了這個把它放在一個開關後面、用很慢的頻率送出；常駐記憶體夠用的時候，`top` 才是便宜的答案。
失敗訊息對照
| 訊息 | 意義 |
|---|---|
| Permission Denial: can't dump meminfo from from pid=4821, uid=10231 due to missing android.permission.DUMP permission | 標籤是光溜溜的 `meminfo` 這個字，因為那就是記憶體 binder 傳進去的字面字串，而重複的 `from from` 是 AOSP 原文。它寫在**標準輸出**、取代整張表，所以一個掃 `K:` 列的自動化讀取器看到的是一台沒有行程的裝置，而不是一次被拒絕的呼叫。 |
| *** SERVICE 'meminfo' DUMP TIMEOUT (10000ms) EXPIRED *** | 十秒是 `dumpsys` 的預設，而在負載高的手機上這是最容易撞到的一份 dump，因為那個期限涵蓋了每個行程自己走映射的時間。你留下的是一張被截斷的表，而由於列是由大到小排的，不見的尾巴是小行程——所以被截斷的 dump 還是回答得了「誰最大」，但永遠不能加總成整機的總量。 |
| Unknown argument: -x; use -h for help | 記憶體 dump 的參數迴圈不認得的選項。它把這行印在標準輸出，然後**繼續**用它看懂的那些參數跑下去，而不是中止，所以打錯一個旗標得到的是一份形狀不同的完整 dump 而不是錯誤——這裡的失敗方式，是一個對你沒問過的問題給出的合理答案。 |
| Can't find service: meminfo | 由 `dumpsys` 這支程式印到標準錯誤：service manager 裡沒有 `meminfo` 這一項，這在開機完成前以及 `system_server` 重啟之後都很正常。它沒有向服務要求任何東西，所以和一張空表不是同一回事——而且沒帶 `2>&1` 收集的話它是看不見的。 |
版本與廠商注意事項
- 這是你能向一台手機要求的最昂貴的東西。它會走過每一個執行中的行程、對每一個送出 binder 呼叫，而每個行程再各自走過自己的記憶體映射來算出自己的數字——在你正拿來觀察 CPU 尖峰的那台裝置上，花掉幾百毫秒到幾秒的實際 CPU。不要把它放在一秒一次的計時器上。
- PSS 與 RSS 是不同的量，絕對不能當成同一個來呈現；後者用 `top` 就能免費拿到。
- 在低記憶體組態上 PSS 的收集是關閉的，所以那個段落的標題可能改成 RSS。
- 從 tag android-11.0.0_r1 到 android-15.0.0_r1 的每一版 AOSP，都會在 PSS 段落之前先印一段 RSS——`Total RSS by process:` 然後 `Total PSS by process:`——所以 dump 最上面出現 RSS 標題是正常的排版。
- 這份 dump 在整個執行期間會把每一個被凍結的快取 app 解凍，結束時才凍回去，所以把它掛在計時器上，會改變它正在回報的那張記憶體與 CPU 的圖。
這個我們有 UI
Android System Monitor 會透過 USB 執行這個指令並解析回應——只要 Chromium 系瀏覽器，不必安裝 SDK，也不會上傳任何東西。
相關指令
和 dumpsys meminfo 會在同一次作業裡出現的指令。
| 指令 | 做什麼 |
|---|---|
| top | 一次性的行程表：CPU 占用、記憶體、狀態與指令列。 |
| am force-stop | 殺掉屬於某個 app 的所有行程與服務。 |
| dumpsys battery | 電池服務目前的狀態：電量、充電狀態、健康度、電壓與溫度。 |
其他系統服務（dumpsys）指令
| 指令 | 做什麼 |
|---|---|
| dumpsys diskstats | 每個分割區的剩餘空間、一次磁碟寫入延遲的實測，以及一份快取起來的各 app 空間用量。 |
| dumpsys thermalservice | 手機是不是正在因為溫度而降速，以及硬體層回報的每一個溫區，單位是攝氏。 |
| dumpsys sensorservice | 手機上的每一個感測器，含廠商、type、取樣率與批次能力，以及一段近期讀數的緩衝。 |
| dumpsys package | 套件管理員知道的一切：版本、路徑、flags、安裝來源，以及每個使用者的狀態。 |
| dumpsys activity activities | 現在哪個 app 在前景，以及它背後的 task 與 stack 結構。 |
| dumpsys dropbox | 平台用來存放當機、ANR 與 tombstone 的環形緩衝——這是不用 root 讀 ANR 追蹤的方法。 |
這些行為是在撰寫 Web ADB 工具背後的解析程式時，對照 AOSP、toybox 與核心原始碼查證的。真的會因 Android 版本或廠牌而異的地方，這一頁會直接說明，而不是給你一個在半數手機上都是錯的數字。