有道云笔记 Android内存监控
http://note.youdao.com/noteshare?id=6733e5300c8a4d06fa3c41a4f03f5c7b
内存总量：/proc/meminfo
adb shelldumpsys meminfoYOUR-PACKAGE-NAME
VSS – Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）
RSS – Resident Set Size 实际使用物理内存（包含共享库占用的内存）
PSS – Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）
USS – Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）
USS 是针对某个进程开始有可疑内存泄露的情况， 是一个程序启动了会产生的虚拟内存，一旦这个程序进程杀掉就会释放！
Item全称含义等价
USSUnique Set Size物理内存进程独占的内存
PSSProportional Set Size物理内存PSS= USS+ 按比例包含共享库
RSSResident Set Size物理内存RSS= USS+ 包含共享库
VSSVirtual Set Size虚拟内存VSS= RSS+ 未分配实际物理内存
https://testerhome.com/topics/2572
内存的采集：
Android的内存的采集这边介绍三种方式：
1，通过Dumpsys 来取值
adb shell dumpsys meminfo ( pid)
adb shell dumpsys meminfo pakagename or Pid
有如下两种显示方式：
正确的观点：
大家都知道，过多地创建bitmap会导致OOM异常，且native heapsize不受dalvik限制，所以可以得出结论：
Bitmap只能是分配在dalvik heap上的，因为只有这样才能解释bitmap容易导致OOM。
在Android2.3和以前的版本，bitmap对象的像素数据都是分配在native heap中的，所以我们在调试过程中这部分内存是在java heap中看不到的，不过在android 3.0之后，bitmap对象就直接分配在java heap上了，这样便于调试和管理。因此在3.0之后我们可以复用bitmap的内存，而不必回收它，不过新的bitmap对象要大小和原来的一样，到了android 4.4之后，就只要高宽不超过原来的就行了。Bitmap是分配在dalvik heap上的，只有这样才能解释bitmap容易导致OOM。
最大内存限制只是限Dalvik heap 的大小
#查看单个应用程序最大内存限制 对于 OOM 的监测很重要！！adb shell getprop|grepheapgrowthlimit
而meminfo 里面的dalvik heap size 的最大值若果超出了128M 那就很可能会发生OOM
2.使用ActivityManager
1. ActivityManager.MemoryInfo :
availMem:表示系统剩余内存
lowMemory：它是boolean值，表示系统是否处于低内存运行
hreshold：它表示当系统剩余内存低于好多时就看成低内存运行
我用过以上三种最多，其实Top 也可以 还有很多方法都可以。
2.Debug.MemoryInfo
dalvikPrivateDirty 进程占用内存
3.android 每个 app 内存限制大小
activityManager.getMemoryClass();
// OOM 之前
Runtime.getRuntime().addShutdownHook();
leakcanary 原理