优化 iOS 应用本地化字符串大小：Airbnb 的压缩与去重策略

Swiftable

介绍 [00:00:10]

• 演讲者背景 [00:01:17]
  • Miguel Jimenez，来自墨西哥瓜达拉哈拉的 iOS 工程师，拥有超过 6 年的经验。
  • 此前主要在初创公司工作，重点是快速构建功能和动画，对性能关注较少。
  • 于 2020 年 2 月加入 Airbnb，随后因 COVID-19 改变了工作和生活方式。
• Airbnb 客户端基础团队 [00:02:30]
  • Miguel 目前在 Airbnb 的客户端基础团队工作，该团队专注于应用质量指标。
  • 应用质量指标包括：
    • 应用大小 (App Size)
    • 启动时间 (Startup Time)
    • 页面性能 (Page Performance)
    • 其他方面
  • 他认为这些优化领域对用户体验至关重要，是之前在小型公司无法接触到的挑战。
  • 用户体验不仅限于动画，还包括从应用商店下载到启动，再到页面渲染速度的整个过程。

本地化 API 的挑战 [00:03:55]

• iOS 中的文件层级和格式 [00:04:06]
  • 本地化文件采用键值对格式。
  • UI Kit 使用 NSLocalizedString，Swift UI 使用 LocalizationKey。
  • 重要发现： Airbnb 的单个本地化语言文件大小为 1.1MB。
  • API 工作原理 [00:04:38]
    • 所有字符串文件在用户下载应用时都会被下载。
    • 这些文件在运行时被打开。
    • 操作系统会根据用户的首选语言打开特定的本地化文件。
• 应用大小是主要挑战 [00:05:10]
  • Airbnb iOS 应用支持 61 种语言。
  • 在 2019 年增加了 31 种语言，总计达到 61 种。
  • 未经优化的影响 [00:05:41]
    • 如果不进行任何优化，本地化字符串文件将占用约 54MB 的应用空间。
    • 应用大小与安装量直接相关：应用越大，用户安装的可能性越小；如果空间不足，用户更有可能卸载应用。

本地化优化概念 [00:06:27]

• 1. 本地化字符串文件压缩 [00:06:39]
  • 核心思想： 用户通常只使用一种语言。应用中下载的其他语言文件很少被使用。
  • 策略：
    • 在构建时压缩所有不太可能被使用的本地化文件。
    • 在运行时按需解压用户当前语言对应的文件。
  • 优势： 减少下载和安装大小。
  • 算法： 使用 Apple 提供的 LZFSE 压缩算法，该算法内置于 iOS 和 macOS。
  • 流程图 [00:07:44]
    • 构建时： 标准本地化字符串文件 -> LZFSE 压缩算法 -> 压缩数据。
    • 运行时： 压缩数据 -> LZFSE 解压算法 -> 解压数据。
    • 关键： 运行时只解压用户当前语言对应的文件。

• 2. 本地化键去重 [00:08:21]
  • 问题： 在当前格式下（键值对），每个语言文件中都会重复包含键，随着支持语言和翻译数量的增加，重复问题呈线性放大。

    

  • 解决方案： 引入一种新格式，将数据分为三个文件。
    • 一个包含翻译值的数组（例如西班牙语翻译）。
    • 另一个包含翻译值的数组（例如英语翻译）。
    • 一个全局键列表，其中所有键在整个应用中只出现一次。

* 关键点： 翻译数组和全局键列表的顺序必须严格对齐，以便通过索引查找对应关系。 * 运行时操作 [00:10:18] * 将特定语言的翻译数组与全局键列表进行“压缩”操作（即将它们重新组合），以在运行时重建原始的键值字典。

权衡与考量 [00:10:46]

• 优点 (Pros) [00:10:56]
  • 显著减少应用大小。
  • 创建了新的自定义流水线，未来可以进行更多优化（例如，识别并移除内容相同的重复翻译键）。
• 缺点 (Cons) [00:11:45]
  • 当前实现不直接兼容 Apple 的 NSLocalizedString 和 LocalizationKey API，因为这些 API 需要 .strings 文件扩展名。
  • 需要构建一个自定义的字符串处理流水线，包括开发、测试、维护，并确保其稳定性，因为本地化是应用的关键部分，错误可能导致严重的 UI 问题（例如，显示空白、错误语言或混淆的翻译）。
  • Miguel 强调，只有当优点显著大于缺点时，才应采用此方法，而对于 Airbnb 而言，情况确实如此。

    

Airbnb 的实现 [00:12:56]

• 两阶段实现：构建时和运行时。

  

• 1. 构建时流水线 [00:13:06]
  • 目标： 在不干扰现有本地化字符串更新流程的情况下，转换和优化文件。
  • 步骤：
    1. 从正常的应用构建过程获取包含原始本地化字符串文件的 .app 包。
    2. 自定义处理步骤：
       • 获取本地化资源。
       • 打开每个文件，提取内容（字典和数组）。
       • 应用去重算法，将数据转换为新格式。
       • 将数据转换为 NSData。
       • 使用 LZFSE 算法压缩数据。
       • 将去重和压缩后的新格式文件重新移回应用包。
       • 关键： 移除原始的本地化文件，以实现大小减小。
    3. 最终生成包含新格式的压缩本地化文件和全局键列表的 .app 包。
  • 压缩代码示例 [00:14:16]
    • 使用 NSData 的 compress(using:) 方法，指定 .lzfse 算法。
    • 此过程在构建机器上运行，而不是在应用内部。
  • 工具： 优化过程使用 Swift CLI 工具构建，任何熟悉 Swift 的开发者都可以贡献。

    

    

• 2. 运行时流水线 [00:15:12]
  • 目标： 在不影响应用启动时间的情况下，提供正确的本地化内容。
  • 核心组件：StringManager
    • 这是一个自定义的单例类，在应用启动时初始化，并在整个应用生命周期中存在。
    • 它取代了 Apple 的本地化 API。
  • 关键代码片段 [00:15:48]
    • 获取当前用户语言： Bundle.main.preferredLocalizations。
    • 打开特定本地化文件： Bundle.main.path(forResource: ofType: inDirectory: forLocalization:)。
  • StringManager 设置流程 [00:16:24]
    1. 检查缓存： 应用首次启动时，没有可用的缓存文件。
    2. 首次启动流程（执行所有步骤）：
       • 打开键文件。
       • 打开翻译文件。
       • 解压数据。
       • “压缩”键和翻译数据。
       • 将结果转换为键为翻译键、值为翻译内容的字典。
       • 将此字典的内存表示形式保存下来。
       • 将该字典保存到文件中，并附上应用版本和语言 ID 作为文件名的一部分，以供后续启动使用。
    3. 后续启动流程：
       • 如果缓存文件存在且有效（通过应用版本和语言 ID 检查），则直接加载缓存文件。
       • 如果缓存文件无效（例如，用户更改了语言或应用更新），则重新执行首次启动流程以生成新文件。
  • 访问翻译 [00:18:52]
    • 开发者不再使用 NSLocalizedString，而是使用自定义的全局函数 translation(key: String)，该函数内部调用 StringManager 单例来获取翻译。
    • 这样可以保持开发者的使用体验与原有 API 相似。

优化效果 [00:19:09]

• 影响衡量 [00:19:09]
  • 优化前： 字符串文件占应用总大小的 22%。
  • 仅应用压缩后： 降至 8%。
  • 应用压缩和去重后： 进一步降至 4%。
  • 总计： 本地化资源减少了 82%，对 Airbnb 来说是一个巨大的胜利。

    

• 启动时间影响 [00:19:46]
  • 该优化对启动时间没有负面影响，这得益于运行时缓存机制。

    

验证步骤 [00:19:58]

• 为了确保一切按预期工作，Airbnb 遵循了一系列严格的验证步骤：
  • 大量的单元测试。
  • 使用 Instruments 和 Emerge 工具测量应用大小和启动时间影响。
  • 在 Alpha 和 Beta 发布版本中运行优化。
  • 通知 QA 团队进行彻底测试。
  • 在一切成功后，发布到 App Store。
• 发布时间：
  • 压缩步骤于 2019 年发布。
  • 去重步骤于当年 5 月发布。
  • 两者都运行良好。

    

问答环节 [00:21:40]

• 如何处理复数字符串（Plural strings）？ [00:21:55]
  • Airbnb 不使用 Apple 的复数 API，而是有自己的自定义实现。
  • 当前的优化不涉及复数处理。
• 既然是自定义实现，为什么不按需下载语言文件？ [00:22:22]
  • Airbnb 曾考虑过此方案。
  • 弊端： 这会增加应用启动时间，因为需要等待网络下载，引入了额外的延迟。
  • 如果网络连接不良或下载失败，用户体验会非常糟糕。
  • 由于实现的复杂性和潜在的风险，最终没有采用此方案。
• 如果 UX 团队更改了一个词，是否需要生成新版本？ [00:23:08]
  • 每次构建应用时，都会执行自定义的格式化（去重和压缩）过程。
  • 因此，当发布新版本时，所有字符串文件的更改都会自动反映在优化后的文件中，不会影响优化流程。