Android中常见的三种异常

在开发android中，程序最常见的异常有三种。

对我而言。

一 .空指针（Java.lang.NullPointerException）
这种问题比较好解决，从日志的log点进去一般都能找到位置，然后结合代码，可以得到解决。

二 .程序无响应 ANR (Application Not Responding)

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

容易出现的几个地方？

1)按键超时:Android默认的响应时间是5s，如果一个触屏事件超过5s，那么就会发生此现象。

2)广播超时:广播的默认响应时间是10s，如果一个广播在10s之内还美柚执行完，那么就会出现此现象。

3)服务超时:服务的默认响应事件是20s,如果请求的服务在20s内失败，那么就会发生此现象。

如何避免ANR？

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

2、应用程序应该避免在BroadcastReceiver里做耗时的操作或计算。但不再是在子线程里做这些任务（因为 BroadcastReceiver的生命周期短），替代的是，如果响应Intent广播需要执行一个耗时的动作的话，应用程序应该启动一个 Service。（此处需要注意的是可以在广播接受者中启动Service，但是却不可以在Service中启动broadcasereciver,关于原因后续会有介绍，此处不是本文重点）

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

三.内存溢出 OOM(Out Of Memory)

这种问题的出现，在图片处理上出现的比较多。
加载bitmap的时候，最容易造成内存溢出。
但是现在有很多的框架出来，框架处理好了图片的加载，
自己现在使用的是Glide框架。（还未学习源码，只是会用）。

1.什么是OOM？

通俗讲就是当我们的APP需要申请一块内存来装图片的时候，系统觉得我们的APP所使用的内存已经够多了。即使它有1G的空余内存，它不同意给我的APP更多的内存里，然后即使系统马上抛出OOM错误，而程序没有捕捉该错误，故弹框崩溃了。

2.为什么会有OOM？

因为android系统的app的每个进程或者每个虚拟机有个最大内存限制，如果申请的内存资源超过这个限制，系统就会抛出OOM错误。跟整个设备的剩余内存没太大关系。比如比较早的android系统的一个虚拟机最多16M内存，当一个app启动后，虚拟机不停的申请内存资源来装载图片，当超过内存上限时就出现OOM。Android系统的APP内存限制怎么确定？

Android不是用GC会自动回收资源么，为什么app的那些不用的资源不回收呢？

Android的gc会按照特定的算法回收程序不用的内存资源，避免app的内存申请约积越多，但是gc一般回收的资源是那些无主的对象内存或者软饮用的资源，或者更软引用的引用资源。

几个注意点？

1 适当调整图像大小 。因为手机屏幕尺寸有限，分配给图像的显示区域有限，尤其对于超大图片，加载自网络或者sd卡，图片文件提及达到几M或者十几个M的：

加载到内存前，先算出该bitmap的大小，然后通过适当调节采样率使得加载的图片刚好，或稍大捷克在手机屏幕上显示就满意了：

BimtapFactory.Option opts = new BitampFactory.Option();
opts.inJustDecodeBounds = true ;
opts.inSampleSize=computeSample(opts, minSideLength, maxNumOfPixels); // Android 提供了一种动态计算的方法 computeSampleSize
opts.inJustDecodeBounds = false ;
try {
return BitmapFactory.decodeFile(imageFile, opts);
} catch (OutOfMemoryError err){
}
2 图像缓存 。在listview或Gallery等控件中一次性加载大量图片时，只加载屏幕显示的资源，尚未显示的不加载，移出屏幕的资源及时释放，采用强引用＋软引用2级缓存，提高加载性能。缓存图像到内存，采用软引用缓存到内存，而不是在每次使用的时候都从新加载到内存。

3 采用低内存占用量的编码方式 。比如Bitmap.Config.ARGB_4444比Bitmap.Config.ARGB_8888更省内存。

4 及时回收图像 。如果引用了大量的Bitmap对象，而应用又不需要同时显示所有图片。可以将暂时不用到的Bitmap对象及时回收掉。对于一些明确直到图片使用情况的场景可以主动recycle回收

App的启动splash画面上的图片资源，使用完就recycle。对于帧动画，可以加载一张，画一张，释放一张。

5 不要在循环中创建过多的本地变量 。慎用static，用static来修饰成员变量时，该变量就属于该类，而不是该类实例，它的生命周期是很长的。如果用它来引用一些内存占用太多的实例，这时候就要谨慎对待了。

6 自定义堆内存分配大小 。优化Dalvik虚拟机的堆内存分配。

收集的内容，以便回顾。