Jetpack Compose 的 TextField 性能，长文本输入的卡顿

Jetpack Compose 的 TextField 性能，长文本输入的卡顿

如果你用 Jetpack Compose 写过带输入功能的页面，比如一个笔记编辑器、长文本表单或者代码输入框，大概率碰到过这种场景：当字符数累积到两三千字之后，每敲一个新字，光标开始不跟手，键盘震动的反馈已经响了，字符却迟半拍才蹦到屏幕上。更糟的是在段落中间插入文字，整个界面甚至会轻微冻结。这不是你的写法不对，这是 Compose TextField 从 1.0 到 1.4 时代一直没根治的老毛病。Google 不是不知道，Issue Tracker 上相关的性能报告和 ANR 日志早就堆了几百条，但修复的节奏始终慢得让人失去耐心。

TextField 的重组陷阱：为什么每敲一个键都在重写全文

Compose 的 TextField 是个完全受控组件，它要求你提供 value: String 和 onValueChange: (String) -> Unit。这个设计看起来简单干净，但在底层却埋了雷。因为 String 在 Kotlin 里是不可变的，每次输入一个字符，onValueChange 返回的都是一个全新的 String 对象。这个对象被写到 State 里，触发重组，TextField 读取新值，重新走一遍 Layout 和 Draw。

短文本时这没问题，重组开销低得可以忽略。但一旦文本长度上去，问题就来了。TextField 内部并不只是“把新字符串贴上去”，它要重新测量文本尺寸（调用 Android 底层的 TextMeasurer 或 StaticLayout），要更新布局节点，要刷新语义树给无障碍用，还要保证光标和选择区域的位置正确。也就是说，你敲一个字，它可能把整段几千字的布局重算了一遍。View 系统的 EditText 也走测量，但人家有十年的增量优化，文本缓冲区通过 Editable 和 Spannable 原地修改，大部分情况下只触发重绘而不是完整重新布局。Compose 的声明式架构在这里反而成了累赘——状态一变，整个管道都得配合演出。

更隐蔽的是，如果你老老实实按照官方文档做状态提升，把字符串状态放到 ViewModel 里的 MutableStateFlow 或者直接用 mutableStateOf 托管，等于每次输入都要跨层发射一次状态更新。Compose Runtime 的 Snapshot 系统虽然高效，但也不是零成本。长文本意味着大对象频繁创建和比对，主线程上的时间片就这样被一点点蚕食。到头来你发现，自己明明没写什么复杂业务逻辑，只是接了个输入框，却能把 120Hz 屏幕卡成 30Hz。

IME 同步：InputConnection 是另一座大山

输入卡顿不只是 Compose 内部重组的锅，输入法框架（IME）的交互同样拖后腿。Android 的 IME 通过 InputConnection 与目标编辑器通信，Compose TextField 需要自己实现一套桥接逻辑，把 Compose 世界的 TextFieldValue（包含 text、selection、composition range）同步给 Android 的 InputMethodManager。

这个同步过程在长文本下极其痛苦。IME 为了做候选词预测和联想，会高频调用 getTextBeforeCursor、getTextAfterCursor 和 getSelectedText。如果当前文本有五千字，光标又在文档末尾，IME 每次调用都可能