在 Lyft 创建 iOS 应用扩展的挑战

在最近的一篇文章中，Lyft 工程师 Artur Stepaniuk 和 Max Husar 描述了 Lyft 如何处理为其 iOS 应用创建应用扩展的复杂性，其难点在于不打破苹果设置的严格的 RAM 和二进制大小限制，也不损害用户体验。

Lyft 的 iOS 应用包含一个扩展，可将其与 Apple Maps 集成，并在 Maps 应用内提供有关 Lyft 优惠的信息。正如 Stepaniuk 和 Husar 所解释的那样，以有效方式创建 iOS 应用扩展的关键是正确管理依赖项，以尽可能提高应用和扩展中的代码重用率，同时优化二进制大小和内存使用率。

此过程中的主要复杂因素是无法使用动态链接来避免在启动时将它们加载到内存中的成本，这会让应用程序在启动时过于缓慢。这使得静态链接成为唯一可行的选择，尽管代价是增加应用程序二进制大小及其内存占用。但是，

更大的二进制大小会导致更长的下载和安装时间，从而可能减少安装数量。最坏的情况是达到 200 MB 的下载大小限制，这会在使用蜂窝数据下载应用程序时触发额外的确认对话框。

在内存方面，Lyft 工程师发现扩展可能只能使用 20 到 50MB 的 RAM，具体取决于 iOS 版本、设备型号和其他因素。

为了减少应用程序二进制大小和内存占用，Lyft 工程师分析了他们应用程序的依赖关系图，以确定占用最大的模块。由于 Lyft 使用 Bazel，他们依靠图形可视化软件 Graphviz，使用 query --output=graph 命令从 Bazel 生成的数据创建图像。

为了详细测量二进制大小影响，可以将每个模块作为唯一的依赖项添加到 Apple Maps 扩展，并使用 binary-size-diff 工具进行分析。

binary-size-diff 是一种对比基础分支和给定拉取请求之间的二进制大小差异的工具。这样就可以测量删除（或包含）依赖项的实际效果。

获得该信息后，下一步就是识别所有看起来没必要加入的依赖项。为此，Lyft 工程师使用了 Bazel 的另一个功能来显示两个模块之间的传递依赖关系。

bazel query 'allpaths(INITIAL_MODULE_PATH:INITIAL_MODULE_NAME, TARGET_MODULE_PATH:TARGET_MODULE_NAME)' --output=graph | grep -v 'node \[shape=box\];' > relations.dot

此命令会显示将所调查模块与其每个较大依赖项连接起来的路径中包含哪些模块，这样你就可以删除它们或使目标模块不依赖它们。在某个场景下，Lyft 团队决定复制一项服务以创建最小依赖项，目的是打破对较大模块的依赖。

使用这种方法，Lyft 工程师将其扩展的二进制大小从 45MB 减少到了 15MB。虽然 30MB 的减少对于服务端或桌面应用程序来说并不重要，但它相当于 200MB“安全”大小限制的 15%。

Stepaniuk 和 Husar 的文章包含了与发布应用扩展过程相关的其他细节，例如如何确保扩展可用于所有受支持的区域、使用 APPLICATION_EXTENSION_API_ONLY 构建设置的效果以及 SiriKit 特性，因此如果你对这些主题感兴趣，请不要错过它。

原文链接：

Challenges of Creating iOS App Extensions at Lyft