开篇废话
上一篇我们了解了Android里面相关的内存泄露以及相应的处理方案，这一篇，接着上一篇的内存泄露的内容，讲一下Android当中的内存溢出。
内存溢出与内存泄露，很多开发人员都容易产生混淆，有可能是因为这两个概念有点关系，又因为名称上也不太好区分吧。不过，我们依然要清楚，内存溢出（Out Of Memory Error） 与 内存泄露 （Memory Leak）还是有质的区别的。都我们的App多次出现内存泄露，可能就会导致内存溢出。
但是，我们的App出现内存溢出，不一定就是因为内存泄露，因为本身Android系统分配给每一个的App的空间就是那么一点。
另外，内存泄露也不一定就会出现内存溢出，因为还是泄露的速度比较慢，系统将进程杀死了，也就不会内存溢出咯，不过，发现内存泄露，我们还是要第一时间解决掉这个bug。
技术详情
讲述逻辑如下：
1.什么是内存溢出
2.有些内存里面容易混淆的概念
3.如何解决内存溢出
1.什么是内存溢出
内存溢出，OOM(Out Of Memory),表示当前占用的内存加上我们申请的内存资源超过了Dalvik虚拟机的最大内存限制就会抛出的Out Of Memory异常。大部分的OOM的问题，都会与Bitmap的加载有关系
2.内存里面容易混淆的一些概念
主要有三个概念：
1.内存溢出
2.内存抖动
3.内存泄露
其中第一个内存溢出，就是刚刚讲的OOM,第三个内存泄露，可以查看我的上一篇文章。
关于第二个内存抖动，出现的情况是，短时间内，大量的对象被创建，然后又马上被释放，瞬间产生的对象会严重占用内存区域，这个区域就是我们之前接触的那个年轻代区域，到达这个区域的阈值时就会触发minor gc,当出现频繁的minor gc的时候，就会出现内存抖动，我们能够通过我们的Android Studio的Memory Monitor能够非常直观的看到内存抖动
出现内存抖动的现象，可根据当前app处理的实际业务结合Memory Monitor中的现象来进行判断，然后有针对性的进行优化。
它们三者的重要等级分别：内存溢出 > 内存泄露 > 内存抖动
内存溢出对我们的App来说，影响是非常大的，整得不好，就有可能导致程序闪退，无响应等现象，因此，我们一定要优先解决OOM的问题。
3.如何解决内存溢出
如何解决OOM，这个问题范围比较大，我这边大概从两个方面去讲述：
1.关于Bitmap的OOM
2.除了Bitmap之外的OOM
3.1 关于Bitmap的OOM
关于Bitmap的OOM我们有几点需要注意的。
3.1.1 ImageView等控件图片的显示
意思就是加载合适属性的图片，当我们有些场景是可以显示缩略图的时候，就不要调用网络请求加载大图，例如在ListView中，我们在上下滑动的时候，就不要去调用网络请求，当监听到滑动结束的时候，才去加载大图，以免上下滑动的时候产生卡顿现象。
3.1.2 及时释放内存
我们知道，在Android系统中，本身就有自己的垃圾回收机制，系统会不定期进行垃圾回收的。但是，这个只是针对Java那一块的内存,但是我们需要知道Bitmap实例化的时候，是通过JNI的方式，所以还有一部分的内存是C那一块的，我们的GC没有办法回收，所以，我们在不用的时候，还是需要调用recycle()方法，源码里面，recycle()方法其实就是调用的JNI的函数，然后释放C那一块的内存。
3.1.3 把图片进行压缩
我们在实际开发过程当中，可能因为业务需要，需要加载一张很大的图片，大到直接可以超过系统分配给我们App的内存大小，这样，就会直接导致内存溢出，那么，这个时候，我们就应当控制图片的大小，那么就应该将bitmap进行压缩了。
下面大概讲一下对一张图片进行压缩的一个过程。
第一步：计算实际采样率
/**
* 计算压缩比例值
* @param options 解析图片的配置信息
* @param reqWidth 所需图片压缩尺寸最小宽度
* @param reqHeight 所需图片压缩尺寸最小高度
* @return
*/
public static int calculateInSampleSize(BitmapFactory.Options options,
int reqWidth, int reqHeight) {
//保存图片原宽高值
final int height = options. outHeight;
final int width = options. outWidth;
//初始化压缩比例为1
int inSampleSize = 1;
//当图片宽高值任何一个大于所需压缩图片宽高值时,进入循环计算系统
if (height > reqHeight || width > reqWidth) {
final int halfHeight = height / 2;
final int halfWidth = width / 2;
//压缩比例值每次循环两倍增加,
//直到原图宽高值的一半除以压缩值后都~大于所需宽高值为止
while ((halfHeight / inSampleSize) >= reqHeight
&& (halfWidth / inSampleSize) >= reqWidth) {
inSampleSize *= 2;
}
}
return inSampleSize;
}
第二步：根据得到的采样率对图片进行解析
/**
* 获取压缩后的图片
* @param res
* @param resId
* @param reqWidth 所需图片压缩尺寸最小宽度
* @param reqHeight 所需图片压缩尺寸最小高度
* @return
*/
public static Bitmap decodeSampledBitmapFromResource(Resources res, int resId,
int reqWidth, int reqHeight) {
//首先不加载图片,仅获取图片尺寸
final BitmapFactory.Options options = new BitmapFactory.Options();
//当inJustDecodeBounds设为true时,不会加载图片仅获取图片尺寸信息
options.inJustDecodeBounds = true;
//此时仅会将图片信息会保存至options对象内,decode方法不会返回bitmap对象
BitmapFactory.decodeResource(res, resId, options);
//计算压缩比例,如inSampleSize=4时,图片会压缩成原图的1/4
options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight);
//当inJustDecodeBounds设为false时,BitmapFactory.decode...就会返回图片对象了
options. inJustDecodeBounds = false;
//利用计算的比例值获取压缩后的图片对象
return BitmapFactory.decodeResource(res, resId, options);
}
3.1.4 使用Bitmap的高级属性inBitmap
Bitmap的inBitmap高级属性主要是值复用内存块，不需要在重新给新的bitmap对象申请一块新的内存，避免了一次内存的分配和回收，从而提供了我们程序运行的效率。
不过这个属性还是有一些坑的，对于适配Android3.0以上 。而且，这个功能，google一直在优化当中，在Android4.4以前，只能复用相同大小的bitmap内存，而4.4之后，则只要比之前的内存小，就可以了。以下贴出inBitmap的简单使用方法：
第一步：首先判断当前图片是否能够使用inBitmap
/**
* 判断是否能够使用inBigmap
* @param candidate 比较标准
* @param targetOptions 判断目标对象属性
* @return
*/
public static boolean canUseForInBitmap(
Bitmap candidate, BitmapFactory.Options targetOptions) {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
// From Android 4.4 (KitKat) onward we can re-use
// if the byte size of the new bitmap is smaller than
// the reusable bitmap candidate
// allocation byte count.
int width = targetOptions.outWidth / targetOptions.inSampleSize;
int height =
targetOptions.outHeight / targetOptions.inSampleSize;
int byteCount = width * height
* getBytesPerPixel(candidate.getConfig());
return byteCount <= candidate.getAllocationByteCount();
}
// On earlier versions,
// the dimensions must match exactly and the inSampleSize must be 1
return candidate.getWidth() == targetOptions.outWidth
&& candidate.getHeight() == targetOptions.outHeight
&& targetOptions.inSampleSize == 1;
}
第二步：从缓存里面拿出bitmap,将此Bitmap赋值给inBitmap。
/**
* 将Bitmap赋值给inBitmap
* @param options 图片的配置信息
* @param cache 图片缓存
*/
private static void addInBitmapOptions(BitmapFactory.Options options, ImageCache cache) {
//inBitmap only works with mutable bitmaps, so force the decoder to
//return mutable bitmaps.
options.inMutable = true;
if (cache != null) {
// Try to find a bitmap to use for inBitmap.
Bitmap inBitmap = cache.getBitmapFromReusableSet(options);
if (inBitmap != null) {
// If a suitable bitmap has been found,
// set it as the value of inBitmap.
options.inBitmap = inBitmap;
}
}
}
第三步：调用刚刚图片压缩时候的decode方法，把options参数传入
3.1.5 捕获异常
很多时候，当内存确实很吃紧的时候，难免还是会出现OOM，所以，根据经验之谈，我们在开发过程中，实例化Bitmap的时候，最好还是添加try catch，进行异常捕获。
需要注意，平常的Exception异常是捕获不到OOM Erro的，因为OOM是一个错误，我们编码的时候需要捕获错误，具体给出以下示例代码：
public static Bitmap createBitmap(int width, int height, Bitmap.Config config) {
Bitmap bitmap = null;
try {
bitmap = Bitmap.createBitmap(width, height, config);
} catch (OutOfMemoryError e) {
while(bitmap == null) {
System.gc();
System.runFinalization();
bitmap = createBitmap(width, height, config);
}
}
}
3.2 除了Bitmap之外的OOM
3.2.1 listview
这个listview确实提到了好多次，毕竟我们实际开发当中，用它来呈现一些数据确实的频率也蛮高，还是需要讲述一下。
使用listview的时候，一定要记得复用convertView
同时，在listview当中，如果需要显示大图的控件，记得使用LRU（最近最少使用，三级缓存）机制进行缓存图片
3.2.2 onDraw方法当中，尽量避免对象的创建
如果在onDraw方法中创建对象，会触发频繁的GC,也就是之前提到的内存抖动，当内存抖动积累到一定的程度，也会出现内存溢出。
3.2.3 使用多进程，一定要小心小心再小心
我们有的时候需要将一些服务，或者主件放到另外一个进程去运行，例如一些定位，推送等，这样确实可以分担主进程的内存压力。
但是，多进程中的一些通信真心没有那么简单。很多机制可能失效，从而影响业务的基本功能。可能会出现一些莫名其妙的crash.
所以，如果我们的App实际业务没有达到一定程度，真心不要使用多进程。
干货总结
此篇文章根据OOM是什么，了解一些容易混淆的概念，然后熟悉一些OOM的解决方案这个逻辑，再结合实际开发可能遇到的问题，讲述了内存溢出的相关知识。其实，大篇幅都是在讲述Bitmap的处理方案，因为，我们这个Bitmap确实在实际开发当中引发OOM的概率还是相当大的。
希望通过以上的讲述，我们能够对于OOM有一个清晰的了解，从而根据我们实际开发当中自己的业务，进行OOM的优化。
其实有的时候，我们在解决OOM的时候需要有一个权衡，因为如果考虑到了OOM的情况而频繁触发GC,可能会导致UI卡顿的现象，跟严重的可能出现ANR的问题，需要我们在实际开发过程中具体场景具体分析。
好了，内存的泄露的知识就先更新到这了，如果觉得本篇文章对大家有益，请给予一个赞和喜欢，这样我才更有动力一直更新下去，如果想和我一起探讨的，可以关注一波。
