内存优化方法总结

一. 参考

1. Android 内存优化总结&实践
   https://mp.weixin.qq.com/s/2MsEAR9pQfMr1Sfs7cPdWQ
2. Manage your app’s memory
   https://developer.android.com/topic/performance/memory#remove

二. 总结

1. 图片:
   a. 一些没必要背景图片和产品设计商量后改成了纯色的背景;
   b. 将一些比较小要求不高的图的格式从RGB8888改成了RGB565;一个像素所占的内存由4个字节降到了2个字节

参考:Android 开发绕不过的坑：你的 Bitmap 究竟占多大内存？
https://mp.weixin.qq.com/s/GkPrmlNm8p3fkeh4vo3Htg

2. 使用为移动平台优化的数据结构

比如在少量数据情况下,用SparseArray替换HashMap

3. 移除一些只用很少功能却很大的库,改为自己实现该功能

比如在上传头像图片这个很小的功能点上用了一个很大的第三方ugc库就可以
删掉,改为自己用原生接口实现.

4. 分析解决内存泄露问题

使用LeakCanary检测出泄露的一些Activity然后进行优化.
(注意,也可以使用Android Profiler 去分析 或去 dump hprof
也可以使用MAT 去对比分析hprof
参考: https://blog.csdn.net/ly969434341/article/details/116793851)

(0) 常见主要泄露的原因有

(a) 非静态内部类持有外部类的引用
比如非静态的Handler类持有了Activity的引用

(b) 匿名内存持有外部类的引用
比如注册new的一些Callback回调类也会持有Activity的引用

参考:https://blog.csdn.net/ly969434341/article/details/116742379

(1) 主要泄露的场景有

(a) 静态变量持有了含有Activity的结构体
(b) 在AsyncTask的线程中直接使用了Activity,没有去使用弱引用
(c ) 内部类持有了Activity,但是其生命周期长与Activity,需要
在Activity的onDestroy时及时去释放相关的引用和cancel相关的任务.

参考:https://blog.csdn.net/ly969434341/article/details/116935530

(2) LeakCanary原理
( a ) 监听Activity的Destroy,获取Activity应该被回收的时机
( b ) 检测该Activity对象是否被泄露;
主要方法是对该Activity建立一个弱引用,并提供一个引用队列.
当该Activity被gc回收的时候如果只有这个弱引用,这个弱引用会被放到引用队列中供引用队列处理;
然后通过判断引用队列是否有该Activity判断是否泄露,(不存在则泄露)
( c ) 若泄露,在堆中查找出强引用关系,输出.

参考:
LeakCanary工作原理笔记
https://blog.csdn.net/ly969434341/article/details/89415667