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)考虑使用不同的方式优化内存占用。

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

时间: 2024-10-13 02:31:56

OOM总结的相关文章

ViewPager做图片浏览器,加载大量图片OOM的问题修正

1 /** 2 * @author CHQ 3 * @version 1.0 4 * @date 创建时间: 2016/7/26 17:18 5 * @parameter 6 * @return 7 * 图片查看器 8 * //可以查看网络图片 9 * //可以查看本地图片 10 */ 11 public class PhotoScan extends Activity { 12 private PhotoViewPager mViewPager; 13 private List<View>

Android 防止OOM优化

1. Android2.x及以下的系统优化: Bitmap被解码后的像素被存储在Native Heap中, Dalvik Heap有个external计数,记录了Bitmap所占用的内存. 当 Dalvik Allocated + External Allocated + new Allocated>= 允许分配最大值时,就会引发OutOfMemoryError异常, 销毁的时候必须要调用recycle().BitmapFactory.Options参数,隐藏了inNativeAlloc属性,

Android高效加载大图、多图解决方案,有效避免程序OOM

我们可以通过下面的代码看出每个应用程序最高可用内存是多少 int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);   Log.d("TAG", "Max memory is " + maxMemory + "KB"); BitmapFactory这个类提供了多个解析方法(decodeByteArray, decodeFile, decodeResource等)用于创建Bit

Android LruCache 压缩图片 有效避免程序OOM

转载请注明出处:http://blog.csdn.net/guolin_blog/article/details/9316683 本篇文章主要内容来自于Android Doc,我翻译之后又做了些加工,英文好的朋友也可以直接去读原文. http://developer.android.com/training/displaying-bitmaps/index.html 压缩加载大图片 我们在编写Android程序的时候经常要用到许多图片,不同图片总是会有不同的形状.不同的大小,但在大多数情况下,这

OOM异常产生的原因和处理方法

一般而言,android中常见的原因主要有以下几个: 1.数据库的cursor没有关闭. 2.构造adapter没有使用缓存contentview. 3.调用registerReceiver()后未调用unregisterReceiver(). 4.未关闭InputStream/OutputStream. 5.Bitmap使用后未调用recycle(). 6.Context泄漏. 7.static关键字等. 接下来分别对这些溢出情况说出解决的思路: 1.针对数据库cursor没有关闭的情况,如果

JVM OOM处理

一般OOM可能情况如下: 1.OutOfMemoryError: Java heap space: 2.OutOfMemoryError: PermGen space: 3.OutOfMemoryError: unable to create new native thread 对于第1及第2种情况可以通过设置JVM参数(Xms -Xmx -XX:PermSize -XX:MaxPermSize)来进行调节处理: 问题3产生的原因是由于我们创建了太多的线程,而能创建的线程数是有限制的,导致了异常

(转)根据ImageView的大小来压缩Bitmap,避免OOM

本文转载于:http://www.cnblogs.com/tianzhijiexian/p/4254110.html Bitmap是引起OOM的罪魁祸首之一,当我们从网络上下载图片的时候无法知道网络图片的准确大小,所以为了节约内存,一般会在服务器上缓存一个缩略图,提升下载速度.除此之外,我们还可以在本地显示图片前将图片进行压缩,使其完全符合imageview的大小,这样就不会浪费内存了. 一.思路 思路:计算出要显示bitmap的imageview大小,根据imageview的大小压缩bitma

android 图片加载优化,避免oom问题产生

1,及时回收bitmap,在activity的onstop()和onDestory()里面调用如下代码进行bitmap的回收: // 先判断是否已经回收 if(bitmap != null && !bitmap.isRecycled()){ // 回收并且置为null bitmap.recycle(); bitmap = null; } System.gc(); 2,对oom异常的捕获:出现异常不能让程序就那么崩掉吧,所以对程序中中设计bitmap的操作都要检测oom异常进而进行处理: B

Linux OOM killer 机制

Linux中的Out Of Memory(OOM) Killer功能是一种确保系统内存足够的最终手段,可以在耗尽系统内存或交换区后,按某种算法判断占用系统最多资源的进程,向进程发送信号,强制终止该进程. 简单来说该机制会监控那些占用内存过大,尤其是瞬间很快消耗大量内存的进程,为了防止内存耗尽而内核会把该进程杀掉. 这个功能即使在无法释放内存的情况下,也能够重复进行确保内存的处理过程,防止系统停滞,还可以找出过度消耗内存的进程. 典型的情况是:某天一台机器突然ssh远程登录不了,但能ping通,说