android开发之详解ANR与OOM

ANR(Application Not Responding)

ANR定义: 在Android上,如果你的应用程序有一段时间内响应不够灵敏,系统会向用户显示一个对话框,这个对话框称作为应用程序无响应(ANR: Application Not Responding)对话框.用户可以选择”等待”而让程序继续运行,也可以选择”强制关闭”.所以一个流畅的合理的应用程序中不能出现ANR,而让用户每次都要处理这个对话框.因此,在程序里对响应性能的设计很重要,这样系统不会显示ANR给用户.

默认情况下,在Android中Activity的最长执行时间是5秒,BroadcastReceiver的最长执行时间则是10秒.

第一: 为什么会引发ANR?

在Android里，应用程序的响应性是由Activity Manager和WindowManager系统服务监视的 。当它监测到以下情况中的一个时，Android就会针对特定的应用程序显示ANR：

1. 在5秒内没有响应输入的事件（例如，按键按下，屏幕触摸）
2. BroadcastReceiver在10秒内没有执行完毕

造成以上两点的原因有很多，比如在主线程中做了非常耗时的操作，比如说是下载，io异常等。

潜在的耗时操作，例如网络或数据库操作，或者高耗时的计算如改变位图尺寸，应该在子线程里（或者以数据库操作为例，通过异步请求的方式）来完成。而不是说你的主线程阻塞在那里等待子线程的完成——也不是调用 Thread.wait()或是Thread.sleep()。替代的方法是，主线程应该为子线程提供一个Handler，以便完成时能够提交给主线程。以这种方式设计你的应用程序，将能保证你的主线程保持对输入的响应性并能避免由于5秒输入事件的超时引发的ANR对话框。

第二: 如何避免ANR?

1. 运行在主线程里的任何方法都尽可能少做事情。特别是，Activity应该在它的关键生命周期方法（如onCreate()和onResume()）里尽可能少的去做创建操作。（可以采用重新开启子线程的方式，然后使用Handler+Message的方式做一些操作，比如更新主线程中的ui等）

2. 应用程序应该避免在BroadcastReceiver里做耗时的操作或计算。但不再是在子线程里做这些任务（因为 BroadcastReceiver的生命周期短），替代的是，如果响应Intent广播需要执行一个耗时的动作的话，应用程序应该启动一个 Service。（此处需要注意的是可以在BroadcastReceiver中启动Service，但是却不可以在Service中启动BroadcastReceiver）

3. 避免在Intent Receiver里启动一个Activity，因为它会创建一个新的画面，并从当前用户正在运行的程序上抢夺焦点。如果你的应用程序在响应Intent广播时需要向用户展示什么，你应该使用Notification Manager来实现。

总结：ANR异常也是在程序中自己经常遇到的问题，主要的解决办法自己最常用的就是不要在主线程中做耗时的操作，而应放在子线程中来实现，比如采用Handler+Mesage的方式，或者是有时候需要做一些和网络相互交互的耗时操作就采用AsynTask异步任务的方式（它的底层其实Handler+Mesage有所区别的是它是线程池）等，在主线程中更新UI。

OOM(Out Of Memory)

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()
//提醒系统及时回收
}

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

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内存，具体解决办法如下：

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

　　关于图片的加载和压缩,详情请看:http://blog.csdn.net/zanelove/article/details/44278783
　　
　　通过上面的方式解决了，但是这并不是最完美的解决方式。

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

　　三：优化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去处理

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

　　五：动态内存管理

　　动态内存管理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的问题，由于加载内存过大也是在所难免。

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

最后

以上就是踏实蛋挞为你收集整理的android开发之详解ANR与OOM的全部内容，希望文章能够帮你解决android开发之详解ANR与OOM所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。