阅读 1100

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