作者： admin

在之前的优化工作中，我们将 x2t 移植到 WASM，并尝试在 JS 和 WASM 之间共享内存，以期减少数据拷贝，提升性能。然而，我们在实践中遇到了一些问题，特别是 **Segmentation Fault** 错误，这促使我们对 WASM 的内存模型以及 JS 和 WASM 共享内存的机制进行了更深入的研究。

WASM 的线性内存模型

WASM 实例拥有一个线性内存（Linear Memory），它本质上是一个 `ArrayBuffer`，可以被 WASM 代码和 JS 代码同时访问。 这个线性内存是 WASM 程序存储数据的主要场所。

• **内存页（Memory Page）：** WASM 的线性内存被划分为大小固定的内存页，每页通常为 64KB。
• **内存增长：** WASM 程序可以通过 `memory.grow` 指令增加线性内存的大小，每次增加一页。线性内存的最大大小受限于 WebAssembly.Memory 实例的配置，通常为 4GB (65536 页)。
• **地址空间：** WASM 代码通过线性地址（Linear Address）访问内存，线性地址是相对于线性内存起始位置的偏移量。

JS 如何访问 WASM 内存

JS 可以通过 `WebAssembly.Memory` 实例的 `buffer` 属性获取线性内存的 `ArrayBuffer` 对象。 拿到 `ArrayBuffer` 后，JS 就可以像操作普通数组一样读写 WASM 的内存了。

const wasmMemory = new WebAssembly.Memory({ initial: 10 }); // 初始 10 页
const buffer = wasmMemory.buffer; // 获取 ArrayBuffer
const uint8Array = new Uint8Array(buffer); // 创建 TypedArray 视图

// JS 写入数据到 WASM 内存
uint8Array[0] = 42;

// 从 WASM 内存读取数据
const value = uint8Array[0];
console.log(value); // 输出 42

JS 与 WASM 共享内存的挑战

虽然 JS 可以直接访问 WASM 的线性内存，但共享内存也带来了一些挑战：

1. **内存对齐（Memory Alignment）：**
   • 不同类型的数据需要按照特定的字节对齐。例如，32 位整数通常需要 4 字节对齐。
   • 如果 JS 和 WASM 以不同的方式访问未对齐的内存，可能会导致性能下降，甚至出现错误。
   • **解决方案：** 确保 JS 和 WASM 使用相同的内存对齐方式。可以使用 `DataView` 对象进行精确的内存访问。
2. **数据类型转换（Data Type Conversion）：**
   • JS 和 WASM 使用不同的数据类型表示方式。 例如，JS 的数字是 64 位浮点数，而 WASM 可以使用 32 位整数、64 位整数等多种类型。
   • 在 JS 和 WASM 之间传递数据时，需要进行类型转换。
   • **解决方案：** 使用 `TypedArray` (例如 `Int32Array`, `Float64Array`) 在 JS 中创建与 WASM 内存布局匹配的视图。
3. **竞争条件（Race Conditions）：**
   • 如果 JS 和 WASM 同时访问同一块内存，可能会出现竞争条件，导致数据不一致。
   • **解决方案：** 使用 `Atomics` API 进行同步。 `Atomics` API 提供了一些原子操作，例如原子加、原子减、原子比较和交换等，可以保证并发访问的安全性。
4. **Segmentation Fault 的原因及解决：**
   • 我们遇到的 Segmentation Fault 错误，可能由以下原因导致：
     • **越界访问：** JS 或 WASM 访问了线性内存范围之外的地址。这可能是由于计算错误或内存增长未同步导致的。
     • **非法地址：** 访问了未分配或受保护的内存地址。
     • **数据竞争：** 尽管使用了 Atomics API，但在某些复杂的并发场景下，仍然可能存在竞争条件。
   • **解决方法：**
     • **仔细检查内存访问逻辑：** 确保 JS 和 WASM 的内存访问都在线性内存的有效范围内。
     • **使用调试工具：** 利用 WASM 调试工具 (例如 Chrome DevTools 的 WebAssembly Inspector) 跟踪内存访问，找出错误的根源。
     • **更细粒度的同步：** 考虑使用更细粒度的 Atomics 操作，或者采用其他的同步机制 (例如互斥锁) 来保护共享内存。
     • **避免复杂的数据结构共享：** 尽量避免在 JS 和 WASM 之间共享复杂的数据结构。如果必须共享，可以使用序列化/反序列化来传递数据。

使用 Atomics API 进行同步的注意事项

虽然 `Atomics` API 可以用来同步 JS 和 WASM 的内存访问，但也需要注意以下几点：

• `Atomics.wait` 只能在 WebWorker 中调用，不能在主线程中使用。
• `Atomics` 操作仍然有一定的性能开销，过度使用可能会影响性能。
• 在复杂的并发场景下，需要仔细设计同步策略，避免死锁等问题。

什么是 Transferable Objects？

Transferable Objects 是一种特殊的对象，它们在传递时不会进行数据复制，而是直接将对象的底层内存的所有权从一个上下文转移到另一个上下文。 这意味着传递后，原始上下文将无法再访问该对象，而接收上下文则拥有该对象的完整控制权。

常见的 Transferable Objects 包括：

• `ArrayBuffer`
• `MessagePort`
• `ImageBitmap`
• `OffscreenCanvas`

**Transferable Objects 的优势：**

1. **零拷贝（Zero-Copy）：** 这是 Transferable Objects 最大的优势。 由于没有数据复制，传递速度非常快，尤其适合传递大型数据块。
2. **避免内存竞争：** 由于所有权转移，只有一个上下文可以访问该对象，因此可以避免内存竞争和数据不一致的问题。 这简化了并发编程，无需使用复杂的同步机制。

**Transferable Objects 的劣势：**

1. **所有权转移：** 这是 Transferable Objects 的一个限制。 传递后，原始上下文将无法再访问该对象。 如果需要同时在多个上下文中使用同一份数据，Transferable Objects 就不适用了。
2. **对象类型限制：** 只有特定类型的对象才能作为 Transferable Objects 传递。 常见的对象类型 (例如普通 JavaScript 对象) 不支持 Transferable Objects。
3. **单向传递：** Transferable Objects 通常用于单向传递数据。 如果需要在两个上下文之间频繁地交换数据，效率可能不高。

**Transferable Objects 方案与内存共享方案的对比：**

**结论：**

• Transferable Objects 是一种简单而高效的数据传递方式，适用于单向传递大型数据块的场景。
• 内存共享 (SharedArrayBuffer) 适用于多个线程/上下文需要同时访问和修改同一份数据的场景，但实现起来更加复杂。

**在 WASM X2T 场景中，Transferable Objects 可能是更好的选择。** 因为 X2T 的主要需求是将处理结果传递给主线程，而不是共享数据。 使用 Transferable Objects 可以避免数据拷贝，提高性能，并且简化并发编程的复杂性。

在日常办公中，我们经常需要在不同的设备、不同的系统中打开文档。为了保证文档在各种环境下都能呈现出作者希望的效果，字体扮演着至关重要的角色。然而，在线文档预览场景下，字体渲染却面临着诸多挑战。今天，就让我们一起深入探讨 怡氧 在字体 fallback 机制上所做的努力，以及我们如何在此基础上进行优化，让在线文档预览更加完美。

在线字体渲染的难题

在线文档预览，与本地应用最大的不同在于，我们无法直接访问用户的本地字体文件。这导致了两个核心问题：

1. **字体资源有限：** 我们无法像本地应用一样，依赖用户系统安装的字体。为了显示效果，我们需要从服务器下载字体文件。
2. **字体版权限制：** 商业字体通常需要授权才能使用，我们不能直接将这些付费字体放在服务器上供用户下载。因此，我们只能选择使用免费字体。

这两个难题使得在线文档的字体 fallback 变得尤为重要。如果用户设置的字体在我们的字体列表中不存在，就需要找到一个合适的替代字体。如果 fallback 逻辑不佳，就会导致文档显示错乱，严重影响用户体验。

怡氧 的字体 fallback 机制：一个精细的“寻字”之旅

怡氧 在这方面做出了很多努力。他们并没有简单粗暴地选择一个默认字体，而是建立了一套复杂的 fallback 机制，其核心思路可以概括为“惩罚值计算”+“Unicode 索引”。

1. 字体字典：信息完备的“字体地图”

首先，怡氧 维护了一个庞大的字体字典，其中包含了：

• **字体名称：** 例如：Arial、Times New Roman 等。
• **Unicode 范围：** 描述该字体支持的 Unicode 字符范围。
• **字体文件大小：** 用于评估下载成本。

这个字体字典相当于一个详细的“字体地图”，帮助 怡氧 快速定位可用的字体资源。

2. 惩罚值计算：优中选优的替代策略

当用户设置的字体不在字典中时，怡氧 会根据字典中的信息，计算每个候选字体的“惩罚值”。这个惩罚值综合考虑了以下因素：

• **字体名称的相似度：** 例如，如果用户设置的字体名为 “Arial Bold”，那么字典中名为 “Arial” 的字体的惩罚值会相对较低。
• **Unicode 范围的匹配程度：** 如果文档中包含大量中文字符，那么支持中文的字体的惩罚值会相对较低。
• **字体文件大小：** 体积较小的字体，下载速度更快，因此惩罚值会相对较低。

最终，怡氧 会选择惩罚值最小的字体作为 fallback 字体，并将其下载到本地。这样可以尽量保证文档的显示效果与用户的期望接近。

3. Unicode 索引：最后的“救命稻草”

然而，即便通过惩罚值计算选择了 fallback 字体，也可能出现目标字体没有用户文档中特定字符的情况。这时，怡氧 会启用最后的 fallback 机制：Unicode 索引。

怡氧 事先会生成一个 Unicode 索引，将整个 Unicode 空间划分成小段，每一小段都对应到一个包含了此段的字体，这个字体是锁支持的列表中文件大小最小的一个。这可以确保任何字符都能在字体集中找到对应的字形，从而最大程度地避免显示为“方块”的乱码情况。

我们的优化：针对中文的“特殊关照”

怡氧 的字体 fallback 机制已经相当完善，但在中文显示方面，仍然存在一定的优化空间。考虑到中文字体的复杂性和多样性，我们基于 怡氧 的机制进行了改进：

1. **引入开源中文字体：** 我们增加了思源黑体、思源宋体等高质量的开源中文字体，这些字体覆盖的 Unicode 范围更广，能够更好地显示中文内容。
2. **硬编码常用字体 fallback：** 我们硬编码了一些常用的中文字体，例如微软雅黑、宋体、黑体、平方等，固定 fallback 到思源黑体或者思源宋体。这样，当用户设置这些常见字体时，可以确保 fallback 到最适合的中文字体。

通过这些优化，我们在很大程度上解决了中文文档乱码的问题，让中文文档的显示更加准确和美观。

总结

字体 fallback 是一个复杂而又至关重要的技术环节，它直接影响着用户体验。怡氧 通过其精密的字体字典、惩罚值计算和 Unicode 索引，构建了一套健壮的 fallback 机制。而我们在此基础上，针对中文进行了优化，进一步提升了在线文档预览的体验。

当然，字体显示永远是一个持续优化的过程。随着技术的发展，我们也将不断探索更好的解决方案，让在线文档的字体显示更加完美。

希望这篇文章能帮助你更好地理解 怡氧 的字体 fallback 机制。如果你有任何问题或者建议，欢迎在评论区留言讨论。