Android常见内存问题
原文链接：https://mp.weixin.qq.com/s/2MsEAR9pQfMr1Sfs7cPdWQ
1、内存泄露
- 单例（主要原因还是因为一般情况下单例都是全局的，有时候会引用一些实际生命周期比较短的变量，导致其无法释放）
- 静态变量（同样也是因为生命周期比较长）
- Handler内存泄露
- 匿名内部类（匿名内部类会引用外部类，导致无法释放，比如各种回调）
- 资源使用完未关闭（BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap）
2、图片分辨率相关
- 分辨率适配问题 同一资源图片在不同分辨率设备获取到的图片分辨率不一样，加载到内存可能存在较大的差异（可能几兆的差异）。
- bitmap缓存池 不同地方需要相同的图片公用一张图片可节约大量内存。
3、图片压缩
- inTargetDensity 表示要被画出来时的目标像素密度
- inSampleSize 这个值是一个int，当它小于1的时候，将会被当做1处理，如果大于1，那么就会按照比例（1 / inSampleSize）缩小bitmap的宽和高、降低分辨率，大于1时这个值将会被处置为2的倍数。
- inJustDecodeBounds 字面意思就可以理解就是只解析图片的边界，有时如果只是为了获取图片的大小就可以用这个，而不必直接加载整张图片。
- inPreferredConfig 默认会使用ARGB_8888,在这个模式下一个像素点将会占用4个byte,而对一些没有透明度要求或者图片质量要求不高的图片，可以使用RGB_565，一个像素只会占用2个byte，一下可以省下50%内存。
- inPurgeable和inInputShareable 这两个需要一起使用，BitmapFactory.java的源码里面有注释，大致意思是表示在系统内存不足时是否可以回收这个bitmap，有点类似软引用，但是实际在5.0以后这两个属性已经被忽略，因为系统认为回收后再解码实际会反而可能导致性能问题
4、缓存池大小
现在很多图片加载组件都不仅仅是使用软引用或者弱引用了，实际上类似Glide 默认使用的事LruCache，因为软引用 弱引用都比较难以控制，使用LruCache可以实现比较精细的控制，而默认缓存池设置太大了会导致浪费内存，设置小了又会导致图片经常被回收，所以需要根据每个App的情况，以及设备的分辨率，内存计算出一个比较合理的初始值，可以参考Glide的做法。
5、内存抖动
主要原因还是有因为大量小的对象频繁创建，导致内存碎片，从而当需要分配内存时，虽然总体上还是有剩余内存可分配，而由于这些内存不连续，导致无法分配，系统直接就返回OOM了。
6、其他 ：
- 常用数据结构优化 ArrayMap及SparseArray是android的系统API，是专门为移动设备而定制的。用于在一定情况下取代HashMap而达到节省内存的目的,具体性能见HashMap，ArrayMap，SparseArray源码分析及性能对比[10]，对于key为int的HashMap尽量使用SparceArray替代，大概可以省30%的内存，而对于其他类型，ArrayMap对内存的节省实际并不明显，10%左右，但是数据量在1000以上时，查找速度可能会变慢。
枚举 枚举变量可能比直接用int多使用2倍的内存。
ListView复用 这个大家都知道，getView里尽量复用conertView,同时因为getView会频繁调用，要避免频繁地生成对象
- 谨慎使用多进程 现在很多App都不是单进程，为了保活，或者提高稳定性都会进行一些进程拆分，而实际上即使是空进程也会占用内存(1M左右)，对于使用完的进程，服务都要及时进行回收。
- 尽量使用系统资源 系统组件，图片甚至控件的id。
- 减少view的层级 对于可以 延迟初始化的页面，使用viewstub。
- 数据相关 序列化数据使用protobuf可以比xml省30%内存，慎用shareprefercnce，因为对于同一个sp，会将整个xml文件载入内存，有时候为了读一个配置，就会将几百k的数据读进内存，数据库字段尽量精简，只读取所需字段。
- dex优化，代码优化，谨慎使用外部库 有人觉得代码多少于内存没有关系，实际会有那么点关系，现在稍微大一点的项目动辄就是百万行代码以上，多dex也是常态，不仅占用rom空间，实际上运行的时候需要加载dex也是会占用内存的(几M)，有时候为了使用一些库里的某个功能函数就引入了整个庞大的库，此时可以考虑抽取必要部分，开启proguard优化代码，使用Facebook redex使用优化dex(好像有不少坑)。