App Thinning，appthinning

App Thinning，appthinning

App Thinning

由於項目中需要開啟Bitcode編譯，之前對Bitcode也有些誤區，故整理了下相關知識，僅供參考，如有不對，還請指出。

當前 iOS App 的編譯打包方式是把適配相容多個裝置的執行檔案及資源檔合并一個檔案，上傳和下載的檔案則包含了所有的這些檔案，導致佔用較多的儲存空間。
App Thinning是一個關於節省iOS裝置儲存空間的功能，它可以讓iOS裝置在安裝、更新及運行App等情境中僅下載所需的資源，減少App的佔用空間，從而節省裝置的儲存空間。

根據Apple官方文檔的介紹，App Thinning主要有三個機制：

1.Slicing

開發人員把App安裝包上傳到AppStore後，Apple服務會自動對安裝包切割為不同的應用變體(App variant)，當使用者下載安裝包時，系統會根據裝置型號下載安裝對應的單個應用變體。（iOS9.0.2以上支援）

iOS app 為了與舊版相容，現在都同時包含了 32 bit 和 64 bit 兩個 slice。另外在圖片資源方面，更是 2x 3x 的映像一應俱全 (現在1x 的應該不太需要了)。而使用者使用 app 時，因為裝置是特定的，其實只需要其中的一套資源。但是現在在購買和下載的時候卻是把整個 app 包都下載了。Apple 終於意識到了這件事情有多傻，iOS 9 中終於可以僅選擇需要的內容 (Slicing) 下載了。對於開發人員來說，並沒有太多要做的事情，只需要使用 asset catalog 來管理素材標記 2x 3x 就可以了。

最終蘋果下載資源的效果如下：

2.Bitcode

開啟Bitcode編譯後，可以使得開發人員上傳App時只需上傳Intermediate Representation(中介軟體)，而非最終的可執行二進位檔案。 在使用者下載App之前，AppStore會自動編譯中介軟體，產生裝置所需的執行檔案供使用者下載安裝。也就是當我們提交程式到 App Store上時， Xcode 會將程式編譯為一個中間表現形式( bitcode )。然後 App store 會再將這個 Bitcode 編譯為可執行檔64位或32位程式。蘋果會根據下載應用的使用者的手機指令集類型產生只有該指令集的二進位，進行下發。從而達到精簡安裝包體積的目的。

Bitcode是LLVM編譯器的中間代碼的一種編碼，LLVM的前端可以理解為C/C++/OC/Swift等程式設計語言，LLVM的後端可以理解為各個晶片平台上的彙編指令或者可執行機器指令資料，那麼，BitCode就是位於這兩者直接的中間碼。LLVM的編譯工作原理是前端負責把項目程式原始碼翻譯成Bitcode中間碼，然後再根據不同目標機器晶片平台轉換為相應的彙編指令以及翻譯為機器碼。這樣設計就可以讓LLVM成為了一個編譯器架構，可以輕而易舉在LLVM架構之上發明新的語言(前端),以及在LLVM架構下面支援新的CPU(後端)指令輸出。
雖然Bitcode僅僅只是一個中間碼不能在任何平台上運行，但是它可以轉化為任何被支援的CPU架構，包括現在還沒被發明的CPU架構，也就是說現在開啟Bitcode功能提交一個App到市集，對於Apple未來進行硬體升級的措施，此機制可以保證在開發人員不重新發布版本的情況下而相容新的裝置。比如以後如果蘋果新出了一款手機並CPU架構也是全新設計的，在蘋果後台伺服器一樣可以從這個App的Bitcode開始編譯轉化為新CPU上的可執行程式，可供新手機使用者下載運行這個App。

在文檔裡可看到
In fact, app slicing handles the
majority of the app thinning process. ‘App Slicing’ feature finally switched on in iOS 9.0.2

說明slicing才是主要處理 app thinning的而且該功能需要在iOS9.0.2以上才支援（iOS9.0中被關閉了，因為一個iCloud的bug）。實際上Bitcode，做的事情是指令集最佳化。根據你裝置的狀態去做編譯最佳化，進而提升效能。所以Bitcode對包的大小最佳化起不到什麼本質上的作用。

Bitcode注意點

1.Xcode 7預設開啟 Bitcode ，如果應用開啟 Bitcode，那麼其整合的其他第三方庫也需要是 Bitcode 編譯的包才能真正進行 Bitcode 編譯
2.開啟 Bitcode 編譯後，編譯產生的 .app 體積會變大(中間代碼，不是使用者下載的包)，且 .dSYM 檔案不能用來崩潰日誌的符號化(使用者下載的包是 Apple 服務重新編譯產生的，有產生新的符號檔案)
3.通過 Archive 方式上傳 AppStore 的包，可以在Xcode的Organizer工具中下載對應安裝包的新的符號檔案

3.On-Demand Resources

ORD(隨需資源)是指開發人員對資源添加標籤上傳後，系統會根據App啟動並執行情況，動態下載並載入所需資源，而在儲存空間不足時，自動刪除這類資源。
這可能在遊戲中應用情境會多一些。你可以用 tag 來組織像映像或者聲音這樣的資源，比如把它們標記為 level1，level2 這樣。然後一開始只需要下載 level1 的內容，在玩的過程中再去下載 level2。或者也可以通過這個來推後下載那些需要內購才能獲得的資源檔。

 

4.測試

看看開啟與不開啟Bitcode對包的大小的影響

測試方法如下：

使用開發模式匯出ipa：

選擇出包的方式這裡使用第二種，產生針對具體機型的包

然後可以看見Compiling Bitcode！

最終結果在最後輸出的檔案中，能夠看到一個App Thinning的結果，裡面有針對各個機型的ipa包。

最終測試結果如下：可以看出開啟Bitcode與否對包的大小影響微乎其微。而且這裡的ipa包大小並不是AppStore中顯示的大小，這裡的大小為實際使用者下載的大小（占手機磁碟中的大小）。

 

參考連結

蘋果官方介紹

Working with App Thinning in iOS 9

Bitcode適配指南

深入理解iOS開發中的BitCode功能