进程占用的内存可以有以下这些类型：
- 自身的代码
- 共享库的代码
- 运行过程分配的堆和栈
- 通过mmap映射的磁盘文件内容
1. 虚拟内存与物理内存
这里要区分两个概念，虚拟内存和物理内存。物理内存对于进程来说是透明的，进程直接操作的是虚拟内存。而数据和代码是存放在真实的物理内存的，之所以进程在虚拟内存中寻址可以获取数据，是因为虚拟内存与物理内存存在着映射关系。
当我们的进程向系统申请内存时，比如通过malloc方法，得到的其实是虚拟内存，如果进程没有使用这些虚拟内存，那么它们是不会和物理内存关联起来的。比如如果我们malloc 10MB的内存，但是只用了一个byte的，那么进程实际得到的只有一个页的物理内存，也就是4096byte的内存空间。当物理内存被换出到磁盘（swap out），虚拟内存对应的地址还是有效的，如果寻址到这些地址，对应的物理内存就会被换入到内存（swap in）。
虚拟内存是连续的，而物理内存却不一定。
2. 共享的内存
从进程自身的角度看，虚拟内存是进程独立的，所有内存都是私有的，包括自身代码、共享库、堆栈等，它不用关心共享内存的事情。但实际上在物理内存的层面，很多东西是可以共享的，比如共享的代码库（.so）、自身代码甚至是自身运行时私有的堆栈内存。
2.1 共享库
同一个共享库的代码在物理内存中只会存在一份，这块内存会映射到不同进程的虚拟内存中，对各个进程来说，就像是自己私有的内存一样，而对于系统来说，则是节省了内存的资源。
2.2 进程自身的代码
同样，同一份代码运行起来的多个进程是共享这些代码的内存的，因为可执行代码类型的内存页是只读的（除非是debugger模式），没有必要复制多份，因此在实际场景中，当我们启动一个大应用程序后，再启动它的另一个实例，第二次启动会快很多，这就是因为其代码已经在内存中了，无需再重新加载一遍。
2.3 进程自身的私有内存
如果从一个进程fork出一个子进程，那么父进程的私有内存（比如堆栈）则会与子进程共享，但会被标记成（copy-on-write），意思是如果两个进程都没有修改这些内存页，那么这些内存页在两个进程间就是共享的，但如果某个进程要修改某个页了，那么这个页就会先被复制一份，再被修改。
3. 进程内存的数据统计
在OSX系统，可以运行以下命令来查看某个进程内每一块内存的类型（mapped file、Stack内存、malloc内存、代码的__DATA或者__TEXT段等），以及大小、是否共享或者copy-on-write等。
sudo vmmap <pid>
如果只是关注RAM的内存，可以加上-resident参数：
sudo vmmap -resident <pid>
比如指定Firefox进程，有如下输出：
可以看到，Firefox进程的代码和库代码加载了108MB__TEXT段数据，字体支持（ATS）需要33MB内存，但只有2.5MB真正加载在物理内存中，它通过MALLOC申请了256MB内存，并且247MB在物理内存中，它有14MB用于栈内存，但只用了248KB。
4. 进程内存大小的度量方法
提到进程消耗的内存大小，我们或多或少听到VSZ、RSS、PSS，那么它们代表的是什么呢？有了上述的知识背景，现在来分析或许能更加清晰。
4.1 VSZ（Virtual Memory Size）
指的是虚拟内存的大小，进程运行理论需要的内存大小，用这个来表示进程消耗了多少内存其实没有太大的意义，因为它包含了未被加载到实际内存中的空间。举个例子，假如有个文本编辑器叫做emacs，它有个编辑xml文件的功能，但这个功能比较少被用到，因为用户一般情况下是编辑普通的文本，因此没有必要一启动就把这个功能的代码加载到内存中。
除非用户真实用到某个页，否则系统不会把这个页加载到内存，这其实称为demand paging feature。
来看一下上面这个例子中虚拟内存工作的流程。首先启动应用程序，系统为进程分配了运行编辑xml所需要的虚拟内存，但并没有真正把这些功能所在的页加载到物理内存。当进程真正调用到编辑xml的功能，CPU上的MMU模块将会告诉系统，对应的虚拟内存页发生缺页了，那么系统就会暂停运行中的进程，把对应的页加载到内存，再把这些物理内存页映射到虚拟内存上，最后让应用程序从暂停的地方继续执行。对于进程来说，它是不知道自己被暂停了的，它只需要简单地认为对应的功能已经加载在虚拟内存上了，并使用它就好了。
虚拟内存描述了进程运行时所需要的总内存大小，包括了那些还没有被加载到实际内存中的代码和数据。
4.2 RSS（Resident Set Size）
RSS表示了进程中真正被加载到物理内存中的页的大小。但是用它来表示进程占用的内存大小也不太合适，因为还有个共享代码库的概念（Shared Libraries）。
比如libxml2.so这个程序库，有多个进程会用到它，而系统在物理内存只会加载一遍这个代码库，然后这块物理内存会被映射到不同进程的虚拟内存空间中，对于单独的进程来说，就像是这个库只加载在自己的虚拟内存中一样，不需要关心它是否与其它进程共享。
而进程的RSS是包含这块共享库的内存空间的，因此如果简单把系统中所有进程的RSS相加的话，结果是比系统总的内存大的，因为共享库占的内存被计算了多遍。
4.3 PSS（Proportional Set Size）
PSS在VSS的基础上，将共享库的内存按使用的进程个数平均分成多份。假如有N个进程使用libxml2.so这个库，这个库加载了200K代码在内存中，那么每个进程的PSS值中有（200 / N）K 的大小是这个共享库贡献的。
如果把系统中所有进程的PSS值加起来，就等于系统所有进程占用的内存总大小。
但是PSS并不是在所有的Linux系统中都有提供的，比如ps命令中就没有PSS值，而Android的adb shell dumpsys meminfo <pid>命令就可以看到进程的PSS值。
4.4 总结一下三种度量方法
如果要度量进程占用的内存大小，较好的选择是使用PSS，用RSS也行，不过要注意有些内存是和别的进程共享的。
再举个例子总结一下前面三个概念，比如一个进程有500K的代码并且链接了2500K的共享库，然后有200K的堆栈分配。其中有400K自身的代码、1000K的共享库以100K的堆栈内存被加载在实际内存（RAM）中，并且系统中一共有两个进程用了同样的共享库。那么：
VSZ：500K + 2500K + 200K = 3200K
RSS：400K + 1000K + 100K = 1500K
PSS：400K + (1000K / 2) + 100K = 1000K
5. 命令执行结果
在Android的adb shell中执行ps命令的结果：
- 执行
adb shell ps：
- 执行
adb shell dumpsys meminfo com.android.calendar：
