关于iOS9的APP瘦身

本文翻译自Gregg Mojica发布在 AppCode 上的文章 Working with App Thinning in iOS 9 ，文章版权由AppCoda授给SwiftGG翻译组。翻译者为博主JackAlan 

iOS9仅在推出后的几周后，在iOS设备上的安装量就超过了一半。这使它获得有史以来最快的普及率，超过了iOS7在2013年的记录。

在此教程中，我们将探索为什么App瘦身是重要的以及如何在自己的App中利用这个令人兴奋的新特性。

在本次WWDC中开放的APP瘦身是一个令人兴奋的新技术，将会改变整个下载的过程。就用户说流量消耗大，iOS设备内存限制以及更快速的下载而言，App瘦身是一个值得学习的至关重要的特性。

先决条件

对于这篇教程，假定你有Xcode的工作知识，以及如何驾驭IDE。如果这对你来说很陌生，或者你根本不确定IDE是什么，你或许应该在看一下 excellent free course . 

我也假定你已经理解如何去在AppStore上或者TestFlight(苹果beta版App测试服务)上发布App。我不会具体到讲述如何用TestFlight.

让我们开始吧。

App瘦身简介

因为当前市场上有着大量的iOS设备，以及多种屏幕尺寸和分辨率，让一个App在多种屏幕下看起来非常棒需要大量的资源(比如png, jpeg以及二进制的PDF)。不幸的是，这导致用户需要下载一个巨大的程序包(此前版本的iOS强制用户下载全部App文件，包括他们在用iPhone时永远也不会用到的适配iPad的图片)。16G的iPhone仍然是一个非常实际的存在(并且可能短时间内不会消失)，所以你要让App缩小体积并且可快速下载以保证用户有足够的空间并优化整体体验。App瘦身特性让这成为可能。

现今，App不仅仅由代码和图片组成。当今的App不仅包括可执行代码而且还有32位，64位版本(优化各种架构比如arm64，arm7S和arm7)，3D图形技术(例如OpenGL，Metal等)，声音，其他文件。总之，当下App的水准到达了令人难以置信的复杂程度。这就是App瘦身需要拯救的地方。

App瘦身会自动检测用户设备类型(比如型号名称)，并只为特定的设备下载相关内容。换句话来说，如果你使用iPad Mini 1(没有视网膜屏而是1X的分辨率)，然后只有1X的文件会被下载(仅在这此时)。更强大的清晰的资源(比如iPad Mini 3或4中的)将不提供下载。因为用户只需要下载他/她的特定设备的内容，这加速了下载过程，并节省了设备上的空间。

虽然这起初可能听起来很复杂，我们将深入到具体的细节。Xcode和App Store处理这项工作的绝大部分。因此，本教程中不会有太多的代码，而是重点关注理解App瘦身的过程和技术使它成为现实。

App瘦身有三个主要方面，应用程序切片( App Slicing ) 中间代码( Bitcode )和按需加载资源( On Demand Resources )。在本教程中，我们将一一探索。 

应用程序切片(App Slicing)

App瘦身第一个我们要讨论的就是切片(slicing)。根据苹果的文档，

切片是创建和提供不同的目标设备的应用程序包的变体( variant )的过程。 一个变体( variant )只包含可执行架构和目标设备所需要的资源。 

换句话来说，应用程序切片只提供给与每个设备相关的资源(取决于屏幕分辨率和架构等等)。事实上，应用程序切片处理了App瘦身进程的绝大多数。

当你已经准备好提交App时，和此前一样，你上传了 .IPA 或者 .App文件到iTunes Connect(但是必须使用Xcode7因为它包含支持App瘦身的iOS9 SDK). 然后App Store将App进行切片，创建特定的变体( variant )，这些变体将被分发给每个设备，依据它的功能( capabilities ). 

按需加载资源(On Demand Resources)

为了完全理解App瘦身，很有必要去了解 按需加载资源( ODR ). 按需所加载的资源就是在App初次安装后可以被下载的文件。例如，特定关卡的游戏(和这些关卡相关的内容) 只有在玩家解锁它们的时候才可以被下载。此外，在设定的时间内，玩家没有进行的早期的关卡可以被移除，以节省设备的存储空间。 

在Xcode的设置中(在Build Setting下)，开启按需加载资源需要更改”Enable On Demand Resources” 这个布尔值为”YES”.

中间代码(Bitcode)

App瘦身的最后一个也是第三个方面就是中间代码。中间代码有点抽象，但在本质上，它是在App被下载前，苹果优化它的新途径。中间代码使得App可以在任何设备上运行的尽可能的快速和高效。中间代码可以为最近的编译器自动编译App，并且对特定的架构做优化。(例如 arm64 64位处理器 如iPhone6s和iPad Air 2)

中间代码使得下载变得更小，通过排除被用于不同架构的优化而非仅仅下载相关的优化。

对于iOS，中间代码是一种新的特性，并且对于新的工程来说它需要被手动开启。这个过程可以被完成通过在Build Setting下的工程设置并且选择Enable bitcode为YES.

在你的项目进行App瘦身

尽管Xcode和App Store 处理了App瘦身的绝大多数流程，你仍然需要采取一定的预防措施以确保你的App使用了这种新的技术。首要的，你必须使用资源目录( asset catalogs ).在这一点上，大多数的App默认使用资源目录( asset catalogs ).如果你还没有用采用资源目录( asset catalogs )，你现有的大部分内容可以被转移到一个目录下通过按下在Xcode的项目设置下的”Use Asset Catalog”按钮，如下所示。 

Xcode的新特性之一就是 Sprite Atlases . Sprite Atlases基本上是资源目录和SpriteKit的组合(Xcode创建2D游戏的技术)。同样的，如果你是用SpriteKit，App瘦身那是必须的。 

测试App瘦身

正如你在如上的组图中看到的，Xcode和苹果的App Store处理了绝大多数App瘦身的过程，这使得在你自己的App中采用这个技术变得相对容易。但是如果你想测试你的App并且确保它已经应用了App瘦身呢？幸运的是苹果的TestFlight提供了完美的解决方案。除App Store的应用瘦身技术外，TestFlight的用户也可以体验这个新特性。

在本篇教程的第二部分，我们将会探索如何在TestFlight中使用App瘦身。

首先，下载这个 基本空白的项目 ，解压，并且在Xcode中运行，你将会注意到这个项目基本没有什么除了在资源目录( asset catalogs )中的一系列的图片(以及少量的代码)。这个资源目录( asset catalogs ) 也包含 1x, 2x 和 3x版本的app图标。 

首先，在模拟器或者真机上运行这个App. 打开设置应用，点击 存储空间和iCloud使用 这一项(或者是 存储空间 这一项在非iOS9的设备上) 并且选择管理存储空间.向下滑动到我们刚刚编译好的App并且点击它。你想会注意到它大概有17.0MB的大小(这个大小可能略有不同，当上传至iTunes Connect时)。 

当你使用Xcode构建并运行一个App时，Xcode并不会自动的处理App变体( variant )和App瘦身。这样，整个App的文件都在你的设备上。 

下一步，从Xcode中单击 Product 标签，并且选择 Archive . 

注意，你可能首先需要修改这个App的 Bundle Identifier 以匹配一个你自己创建的标识符。否则，这个App将不会被上传到iTunes Connect. 

确保你在点击”Submit”前，选择了”Include bitcode”。如果一切顺利的话，你将会看到一个绿色对号通知你这次构建已经被上传。

安装后注意到这个App现在接近5.4MB. 这就是App瘦身的意义。

哇哦！你刚刚从你的App中剔除掉了12.4MB - 并且这是一个非常基础的App. 那些包含多种不同的资源( asset )的App将会在App大小方面看到更急剧的变化喔~ 

总结

在本篇教程，我们看了看App瘦身的强大。如此一来，我们讨论了App瘦身的三个主要的方面：应用程序切片( App Slicing ) 中间代码( Bitcode )和按需加载资源( On Demand Resources ). 

十月份的时候苹果当时说，iOS9.0和9.0.1 不会支持App切片，原因是由于一个问题影响iCloud创建自iOS9的备份，其中一些AppStore中的App将会只还原到同样型号的iOS设备。

不过现在都9.2啦，没有这个鬼畜的问题了。

总之，App瘦身特性将会加速App的下载和App的空间占用~