11M iOS App给你的瘦身建议

你可能不知道的是，有些广为使用的社交网络 App 包大小达到了惊人的 400MB。如果每周发布一个新版本的话，一年下来用户将要下载 20GB 的数据。

自发布 Halide 以来，我们收到的最出乎意料的点赞是关于该 App 的大小。Halide 约 11MB，我们一年所推送的数据要少于那些社交网络 App 一次更新就要推送的数据。

有朋友会问：“难道你们没有使用 Swift 吗？”。Swift 会将自己的标准库捆绑到你的 App 中，这将增大 App 的大小。Halide 几乎是完全采用 Swift 开发的。

那么我们是怎样做到 App 瘦身的？让我们首先给出一点技术相关的内容。虽然它们主要来自对 QA1795 的概述，但是这些内容很重要。

从 Xcode 中导出构建时，在 Xcode 中选择“Save for Ad Hoc deployment.”。如果 App 支持“app thinning”（当前的 App 应该都支持），选择“Export for Specific Devices.”。确保你勾选了“Rebuild from bitcode”选项。

这样做，我们不仅能得到 App 软件包最终的大小，而且还能得到一份“App 瘦身报告”。依此报告去检查 App 软件包，找出其中最具影响的问题。

将资源（Asset）保存在 Asset Catalog 中。在上传 App 时，Apple 会将其切分为特定于设备的版本，具有两倍尺寸屏幕的设备不会得到三倍的资源，反之亦然。

在将资源置入 Asset Catalog 前运行 pngcrush 工具。根据 QA1681 介绍，Xcode 将自动为处于 Asset Catalog 之外的 PNG 压减资源。

将 UI 资源及类似条条框框限定为 PNG，App 中的大部分资源很可能由此构成。但是如果资源中有一些照片，尝试一下 JPEG。稍加压缩就非常有助于 App 瘦身。

完成这些工作难点，只会对上百 M 的大块头 App 取得数 M 的瘦身效果。我不知道该怎么婉转的告诉你，但你需要的是减少代码量。

Halide 具有约一万五千行 Swift 代码，其中包括：一个实时视频处理器、大量的用户控制，以及我们的平台控制 AVFoundation。我们关注的是并非由我们自己编写的代码。

我借助 Auto Layout 削减了上千行的模板代码。很多开发人员依然执着于使用手工布局。可能他们对 Auto Layout 并不甚了解，或者由于他们辗转从他人那里听说 Auto Laytout 的性能堪忧（虽然事实并非如此）。

我已经看到太多的开发人员致力于开发内部使用的布局引擎，尤其是在一些大型企业中。这太疯狂了。Apple 在操作系统上绑定了精细的布局引擎，因此不要使用定制框架，这会导致 App 规模膨胀。

如果弃用 Interface Builder（IB），我们可以再削减 100K 大小。用户手册和设置页几乎完全是使用 IB 搭建的，使用了一些简单的约束。Camera UI 高层布局的管理也类似。虽然减掉 100K 很诱人，但是出于对短期内生产效率的考虑，值得让这一部分保持原样。

如果查看一些大型 App 的软件包，我们将会发现其中存在数十个第三方框架，大小从 100K 到数兆不等。

我并没有使用第三方软件库。虽然这有些走极端，但是我们的情况有些特殊。

这是因为并没有多少第三方软件库能适合我们的需要。在 iOS 开发社区中，有很多人在做 JSON 的映射，但是没有人关注对 DNG 文件的底层操作。