OOM总结

Posted heavenliu

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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)考虑使用不同的方式优化内存占用。

 

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

 

以上是关于OOM总结的主要内容,如果未能解决你的问题,请参考以下文章

Android中内存泄露与如何有效避免OOM总结

Spark面对OOM问题的解决方法及优化总结

Android如何避免OOM总结

OutOfMemoryError(OOM)和StackOverflowError(SOF)异常总结

JVM的OOM分析总结

Spark面对OOM问题的解决方法及优化总结