- 停止输入后才重新排版
- 已经算过的公式会被记住
- 光标在别处时完全不重算
第二章
为什么 Akileas 这么快
大多数编辑器在文档变长之后就开始"想一下再显示"，输入时能感到明显的迟滞。 Akileas 从设计上就不允许这件事发生：你敲下按键的那一刻，画面就已经更新了， 剩下的精细排版在后台悄悄补上，永远不会挡在你和文字之间。
2.1 击键即显示
编辑器内部把"你按下一个键"这件事拆成了两半：立刻显示与随后精修。 前者只做最少的事，保证画面在同一帧内就刷新；后者复杂但可以慢慢来，而且随时可以被更新的输入打断。
立即发生
必须在同一帧内完成，否则你会看到延迟。
- 你在光标处敲下一个字符
- 只有这一行被重新绘制
- 屏幕刷新，字符与光标就位
随后发生
在后台进行，绝不阻塞你的输入。
- 后台开始分析文档的变化
- 只重新计算受影响的那一部分
- 语法高亮与精细排版平滑补上
- 若你已继续输入，过时的结果自动丢弃
这就是为什么在十万行的文档里打字，和在一页空白纸上打字，手感几乎没有区别。 实测中，按下按键到画面刷新的这一步只需要 37 微秒， 不到一帧（8.33 毫秒）预算的百分之一。
2.2 只重算改动的那一行
文档变长之后变卡，通常是因为每次输入都要把整篇重新解析一遍。Akileas 不做这件事。
它把文档的解读分成两层：一层记录"哪些是段落、标题、代码块、列表"，另一层记录"某一段里的 加粗、链接、公式"。当你在正文中改动几个字时，外层的结构完全没有变化， 于是只有你正在编辑的那一行需要重新解读，其余九万九千九百九十九行原样复用。
NOTE
这也是为什么输入普通文字几乎感觉不到任何延迟，而只有像输入 #
这样会改变标题结构、牵动整块内容的操作，后台才会多花一点时间——
但即便在这种情况下，画面依然在 85 微秒内就已经更新完毕，你完全感知不到后台的忙碌。
2.3 公式、图表、表格互不拖累
数学公式、Mermaid 图表和表格是文档里最"贵"的三种内容。如果它们共用一条更新通道， 你每敲一个字都可能触发一次图表重算，输入就会一顿一顿的。
Akileas 让它们各自独立：只有真正变了的那一类才会重新计算。 在正文里写字，不会惊动旁边那张已经画好的架构图。
文档发生变化
- 只编译视野内可见的图表
- 缩放与平移不重新计算图形
- 图形几何被缓存复用
- 按实际显示宽度自适应列宽
- 中英混排也能对齐
- 改动单元格只影响该表
合成同一幅画面，交给显卡绘制
2.4 十万行也能瞬间滚到任意位置
在超长文档里拖动滚动条，很多编辑器会先卡住、再突然跳过去。原因是它们需要从头累加每一行的高度， 才能算出"你拖到的位置对应哪一行"。
Akileas 把整篇文档的高度组织成一份可以快速查找的索引。无论文档多长， 定位都只需要和文档长度的对数成正比的计算量——把滚动条拖到 85%， 它能在几微秒内告诉你那是第几行的第几个字符。滚动过程中尚未测量过的行会先按平均高度估算， 再随着你的拖动逐步精确，因此不会出现跳动或抖动。
定位耗时几微秒与文档长度几乎无关
滚动抖动无未知行按均值预估后细化
2.5 崩溃与断电也不会丢稿
保存看起来是一个动作，但如果在写入过程中断电，半截文件会直接毁掉你原本完好的稿子。 Akileas 用"先写副本、校验通过、再一次性替换"的方式避免这件事。
- 1 生成新版本 把当前内容组织成完整的文件内容
- 2 写入临时副本 先写到一个临时文件，原文件此刻纹丝不动
- 3 校验完整性 确认写入的数据完整无误，并强制落盘
- 4 一次性替换 用副本原子地顶替原文件，不存在"写了一半"的状态
- 5 记入时光机 顺手留存一份历史版本，可随时比对与回滚
除此之外，编辑器还会持续追加一份带校验的轻量编辑记录。即使遇到断电关机， 重新打开时也会自动校验并重放，把未保存的内容还给你。
2.6 技术底座
上面这些能力来自几个根本性的选择——它们决定了 Akileas 的起点就和浏览器内核的编辑器不在同一条路上。
原生编译，没有浏览器内核
整个应用编译成本机代码，直接调用系统图形接口。不内嵌浏览器引擎， 因此没有"启动要等好几秒"和"内存吃掉几百兆"的代价。
没有垃圾回收停顿
内存由编译器在编译期确定释放时机，不存在运行时的垃圾回收。 那些每隔几秒就卡一下的丢帧，在这里不会发生。
由显卡直接绘制
字形、矢量图形与界面元素都交给显卡渲染，支持高刷新率屏幕与清晰的亚像素字体， 滚动与缩放的顺滑度不受文档长度影响。
内存与缓存都有上限
图片、公式与图表缓存各自设有明确上限，超出后自动淘汰最久未用的内容， 长时间编辑超大文档也不会越用越卡。
这些设计带来的直接结果是：轻量文档常驻内存约 25 MB ~ 45 MB， 十万行文档稳定在 60 MB ~ 110 MB，且不会随编辑时长增长。