一个APP通常就是一个进程对应一个虚拟机
获取内存大小：
GC只在Heap剩余空间不足的时候才触发垃圾回收
GC触发时，所有的线程都是会被暂停的
每个App分配的内存限制，随不同设备而不同
吃内存大户：图片
App内存优化方法：1:数据结构优化 2：对象复用
数据结构优化：
频繁字符串拼接用StringBuillder(字符串通过+的方式拼接，会产生中间字符串内存块，这些都是没用的并且更耗时更低效)！
ArrayMap,SparseArray替换HashMap(ArrayMap,SparseArray效率更高，内存更小，使用方法和HashMap一样的,HashMap一个entry需要额外占用的32B)
内存抖动（突然间生成很多对象，变量或内存空间后用了没多久又不用了，如此反复就是内存抖动，内存像波浪形一会高一会低）
再小的class耗费0.5KB（尽量复用class）
对象复用：
复用系统自带的资源
ListView/GridView的ConvertView复用
避免在OnDraw方法里面执行对象的创建（在OnDraw中对象的变更会重绘View）
避免内存泄漏：
内存泄漏会导致剩余可用的Heao越来越少，频繁触发GC
尤其Activity泄漏（如果有耗时操作为执行完，则GC无法回收还在被引用的资源）
用Application Context而不是Activity Context
注意Cursor对象是否及时关闭（数据库操作时）
强引用和软引用的意义：
优化OOM问题的方法：
注意临时BitMap对象的及时回收
避免BitMap的浪费
Try catch某些大内存分配的操作
加载BitMap:缩放比例，解码格式，局部加载
OOM绝大部分发生在图片
