RecyclerView中getPosition()过时了？手把手教你用getBindingAdapterPosition替代

RecyclerView位置获取的深度重构：告别过时方法，拥抱精准定位

最近在重构一个老项目时，RecyclerView适配器里那些熟悉的getPosition()和getAdapterPosition()方法突然都变成了灰色，IDE毫不留情地标上了“已弃用”的警告。这让我意识到，很多Android开发者可能还在沿用几年前的习惯写法，而Google在RecyclerView 1.2.0版本中引入的这套新API，其实是对位置获取逻辑的一次重要重构。今天我就结合自己踩过的坑和实际项目经验，来聊聊如何正确理解和使用这些新方法。

如果你正在维护一个老项目，或者刚接触RecyclerView不久，这篇文章会帮你理清思路。我们不仅要解决“用什么替代”的问题，更要理解“为什么需要替代”——这关系到你的列表在数据更新、动画执行时能否稳定工作，避免那些难以追踪的诡异bug。

1. 为什么老方法被弃用：理解RecyclerView的异步更新机制

要理解为什么Google要弃用getPosition()和getAdapterPosition()，得先回到RecyclerView的设计哲学上。RecyclerView的核心优势之一就是它的高效更新机制，但这种高效也带来了复杂性。

1.1 RecyclerView的更新是异步的

很多人可能没意识到，当你调用notifyItemInserted()或notifyItemRemoved()时，RecyclerView并不会立即更新所有视图的位置。相反，它会先计算一个“预布局”阶段，处理动画效果，然后再进行实际的布局更新。这个过程中，同一个item在不同阶段可能有不同的位置。

看看getPosition()被弃用的官方注释就明白了：

@Deprecated
public final int getPosition() {
    return mPreLayoutPosition == NO_POSITION ? mPosition : mPreLayoutPosition;
}

注意：这个方法已弃用，因为它的含义不明确。适配器更新是异步处理的，你应该根据具体用例使用getLayoutPosition()、getBindingAdapterPosition()或getAbsoluteAdapterPosition()。

这里的关键词是“含义不明确”。在异步更新的世界里，一个item的“位置”至少可以有两种理解：

• 它在数据源（Adapter）中的逻辑位置
• 它在当前屏幕布局中的视觉位置

这两种位置在大多数情况下是一致的，但在动画执行期间、数据更新过程中，它们可能暂时不同步。

1.2 一个常见的陷阱场景

假设你有一个聊天列表，用户长按某条消息要删除。你可能会这样写：

override fun onLongClick(view: View): Boolean {
    val position = holder.adapterPosition // 已弃用！
    if (position != RecyclerView.NO_POSITION) {
        dataList.removeAt(position)
        notifyItemRemoved(position)
    }
    return true
}

这段代码在简单场景下能工作，但如果你的列表正在执行动画（比如上一条消息刚被删除，动画还没结束），adapterPosition返回的可能不是你想要的位置。更糟糕的是，这种bug很难复现，因为它依赖于特定的时机。

1.3 新方法带来的清晰度

Google引入新方法的核心目的，就是让开发者明确知道自己想要的是哪种位置：

这种明确的区分，让代码的意图更加清晰，也减少了误解的可能性。

2. getLayoutPosition()：获取用户看到的实际位置

getLayoutPosition()可能是最直观的方法——它返回的是ViewHolder在最新一次布局计算中的位置，也就是用户当前在屏幕上看到的位置。

2.1 什么时候应该使用getLayoutPosition()

我个人的经验法则是：所有与UI直接相关的操作，都应该使用getLayoutPosition()。这包括：

• 点击事件处理（用户点击的是屏幕上显示的那个位置）
• 动画执行期间的位置获取
• 与视图状态相关的任何操作

举个例子，如果你要实现一个item的拖拽排序功能，在拖拽过程中获取的位置就应该是布局位置：

class ItemTouchHelperCallback : ItemTouchHelper.Callback() {
    
    override fun onMove(
        recyclerView: RecyclerView,
        viewHolder: RecyclerView.ViewHolder,
        target: RecyclerView.ViewHolder
    ) {
        // 获取拖拽起始位置和目标位置
        val fromPosition = viewHolder.layoutPosition
        val toPosition = target.layoutPosition
        
        // 这里使用布局位置，因为用户操作的是视觉上的位置
        if (fromPosition < toPosition) {
            for (i in fromPosition until toPosition) {
                Collections.swap(dataList, i, i + 1)
            }
        } else {
            for (i in fromPosition downTo toPosition + 1) {
                Collections.swap(dataList, i, i - 1)
            }
        }
        
        adapter.notifyItemMoved(fromPosition, toPosition)
        return true
    }
}

2.2 理解布局位置与适配器位置的差异

为了更清楚地看到两者的区别，我写了一个简单的测试：

// 模拟数据更新期间的差异
val adapter = object : RecyclerView.Adapter<ViewHolder>() {
    override fun onBindViewHolder(holder: ViewHolder, position: Int) {
        // 记录绑定时的位置
        holder.bindingPosition = position
        
        holder.itemView.setOnClickListener {
            val layoutPos = holder.layoutPosition
            val bindingPos = holder.bindingAdapterPosition
            
            Log.d("PositionTest", 
                "点击时: layoutPosition=$layoutPos, " +
                "bindingAdapterPosition=$bindingPos, " +
                "绑定时的position=$bindingPosition")
            
            // 模拟删除操作
            if (layoutPos != RecyclerView.NO_POSITION) {
                data.removeAt(layoutPos)
                notifyItemRemoved(layoutPos)