写代码这些年凡是列表里塞输入框的项目几乎都要被同一个 bug 折磨一遍明明在第一个 EditText 里输了“张三”滑下去再回来第五个输入框里也变成了“张三”。我最近接手的订单备注编辑页面就复现了这个问题测试妹子一脸无辜地甩过来录屏第一行的备注内容整整齐齐地长在了第五行的脸上。这个问题的根子不在 EditText而在 RecyclerView/ListView 的复用机制。这篇就围绕这个经典场景把病根、标准解法、高频坑位和进阶优化一次讲透。1. 复用机制导致的EditText错乱先搞清病根在哪1.1 列表项为什么会“死而复生”RecyclerView 和 ListView 的设计目标是一致的屏幕上只显示有限几个 item滚动时通过回收和复用 View 来降低内存开销。比如屏幕能放 8 个 itemRecyclerView 只会创建 8~12 个 ViewHolder多出来的位置全靠滑动时把离开屏幕的 item 的 View 挪过来接着用。这个机制本身很聪明但它有一个天然副作用item 一旦被复用它携带的所有即时状态都会跟着走。普通控件无所谓因为 onBindViewHolder 每次都会重新 setText、setImageResource 把状态重置一次。但 EditText 不一样它是用户正在交互的控件输入内容既属于 View 状态又属于数据状态。问题就出在这个交叉地带。如果在绑定 item 时没有把 EditText 的当前内容显式存到数据源里而只是“随手留在了 View 上”那这个内容就会跟着 ViewHolder 一起被搬到下一个 item 上于是出现“第一个输入框的内容长到第五个输入框脸上”的灵异现场。1.2 错乱的本质视图状态残留与绑定时序很多人一上来就怀疑是 TextWatcher 的问题其实 TextWatcher 只是帮凶真正的元凶是视图状态残留 数据绑定不彻底。举个例子item 0 的用户输入了“北京”这时候 ViewHolder A 的 EditText 内容是“北京”。用户滑走item 0 离开屏幕ViewHolder A 被回收。item 5 滑入屏幕系统把 ViewHolder A 分配给 item 5调用 onBindViewHolder 时如果开发者在绑定前没有把 editText 清空或者没有重新 setText(item5.content)那 EditText 里自然还是“北京”。更隐蔽的是时序问题。如果你给 EditText 挂了 TextWatcher 来实时更新数据源数据源里的 item5.content 确实可能已经被“北京”污染了因为 ViewHolder A 被复用到 item 5 之后EditText 显示的还是旧文本但 watcher 并没有主动触发内容没变化于是数据源和 UI 一起错。ListView 时代这个问题更严重因为 getView 里通常直接操作 convertView很多人图省事不在 convertView 为空时重置状态。RecyclerView 强制 ViewHolder 模式以后规范了一些但 EditText 这种带交互状态的控件依然防不胜防。2. 稳定解法ViewHolder模式下EditText与数据源的强绑定2.1 核心思路把输入内容当数据而不是当UI状态解决这个问题的关键认知只有一句话对于列表里的 EditTextUI 上的文字只是数据的投影数据源才是唯一可信状态。这听起来像废话但实际执行时很容易跑偏。新手最常见的做法是只在初始化时 setText 一次然后就不管了输入的内容全靠 View 自己留着。这种思路在静态列表里没问题一旦涉及复用、排序、删除、异步加载立刻炸。正确的做法是每次 onBindViewHolder 时用数据源里的字段覆盖 EditText 的显示内容每次用户输入时把 EditText 的最新内容回写到数据源对应 item 的字段里。视图负责展示数据源负责记忆两者靠绑定逻辑保持同步互不依赖。2.2 代码实现Adapter 里如何安全地处理 EditText文字不够直观直接上一份我实际在用的 Kotlin 写法。这个写法处理了三个关键点复用前移除旧监听器、内容回填时避免重复触发、光标位置保持。class EditableAdapter( private val dataList: MutableListEditModel ) : RecyclerView.AdapterEditableAdapter.EditorHolder() { inner class EditorHolder(val binding: ItemEditBinding) : RecyclerView.ViewHolder(binding.root) override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): EditorHolder { val binding ItemEditBinding.inflate( LayoutInflater.from(parent.context), parent, false ) return EditorHolder(binding) } override fun getItemCount(): Int dataList.size override fun onBindViewHolder(holder: EditorHolder, position: Int) { val item dataList[position] val editText holder.binding.etContent // 1. 先移除旧 watcher防止叠加触发 val oldWatcher editText.getTag(R.id.tag_watcher) as? TextWatcher oldWatcher?.let { editText.removeTextChangedListener(it) } // 2. 仅当内容不一致时才回填避免不必要的 setText val currentText editText.text?.toString().orEmpty() if (currentText ! item.content) { editText.setText(item.content) // 3. 回填后把光标移到最后避免重新绑定时光标跳到开头 editText.setSelection(editText.text?.length ?: 0) } // 4. 创建新 watcher只负责回写数据源 val watcher object : TextWatcher { override fun beforeTextChanged(s: CharSequence?, start: Int, count: Int, after: Int) {} override fun onTextChanged(s: CharSequence?, start: Int, before: Int, count: Int) {} override fun afterTextChanged(s: Editable?) { val pos holder.bindingAdapterPosition if (pos ! RecyclerView.NO_POSITION) { dataList[pos].content s?.toString().orEmpty() } } } editText.addTextChangedListener(watcher) editText.setTag(R.id.tag_watcher, watcher) } }配套的数据模型data class EditModel( val id: Long, var content: String )几个细节需要解释一下。关于移除旧 watcheronBindViewHolder 每次被调用时如果之前已经 add 过一次 watcher再 add 就会造成两个 watcher 同时监听同一个 EditText。后果是 afterTextChanged 里回写数据源时被执行两次虽然结果相同但如果你在回调里做了计数、长度限制、动态计算等逻辑就等着被 bug 追着跑吧。把 watcher 存在 view 的 tag 里绑定前先 remove 掉这是最稳的清理方式。关于 setText 的条件判断每次 onBindViewHolder 就无条件 setText 一次看起来没问题但 setText 会触发 TextWatcher从而走进 afterTextChanged 回写数据源。这时候如果数据源里的内容和 EditText 当前显示的内容一致就白触发一次还会造成不必要的性能开销。加上内容判断只在真正需要回填时 setText既省事又干净。2.3 为什么 setSelection 能避免“光标跳开头”的诡异现象这个小坑很容易被忽略。当 EditText 被复用并重新 setText 时如果原来的光标位置比新文本长度大系统可能会把光标重置到文本开头或者定位到末尾附近。用户在编辑一半时滑动一下再回来光标突然跳到第 0 位后续输入的内容全跑到最前面体验极其割裂。绑定后统一 setSelection(editText.text.length)至少保证每次重新绑定时光标在最后这是列表输入场景下最省心的策略。当然如果你想恢复用户离开时的精确光标位置可以把 selectionStart 也存进数据模型但这属于过度设计的范畴一般情况下真没必要。3. 高频坑位复盘TextWatcher重复触发与position错位的真实场景3.1 多个 TextWatcher 叠加回调次数翻倍的暗雷我在给一个模拟项目做代码审查时看到过这样的写法onCreateViewHolder 里给 EditText add 了一个 watcheronBindViewHolder 里又 add 了一个。因为 ViewHolder 本身是复用的onCreateViewHolder 只执行一次这个还能忍。但另一个项目是在 onBindViewHolder 里直接 add没有移除结果同一个 EditText 上挂了 3 个 watcher 之后每次输入一个字符同一个回调逻辑被反复执行。最直接的症状是输入框内文字长度显示翻倍、字数统计异常、每次删除字符时数据源被回写多次。排查思路其实很简单在 watcher 回调第一行打日志连续输入几个字符看日志条数。如果按一次键盘冒了两三行日志说明 watcher 叠加了。解决办法就是我在 2.2 的写法里展示的绑定前先 remove 旧的再 add 新的保证同一个 ViewHolder 的 EditText 上永远只有一个活跃 watcher。3.2 setText 回填触发 watcher 导致的“数据打架”假设你按标准写法做了数据绑定onBindViewHolder 里 setText(item.content)。这时候 watcher 会被触发走到 afterTextChanged把 item.content 又写回 dataList[pos].content。如果这一切发生在绑定过程中问题还不大因为内容一致。但如果你在 setText 之后、watcher 还没触发完之前又对 item 做了其他操作比如根据输入长度控制“还剩多少字”的提示文字此时 oldText 和 newText 同时存在你拿到的 s 可能是新值而 item 里还是旧值UI 就会闪一下。更危险的是如果 onBindViewHolder 里 setText 了一个格式化后的字符串比如加了千分位分隔符watcher 回写时把这个带格式的字符串存进数据源下一次绑定时 setText 又会触发一次格式化反复横跳之后数据就彻底脏了。我的建议是TextWatcher 回写的是用户的原始输入不要在 watcher 里做格式化格式化只发生在展示层。如果确实需要格式化再回填加一个 boolean 标志位比如 isBinding在 setText 之前置 trueafterTextChanged 里判断如果是绑定阶段就直接 return不执行数据回写。private var isBinding false // onBindViewHolder 内 isBinding true editText.setText(item.content) isBinding false // watcher 内 override fun afterTextChanged(s: Editable?) { if (isBinding) return // 真正处理用户输入 }3.3 滑动到底部再滑回来输入内容为什么凭空消失这个问题和错乱是一体两面。如果 onBindViewHolder 里没有用数据源回填 EditText而是只执行了一次 setText之后全靠用户手动输入那滑动后 item 被回收、再滑回来重新绑定时EditText 已经被重置了。没有数据源兜底内容自然消失。我见过一个下午都在排查此事的同学他的代码里数据源也有onBindViewHolder 也写了 setText但用户输入时没写回数据源只在点击“保存”按钮时才一次性遍历所有 ViewHolder 来取值。中间任何一次滑动数据源里的字段都是空字符串来回滑两下输入内容就全没了。这类问题的判断标准很简单用户输入一个字数据源立刻更新一个字而不是等提交时才同步。如果你还在用“保存时遍历 ViewHolder”的方案强烈建议改成实时回写因为 ViewHolder 根本不是可靠的数据容器。3.4 异步加载时 position 错位回调鬼影还有一种错位和 EditText 本身无关但会直接影响列表内容的准确性异步回调里直接使用 onBindViewHolder 传进来的 position。比如你在绑定 item 时发起一个网络请求请求返回后根据 position 更新那个 item 的文本。但由于 RecyclerView 的 item 在滑动后 position 会变回调来临时的 position 可能已经指向另一个 item 了于是新的文本被设置到错误的输入框里。现在标准的做法是不要在异步回调里用 position改用 ViewHolder 或稳定 id。如果你用 ViewHolder 作为 key回调前先判断 holder 是否还是当前 item 的 holderoverride fun onBindViewHolder(holder: EditorHolder, position: Int) { val item dataList[position] // 异步请求回来后只更新数据源 fetchData(item.id) { result - dataList[position].content result // 若该 holder 还停留在同一个 item 上再刷新视图 if (holder.bindingAdapterPosition position) { editText.setText(result) } } }这套逻辑的核心是数据源永远先更新视图刷新必须校验 holder 是否仍然对应同一个位置。4. 进阶优化防抖刷新、局部刷新与跨列表复用的边界处理4.1 输入防抖与延迟同步避免全局刷新卡顿有些需求是 EditText 内容变化后要实时更新 item 里的其他区域比如输入备注时同步显示“当前已输入 N 字”或者输入标题时预览文章标题。如果每次 afterTextChanged 里都调用 notifyDataSetChanged()性能会非常差因为输入一个字符就会触发全列表重绘而且 EditText 会丢失焦点用户根本没法连续输入。更合理的做法是输入过程中只更新 dataList[pos] 里的字段让 EditText 自己负责展示用户已经在 EditText 里看到自己的输入了其他展示区域的数据依赖则用局部刷新或者用一个极短的防抖延迟例如 200~300ms做一次轻量同步。我自己常用的防抖写法private val syncRunnable HashMapInt, Runnable() private val handler Handler(Looper.getMainLooper()) // afterTextChanged 内 val pos holder.bindingAdapterPosition dataList[pos].content s?.toString().orEmpty() // 取消旧任务300ms 后再更新相关区域 syncRunnable[pos]?.let { handler.removeCallbacks(it) } val task Runnable { notifyItemChanged(pos, PAYLOAD_CONTENT) } syncRunnable[pos] task handler.postDelayed(task, 300L)注意这里的 notifyItemChanged 用了 payload这意味着 onBindViewHolder 里需要处理 partial bind。这样输入过程中列表不会疯狂重绘停顿 300ms 后相关区域才刷新一次焦点也基本不会被打断。4.2 局部刷新与 payload 机制不打断输入的刷新姿势RecyclerView 的 payload 是个好东西。普通的 notifyItemChanged 会走完整的 onBindViewHolder默认所有内容都会被重新绑定EditText 焦点大概率保不住。而带 payload 的 notifyItemChanged(pos, payload) 只更新和这个 payload 相关的部分。在 onBindViewHolder 里重写带 payload 的重载方法override fun onBindViewHolder( holder: EditorHolder, position: Int, payloads: MutableListAny ) { if (payloads.isNotEmpty()) { // 局部刷新只需要更新相关 UI不要动 EditText val payload payloads.first() as? String if (payload PAYLOAD_CONTENT) { holder.binding.tvCount.text ${dataList[position].content.length}/200 } return } super.onBindViewHolder(holder, position, payloads) }这个方式能极大减少 EditText 被重新 setText 的次数焦点、光标、输入法状态都能保持稳定。如果你项目里输入框联动刷新很频繁这属于必会的技能。4.3 跨列表、跨页面复用时维护 item 状态的边界如果是 ViewPager2 嵌套 RecyclerView或者多个列表共享同一份数据源复用的范围就不仅限于单个 RecyclerView 了。ViewPager2 默认会预加载相邻页面的列表而多个列表的 item 可能共用同一个 ViewHolder 池错乱的概率更高。这种场景下我的建议是一定要保证数据源里存了完整的输入内容绑定逻辑按 id 而不是 position 定位。两个列表对应同一个 id 的 item 时它们各自 EditText 的显示内容都应该来自同一个数据字段谁输入了另一个下次绑定时就跟着变。另外在页面切换比如 Fragment 销毁重建、ViewPager 切换 tab时要主动把 EditText 的当前内容回写到数据源不要依赖 watcher 的被动触发。因为页面销毁时 watcher 可能已经被回收最后一次输入的内容会丢。4.4 生命周期与内存回收防止 watcher 泄漏最后一个容易被忽视的点TextWatcher 持有 ViewHolder 的引用而 ViewHolder 持有 EditText如果 watcher 没有被移除可能会造成短期泄漏。尤其是在快速滚动的列表里复用频率高、watcher 创建销毁频繁虽然大多数情况下对象的生命周期会随着 View 一起结束但保守起见建议在 onViewDetachedFromWindow 或 Fragment 销毁时做一次清理。如果你用的是我在 2.2 里的写法watcher 每次绑定时都会先移除旧的再 add 新的其实已经把泄漏窗口压到很小了。如果实在不放心可以给 ViewHolder 写一个 release() 方法在 onViewRecycled 里调用把 EditText 上的 watcher 全部移除顺便清空文本让回收的 ViewHolder 以“干净”的状态进入复用池。override fun onViewRecycled(holder: EditorHolder) { super.onViewRecycled(holder) holder.binding.etContent.removeTextChangedListener( holder.binding.etContent.getTag(R.id.tag_watcher) as? TextWatcher ) holder.binding.etContent.setText() }这不算强制要求但我习惯在涉及长列表、大量输入框的场景里加上它多一道保险心里踏实。最后再多说一句个人体会。列表里出现 EditText本质上说明这块业务的数据结构是活的、可编辑的。与其在 View 层反复打补丁不如一开始就把数据模型设计成一个干净的“可编辑实体”让 ViewHolder 退化成纯展示层让数据源成为唯一真相。想清楚这一点很多纠缠不清的 bug 都会自动消失。
