1.9 KiB
1.9 KiB
第十二章：把这些设计迁移到自己的代码
12.1 先按变化频率拆工作
找出输入中很少变的部分与高频变化的部分。这里文字和字体较稳定，宽度频繁变化，于是准备与布局分离。类似思路也适用于图表几何、搜索索引和格式化数据。
预计算需要内存，也会增加第一次处理的成本。只有被复用、能减少更贵的工作时，它才值得。
12.2 让 API 允许调用者少做事
如果只要计数，就提供计数路径；只要范围，就不强迫构造字符串；只要可见几行，就允许提前停止。
这比在一个总会生成全部结果的 API 内微调循环，通常更能减少实际工作。
12.3 给常见输入一条清晰的快路径
先通过准备阶段建立可验证的前提，再让热循环使用这些前提。完整路径仍负责其余情况。快路径的正确性应来自明确条件，而不是凭输入“看起来简单”猜测。
12.4 衡量总工作量
除了总耗时，还观察测量次数、提交字符量、扫描范围、对象分配和重复启动次数。它们能解释为什么快，也能暴露短样本看不到的二次增长。
12.5 把结论说到证据能支持的位置
这次源码研究与实验支持的是：Pretext 用准备阶段的测量和规则数据，使后续宽度变化主要成为数值布局；缓存、专用计数循环和按需生成结果进一步减少工作。完整页面是否获益、获益多少，还取决于首次准备量、复用频率、字体与 CSS 是否匹配，以及应用剩余的 DOM 和绘制成本。
读完后可以用三个问题检验理解：哪些工作被移到准备阶段？哪些结果被跨调用复用？调用者只要高度时，哪些工作根本没有发生？把这三个问题顺着源码回答出来，就能解释 Pretext 的主要性能来源。