我们如何将 Pinterest 的 iOS 应用大小减少 30% 以上
众所周知，应用程序的大小（下载大小 [1] [2]）是非常重要的，并且在应用程序的大小和客户参与度之间存在关联。通常，人们会根据大小来决定是否使用软件，甚至以兆字节来支付带宽。更不用说，随着应用程序大小的增加，卸载率也会上升，这会导致用户试图释放设备上的磁盘空间。
近来，我们对 Pinterest 的 iOS 版 v9.1 进行了改进，使其体积大大减少：
表 1：iPhone 11 Pro 是我们的目标机型。
结果，自从发布以来，我们发现新版本（用户从 App Store 下载）的应用程序安装量有所增加。
关于 Pinterest 的背景，我们使用 Bazel 进行 iOS 版本构建。加入你不熟悉 Bazel，这篇文章值得一读。
要创建本地化文件，我们有一个 CI 作业，它在应用程序（通过 Bazel 查询）中自动扫描所有源代码，并将其发送给 Mojito 进行翻译。这在我们添加一些扩展之前一直运行良好。
每个扩展都是具有自己 BUILD 文件的模块。在 Bazel 构建后，它将本地化字符串从主应用包复制到每个扩展包。但是，这会通过复制每个扩展中的 Localizable.strings 文件来扩展整个应用包。
因此，我们决定删除扩展中的本地化副本。
第一，我们更新了 BUILD 文件，这样扩展程序就不会从主应用包复制本地化字符串了。
但是，使用这个更改，NSLocalizedString 无法正确加载本地化字符串。在进一步研究之后，我们发现这些宏都使用 +[NSBundle mainBundle]，但是 [NSBundle mainBundle] 实际上会返回一个包含“当前应用程序可执行文件”的包，当从扩展中调用该包时，该包将作为你的应用程序的子文件夹。
举例来说，它是 /path/to/Pinterest.app/PlugIns/SiriExtension.appex/ 而非 /path/to/Pinterest.app/。为了使 NSLocalizedStringWithDefaultValue 能够从主应用包中读取本地化字符串，我们进行了更改来对路径进行设置。
这些全部已保存更改（（所有 Localizable.strings 的大小）*（具有这种本地化重复的扩展的数量）），大约占全部应用程序大小的 30%。
接下来，我们计划将本地化资源放入各自的 SDK/ 扩展中，而非依赖于应用包，这样做有以下好处：
每个包都将是自包含的，所以它不需要主应用程序包就能运行或测试本地化，并且可以被绑定到一个单独的应用程序中。
在扩展代码中，NSLocalizedString 和本地化 API 按照自己的方式工作。
让包开源。
此外，还可以进行其他可能的改进，例如，删除不必要的非面向消费者的代码本地化，研究更大尺寸的图像格式，以及其他编译器级的优化。
你也「在看」吗？👇