能編輯多大的檔案？

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