Android記憶體之VSS RSS PSS USS

2021-07-17 04:26:42 字數 2590 閱讀 3829

一般來說記憶體占用大小有如下規律:vss >= rss >= pss >= uss

本篇文章的目的是為了幫助理解從多種工具匯出的關於linux進**實占用記憶體的報告。

android 有乙個叫做procrank(/system/xbin/procrank)的工具,它可以從高到低地列出linux程序的記憶體佔用量 。 每個程序按大小可以分為 vss, rss, pss, 和uss.

為了簡化描述,以下記憶體將以「頁」的形式來表示,而不是「位元組」。像我們的linux系統記憶體管理中最低級別的頁有4096 位元組。

vss(reported as vsz from ps) 是乙個程序總共可訪問的位址空間。其大小還包括了可能不在ram中的記憶體(比如雖然malloc分配了空間,但尚未寫入)。 vss 很少被用於判斷乙個程序的真實記憶體使用量。

rss是乙個程序在ram中真實儲存的總記憶體。但是rss還是可能會造成誤導,因為它僅僅表示該程序所使用的所有共享庫的大小,它不管有多少個程序使用該共享庫,該共享庫僅被載入到記憶體一次。

所以rss並不能準確反映單程序的記憶體占用情況。 

pss與rss不同,它按比例表示使用的共享庫, 例如:如果有三個程序都使用了乙個共享庫,共占用了30頁記憶體。那麼pss將認為每個程序分別占用該共享庫10頁的大小。 pss是非常有用的資料,因為系統中所有程序的pss都相加的話,就剛好反映了系統中的總共占用的記憶體。 而當乙個程序被銷毀之後, 其占用的共享庫那部分比例的pss,將會再次按比例分配給餘下使用該庫的程序。這樣pss可能會造成一點的誤導,因為當乙個程序被銷毀後,pss不能準確地表示返回給全域性系統的記憶體(the memory returned to the overall system)。

uss是乙個程序所占用的私有記憶體。即該程序獨佔的記憶體。

uss是非常非常有用的資料,因為它反映了執行乙個特定進**實的邊際成本(增量成本)。當乙個程序被銷毀後,uss是真實返回給系統的記憶體。當程序中存在乙個可疑的記憶體洩露時,uss是最佳觀察資料。

如果系統支援python, 有乙個叫做smem的工具,它能報告記憶體以上分類的統計資訊。 

# procrank

procrank

pid 	vss 	rss 	pss 	uss 	cmdline

481 31536k 30936k 14337k 9956k system_server

475 26128k 26128k 10046k 5992k zygote

526 25108k 25108k 9225k 5384k android.process.acore

523 22388k 22388k 7166k 3432k com.android.phone

574 21632k 21632k 6109k 2468k com.android.settings

521 20816k 20816k 6050k 2776k jp.co.omronsoft.openwnn

474 3304k 3304k 1097k 624k /system/bin/mediaserver

37 304k 304k 289k 288k /sbin/adbd

29 720k 720k 261k 212k /system/bin/rild

601 412k 412k 225k 216k procrank

1 204k 204k 185k 184k /init

35 388k 388k 182k 172k /system/bin/qemud

284 384k 384k 160k 148k top

27 376k 376k 148k 136k /system/bin/vold

261 332k 332k 123k 112k logcat

33 396k 396k 105k 80k /system/bin/keystore

32 316k 316k 100k 88k /system/bin/installd

269 328k 328k 95k 72k /system/bin/sh

26 280k 280k 93k 84k /system/bin/servicemanager

45 304k 304k 91k 80k /system/bin/qemu-props

34 324k 324k 91k 68k /system/bin/sh

260 324k 324k 91k 68k /system/bin/sh

600 324k 324k 91k 68k /system/bin/sh

25 308k 308k 88k 68k /system/bin/sh

28 232k 232k 67k 60k /system/bin/debuggerd

#

Android記憶體優化之LeakCanary

leakcanary是檢查記憶體洩漏的神器 雖然我沒檢查出來啥記憶體洩漏 是我 寫的ok還是我的開啟方式不正確?不管怎麼說 是必要的工作 學習自依賴dependenciespublic class extends private refwatcher refwatcher override publ...

Android記憶體優化之磁碟快取

基於以上的缺點有時候又須要第二種快取,那就是磁碟快取。大家應該都用過新聞client,非常多都有離線功能,功能的實現就是磁碟快取。在android中用到的磁碟快取大多都是基於disklrucache實現的,詳細怎麼使用呢?open 方法接收四個引數。第乙個引數是資料的快取檔案位址,第二個引數是當前應...

Android記憶體管理之LMK和OOM

oom out of memory lom low on memory 記憶體使用情況檢視 procrank dumpsys meminfo 一 lmk low memory killer android kernel 會定時執行一次檢查,殺死一些程序,釋放掉記憶體,採用的就是low memory ...