為甚麼要有上限
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 緩衝區、只排視口的原生編輯器，在這裡根本不該畫出一條直線——代價應當不再跟著檔案大小走。等我們換掉它，這一頁就是「之前」。