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功能