Kotlin indexOf性能优化：RecyclerView判断登录用户是否在Post点赞User数组

现有实现的性能问题 #

• 直接对帖子点赞数组调用indexOf(currentUser)判断点赞状态的逻辑存在不必要的开销：由于User是Kotlin data class，indexOf底层会触发User类的全字段equals比对，也就是每次匹配都要依次比对id、username、fullname、email、bio5个字段的值。对于1k规模的点赞数组来说，这些重复的全字段比对会叠加到RecyclerView的item绑定流程中，快速滑动列表时容易造成不必要的掉帧。
• 原User类定义存在语法小问题：代码中val email: String?行末尾缺少逗号，会导致编译报错，补全后的正确类结构如下：

data class User(
    val id: String,
    val username: String?,
    val fullname: String?,
    val email: String?,
    val bio: String?
)

可落地的优化方案 #

• 仅匹配唯一业务标识，绕开全字段比对
  不需要传入完整的当前登录User对象做equals匹配，直接提取当前用户的唯一id，用likeList.any { it.id == currentLoginUserId }判断是否点赞即可。毕竟User的id是全局唯一的主键，这个判断逻辑和全字段比对的结果完全等价，但每次比对只需要做单个字符串的相等判断，性能比全字段比对高一个数量级。
• 预转换为集合结构，把查询复杂度从O(n)降到O(1)
  在数据层加载每个帖子的点赞数据时，提前提取所有点赞用户的id，构造一个不可变的Set<String>类型的likedUserIdSet存在帖子实体里。绑定item时直接用currentLoginUserId in post.likedUserIdSet判断状态，Set的contains操作是常量时间复杂度，哪怕单帖子有1w个点赞用户，查询也没有任何性能压力，完全不需要遍历数组。
• 规避重复计算
  不要在onBindViewHolder方法里临时遍历点赞数组、临时构造id集合，所有预处理逻辑放在数据加载阶段完成，item绑定阶段只做轻量的状态判断即可。

1k规模数据的性能达标性说明 #

• 就算不做集合结构转换，单纯拿当前登录用户的id遍历1k个User对象做单字段比对，单item的查询耗时也就0.1ms不到，远低于RecyclerView单item绑定的16ms性能预算（要撑住60帧流畅滚动），完全够线上用。
• 原有的全字段indexOf实现，1k次全字段判断下来大概要花0.5-1ms，虽然也不至于卡到不能用，但纯纯是没必要的性能浪费，没有保留的价值。

内容的提问来源于stack exchange，提问作者nasibeyyubov