为什么要有上限
SFTP 浏览器不用离开应用就能编辑远程文本文件：下载、在编辑器里改、再覆盖上传回去。只有小于上限的文件才会出现编辑这一项——而上限是一个承诺：低于它的文件都能打开、都能输入。
定得太低，本来能轻松编辑的文件被挡在外面；定得太高，用户点开文件却发现打字跟不上，那比一开始就不提供更糟。
我们原来的值是手机 128 KB、桌面 512 KB，两个都是凭感觉定的。连我们自己那份「换掉编辑器」的内部计划里写的「超过 10 KB 就开始退化」，也出自同一个来源：没有人真的拿秒表量过。所以我们把秒表做进了应用里。
量的是掉帧，不是秒表
编辑大文件真正贵的部分不在我们的代码里。ArkUI 的文本框会对整篇文档做排版，并且在每一次按键时把整篇文档作为一个新字符串交回 JavaScript。这两件事都不会出现在我们给自己函数加的计时里——它们发生在回调返回之后、UI 线程上。而你真正感觉到的恰恰就是这个：线程忙住了，界面不动了。
量具
所以量具是 UI 线程自己的心跳。系统可以在下一帧开始时回调你；在回调里重新注册，就等于每一帧都采一次样。本该在 16.7 ms 后到来的一帧,如果 900 ms 才到，就说明线程消失了 900 ms——这个间隔就是卡顿本身，单位和你的体感一致，而且完全不需要被测组件配合。下限是一帧：表里的「17 ms」意味着这个操作没有量得出的开销。
文档，以及那一次按键
测试文件的形状和这个上限真正管的东西一致——通过 SFTP 拉下来的配置、日志、脚本：行长不一、平均约 52 列、有缩进，也夹着少量长行。它们由固定种子生成，所以两次运行比较的是同一个文件。
按键插入在文档中间，而不是追加到末尾。追加可以被只重排尾部的引擎轻松应付；而改一份配置文件从来不是追加。
不同大小的代价
手机模拟器上的一次完整运行。打开是文件打开时最长的一次卡顿，按键是在文档中间输入一个字符引起的帧间隔中位数，最差一帧是其中最慢的一次，内存是排完版的文档给进程增加的占用。
| 文件 | 行数 | 打开 | 按键 | 最差一帧 | 内存 | |
|---|---|---|---|---|---|---|
| 8 KB | 172 | 17 ms | 16 ms | 26 ms | 4 MB | 流畅 |
| 16 KB | 346 | 19 ms | 18 ms | 21 ms | 4 MB | 流畅 |
| 32 KB | 701 | 34 ms | 25 ms | 30 ms | 7 MB | 流畅 |
| 64 KB | 1,385 | 61 ms | 48 ms | 50 ms | 16 MB | 可用 |
| 128 KB | 2,760 | 105 ms | 91 ms | 105 ms | 33 MB | 临界 |
| 256 KB | 5,516 | 205 ms | 188 ms | 203 ms | 65 MB | 难受 |
| 512 KB | 11,084 | 457 ms | 365 ms | 385 ms | 133 MB | 难受 |
| 1 MB | 22,150 | 805 ms | 583 ms | 661 ms | 258 MB | 不可用 |
曲线是一条直线：在一帧的地板之上，每千字节约 0.55 ms 的输入延迟。其中大约十分之一是我们自己的——统计行数、算出光标的行列位置——其余属于平台的文本引擎。所以这个数字会随编辑器引擎的更换而变，而不会因为我们调优 ArkTS 而变。
有两件事在任何大小下都是免费的：查找，以及跳到匹配处。在 1 MB 的文件里滚到一兆之外的命中处只花了一帧，和 8 KB 时一样。
我们改了什么
两个上限、一次实测，外加一件本以为需要单独规则、结果并不需要的事。
手机：128 KB 保留——现在有依据了
它是最后一个还能用的尺寸，而不是一个宽裕的尺寸。在这里一次按键约要十分之一秒，而且在多次运行中，128 KB 会落在我们「可用」线的两侧。32 KB 以下编辑器是真的流畅，而这已经覆盖了绝大多数人通过 SFTP 编辑的东西。
桌面：512 KB → 128 KB
旧数字假设桌面「装得下更多」。并没有：代价来自文本排版，不来自机器，二合一设备实测与手机相差不过几个百分点。512 KB 时一次按键要 0.36 秒——那不是大文件打开得慢，那是一个打不了字的编辑器，被一个声称「能用」的上限交到了用户手里。
中文文件不需要另立规则
以字节表述的上限，对中文来说是另一个承诺——一个汉字是三个字节而不是一个，所以我们也量了。在相同字节数下，结果与纯 ASCII 那轮只差几个百分点：每千字节的字符更少，而多出来的字形排布开销正好抵消了差距。内存高出约 20%。一个用字节表述的上限，对两者都诚实。
两点必须说清楚
这些数字来自模拟器，不是来自真机。表格出自 DevEco 的手机镜像（Pura 90），桌面那一组对照出自二合一镜像（MateBook Pro），两者都跑在一台 Apple Silicon 的 Mac 上。真机有自己的 CPU、内存带宽和散热表现，诚实的说法是：我们还没量过真机。这也正是这个基准测试被放进应用的开发者设置里、而不是留在某台笔记本上的原因——在你手上的任何设备上点一下，它会打印出同样的表。
而这是一条基线。今天的编辑器是平台自带的文本框，表里约 90% 量的都是这个控件。一个用 rope 缓冲区、只排视口的原生编辑器，在这里根本不该画出一条直线——代价应当不再跟着文件大小走。等我们换掉它，这一页就是「之前」。