RecyclerView 性能优化 | 把加载表项耗时减半 (二)

上一篇介绍了如何高效地量化绘制性能，并对 RecyclerView 加载速度做了 2 次优化，使得表项加载耗时从 370 ms 缩减到 288 ms。这一篇继续介绍后续的 2 种优化手段。把这些优化叠加在一起，就能实现加载耗时减半的效果。

这次性能调优的界面如下：

界面用列表的形式，展示了一个主播排行榜。

先回顾下上一篇做的两次优化：

1. 用动态构建布局取代 xml，蒸发 IO 和 反射的性能损耗，缩短构建表项布局耗时。
2. 替换表项根布局，由更简单的PercentLayout取代ConstraintLayout，以缩短 measure + layout 时间。

关于这两点的详细讲解可以点击RecyclerView 性能优化 | 把加载表项耗时减半 (上)

耗时的 Glide 首次异步加载

如上图所示，每个表项有两张图片的内容来自网路，使用 Glide 进行异步加载。

我把替换表项根布局的思路沿用到图片加载上：是不是因为 Glide 太复杂导致onBindViewHolder()执行太久？

做一个实验，把注释掉图片加载，再跑一遍 demo：

measure + layout=160,     unknown delay=19,     anim=0,    touch=0,     draw=12,  total=161
measure + layout=0,     unknown delay=134,     anim=2,    touch=0,     draw=0,    total=138
measure + layout=0,     unknown delay=0,     anim=0,    touch=0,     draw=0,   total=3
复制代码

令我感到吃惊的是，measure + layout耗时一下子从 288 ms 缩减到 160 ms。原来加载图片对列表加载性能影响如此之大！

我在onBindViewHolder()的前后打了 log，以便更直观的检测 Glide 加载图片对性能的影响：

class RankProxy : VarietyAdapter.Proxy<Rank, RankViewHolder>() {
    // 构建表项
    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): RecyclerView.ViewHolder {...}

    // 绑定表项数据
    override fun onBindViewHolder(holder: RankViewHolder, data: Rank, index: Int, action: ((Any?) -> Unit)?) {
        // 开始计时
        val start = System.currentTimeMillis()
        holder.tvCount?.text = data.count.formatNums()
        // Glide 加载第一张图片
        holder.ivAvatar?.let {
            Glide.with(holder.ivAvatar.context).load(data.avatarUrl).into(it)
        }
        // Glide 加载第二张图片
        holder.ivLevel?.let {
            Glide.with(holder.ivLevel.context).load(data.levelUrl).into(it)
        }
        holder.tvRank?.text = data.rank.toString()
        holder.tvName?.text = data.name
        holder.tvLevel?.text = data.level.toString()
        holder.tvTag?.text = data.tag
        // 结束计时
        Log.w("test", "bind view duration = ${System.currentTimeMillis() - start}")
    }
}
复制代码

运行 demo，log 如下：

03-20 18:22:04.243 17994 17994 W ttaylor : rank bind view duration = 41
03-20 18:22:04.252 17994 17994 W ttaylor : rank bind view duration = 2
03-20 18:22:04.261 17994 17994 W ttaylor : rank bind view duration = 2
03-20 18:22:04.270 17994 17994 W ttaylor : rank bind view duration = 1
03-20 18:22:04.279 17994 17994 W ttaylor : rank bind view duration = 1
...
复制代码

绑定列表第一个表项特别耗时！而且是很夸张的 41 ms，这让我好奇 Glide 第一次启动时做了些啥？

经过一番 Glide 源码的走查（过程略），我发现 Glide 会启动一个叫GlideExecutor的线程池来进行图片的异步加载。

线程池的构建是昂贵的，耗时的。

有没有什么办法让 Glide 不使用自己的线程池，而使用整个 App 通用的线程池进行加载？

我想到的解决方案是：“在协程中，使用 Glide 的同步方法加载图片。”

为ImageView新增一个扩展方法：

fun ImageView.load(url: String) {
    viewScope.launch {
        val bitmap = Glide.with(context).asBitmap().load(url).submit().get()
        withContext(Dispatchers.Main) { setImageBitmap(bitmap) }
    }
}
复制代码

扩展方法启动了一个协程并使用 Glide 的submit()加载图片，这个方法会返回一个FutureTarget，调用它的get()就可以同步地获得 Bitmap 对象。然后切换到主线程将其设置给 ImageView。

其中的viewScope是一个CoroutineScope对象，我把它声明为View的扩展属性。

val View.viewScope: CoroutineScope
    get() {
        // 获取现有 viewScope 对象
        val key = "ViewScope".hashCode()
        var scope = getTag(key) as? CoroutineScope
        // 若不存在则新建 viewScope 对象
        if (scope == null) {
            scope = CoroutineScope(SupervisorJob() + Dispatchers.IO)
            // 将 viewScope 对象缓存为 View 的 tag
            setTag(key,scope)
            val listener = object : View.OnAttachStateChangeListener {
                override fun onViewAttachedToWindow(v: View?) {
                }

                override fun onViewDetachedFromWindow(v: View?) {
                    // 当 view detach 时 取消协程的任务
                    scope.cancel()
                }

            }
            addOnAttachStateChangeListener(listener)
        }
        return scope
    }
复制代码

viewScope这个扩展属性的语义是：“每个 View 都有一个和它生命周期绑定的 CoroutinScope 用于启动协程”。这种动态扩展类并绑定生命周期的写法是参照了ViewModelScope，详细讲解可以点击读源码长知识 | 动态扩展类并绑定生命周期的新方式。

用新的扩展函数重写onBindViewHolder()：

class RankProxy : VarietyAdapter.Proxy<Rank, RankViewHolder>() {
    override fun onBindViewHolder(holder: RankViewHolder, data: Rank, index: Int, action: ((Any?) -> Unit)?) {
        holder.tvCount?.text = data.count.formatNums()
        holder.ivAvatar?.load(data.avatarUrl)// 使用协程加载图片
        holder.ivLevel?.load(data.levelUrl)// 使用协程加载图片
        holder.tvRank?.text = data.rank.toString()
        holder.tvName?.text = data.name
        holder.tvLevel?.text = data.level.toString()
        holder.tvTag?.text = data.tag
    }
}
复制代码

运行一下 demo，看看数据：

measure + layout=251,     unknown delay=19,     anim=0,    touch=0,     draw=12,  total=300
measure + layout=0,     unknown delay=290,     anim=2,    touch=0,     draw=0,    total=321
measure + layout=0,     unknown delay=0,     anim=0,    touch=0,     draw=0,   total=3
复制代码

measure + layout时间从 288 ms 缩减到 251 ms，往减半又迈出了一步。

表项数量影响绘制性能

在之前一系列 RecyclerView 源码阅读过程中，得出很多结论，其中有一个结论和加载性能有关：

填充表项是一个 while 循环，有多少表项需要被填充，就会循环多少次。

源码如下：

public class LinearLayoutManager {
    // 根据剩余空间填充表项
    int fill(RecyclerView.Recycler recycler, LayoutState layoutState,RecyclerView.State state, boolean stopOnFocusable) {
        ...
        // 计算剩余空间
        int remainingSpace = layoutState.mAvailable + layoutState.mExtraFillSpace;
        // 循环，当剩余空间 > 0 时，继续填充更多表项
        while ((layoutState.mInfinite || remainingSpace > 0) && layoutState.hasMore(state)) {
            ...
            // 填充单个表项
            layoutChunk(recycler, state, layoutState, layoutChunkResult)
            ...
        }
    }
    
    // 填充单个表项
    void layoutChunk(RecyclerView.Recycler recycler, RecyclerView.State state,LayoutState layoutState, LayoutChunkResult result) {
        // 1.获取下一个该被填充的表项视图 onCreateViewHolder(), onBindViewHoder() 在这里被调用
        View view = layoutState.next(recycler);
        // 2.使表项成为 RecyclerView 的子视图
        addView(view);
        ...
    }
}
复制代码

onCreateViewHolder()和onBindViewHoder()都会在这个循环中被调用。所以，表项越多，绘制越耗时。

立马做了实验，先让整个屏幕只显示 2 个表项：

增加了 RecyclerView 的上边距，让整个屏幕中只显示了 2 个表项，看一眼性能日志：

measure + layout=120,   anim=0,    touch=0,     draw=1,    first draw = false   total=126
measure + layout=0,    anim=0,    touch=0,     draw=0,    first draw = false   total=124
measure + layout=12,    anim=0,    touch=0,     draw=0,    first draw = true    total=15
复制代码

measure + layout只用了 120 ms（关于如何获取性能日志可以点击RecyclerView 性能优化 | 把加载表项耗时减半 (上)）

为了优化首次加载列表的性能，可不可以把第一屏的所有表项都合并成一个表项？

列表数据是服务器返回的，个数是可变的。如果用 xml 静态地构建布局就无法做到动态地合并表项，遂只能通过 Kotlin DSL 动态地构建表项：

class RankProxy : VarietyAdapter.Proxy<RankBean, RankViewHolder>() {
    // 构建表头视图
    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): RecyclerView.ViewHolder {
        val itemView = parent.context.run {
            LinearLayout { // 构建 LinearLayout
                layout_id = "container"
                layout_width = match_parent
                layout_height = wrap_content
                orientation = vertical
                margin_start = 20
                margin_end = 20
                padding_bottom = 16
                shape = shape {
                    corner_radius = 20
                    solid_color = "#ffffff"
                }

                PercentLayout { // 构建 PercentLayout
                    layout_width = match_parent
                    layout_height = 60
                    shape = shape {
                        corner_radii = intArrayOf(20, 20, 20, 20, 0, 0, 0, 0)
                        solid_color = "#ffffff"
                    }

                    TextView { // 构建 TextView
                        layout_id = "tvTitle"
                        layout_width = wrap_content
                        layout_height = wrap_content
                        textSize = 16f
                        textColor = "#3F4658"
                        textStyle = bold
                        top_percent = 0.23f 
                        start_to_start_of_percent = parent_id 
                        margin_start = 20
                    }

                    TextView { // 构建 TextView
                        layout_id = "tvRank"
                        layout_width = wrap_content
                        layout_height = wrap_content
                        textSize = 11f
                        textColor = "#9DA4AD"
                        left_percent = 0.06f 
                        top_percent = 0.78f 
                    }

                    TextView { // 构建 TextView
                        layout_id = "tvName"
                        layout_width = wrap_content
                        layout_height = wrap_content
                        textSize = 11f
                        textColor = "#9DA4AD"
                        left_percent = 0.18f 
                        top_percent = 0.78f 
                    }

                    TextView { // 构建 TextView
                        layout_id = "tvCount"
                        layout_width = wrap_content
                        layout_height = wrap_content
                        textSize = 11f
                        textColor = "#9DA4AD"
                        margin_end = 20
                        end_to_end_of_percent = parent_id 
                        top_percent = 0.78f 
                    }
                }
            }
        }
        return RankViewHolder(itemView)
    }
}

// 表项实体类
data class RankBean(
    val title: String,
    val rankColumn: String,
    val nameColumn: String,
    val countColumn: String,
    val ranks: List<Rank> // 所有主播信息
)

// 主播信息实体类
data class Rank(
    val rank: Int,
    val name: String,
    val count: Int,
    val avatarUrl: String,
    val levelUrl: String,
    val level: Int ,
    val tag: String
)

class RankViewHolder(itemView: View) : RecyclerView.ViewHolder(itemView) {
    val tvTitle = itemView.find<TextView>("tvTitle")
    val tvRankColumn = itemView.find<TextView>("tvRank")
    val tvAnchormanColumn = itemView.find<TextView>("tvName")
    val tvSumColumn = itemView.find<TextView>("tvCount")
    val container = itemView.find<LinearLayout>("container")
}
复制代码

使用 DSL 在onCreateViewHolder()中动态构建了表头：

表头是列表中静态的部分，这部分数据不依赖服务器返回。整个 item 是一个纵向的LinearLayout，这为动态地纵添加表项提供了方便。

数据结构也得重构一下，把服务器返回的List<Rank>结构包在一个更大的RankBean结构中。以便在一次onBindViewHolder()中获取所有的主播排名信息，然后遍历List<Rank>，逐个构建表项视图并填充到LinearLayout中：

class RankProxy : VarietyAdapter.Proxy<RankBean, RankViewHolder>() {
    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): RecyclerView.ViewHolder {
        // 构建表头及容器
    }
    
    // 动态构建表项并同时绑定数据
    override fun onBindViewHolder(holder: RankViewHolder, data: RankBean, index: Int, action: ((Any?) -> Unit)?) {
        holder.tvAnchormanColumn?.text = data.nameColumn
        holder.tvRankColumn?.text = data.rankColumn
        holder.tvSumColumn?.text = data.countColumn
        holder.tvTitle?.text = data.title

        holder.container?.apply {
            // 遍历所有主播
            data.ranks.forEachIndexed { index, rank ->
                // 为每一个主播数据构造一个 PercentLayout
                PercentLayout {
                    layout_width = match_parent
                    layout_height = 35
                    background_color = "#ffffff"

                    TextView { // 构建排名控件
                        layout_id = "tvRank"
                        layout_width = 18
                        layout_height = wrap_content
                        textSize = 14f
                        textColor = "#9DA4AD"
                        left_percent = 0.08f
                        center_vertical_of_percent = parent_id
                        text = rank.rank.toString()
                    }

                    ImageView { // 构建头像控件
                        layout_id = "ivAvatar"
                        layout_width = 20
                        layout_height = 20
                        scaleType = scale_center_crop
                        center_vertical_of_percent = parent_id
                        left_percent = 0.15f
                        Glide.with(this.context).load(rank.avatarUrl).into(this)
                    }

                    TextView { // 构建姓名控件
                        layout_id = "tvName"
                        layout_width = wrap_content
                        layout_height = wrap_content
                        textSize = 11f
                        textColor = "#3F4658"
                        gravity = gravity_center
                        maxLines = 1
                        includeFontPadding = false
                        start_to_end_of_percent = "ivAvatar"
                        top_to_top_of_percent = "ivAvatar"
                        margin_start = 5
                        ellipsize = TextUtils.TruncateAt.END
                        text = rank.name
                    }

                    TextView { //构建标签控件
                        layout_id = "tvTag"
                        layout_width = wrap_content
                        layout_height = wrap_content
                        textSize = 8f
                        textColor = "#ffffff"
                        text = "save"
                        gravity = gravity_center
                        padding_vertical = 1
                        includeFontPadding = false
                        padding_horizontal = 2
                        shape = shape {
                            corner_radius = 4
                            solid_color = "#8cc8c8c8"
                        }
                        start_to_start_of_percent = "tvName"
                        top_to_bottom_of_percent = "tvName"
                    }

                    ImageView { // 构建等级图标控件
                        layout_id = "ivLevel"
                        layout_width = 10
                        layout_height = 10
                        scaleType = scale_fit_xy
                        center_vertical_of_percent = "tvName"
                        start_to_end_of_percent = "tvName"
                        margin_start = 5
                        Glide.with(this.context).load(rank.levelUrl).submit()
                    }

                    TextView { // 构建等级标签控件
                        layout_id = "tvLevel"
                        layout_width = wrap_content
                        layout_height = wrap_content
                        textSize = 7f
                        textColor = "#ffffff"
                        gravity = gravity_center
                        padding_horizontal = 2
                        shape = shape {
                            gradient_colors = listOf("#FFC39E", "#FFC39E")
                            orientation = gradient_left_right
                            corner_radius = 20
                        }
                        center_vertical_of_percent = "tvName"
                        start_to_end_of_percent = "ivLevel"
                        margin_start = 5
                        text = rank.level.toString()
                    }

                    TextView { // 构建粉丝数控件
                        layout_id = "tvCount"
                        layout_width = wrap_content
                        layout_height = wrap_content
                        textSize = 14f
                        textColor = "#3F4658"
                        gravity = gravity_center
                        center_vertical_of_percent = parent_id
                        end_to_end_of_percent = parent_id
                        margin_end = 20
                        text = rank.count.formatNums()
                    }
                }
            }
        }
    }
}
复制代码

运行 demo，看下数据：

measure + layout=170,     unknown delay=41,     anim=0,    touch=0,     draw=18, total= 200
measure + layout=0,     unknown delay=250,     anim=1,    touch=0,     draw=0,   total=289
measure + layout=4,     unknown delay=4,     anim=0,    touch=0,     draw=2,    total=13
measure + layout=4,     unknown delay=0,     anim=0,    touch=0,     draw=1,    total=13
复制代码

measure + layout耗时一下从 251 ms，缩减到 170 ms，提升巨大。

可见，显示在屏幕上的表项数量对列表绘制性能影响很大，数量越多绘制越慢。

虽然这个做法，让首次加载 RecyclerView 提速不少，但也有缺点。它为列表新增了一种表项类型，而且这个表项的 ViewHolder 持有超多的 View，难免增加内存压力。并且它无法被后续表项复用。

这个做法对于 Demo 这种场景，也不失为一种优化加载速度的方法，即将可能显示在首屏的表项都合并一个新的表项类型，当下拉刷新时，还是正常的一个个加载原有的表项。

总结

经过了 4 次优化，把列表首次加载时间从 370 ms 缩短到 170 ms，有 54% 的提升。回顾一下这 4 次优化：

1. 用动态构建布局取代 xml，蒸发 IO 和 反射的性能损耗，缩短构建表项布局耗时。
2. 替换表项根布局，由更简单的PercentLayout取代ConstraintLayout，以缩短 measure + layout 时间。
3. 使用协程 + Glide 同步加载方法，以缩减加载图片耗时。
4. 将列表首屏显示的表项合并成一个新的表项类型，以缩短填充表项耗时。

作者：唐子玄
链接：https://juejin.cn/post/6942276625090215943
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。