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

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

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

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

两种大图加载方式对比

方法1

Android 高清加载巨图方案 拒绝压缩图片 使用BitmapRegionDecoder分区域加载 源码地址可见：自定义大图加载--LagouBitmap

方法2

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卡顿.