本文翻譯自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的空間占用~