2f7ce0cb72
- 重构 webfont-sdk.js 为核心增量引擎 + 多触发器架构 - 支持 loadFont（轮询）、observeFont（MutationObserver）、loadText（手动传文本）三种模式 - 三种模式共享 loadedChars，按 fontName|family 自动去重增量加载 - loadFont interval 可从外部配置 - 首页改用 loadText 模式，输入即时触发字体加载 - textarea 高度根据文本行数动态变化 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1.6 KiB
/loop 持续优化字体子集化性能，可以大胆放开手脚的去做，但是优化完一定要通过pnpx tsx ./基准测试.test.ts。中途不要切换到其他模式，比如计划模式也不要询问我，你直接做就行了，请你持续的去优化，不要去询问我，不要去中断，好吧
把基准测试结果文档保存在本地 benchmark_results/ ，这样我方便查看。你的文档中应该在每个重大节点更新基准测试结果（benchmark_results/OPTIMIZATION_LOG.md），这样我能方便看到你使用了哪些优化方法，得到了什么样的优化效果。
=== 字体裁剪基准测试 ===
8个汉字: avg=23.6ms min=18.4ms max=37.2ms 输出=16,508 bytes ssim=1.0000 拉丁+数字: avg=16.4ms min=13.7ms max=18.2ms 输出=1,272 bytes ssim=1.0000 千字文前段: avg=59.4ms min=47.3ms max=76.5ms 输出=161,344 bytes ssim=1.0000
=== 一晚上优化后的 字体裁剪基准测试 ===
8个汉字: avg=7.7ms min=3.8ms max=20.7ms 输出=16,572 bytes ssim=1.0000 拉丁+数字: avg=3.2ms min=1.6ms max=6.6ms 输出=1,272 bytes ssim=1.0000 千字文前段: avg=11.7ms min=6.8ms max=21.7ms 输出=161,816 bytes ssim=1.0000
其他方向
就是有一个纯前端的优化，咱们提供的js SDK好像是通过定时器扫描的吧，这当然是一种方式，也是最省心的一种方式，但是咱们是不是还可以考虑另外一种方式，就是通过配置来启用定时扫描还是由用户自己的事件来触发，甚至由用户直接传递文本，这样的话对于首页上的demo来说，可能会有更高的及时性响应