转载_iOS理解开发中的BitCode选项(Objective-C)

2018.4.18
如相关原作者要求删除，请联系我，立删。

1.iOS开发 - Bitcode适配指南
2.理解iOS开发中BitCode功能
3.深入理解iOS开发中的BitCode功能

从Xcode7开始,新建项目默认就打开了bitcode设置

LLVM是目前苹果采用的编译器工具链,Bitcode是LLVM编译器的中间代码的一种编码,LLVM的前端可以理解为C/C++/OC/Swift等编程语言,LLVM的后端可以理解为各个芯片平台上的汇编指令或者可执行机器指令数据,那么,BitCode就是位于这两者直接的中间码. LLVM的编译工作原理是前端负责把项目程序源代码翻译成Bitcode中间码,然后再根据不同目标机器芯片平台转换为相应的汇编指令以及翻译为机器码.这样设计就可以让LLVM成为了一个编译器架构,可以轻而易举的在LLVM架构之上发明新的语言(前端),以及在LLVM架构下面支持新的CPU(后端)指令输出,虽然Bitcode仅仅只是一个中间码不能在任何平台上运行,但是它可以转化为任何被支持的CPU架构,包括现在还没被发明的CPU架构,也就是说现在打开Bitcode功能提交一个App到应用商店,以后如果苹果新出了一款手机并CPU也是全新设计的,在苹果后台服务器一样可以从这个App的Bitcode开始编译转化为新CPU上的可执行程序,可供新手机用户下载运行这个App.
再看官方文档的解释：
Bitcode is an intermediate representation of a compiled program. Apps you upload to iTunes Connect that contain bitcode will be compiled and linked on the App Store. Including bitcode will allow Apple to re-optimize your app binary in the future without the need to submit a new version of your app to the store.
说的是bitcode是被编译程序的一种中间形式的代码。包含bitcode配置的程序将会在App store上被编译和链接。bitcode允许苹果在后期重新优化我们程序的二进制文件，而不需要我们重新提交一个新的版本到App store上。
继续看，在What’s New in Xcode-New Features in Xcode 7中，还有一段如下的描述
Bitcode. When you archive for submission to the App Store, Xcode will compile your app into an intermediate representation. The App Store will then compile the bitcode down into the 64 or 32 bit executables as necessary.
当我们提交程序到App store上时，Xcode会将程序编译为一个中间表现形式(bitcode)。然后App store会再将这个botcode编译为可执行的64位或32位程序。

Bitcode配置

在相关的错误提示中，一般类似的有提到如何处理我们遇到的问题：
You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64
要么让第三方库支持，要么关闭target的bitcode选项。
实际上从Xcode 7之后，我们新建一个iOS程序时，bitcode选项默认是设置为YES的。我们可以在”Build Settings”->”Enable Bitcode”选项中看到这个设置。
不过，我们现在需要考虑的是三个平台：iOS，Mac OS，watchOS。
对应iOS，bitcode是可选的。
对于watchOS，bitcode是必须的。
Mac OS不支持bitcode。
如上面所说，bitcode是一种中间代码。LLVM官方文档有介绍这种文件的格式，有兴趣的可以移步LLVM Bitcode File Format。

一点编译原理

为了更好的理解什么是bitcode，我们简短的看一下编译器编译的过程：

1. Lexer :读入源文件，并将其转化成字符流
2. Parser :将字符流转换成AST（抽象语法树）
3. Semantic Analysis: 对输入的AST进行语法检查。
4. Code Generation: 代码生成，将AST转换成低层次的IR指令
5. Optimization: 分析IR指令，将其中潜在会拖慢运行速度的指令干掉。
6. AsmPrinter: 通过IR（中间码）生成特定CPU架构的汇编代码
7. Assemble: 将汇编代码转化成二进制
8. Linker: 通常程序会引用其他的二进制文件（.a或者framework)，但是这些链接在程序中没有正确的地址，只是个占位符。Linker的工作就是给这些占位符正确的地址。
   更多信息可以参考：The Compiler
   
   

   一般情况下，在真实的编译器构架那种，会将上述过程分成前端和后端两部分来处理：
   
   在前后端之间传递的就是IR（中间码），而bitcode就是一种特殊形式的中间码。原本前后端的工作都是在本地LLVM中完成，虽然Apple没有给出具体的Bitcode实现，但是通过他们的文档可以猜测，是将一部分后端的工作移到了服务器进行。从Xcode上传IR到服务器，服务器来真对不同的机型进行后续操作。从而达到真对不同机型生成对应指令集的二进制，而减小报体积的目的。
   需要注意的是bitcode只默认在archive下编译。在debug和release下并不会。

检测是否打开Bitcode

当打开bitcdoe选项之后，我们可以使用otool工具来检查二进制文件中是否包含bitcode段。

针对于静态链接库.a文件

otool -arch armv7 -l xxxx.a | grep __bitcode | wc -l

如果是当前库支持.a文件则会输出一个数字

如果不支持bitcode则不会出现该数字。
上述命令只检查了armv7架构，同时，也必须使用改指令检查其他的指令集是否包含bitcode如：arm64，armv7s等等

检查app或者framework中是否包含bitcode

由于app中二进制和framework中二进制文件与.a文件存在差异，因为需要检查的是__LLVM段，当出现该段的时候，则表示支持bitcdoe，否则不支持。
otool -l xxxx | grep __LLVM | wc -l
这里otool有个bug，当你的framework使用过lipo命令，进行拆解和合并之后，需要指定指令集进行检查才可以。
otool -arch armv7 -l xxxx | grep __LLVM | wc -l
BUT, 上述检查过了之后，也不一定是真的支持bitcode，在实际的测试中，发现上述检测命令通过之后，某个使用的第三方库，依然报错不支持bitcode。因而最终结果，还是需要以是否能够连接成功为准。重要事情说三遍，上述网上流传的检测方法只做参考，最终还是要以实际效果为准。

最终结果检查

如果您是一个APP，可以直接进行Archive打包，如果是一个库，则建议建一个Demo工程进行打包，记得要打开bitcode设置。

CheckPoint1 连接是否报错

如果有任何一个库没有打开bitcode链接，将会出现类似下方的错误。只要链接过了，那么恭喜了，基本上是OK了。

连接报错

CheckPoint2 检查最终效果

1.使用开发模式导出ipa

使用开发模式导出ipa

使用开发模式导出ipa

2.选择出包的方式

这里建议使用第二种，生成真对具体机型的包

出现了，Compiling Bitcode，这个过程！！！！！

3.最终结果
在最后输出的文件中，你能够看到一个App Thinning的结果，里面有针对各个机型的ipa包。

Apps

在App Thinning Size Report中能够明显看到，由于使用了bitcode等技术之后，所带来的收益：

App Thinning Size Report for All Variants of Black

Variant: Black-iPad (4th generation)-etc.ipa
Supported devices: iPad (3rd generation) and iPad (4th generation)
App + On Demand Resources size: 368 KB compressed, 737 KB uncompressed
App size: 368 KB compressed, 737 KB uncompressed
On Demand Resources size: Zero KB compressed, Zero KB uncompressed
....