内存泄露会产生的问题：
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
网友评论