我读了关于VSS / RSS / PSS / USS的解释：
这篇文章的目的是提供有助于从各种工具解释内存报告的信息，以便确定Linux进程和系统的真实内存使用情况。
Android有一个名为procrank（/ system / xbin / procrank）的工具，它按从高到低的顺序列出了Linux进程的内存使用情况。每个过程报告的大小为VSS，RSS，PSS和USS。
为了简化本说明书，存储器将以页面而不是字节表示。像我们这样的Linux系统在最低级别管理4096字节页面的内存。
VSS（从ps报告为VSZ）是进程的总可访问地址空间。此大小还包括可能不驻留在RAM中的内存，如已分配但未写入的malloc。 VSS很难用于确定进程的实际内存使用情况。
RSS是进程中实际保存在RAM中的总内存。 RSS可能会产生误导，因为它报告了该进程使用的所有共享库的总数，即使共享库仅加载到内存中一次，无论有多少进程使用它。 RSS不能准确表示单个进程的内存使用情况。
PSS与RSS的不同之处在于它报告了其共享库的比例大小，即如果三个进程都使用具有30个页面的共享库，则该库将仅为每个报告的PSS贡献10个页面。三个过程。 PSS是一个非常有用的数字，因为当系统中所有进程的PSS相加时，这是系统中总内存使用量的良好表示。当进程被终止时，为其PSS贡献的共享库将按比例分配给仍在使用该库的其余进程的PSS总计。这样，PSS可能会产生一些误导，因为当一个进程被终止时，PSS无法准确地表示返回整个系统的内存。
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
#
但是我找不到这篇文章的原文，我想知道这个解释是否准确。
答案 0 :(得分：21)
这听起来是正确的，也与这里的描述对齐：http://elinux.org/Android_Memory_Usage
从页面...