内存泄露会产生的问题：

1：内存泄露造成的第一个问题是异常，包括内存分配失败，OOM。

2：内存泄露造成的第二个问题是卡顿。导致频繁的GC。

常见的内存泄露

静态对象，监听器，广播，webview，this$0，线程，定时器，handler，系统textline，输入法

检测工具

leakcanary（注册了ActivityLifecycleCallbacks回调接口，如果想dump后再做处理，有一个after回调接口）

内存占用的两个误区：

1：内存占用越少越好。

应该是当内存充足的时候占用多一点，内存少的时候占用少一些。

android3.0之前，bitmap对象放在堆中，像素数据放在native中，native中的内存完全依赖finalize函数回调。

android3.0-android7.0，bitmap对象和数据都放在堆中，bitmap会随着对象回收，但是它是消耗大户，似乎不是那么好。

android8.0使用辅助回收native内存机制，吧像素数据放到了native内存中。同时可以做到快速释放。

2：Native内存不用管

 这是错的

内存优化的探讨

a：设备分级

内存优化首先要根据设备环境来综合考虑，类似device-year-class会根据手机内存，CPU核心数，频率决定哪一个年份，来判断是否使用动画什么的。

b：缓存管理

需要一套统一的缓存管理机制，可以适当的使用内存。

c：进程模型

一个空进程也会占用10M左右的内存，所以对低端机，要减少进程数。

d：安装包大小

安装包太大，很难在低端机上使用，所以要有轻量版本。

e：bitmap优化

图片按需加载，统一图片加载库，防止图片重复加载，.9图片

把bitmap放到native内存，不代表图片问题解决了，只是提高了系统内存利用率。我们应该统一图片库，

图片统一监控，比如大图片监控（超过view的宽高的要注意），重复图片监控（hash值一样的重复），图片总内存监控。

f：webview有内存占用过多的情况，可以使用单独的进程。

内存泄露

内存泄露两种情况，一种是同一个对象泄漏，一种是每次都泄漏一个对象，就会有成千上万个对象。

gc的类型

GC_FOR_ALLOC

当堆内存不够的时候容易被触发，尤其是new一个对象的时候，很容易被触发到，所以如果要加速启动，可以提高dalvik.vm.heapstartsize的值，这样在启动过程中可以减少GC_FOR_ALLOC的次数。注意这个触发是以同步的方式进行的。如果GC后仍然没有空间，则堆进行扩张

GC_EXPLICIT

这个gc是被可以调用的，比如system.gc, 一般gc线程的优先级比较低，所以这个垃圾回收的过程不一定会马上触发， 千万不要认为调用了system.gc，内存的情况就能有所好转

GC_CONCURRENT

当分配的对象大小超过384K时触发，注意这是以异步的方式进行回收的.如果发现大量反复的Concurrent GC出现，说明系统中可能一直有大于384K的对象被分配，而这些往往是一些临时对象，被反复触发了。给到我们的暗示是：对象的复用不够。

内存抖动优化

字符串拼接优化，资源重用，减少不必要不合理对象（ondraw，getview中减少申请），使用合理数据格式（sparsearray）

测试工具

systrace mat leakcarary