Android性能优化之UI卡顿优化实例分析

网络上有许多关于UI卡顿优化的解析，但大部分都是简单的原理介绍，例子都比较简单，每每是为了验证UI卡顿而硬造的，不能在实际场景中应用。

本文结合大图加载，与UI卡顿优化，向你们介绍UI卡顿优化的基本原理。

UI卡顿的根本缘由是UI线程没法在16ms内完成UI绘制。 下面以android大图加载为例，结合内存分析，systrace，TraceView等分析UI卡顿优化.

两种大图加载方式对比

方法1

方法一是鸿洋大神多年前写的一种使用BitmapRegionDecoder分区域加载实现大图加载的方法，详情可见如下连接

Android 高清加载巨图方案 拒绝压缩图片

源码地址可见：自定义大图加载--LagouBitmap

方法2

方法二基于SubsamplingScaleImageView这个库来实现大图加载，他主要利用了切片来实现大图加载，详细原理介绍能够见如下连接.

Android超长图加载与subsampling scale image view实现分析 使用SubSamplingScaleImageView实现加载

源码实例可见：SubSamplingScaleImageView

内存分析

分别使用两种方式加载图片，滑动后使用Profiler查看内存状况

方法1 方法2

能够看出方法一存在比较严重的内存抖动，方法二的内存较为平缓 其缘由在于方法一在内存中建立了对象，致使对象频繁建立与回收，形成内存抖动

protected void onDraw(Canvas canvas) {
 Bitmap bm = mDecoder.decodeRegion(mRect, options);  canvas.drawBitmap(bm, 0, 0, null); } 复制代码

systrace分析

方法1 方法2

能够看出，方法1存在掉帧状况，即没法在16ms内完成绘制工做，systraceView提示Long View#draw，即绘制时间过长 而方法2则不存在掉帧状况，绘制均可以在16ms内完成

方法一具体是什么问题致使了没法在16ms内绘制完成，咱们须要在TraceView中详细定位一下

TraceView分析

在TraceView中相同颜色的色块即表明一个方法的执行，能够清晰的看出图中主线程有个方法执行时间过长 点击后在下方会展现出详细的方法名，即BitmapRegionDecoder.decodeRegion方法 能够看出这是个耗时操做，在onDraw中反复调用decodeRegion方法便是掉帧的缘由

总结

1.在单纯使用BitmapRegionDecoder加载大图时，因为在onDraw中频繁建立对象会形成内存抖动，在onDraw中反复调用decodeRegion，这是个耗时操做，会致使掉帧

2.而在SubScaleSampleImageView中，将大图切片，再判断是否可见，若是可见则加入内存中，不然回收，减小了内存占用与抖动 同时根据不一样的缩放比例选择合适的采样率，进一步减小内存占用 同时在子线程进行decodeRegion操做，解码成功后回调至主线程，减小UI卡顿.