android oom 全解析

Android oom 有时出现很频繁，这一般不是Android设计的问题，一般是我们的问题。

　　就我的经验而言，出现oom，无非主要是以下几个方面：

　　一、加载对象过大

　　二、相应资源过多，没有来不及释放。

　　解决这样的问题，也有一下几个方面：

　　一：在内存引用上做些处理，常用的有软引用、强化引用、弱引用

　　二：在内存中加载图片时直接在内存中做处理，如：边界压缩.
　　三：动态回收内存
　　四：优化Dalvik虚拟机的堆内存分配
　　五：自定义堆内存大小

　　可真有这么简单吗，不见得，看我娓娓道来：

　　软引用(SoftReference)、虚引用(PhantomRefrence)、弱引用(WeakReference),这三个类是对heap中java对象的应用，通过这个三个类可以和gc做简单的交互，除了这三个以外还有一个是最常用的强引用.

　　强引用，例如下面代码：

　　Object o=new Object();
　　Object o1=o;

　　上面代码中第一句是在heap堆中创建新的Object对象通过o引用这个对象，第二句是通过o建立o1到new Object()这个heap堆中的对象的引用，这两个引用都是强引用.只要存在对heap中对象的引用，gc就不会收集该对象.如果通过如下代码：

　　o=null; 　　

　　o1=null;

　　heap中对象有强可及对象、软可及对象、弱可及对象、虚可及对象和不可到达对象。应用的强弱顺序是强、软、弱、和虚。对于对象是属于哪种可及的对象，由他的最强的引用决定。如下:

String abc=new String("abc");  //1
SoftReference<String> abcSoftRef=new SoftReference<String>(abc);  //2
WeakReference<String> abcWeakRef = new WeakReference<String>(abc); //3
abc=null; //4
abcSoftRef.clear();//5在此例中，透过 get() 可以取得此 Reference 的所指到的对象，如果返回值为 null 的话，代表此对象已经被清除。这类的技巧，在设计 Optimizer 或 Debugger 这类的程序时常会用到，因为这类程序需要取得某对象的信息，但是不可以 影响此对象的垃圾收集。

　　虚引用
　　就是没有的意思，建立虚引用之后通过get方法返回结果始终为null,通过源代码你会发现,虚引用通向会把引用的对象写进referent,只是get方法返回结果为null.先看一下和gc交互的过程在说一下他的作用.
不把referent设置为null, 直接把heap中的new String("abc")对象设置为可结束的(finalizable).
与软引用和弱引用不同, 先把PhantomRefrence对象添加到它的ReferenceQueue中.然后在释放虚可及的对象. 你会发现在收集heap中的new String("abc")对象之前,你就可以做一些其他的事情.通过以下代码可以了解他的作用.

　　虽然这些常见引用，能够使其gc回收，但是gc又不是非常的智能了，因而oom乱免。

　　二：在内存中加载图片时直接在内存中做处理。

　　尽量不要使用setImageBitmap或setImageResource或BitmapFactory.decodeResource来设置一张大图，因为这些函数在完成decode后，最终都是通过java层的createBitmap来完成的，需要消耗更多内存。

　　因此，改用先通过BitmapFactory.decodeStream方法，创建出一个bitmap，再将其设为ImageView的 source，decodeStream最大的秘密在于其直接调用JNI>>nativeDecodeAsset()来完成decode，无需再使用java层的createBitmap，从而节省了java层的空间。

　　如果在读取时加上图片的Config参数，可以跟有效减少加载的内存，从而跟有效阻止抛out of Memory异常，另外，decodeStream直接拿的图片来读取字节码了，不会根据机器的各种分辨率来自动适应，使用了decodeStream之后，需要在hdpi和mdpi，ldpi中配置相应的图片资源，否则在不同分辨率机器上都是同样大小（像素点数量），显示出来的大小就不对了。

　　另外，以下方式也大有帮助：

InputStream is = this.getResources().openRawResource(R.drawable.pic1); BitmapFactory.Options options=new BitmapFactory.Options(); options.inJustDecodeBounds = false; options.inSampleSize = 10;   //width，hight设为原来的十分一 Bitmap btp =BitmapFactory.decodeStream(is,null,options); if(!bmp.isRecycle() ){ bmp.recycle()   //回收图片所占的内存 system.gc()  //提醒系统及时回收
}

　　以下奉上一个方法,以最省内存的方式读取本地资源的图片

/** *  * @param context * @param resId * @return */ public static Bitmap readBitMap(Context context, int resId){ BitmapFactory.Options opt = new BitmapFactory.Options(); opt.inPreferredConfig = Bitmap.Config.RGB_565; opt.inPurgeable = true; opt.inInputShareable = true; //获取资源图片
 InputStream is = context.getResources().openRawResource(resId); return BitmapFactory.decodeStream(is,null,opt); }

昨天在模拟器上给gallery放入图片的时候，出现java.lang.OutOfMemoryError: bitmap size exceeds VM budget 异常，图像大小超过了RAM内存。

模拟器RAM比较小，只有8M内存，当我放入的大量的图片（每个100多K左右），就出现上面的原因。
由于每张图片先前是压缩的情况，放入到Bitmap的时候，大小会变大，导致超出RAM内存，具体解决办法如下：

```java
//解决加载图片 内存溢出的问题 //Options 只保存图片尺寸大小，不保存图片到内存 BitmapFactory.Options opts = new BitmapFactory.Options(); //缩放的比例，缩放是很难按准备的比例进行缩放的，其值表明缩放的倍数，SDK中建议其值是2的指数值,值越大会导致图片不清晰 opts.inSampleSize = 4; Bitmap bmp = null; bmp = BitmapFactory.decodeResource(getResources(), mImageIds[position],opts);                              ...               //回收
                bmp.recycle();

通过上面的方式解决了，但是这并不是最完美的解决方式。

通过一些了解，得知如下：

优化Dalvik虚拟机的堆内存分配

对于Android平台来说，其托管层使用的Dalvik JavaVM从目前的表现来看还有很多地方可以优化处理，比如我们在开发一些大型游戏或耗资源的应用中可能考虑手动干涉GC处理，使用dalvik.system.VMRuntime类提供的setTargetHeapUtilization方法可以增强程序堆内存的处理效率。当然具体原理我们可以参考开源工程，这里我们仅说下使用方法: private final static floatTARGET_HEAP_UTILIZATION = 0.75f; 在程序onCreate时就可以调用VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION);即可。

Android堆内存也可自己定义大小

对于一些Android项目，影响性能瓶颈的主要是Android自己内存管理机制问题，目前手机厂商对RAM都比较吝啬，对于软件的流畅性来说RAM对性能的影响十分敏感，除了优化Dalvik虚拟机的堆内存分配外，我们还可以强制定义自己软件的对内存大小，我们使用Dalvik提供的dalvik.system.VMRuntime类来设置最小堆内存为例:

private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ;

VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE); //设置最小heap内存为6MB大小。当然对于内存吃紧来说还可以通过手动干涉GC去处理

bitmap 设置图片尺寸，避免内存溢出 OutOfMemoryError的优化方法

★android 中用bitmap 时很容易内存溢出，报如下错误：Java.lang.OutOfMemoryError : bitmap size exceeds VM budget

● 主要是加上这段：

BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 2;

● eg1：(通过Uri取图片)

private ImageView preview;
BitmapFactory.Options options = new BitmapFactory.Options(); options.inSampleSize = 2;//图片宽高都为原来的二分之一，即图片为原来的四分之一 Bitmap bitmap = BitmapFactory.decodeStream(cr .openInputStream(uri), null, options); preview.setImageBitmap(bitmap);

以上代码可以优化内存溢出，但它只是改变图片大小，并不能彻底解决内存溢出。
● eg2:（通过路径去图片）

private ImageView preview;
private String fileName= "/sdcard/DCIM/Camera/2010-05-14 16.01.44.jpg";
BitmapFactory.Options options = new BitmapFactory.Options(); options.inSampleSize = 2;//图片宽高都为原来的二分之一，即图片为原来的四分之一 Bitmap b = BitmapFactory.decodeFile(fileName, options); preview.setImageBitmap(b); filePath.setText(fileName);

　　　　这样，能够压缩足够的比例，但是对于小内存手机，特别是那种16mheap的手机是避免不了了。

　　三.动态分配内存

　　动态内存管理DMM（Dynamic Memory Management）是从Heap中直接分配内存和回收内存。

　　有两种方法实现动态内存管理。

　　一是显示内存管理EMM（Explicit Memory Management）。
在EMM方式，内存从Heap中进行分配，用完后手动回收。程序使用malloc()函数分配整数数组，并使用free()函数释放分配的内存。

　　二是自动内存管理AMM（Automatic Memory Management）。
AMM也可叫垃圾回收器（Garbage Collection）。Java编程语言实现了AMM，与EMM不同，Run-time system关注已分配的内存空间，一旦不再使用，立即回收。

　　无论是EMM还是AMM，所有的Heap管理计划都面临一些共同的问题和前在的缺陷：
　　1）内部碎片（Internal Fragmentation）
当内存有浪费时，内部碎片出现。因为内存请求可导致分配的内存块过大。比如请求128字节的存储空间，结果Run-time system分配了512字节。

　　2）外部碎片（External Fragmentation）
当一系列的内存请求留下了数个有效的内存块，但这些内存块的大小均不能满足新请求服务，此时出现外部碎片。

　　3）基于定位的延迟（Location-based Latency）
延迟问题出现在两个数据值存储得相隔很远，导致访问时间增加。

　　EMM往往比AMM更快。
　　EMM与AMM比较表：
——————————————————————————————————————
EMM AMM
——————————————————————————————————————
Benefits 尺寸更小、速度更快、易控制 stay focused on domain issues
Costs 复杂、记账、内存泄露、指针悬空不错的性能
——————————————————————————————————————

早期的垃圾回收器非常慢，往往占用50%的执行时间。

垃圾回收器理论产生于1959年，Dan Edwards在Lisp编程语言的开发时实现了第一个垃圾回收器。

垃圾回收器有三种基本的经典算法：

1）Reference counting（引用计数）
基本思想是：当对象创建并赋值时该对象的引用计数器置1，每当对象给任意变量赋值时，引用记数＋1；一旦退出作用域则引用记数－1。一旦引用记数变为0，则该对象可以被垃圾回收。
引用记数有其相应的优势：对程序的执行来说，每次操作只需要花费很小块的时间。这对于不能被过长中断的实时系统来说有着天然的优势。
但也有其不足：不能够检测到环（两个对象的互相引用）；同时在每次增加或者减少引用记数的时候比较费时间。
在现代的垃圾回收算法中，引用记数已经不再使用。

2）Mark-sweep（标记清理）
基本思想是：每次从根集出发寻找所有的引用（称为活对象），每找到一个，则对其做出标记，当追踪完成之后，所有的未标记对象便是需要回收的垃圾。
也叫追踪算法，基于标记并清除。这个垃圾回收步骤分为两个阶段：在标记阶段，垃圾回收器遍历整棵引用树并标记每一个遇到的对象。在清除阶段，未标记的对象被释放，并使其在内存中可用。

3）Copying collection（复制收集）
基本思想是：将内存划分为两块，一块是当前正在使用；另一块是当前未用。每次分配时使用当前正在使用内存，当无可用内存时，对该区域内存进行标记，并将标记的对象全部拷贝到当前未用内存区，这是反转两区域，即当前可用区域变为当前未用，而当前未用变为当前可用，继续执行该算法。
拷贝算法需要停止所有的程序活动，然后开始冗长而繁忙的copy工作。这点是其不利的地方。

近年来还有两种算法：

1）Generational garbage collection（分代）
其思想依据是：
(1) 被大多数程序创建的大多数对象有着非常短的生存期。
(2) 被大多数程序创建的部分对象有着非常长的生存期。
简单拷贝算法的主要不足是它们花费了更多的时间去拷贝了一些长期生存的对象。
而分代算法的基本思想是：将内存区域分两块（或更多），其中一块代表年轻代，另一块代表老的一代。针对不同的特点，对年轻一代的垃圾收集更为频繁，对老代的收集则较少，每次经过年轻一代的垃圾回收总会有未被收集的活对象，这些活对象经过收集之后会增加成熟度，当成熟度到达一定程度，则将其放进老代内存块中。
分代算法很好的实现了垃圾回收的动态性，同时避免了内存碎片，是目前许多JVM使用的垃圾回收算法。

2）Conservative garbage collection（保守）

哪一种算法最好？答案是没有最好。

EMM作为很常用的垃圾回收算法，有5种基本方法：
　　1）Table-driven algorithms
　　表驱动算法把内存分为固定尺寸的块集合。这些块使用抽象数据结构进行索引。比如一个bit对应一个块，用0和1表示是否分配。不利因素：位映射依赖于内存块的尺寸；另外，搜索一系列的空闲内存块可能需要搜索整个bit映射表，这影响性能。

　　2）Sequential fit
顺序适应算法允许内存分为不同的尺寸。此算法跟踪已分配和空闲的Heap，标记空闲块的起始地址和结束地址。它有三种子分类：
(1) First fit（首次适应）——分配找到的第一个适合内存请求的块
(2) Best fit（最佳适应）——分配最适合内存请求的块
(3) Worst fit（最不适应）——分配最大的块给内存请求

3）Buddy systems
　　Buddy systems算法的主要目的是加速已分配内存在释放后的合并速度。显示内存管理EMM使用Buddy systems算法可能导致内部碎片。

4）Segregated storage
　　隔离存储技术涉及到把Heap分成多个区域（zone），并为每个区域采用不同的内存管理计划。这是很有效的方法。

5）Sub-allocators
　　子配置技术尝试解决在Run-time System下分配大块内存并单独管理的内存分配问题。换句话说，程序完全负责自己的私有存储堆（stockpile）的内存分配和回收，无需run-time System的帮助。它可能带来额外的复杂性，但是你可以显著地提高性能。在1990年的《C Compiler Design》一书中，Allen Holub就极好地利用了Sub-allocators来加速其编译器的实现。

　　注意，显示内存管理EMM必须是灵活的，能够响应数种不同类型的请求。

　　最后，使用EMM还是使用AMM？这是一个Religious question，凭个人喜好。EMM在复杂的开销下实现了速度和控制。AMM牺牲了性能，但换来了简单性。

　　无论是emm，amm分配内存，出现了oom的问题，由于加载内存过大也是在所难免。

　　四。优化Dalvik虚拟机的堆内存分配

　　对于Android平台来说，其托管层使用的Dalvik Java VM从目前的表现来看还有很多地方可以优化处理，比如我们在开发一些大型游戏或耗资源的应用中可能考虑手动干涉GC处理，使用dalvik.system.VMRuntime类提供的setTargetHeapUtilization方法可以增强程序堆内存的处理效率。当然具体原理我们可以参考开源工程，这里我们仅说下使用方法:private final static float TARGET_HEAP_UTILIZATION = 0.75f;在程序onCreate时就可以调用VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION);即可。

Android堆内存也可自己定义大小

对于一些Android项目，影响性能瓶颈的主要是Android自己内存管理机制问题，目前手机厂商对RAM都比较吝啬，对于软件的流畅性来说RAM对性能的影响十分敏感，除了优化Dalvik虚拟机的堆内存分配外，我们还可以强制定义自己软件的堆内存大小，我们使用Dalvik提供的 dalvik.system.VMRuntime类来设置最小堆内存为例:

private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ;

VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE); //设置最小heap内存为6MB大小。当然对于内存吃紧来说还可以通过手动干涉GC去处理

　　注意了，这个设置dalvik虚拟机的配置的方法对Android4.0 设置无效。

　　这就是我对Android的oom的一点看法.

android oom 全解析相关推荐

Android动画全解析（三）
昨天晚上下班,公交车上没事,又翻开了老罗的博客:那两年炼就的Android内功修养,回看了下,真是又一翻心潮澎湃啊!!大概两年前,老罗的博客就成了我的必备书,没事了就翻翻,再次向罗大神致敬!!罗大神的 ...
Android Binder 全解析(1) -- 概述
摘要如果各位玩过<炉石传说>,那么可能对法师的职业卡「不稳定的传送门」很有印象,特别是没有欧洲玩家,经常能够拿到其他职业的强力单卡.Android 也提供了传送门,让我们可以像使用本地方 ...
Android Service 全解析
Service的种类按运行地点分类: 类别区别优点缺点应用本地服务(Local) 该服务依附在主进程上, 服务依附在主进程上而不是独立的进程,这样在一定程度上节约了资源,另外Loca ...
关于 android oom（内存溢出的分析）
laozhu1124 android oom 全解析 Android oom 有时出现很频繁,这一般不是Android设计的问题,一般是我们的问题. 就我的经验而言,出现oom,无非主要是以下几个方面 ...
Android图片加载框架最全解析（八），带你全面了解Glide 4的用法
本文转载自郭神的Glide分析系列:http://blog.csdn.net/guolin_blog/article/details/78582548 本文同步发表于我的微信公众号,扫一扫文章底部的二 ...
Android图片加载框架最全解析（三），深入探究Glide的缓存机制
转载请注明出处:http://blog.csdn.net/guolin_blog/article/details/54895665 本文同步发表于我的微信公众号,扫一扫文章底部的二维码或在微信搜索郭 ...
Android系统init进程启动及init.rc全解析
这是一篇用心写的博客,也希望大家用心看并帮忙找到文章的改进之处,谢谢: 服务启动机制 system/core/init/init.c文件main函数中parse_config_file(init.rc ...
Android异步加载全解析之引入二级缓存
Android异步加载全解析之引入二级缓存为啥要二级缓存前面我们有了一级缓存,为啥还要二级缓存呢?说白了,这就和电脑是一样的,我们电脑有内存和硬盘,内存读取速度快,所以CPU直接读取内存中的数据, ...
Android图片加载框架最全解析（二），从源码的角度理解Glide的执行流程
转载请注明出处:http://blog.csdn.net/guolin_blog/article/details/53939176 本文同步发表于我的微信公众号,扫一扫文章底部的二维码或在微信搜索郭 ...

android oom 全解析

android oom 全解析相关推荐

最新文章

热门文章