Android内存优化

BitMap优化：

1，Android种大部分内存错误都可能是BitMap，我们在使用的时候没有释放资源，到时内存溢出！

01：当我们确定这个BItMap不会再用到的时候建议手动调用 uesume()方法释放内存：代码如图



给大家介绍一下Bitmap.java中recycle()方法的说明：



调用bitmap.recycle之后，这个Bitmap如果没有被引用到，那么就会被垃圾回收器回收。如果不主动调用这个方法，垃圾回收器也会进 行回收工作，只不过垃圾回收器的不确定性太大，依赖其自动回收不靠谱(比如垃圾回收器一次性要回收好多Bitmap，那么需要的时间就会很多，导致回收的 时候会卡顿)。所以我们需要主动调用recycle。

02：主动释放 ImageView图片资源：

由于我们在实际开发中，很多情况是在xml布局文件中设置ImageView的src或者在代码中调用 ImageView.setImageResource/setImageURI/setImageDrawable等方法设置图像，下面代码可以回收这 个ImageView所对应的资源：



03：主动释放ImageView的背景资源：如果你的 Background下面有图片的话，下面这段话可以释放资源：



04：尽量少用Png图，多用NinePatch的图：现在手机的分辨率越来越高，图片资源在被加载后所占用的内存也越来越大，所以要尽量避免使用大的PNG图，在产品设计的时候就要尽量避免用一张大图来进行展示，尽量多用NinePatch资源。

Android中的NinePatch指的是一种拉伸后不会变形的特殊png图，NinePatch的拉伸区域可以自己定义。这种图的优点是体积 小，拉伸不变形，可以适配多机型，Android SDK中有自带NinePatch资源制作工具，Android-Studio中在普通png图片点击右键可以将其转换为NinePatch资源，使用起 来非常方便：



05：使用大图之前，尽量先进行解压：

高效加载大图：

图片有不同的形状与大小。在大多数情况下它们的实际大小都比需要呈现的尺寸大很多。例如，系统的图库应用会显示那些我们使用相机拍摄的照片，但是那些图片的分辨率通常都比设备屏幕的分辨率要高很多。

考虑到应用是在有限的内存下工作的，理想情况是我们只需要在内存中加载一个低分辨率的照片即可。为了更便于显示，这个低分辨率的照片应该是与其对应的UI控件大小相匹配的。加载一个超过屏幕分辨率的高分辨率照片不仅没有任何显而易见的好处，还会占用宝贵的内存资源，另外在快速滑动图片时容易产生额外的效率问题。

这一课会介绍如何通过加载一个缩小版本的图片，从而避免超出程序的内存限制：

读取位图的尺寸与类型(Read Bitmap Dimensions and Type)：

BitmapFactory提供了一些解码（decode）的方法（decodeByteArray(), decodeFile(), decodeResource()等），用来从不同的资源中创建一个Bitmap。 我们应该根据图片的数据源来选择合适的解码方法。 这些方法在构造位图的时候会尝试分配内存，因此会容易导致OutOfMemory的异常。每一种解码方法都可以通过BitmapFactory.Options设置一些附加的标记，以此来指定解码选项。设置 inJustDecodeBounds 属性为true可以在解码的时候避免内存的分配，它会返回一个null的Bitmap，但是可以获取到 outWidth, outHeight 与 outMimeType。该技术可以允许你在构造Bitmap之前优先读图片的尺寸与类型。

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

options.inJustDecodeBounds = true;

BitmapFactory.decodeResource(getResources(), R.id.myimage, options);

int imageHeight = options.outHeight;

int imageWidth = options.outWidth;

String imageType = options.outMimeType;

为了避免java.lang.OutOfMemory 的异常，我们需要在真正解析图片之前检查它的尺寸（除非你能确定这个数据源提供了准确无误的图片且不会导致占用过多的内存）。

加载一个按比例缩小的版本到内存中(Load a Scaled Down Version into Memory)：

通过上面的步骤我们已经获取到了图片的尺寸，这些数据可以用来帮助我们决定应该加载整个图片到内存中还是加载一个缩小的版本。有下面一些因素需要考虑：

评估加载完整图片所需要耗费的内存。
程序在加载这张图片时可能涉及到的其他内存需求。
呈现这张图片的控件的尺寸大小。
屏幕大小与当前设备的屏幕密度。

例如，如果把一个大小为1024x768像素的图片显示到大小为128x96像素的ImageView上吗，就没有必要把整张原图都加载到内存中。

为了告诉解码器去加载一个缩小版本的图片到内存中，需要在BitmapFactory.Options 中设置 inSampleSize 的值。例如, 一个分辨率为2048x1536的图片，如果设置 inSampleSize 为4，那么会产出一个大约512x384大小的Bitmap。加载这张缩小的图片仅仅使用大概0.75MB的内存，如果是加载完整尺寸的图片，那么大概需要花费12MB（前提都是Bitmap的配置是 ARGB_8888）。下面有一段根据目标图片大小来计算Sample图片大小的代码示例：



Note: 设置inSampleSize为2的幂是因为解码器最终还是会对非2的幂的数进行向下处理，获取到最靠近2的幂的数。详情参考inSampleSize的文档。

为了使用该方法，首先需要设置 inJustDecodeBounds 为 true, 把options的值传递过来，然后设置 inSampleSize 的值并设置 inJustDecodeBounds 为 false，之后重新调用相关的解码方法。



使用上面这个方法可以简单地加载一张任意大小的图片。如下面的代码样例显示了一个接近 100x100像素的缩略图：



数据库操作没有关闭游标



释放对象引用

前面有说过，一个对象的内存没有被释放是因为他被其他的对象所引用，系统不回去释放这些有GC Root的对象。

示例A：假设有如下操作：



我们有一个成员变量 obj，在operation()中我们希望能够将处理obj实例的操作post到某个线程的MessageQueue中。在以上的代码中，即便是 mHandler所在的线程使用完了obj所引用的对象，但这个对象仍然不会被垃圾回收掉，因为DemoActivity.obj还保有这个对象的引用。 所以如果在DemoActivity中不再使用这个对象了，可以在[Mark]的位置释放对象的引用，而代码可以修改为：





示例B：假设我们希望在锁屏界面(LockScreen)中，监听系统中的电话服务以获取一些信息(如信号强度等)，则可以在LockScreen 中定义一个PhoneStateListener的对象，同时将它注册到TelephonyManager服务中。对于LockScreen对象，当需要 显示锁屏界面的时候就会创建一个LockScreen对象，而当锁屏界面消失的时候LockScreen对象就会被释放掉。

但是如果在释放LockScreen对象的时候忘记取消我们之前注册的PhoneStateListener对象，则会导致LockScreen 无法被垃圾回收。如果不断的使锁屏界面显示和消失，则最终会由于大量的LockScreen对象没有办法被回收而引起OutOfMemory,使得 system_ui进程挂掉。

总之当一个生命周期较短的对象A，被一个生命周期较长的对象B保有其引用的情况下，在A的生命周期结束时，要在B中清除掉对A的引用。

使用MAT可以很方便地查看对象之间的引用：

在Activity的生命周期中释放资源

Android应用程序中最典型的需要注意释放资源的情况是在Activity的生命周期中，在onPause()、onStop()、 onDestroy()方法中需要适当的释放资源的情况。

消除过渡绘制：

过渡绘制指的是在屏幕一个像素上绘制多次(超过一次),比如一个TextView后有背景，那么显示文本的像素至少绘了两次，一次是背景，一次是 文本。GPU过度绘制或多或少对性能有些影响,设备的内存带宽是有限的，当过度绘制导致应用需要更多的带宽(超过了可用带宽)的时候性能就会降低。带宽的 限制每个设备都可能是不一样的。

过渡绘制的原因:

同一层级的View叠加
复杂的层级叠加

减少过渡绘制能去掉一些无用的View，能有效减少GPU的负载，也可以减轻一部分内存压力：

01. 过渡绘制概念:

GPU过渡绘制的概念：GPU过度绘制指的是在屏幕一个像素上绘制多次(超过一次),比如一个TextView后有背景，那么显示文本的像素至少绘了两次，一次是背景，一次是文本。GPU过度绘制或多或少对性能有些影响,设备的内存带宽是有限的，当过度绘制导致应用需要更多的带宽(超过了可用带宽)的时候性能就会降低。带宽的限制每个设备都可能是不一样的。

过渡绘制的原因:

01. 太多的View叠加

02. 复杂的层级叠加

03. 更长的inflation时间

过渡绘制和不合理的xml布局的影响:

01. 布局文件是一个xml文件，inflate布局文件其实就是解析xml，根据标签信息创建相应的布局对象并做关联。xml中的标签和属性设置越多，节点树的深度越深，在解析时要执行的判断逻辑、函数的嵌套和递归就越多，所以时间消耗越多；

——

02. inflate操作只是布局影响的第一个环节，一个界面要显示出来，在requestLayout后还要执行一系列的measure、layout、draw的操作，每一步的执行时间都会受到布局本身的影响。而界面的最终显示是所有这些操作完成后才实现的，所以如果布局质量差，会增加每一步操作的时间成本，最终显示时间就会比较长。