OOM总结

本文主要信息是来自互联网，我只是自己做了一点总结和摘要。

OOM发生的原因

简单的说通过不同的内存分配方式对不同的对象进行操作，会因为android系统版本的差异而产生不同的行为。主要是2.0和4.0有较大的变化。

在2.x系统中，dalvik allocated  + external allocated + 新分配的大小>= getMemoryClass() 就会发生OOM。

在4.x系统中，废除了external计数器，类似Bitmap的分配改到了Dalvik的java Heap 中申请，只要allocate + 新分配的内存>=getMemoryClass就会发生OOM。

如何避免OOM

根据上面的介绍，避免OOM就是降低内存占用，和内存对象的重复利用，避免对象内存泄露，优化内存使用策略。

1. 减小对象的内存占用

1）尽可能的使用android系统特有的对象，比如可以用arrayMap 和 SparseArray 代替hasMap，hasMap需要一个额外的对象来记录Mapping操作。SparseArray 更加高效，避免了对key和value的自动装箱和解箱。

2）避免使用Enum枚举，在android 官方文档里面就提到枚举通常需要更多的内存比 static constants。

3） 减少Bitmap对象的内存占用，一般情况下通常有2个措施：

　　inSampleSize，缩放比例，在把图片载入内存之前，我们就先计算一个合适的缩放比例

　　decode format， 选择合适的解码格式ARGB_8888,每个像素点占32位，ARGB_4444每个像素点占16位，RGB_565每个像素点占16位，ALPHA_8只有透明度，没有颜色。8位一个字节，所以在图片过大的时候，适当选择16位的解码格式，可以减少一半的图片内存占用。

4）可以使用更小的图片，特别是在listview中，可以用较小的图片显示，只用在用户需要看大图的时候，才显示大图。

2. 内存对象的重复使用

1）android 系统本身内置了很多资源，比如字符串，颜色，图片，动画，样式等，这些资源可以直接使用，但是不足之处是不同的android版本之间会有差异。

2） 注意在listview等对convertView的重复使用

3） Bitmap对象的复用，在listview等显示大量图片的控件里，需要使用LRU的机制来缓存处理好的bitmap。

利用inBitmap的高级特性提高android系统在bitmap分配与释放上的执行效率，在android 3.0和4.0上存在一些使用限制，inBitmap可以通知Bitmap解码去尝试使用已经存在的内存区域，这样就达到了图片内存重用的效果。InBitmap的使用限制如下：

1. 在SDK11-18之间，重用的Bitmap大小必须一致，在19以后，新申请的bitmap必须小于或者等于已经赋值过的Bitmap大小。

2. 新申请的bitmap必须和旧的bitmap具有相同的解码格式。不过可以通过建立bitmap对象池来解决这个问题。

4）避免在onDraw里面执行对象创建，因为onDraw会被频繁调用，这样就频繁执行对象创建，而迅速增加内存使用，频繁的GC，导致内存抖动。

5）使用StringBuilder代替String做字符的拼接

3 避免内存泄露

开源控件LeakCanary开源控件，可以很好的帮助我们发现内存泄露情况。

 

1）注意Activity的泄露，这个是最严重的问题，一般有2种情况会导致内存泄露：

1.内部类引用导致Activity泄露：最典型的是Handler导致的，如果handler中有延迟的任务或者等待执行的任务队列过长，都有可能造成Activity泄露，解决方式： 在退出UI之前，执行remove Handler消息队列中的消息和runnable对象，或者使用static + weakReference的方式断开Handler与Activity之间存在的引用关系的目的。

2. Activity Context被传递到其他实体中，也可能导致自身被引用而发生泄露。

2）考虑使用Application Context而不是Activity Context

3）注意临时bitmap对象的及时回收，因为在创建一个临时的相对较大的bitmap对象，在进过变换后得到新的bitmap对象，那么应该尽快回收原始的bitmap，释放空间，尽量不要使用createBitmap方法。

4）注意监听器的注销，特别是手动添加的监听器要及时remove。

5）注意缓存容易中的对象泄露，不要的缓存应该立刻释放。

6）webview泄露，不同版本，不同厂商出货的ROM里面webview都存在很大差异，所以最好是webview开启另外一个线程，桶AIDL与住线程通信，根据业务需要适当的销毁进程。

7）Cursor对象及时关闭

4 内存使用策略优化：

1）谨慎使用large heap，在一些特殊情况下可以通过mainfest的application 标签添加largHeap=true来声明一个更大heap空间，但是由于总heap空间不变，会导致系统性能大打折扣。而且有的机器就不允许这样的操作。

2）综合考虑设备内存阀值与其他因素，设计合适的缓存大小。

3）onLowMemory 与 onTrimMemory

4） 资源文件需要选择合适的文件存放，不需要被拉伸的图片需要放到assets活nodpi目录下

5）try catch 某些大内存的分配操作，对于可能发生OOM的代码，可以考虑在catch里面尝试一次降级内存的操作。

6）谨慎使用static对象，因为static对象的生命周期过长。

7）特别留意单例对象中不合理的持有，因为单例的生命周期和应用保持一致，使用不合理容易导致对象泄露

8）尽量使用IntentService，因为在它会处理完 任务后尽快结束自己。

9） 优化布局层次，减少内存消耗

10）谨慎使用抽象编程，抽象编程能够提代码的灵活些和可维护性，但是却会造成一个显著的额外内存消耗。

11）使用nano protobufs序列化数据，

12）谨慎使用依赖注入框架，虽然这个种方式简化代码，但是这些注入框架会通过扫描代码执行多次初始化操作，这样会导致代码需要大量的内存空间来mapping代码，而且mapping pages会长时间保留在内存中。

13）谨慎使用多线程，使用多线程可以把应用中的部分组件运行在单独的进程中，扩大内存占用范围，但是必须谨慎使用，因为这个不经增加了代码逻辑复杂性，使用不当而且会显著增加内存，使用的前提是：需要运行一个常驻后台，而且这个任务不是轻量级的，可以考虑使用。

14）使用ProGuard提车不需要的代码，减少mapping代码需要的内存空间

15）谨慎使用第三方的libraries，特别是尽量不要使用不是为了移动网络环境而编写的。

16）考虑使用不同的方式优化内存占用。

 

本文不是原创，只是作为学习笔记记录