能编辑多大的文件？

SFTP 浏览器不用离开应用就能编辑远程文本文件：下载、在编辑器里改、再覆盖上传回去。只有小于上限的文件才会出现编辑这一项——而上限是一个承诺：低于它的文件都能打开、都能输入。

定得太低，本来能轻松编辑的文件被挡在外面；定得太高，用户点开文件却发现打字跟不上，那比一开始就不提供更糟。

我们原来的值是手机 128 KB、桌面 512 KB，两个都是凭感觉定的。连我们自己那份「换掉编辑器」的内部计划里写的「超过 10 KB 就开始退化」，也出自同一个来源：没有人真的拿秒表量过。所以我们把秒表做进了应用里。

编辑大文件真正贵的部分不在我们的代码里。ArkUI 的文本框会对整篇文档做排版，并且在每一次按键时把整篇文档作为一个新字符串交回 JavaScript。这两件事都不会出现在我们给自己函数加的计时里——它们发生在回调返回之后、UI 线程上。而你真正感觉到的恰恰就是这个：线程忙住了，界面不动了。

手机模拟器上的一次完整运行。打开是文件打开时最长的一次卡顿，按键是在文档中间输入一个字符引起的帧间隔中位数，最差一帧是其中最慢的一次，内存是排完版的文档给进程增加的占用。

曲线是一条直线：在一帧的地板之上，每千字节约 0.55 ms 的输入延迟。其中大约十分之一是我们自己的——统计行数、算出光标的行列位置——其余属于平台的文本引擎。所以这个数字会随编辑器引擎的更换而变，而不会因为我们调优 ArkTS 而变。

有两件事在任何大小下都是免费的：查找，以及跳到匹配处。在 1 MB 的文件里滚到一兆之外的命中处只花了一帧，和 8 KB 时一样。

两个上限、一次实测，外加一件本以为需要单独规则、结果并不需要的事。

这些数字来自模拟器，不是来自真机。表格出自 DevEco 的手机镜像（Pura 90），桌面那一组对照出自二合一镜像（MateBook Pro），两者都跑在一台 Apple Silicon 的 Mac 上。真机有自己的 CPU、内存带宽和散热表现，诚实的说法是：我们还没量过真机。这也正是这个基准测试被放进应用的开发者设置里、而不是留在某台笔记本上的原因——在你手上的任何设备上点一下，它会打印出同样的表。

而这是一条基线。今天的编辑器是平台自带的文本框，表里约 90% 量的都是这个控件。一个用 rope 缓冲区、只排视口的原生编辑器，在这里根本不该画出一条直线——代价应当不再跟着文件大小走。等我们换掉它，这一页就是「之前」。