1、内存不足会导致什么问题？
内存里可以细分为 VSS 虚拟内存、PSS物理内存 以及堆内存；这三个内存不足都容易导致2个典型问题：
（1）卡顿；
内存不足时，会导致系统频繁GC , 由于java 是自动管理内存回收的，所以每次GC都需要遍历所有对象引用；由于内存不足，所以分配新内存与回收旧内存就会变得举步维艰；试想下，运行过程中，内存经常告警，系统只能频繁GC来检查哪些对象可以被回收，而每次GC必然会耗费一些时间，等清理完毕后才有新的空间出来，程序才得以正常运行；
（2）异常：
这里的异常包括OOM ， 当申请内存过大，超过系统对每个app进程分配的最大值时（具体在dalvik.vm.heapsize里设置），最后就会抛出内存溢出的异常 OOM；
如果真的是RAM 内存不足，系统经过GC也没有办法提供足够的空间，就会触发Android的 LMK 机制（Low Memory Kill）; 系统会按照进程优先级，一个个去杀死运行中的进程，知道内存降下来为止。
2、图片内存分配的升级优化
我们知道，Android中堆内存按照 native 与 java层的使用方式不同，可以分为 native 内存（由c/c++ new对象时分配）以及 java 堆内存（由java new 对象时分配）；
如上面所说：
在 Android 3.0 之前，Bitmap 对象基本信息（宽度高度、缩放等）放在Java堆内存中，而把其中占比例最大的像素数据放到了native 堆内存，但这样有个比较大的缺点，就是生命周期不可控，需要用户自己去回收，不然有泄漏；于是，为了做到对象回收时，内存数据也被回收，于是在 3.0 - 7.0 ，google 把bitmap 全部放到 java 堆内存上了，然而，前面说到，Android 对每个app 的java 堆内存有限制的： 以亲儿子 nexus 6p 举例：
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=192m
dalvik.vm.heapsize=512m
如果不在APP的 mainfest 里设置 largeheap = true，那么当app 的堆内存增长到192 M 就会报OOM 的异常了，设置开启后才是512M ，但也只是512M，哪怕6p 这个手机此时RAM剩余内存还有2G , 依然会OOM， 因为这是单个APP 的上限大小。
所以，尽管近年来单个app 的内存使用大小已经逐渐从16M 提升到512M ，但使用不当，依然有可能造成OOM；
所以，google 在 8.0 版本上有做了一层优化：引入一个NativeAllocationRegistry 这个辅助native回收内存的机制，从而把bitmap 放心地放到了native 层，也不用再担心出现2.3 版本的回收不及时问题，也解决7.0 以前的OOM 问题；
3、如何分析内存分配
未完待续
