Bitcode 是指代码类型：发送到 iTunes Connect 的“LLVM Bitcode”。这允许 Apple 使用某些计算来进一步重新优化应用程序（例如：可能缩小可执行文件的大小）。如果 Apple 需要更改您的可执行文件，那么他们可以在不上传新版本的情况下执行此操作。
这不同于： 切片，这是 Apple 根据设备的分辨率和架构为用户设备优化您的应用程序的过程。切片不需要位码。 （例如：仅包括 5s 上的@2x 图像）
App Thinning 是切片、位码和按需资源的组合
位码是已编译程序的中间表示。您上传到 iTunes Connect 的包含位码的应用程序将在 App Store 上进行编译和链接。包含位码将允许 Apple 在未来重新优化您的应用程序二进制文件，而无需向商店提交您的应用程序的新版本。
Apple Documentation on App Thinning
什么是嵌入式位码？
根据docs：
位码是已编译程序的中间表示。您上传到 iTunes Connect 的包含位码的应用程序将在 App Store 上进行编译和链接。包含位码将允许 Apple 在未来重新优化您的应用程序二进制文件，而无需向商店提交您的应用程序的新版本。
更新："New Features in Xcode 7" 中的这句话让我想了很久，切片 需要 Bitcode 来减小应用程序大小：
当您归档以提交到 App Store 时，Xcode 会将您的应用程序编译为中间表示。然后，App Store 将根据需要将位代码编译成 64 位或 32 位可执行文件。
然而事实并非如此，Bitcode 和 Slicing 是独立工作的：Slicing 是关于减少应用程序大小和生成应用程序包变体，而 Bitcode 是关于某些二进制优化。我已经通过检查非位码应用程序的可执行文件中包含的架构来验证这一点，并发现它们只包含必要的架构。
Bitcode 允许称为 Slicing 的其他 App Thinning 组件生成具有特定架构的特定可执行文件的应用程序包变体，例如 iPhone 5S 变体将仅包含 arm64 可执行文件、iPad Mini armv7 等。
何时在新 Xcode 中启用 ENABLE_BITCODE？
对于 iOS 应用程序，位码是默认设置，但可选。如果您提供位码，则应用程序包中的所有应用程序和框架都需要包含位码。对于 watchOS 和 tvOS 应用程序，需要位码。
在新的 Xcode 中启用 ENABLE_BITCODE 时，二进制文件会发生什么情况？
来自 Xcode 7 参考：
激活此设置表示目标或项目应在编译期间为支持它的平台和架构生成位码。对于存档构建，将在链接的二进制文件中生成位码以提交到应用商店。对于其他构建，编译器和链接器将检查代码是否符合生成位码的要求，但不会生成实际的位码。
这里有几个链接将有助于更深入地理解 Bitcode：
比特码揭秘
为什么我没有启用 Bitcode
由于确切的问题是“启用位码有什么作用”，因此我想提供一些迄今为止我已经弄清楚的技术细节。在 Apple 发布此编译器的源代码之前，其中大部分内容几乎不可能 100% 确定
首先，Apple 的位码似乎与 LLVM 字节码不同。至少，我无法找出它们之间的任何相似之处。它似乎有一个专有的标头（总是以“xar！”开头），并且可能有一些链接时引用魔法可以防止数据重复。如果你写出一个硬编码的字符串，这个字符串只会被放入数据中一次，而不是像普通 LLVM 字节码那样的两倍。
其次，bitcode 并没有像预期的那样真正作为单独的架构在二进制存档中提供。它与 x86 和 ARM 放入一个二进制文件（FAT 存档）的方式不同。相反，他们使用架构特定的 MachO 二进制文件中的一个特殊部分，名为“__LLVM”，它随每个支持的架构一起提供（即，复制的）。我认为这是他们的编译器系统的一个缺点，将来可能会修复以避免重复。
C 代码（使用 clang -fembed-bitcode hi.c -S -emit-llvm 编译）：
#include <stdio.h>
int main() {
printf("hi there!");
return 0;
}
LLVM 红外输出：
; ModuleID = '/var/folders/rd/sv6v2_f50nzbrn4f64gnd4gh0000gq/T/hi-a8c16c.bc'
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.10.0"
@.str = private unnamed_addr constant [10 x i8] c"hi there!\00", align 1
@llvm.embedded.module = appending constant [1600 x i8] c"\DE\C0\17\0B\00\00\00\00\14\00\00\00$\06\00\00\07\00\00\01BC\C0\DE!\0C\00\00\86\01\00\00\0B\82 \00\02\00\00\00\12\00\00\00\07\81#\91A\C8\04I\06\1029\92\01\84\0C%\05\08\19\1E\04\8Bb\80\10E\02B\92\0BB\84\102\148\08\18I\0A2D$H\0A\90!#\C4R\80\0C\19!r$\07\C8\08\11b\A8\A0\A8@\C6\F0\01\00\00\00Q\18\00\00\C7\00\00\00\1Bp$\F8\FF\FF\FF\FF\01\90\00\0D\08\03\82\1D\CAa\1E\E6\A1\0D\E0A\1E\CAa\1C\D2a\1E\CA\A1\0D\CC\01\1E\DA!\1C\C8\010\87p`\87y(\07\80p\87wh\03s\90\87ph\87rh\03xx\87tp\07z(\07yh\83r`\87th\07\80\1E\E4\A1\1E\CA\01\18\DC\E1\1D\DA\C0\1C\E4!\1C\DA\A1\1C\DA\00\1E\DE!\1D\DC\81\1E\CAA\1E\DA\A0\1C\D8!\1D\DA\A1\0D\DC\E1\1D\DC\A1\0D\D8\A1\1C\C2\C1\1C\00\C2\1D\DE\A1\0D\D2\C1\1D\CCa\1E\DA\C0\1C\E0\A1\0D\DA!\1C\E8\01\1D\00s\08\07v\98\87r\00\08wx\876p\87pp\87yh\03s\80\876h\87p\A0\07t\00\CC!\1C\D8a\1E\CA\01 \E6\81\1E\C2a\1C\D6\A1\0D\E0A\1E\DE\81\1E\CAa\1C\E8\E1\1D\E4\A1\0D\C4\A1\1E\CC\C1\1C\CAA\1E\DA`\1E\D2A\1F\CA\01\C0\03\80\A0\87p\90\87s(\07zh\83q\80\87z\00\C6\E1\1D\E4\A1\1C\E4\00 \E8!\1C\E4\E1\1C\CA\81\1E\DA\C0\1C\CA!\1C\E8\A1\1E\E4\A1\1C\E6\01X\83y\98\87y(\879`\835\18\07|\88\03;`\835\98\87y(\076X\83y\98\87r\90\036X\83y\98\87r\98\03\80\A8\07w\98\87p0\87rh\03s\80\876h\87p\A0\07t\00\CC!\1C\D8a\1E\CA\01 \EAa\1E\CA\A1\0D\E6\E1\1D\CC\81\1E\DA\C0\1C\D8\E1\1D\C2\81\1E\00s\08\07v\98\87r\006\C8\88\F0\FF\FF\FF\FF\03\C1\0E\E50\0F\F3\D0\06\F0 \0F\E50\0E\E90\0F\E5\D0\06\E6\00\0F\ED\10\0E\E4\00\98C8\B0\C3<\94\03@\B8\C3;\B4\819\C8C8\B4C9\B4\01<\BCC:\B8\03=\94\83<\B4A9\B0C:\B4\03@\0F\F2P\0F\E5\00\0C\EE\F0\0Em`\0E\F2\10\0E\EDP\0Em\00\0F\EF\90\0E\EE@\0F\E5 \0FmP\0E\EC\90\0E\ED\D0\06\EE\F0\0E\EE\D0\06\ECP\0E\E1`\0E\00\E1\0E\EF\D0\06\E9\E0\0E\E60\0Fm`\0E\F0\D0\06\ED\10\0E\F4\80\0E\809\84\03;\CCC9\00\84;\BCC\1B\B8C8\B8\C3<\B4\819\C0C\1B\B4C8\D0\03:\00\E6\10\0E\EC0\0F\E5\00\10\F3@\0F\E10\0E\EB\D0\06\F0 \0F\EF@\0F\E50\0E\F4\F0\0E\F2\D0\06\E2P\0F\E6`\0E\E5 \0Fm0\0F\E9\A0\0F\E5\00\E0\01@\D0C8\C8\C39\94\03=\B4\C18\C0C=\00\E3\F0\0E\F2P\0Er\00\10\F4\10\0E\F2p\0E\E5@\0Fm`\0E\E5\10\0E\F4P\0F\F2P\0E\F3\00\AC\C1<\CC\C3<\94\C3\1C\B0\C1\1A\8C\03>\C4\81\1D\B0\C1\1A\CC\C3<\94\03\1B\AC\C1<\CCC9\C8\01\1B\AC\C1<\CCC9\CC\01@\D4\83;\CCC8\98C9\B4\819\C0C\1B\B4C8\D0\03:\00\E6\10\0E\EC0\0F\E5\00\10\F50\0F\E5\D0\06\F3\F0\0E\E6@\0Fm`\0E\EC\F0\0E\E1@\0F\809\84\03;\CCC9\00\00I\18\00\00\02\00\00\00\13\82`B \00\00\00\89 \00\00\0D\00\00\002\22\08\09 d\85\04\13\22\A4\84\04\13\22\E3\84\A1\90\14\12L\88\8C\0B\84\84L\100s\04H*\00\C5\1C\01\18\94`\88\08\AA0F7\10@3\02\00\134|\C0\03;\F8\05;\A0\836\08\07x\80\07v(\876h\87p\18\87w\98\07|\88\038p\838\80\037\80\83\0DeP\0Em\D0\0Ez\F0\0Em\90\0Ev@\07z`\07t\D0\06\E6\80\07p\A0\07q \07x\D0\06\EE\80\07z\10\07v\A0\07s \07z`\07t\D0\06\B3\10\07r\80\07:\0FDH #EB\80\1D\8C\10\18I\00\00@\00\00\C0\10\A7\00\00 \00\00\00\00\00\00\00\868\08\10\00\02\00\00\00\00\00\00\90\05\02\00\00\08\00\00\002\1E\98\0C\19\11L\90\8C\09&G\C6\04C\9A\22(\01\0AM\D0i\10\1D]\96\97C\00\00\00y\18\00\00\1C\00\00\00\1A\03L\90F\02\134A\18\08&PIC Level\13\84a\D80\04\C2\C05\08\82\83c+\03ab\B2j\02\B1+\93\9BK{s\03\B9q\81q\81\01A\19c\0Bs;k\B9\81\81q\81q\A9\99q\99I\D9\10\14\8D\D8\D8\EC\DA\5C\DA\DE\C8\EA\D8\CA\5C\CC\D8\C2\CE\E6\A6\04C\1566\BB6\974\B227\BA)A\01\00y\18\00\002\00\00\003\08\80\1C\C4\E1\1Cf\14\01=\88C8\84\C3\8CB\80\07yx\07s\98q\0C\E6\00\0F\ED\10\0E\F4\80\0E3\0CB\1E\C2\C1\1D\CE\A1\1Cf0\05=\88C8\84\83\1B\CC\03=\C8C=\8C\03=\CCx\8Ctp\07{\08\07yH\87pp\07zp\03vx\87p \87\19\CC\11\0E\EC\90\0E\E10\0Fn0\0F\E3\F0\0E\F0P\0E3\10\C4\1D\DE!\1C\D8!\1D\C2a\1Ef0\89;\BC\83;\D0C9\B4\03<\BC\83<\84\03;\CC\F0\14v`\07{h\077h\87rh\077\80\87p\90\87p`\07v(\07v\F8\05vx\87w\80\87_\08\87q\18\87r\98\87y\98\81,\EE\F0\0E\EE\E0\0E\F5\C0\0E\EC\00q \00\00\05\00\00\00&`<\11\D2L\85\05\10\0C\804\06@\F8\D2\14\01\00\00a \00\00\0B\00\00\00\13\04A,\10\00\00\00\03\00\00\004#\00dC\19\020\18\83\01\003\11\CA@\0C\83\11\C1\00\00#\06\04\00\1CB\12\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00", section "__LLVM,__bitcode"
@llvm.cmdline = appending constant [67 x i8] c"-triple\00x86_64-apple-macosx10.10.0\00-emit-llvm\00-disable-llvm-optzns\00", section "__LLVM,__cmdline"
; Function Attrs: nounwind ssp uwtable
define i32 @main() #0 {
%1 = alloca i32, align 4
store i32 0, i32* %1
%2 = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([10 x i8]* @.str, i32 0, i32 0))
ret i32 0
}
declare i32 @printf(i8*, ...) #1
attributes #0 = { nounwind ssp uwtable "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="core2" "target-features"="+ssse3,+cx16,+sse,+sse2,+sse3" "unsafe-fp-math"="false" "use-soft-float"="false" }
attributes #1 = { "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="core2" "target-features"="+ssse3,+cx16,+sse,+sse2,+sse3" "unsafe-fp-math"="false" "use-soft-float"="false" }
!llvm.module.flags = !{!0}
!llvm.ident = !{!1}
!0 = !{i32 1, !"PIC Level", i32 2}
!1 = !{!"Apple LLVM version 7.0.0 (clang-700.0.53.3)"}
IR 中的数据数组也会根据 clang 的优化和其他代码生成设置而变化。我完全不知道这是什么格式或任何东西。
编辑：
根据 Twitter 上的提示，我决定重新审视并确认这一点。我关注 this blog post 并使用他的位码提取器工具从 MachO 可执行文件中获取 Apple Archive 二进制文件。在使用 xar 实用程序提取 Apple Archive 后，我得到了这个（当然，用 llvm-dis 转换为文本）
; ModuleID = '1'
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.10.0"
@.str = private unnamed_addr constant [10 x i8] c"hi there!\00", align 1
; Function Attrs: nounwind ssp uwtable
define i32 @main() #0 {
%1 = alloca i32, align 4
store i32 0, i32* %1
%2 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([10 x i8], [10 x i8]* @.str, i32 0, i32 0))
ret i32 0
}
declare i32 @printf(i8*, ...) #1
attributes #0 = { nounwind ssp uwtable "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="core2" "target-features"="+ssse3,+cx16,+sse,+sse2,+sse3" "unsafe-fp-math"="false" "use-soft-float"="false" }
attributes #1 = { "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="core2" "target-features"="+ssse3,+cx16,+sse,+sse2,+sse3" "unsafe-fp-math"="false" "use-soft-float"="false" }
!llvm.module.flags = !{!0}
!llvm.ident = !{!1}
!0 = !{i32 1, !"PIC Level", i32 2}
!1 = !{!"Apple LLVM version 7.0.0 (clang-700.1.76)"}
非位码 IR 和位码 IR 之间唯一显着的区别是每个架构的文件名已被剥离为 1、2 等。
我还确认嵌入在二进制文件中的位码是在优化后生成的。如果你使用 -O3 编译并提取位码，它会与使用 -O0 编译不同。
为了获得额外的荣誉，我还确认，当您下载 iOS 9 应用程序时，Apple 不会向设备发送比特码。它们包括许多其他我不认识的奇怪部分，例如 __LINKEDIT，但它们不包括 __LLVM.__bundle，因此似乎没有在设备上运行的最终二进制文件中包含位码。奇怪的是，Apple 仍然向 iOS 8 设备提供带有单独 32/64 位代码的胖二进制文件。
xar! 是 Apple 的存档文件格式。
位码（iOS、watchOS） 位码是已编译程序的中间表示。您上传到 iTunes Connect 的包含位码的应用程序将在 App Store 上进行编译和链接。包含位码将允许 Apple 在未来重新优化您的应用程序二进制文件，而无需向商店提交您的应用程序的新版本。
基本上这个概念有点类似于在不同 JVM 上运行字节码的 java，在这种情况下，位码被放置在 iTune 存储中，而不是将中间代码提供给不同的平台（设备），它提供了不需要的编译代码任何要运行的虚拟机。
因此，我们需要创建一次位码，它将可用于现有或即将推出的设备。编译一个使其与他们拥有的每个平台兼容是苹果公司的头疼问题。
开发人员无需进行更改并再次提交应用程序即可支持新平台。
我们以苹果在其中引入x64芯片的 iPhone 5s 为例。虽然 x86 应用程序与 x64 架构完全兼容，但要充分利用 x64 平台，开发人员必须更改架构或一些代码。一旦她/他完成了应用程序将被提交到应用程序商店进行审查。
如果这个位码概念是较早推出的，那么我们开发人员无需进行任何更改即可支持 x64 位架构。
更新
Apple has clarified 切片的发生与启用位码无关。我在实践中也观察到了这一点，非比特码启用的应用程序只会作为适合目标设备的架构下载。
原来的
位码。归档您的应用程序以以中间表示形式提交到 App Store，该中间表示形式在交付时编译为目标设备的 64 位或 32 位可执行文件。切片。合并到资产目录并标记为平台的艺术品允许 App Store 仅提供安装所需的内容。
按照我的阅读方式，如果您支持位码，您的应用程序的下载者将只能获得他们自己设备所需的编译架构。
位码
Bitcode（磁盘上的位码表示、位码文件格式、二进制格式）。
它是 [Intermediate Representation (IR) in LLVM] 的三种表示形式之一。它是 LLVM IR 的比特流（二进制编码）文件格式。这是 LLVM IR 序列化的结果。它可以选择性地嵌入到 Wrapper 或 Native Object File（Mach-O 在原始段数据中[About]）。它适用于即时编译器。您可以使用 llvm-dis 将 bitcode IR 转换为人类可读的 IR
Apple 使用的另一个优点是可以为另一个（新）架构（instruction set architecture (ISA)）重新编译二进制文件，而无需开发人员注意。此外，您还可以进行逆向工程，这使 Apple 可以更轻松地分析二进制文件，但另一方面，它是一个缺点，可以被恶意软件使用。它还增加了构建时间
当您构建位码 .BCSymbolMap[About] 时，还会生成用于分析错误堆栈跟踪
请注意，不会为模拟器（arch x86_64）生成位码。 Xcode 在接下来的场景中使用 bitcode：
标志：
-fembed-bitcode - 嵌入位码
-fembed-bitcode-marker - 只需标记它的位置。 __LLVM 段为空，没有任何数据
使用：
启用位码 (ENABLE_BITCODE)。是 - 是应用程序的默认设置，框架目标使用 -fembed-bitcode-marker 进行常规构建使用 -fembed-bitcode 在存档（产品 -> 存档）或（xcodebuild 存档）中嵌入位码
使用 -fembed-bitcode-marker 进行常规构建
使用 -fembed-bitcode 在存档中嵌入位码（产品 -> 存档）或（xcodebuild 存档）
将标志显式添加到其他 C 标志（OTHER_CFLAGS）
用户定义设置 BITCODE_GENERATION_MODE 标记 - 添加 -fembed-bitcode-marker 位码 - 添加 -fembed-bitcode
标记 - 添加 -fembed-bitcode-marker
bitcode - 添加 -fembed-bitcode
xcodebuild 上面有适当的选项
//please make sure that this settings is placed before xcodebuild params(.e.g. -workspace, -scheme...)
xcodebuild ENABLE_BITCODE=YES
//or
xcodebuild BITCODE_GENERATION_MODE="bitcode"
//or
xcodebuild OTHER_CFLAGS="-fembed-bitcode"
如果您在应用程序中使用 embed bitcode 但并非所有库都支持它，您会得到
ld: bitcode bundle could not be generated because '<path>' was built without full bitcode. All frameworks and dylibs for bitcode must be generated from Xcode Archive or Install build file '<path>' for architecture <arch>
检查二进制文件是否包含位码
位码必须存储在名为 __LLVM 的对象文件的一部分中，__bitcode 用于 MachO，而 .llvmbc 用于其他对象格式。
位码注入 __LLVM 分段三个部分：__bitcode、__cmdline、__asm。 Apple 的 LLVM 版本使用了一些不同的逻辑，并将 __bitcode 和 __cmdline 移动到 __bundle 部分作为 .xar 存档。
eXtensible ARchive(XAR) - .xar、.pkg 归档器的文件格式，由标题、目录 (toc)、堆组成。 TOC 用于随机访问存档文件。 xar 中的每个文件都是独立压缩的
otool -l 并找到 __LLVM __bundle。
您可以检查 Mach-O 文件中的段名和节名
但它不保证包含位码（例如标记）
//<segname> <sectname> e.g. __LLVM __bundle. They are started from __
otool -l "/Users/alex/MyModule.framework/MyModule"
//or universal framework(specify arch)
otool -arch arm64 -l "/Users/alex/MyModule.framework/MyModule"
//or all arch
otool -arch all -l "/Users/alex/MyModule.framework/MyModule"
//-l print the load commands
输出：
Section
sectname __bundle
segname __LLVM
addr 0x00000000000c0000
size 0x00000000003af3ce
offset 770048
...
otool -v -s __LLVM __bundle
otool -v -s __LLVM __bundle <binary_path>
//e.g.
otool -v -s __LLVM __bundle "/Users/alex/MyModule.framework/MyModule"
// -s <segname> <sectname> print contents of section. e.g. -s __LLVM __bundle
// -v print verbosely (symbolically) when possible
otool -s __LLVM __bundle 的输出。它是比特流（二进制编码）
Contents of (__LLVM,__bundle) section
00000000000b4000 21726178 01001c00 00000000 c60d0000
00000000000b4010 00000000 be860000 01000000 9decda78
00000000000b4020 b6dc735b f3dfc715 5f7a3429 bdc1ce2f
otool -v -s __LLVM __bundle 的输出。它是 XAR 的目录 (TOC)。 -v 将比特流（二进制编码）转换为 XAR 目录 (TOC) 的 XML 格式
For (__LLVM,__bundle) section: xar table of contents:
<?xml version="1.0" encoding="UTF-8"?>
<xar>
<subdoc subdoc_name="Ld">
<version>1.0</version>
...
生成另一个指标 .bcsymbolmap[About]
查找并提取位码
Closed source Library developer - XCFramework
App developer - enable bitcode
位码是强制性的 Official
对于 iOS 应用程序，位码是默认设置，但可选。对于 watchOS 和 tvOS 应用程序，需要位码。
二进制大小
位码会增加二进制大小，如果不是强制性的，您可以使用 bitcode_strip 从二进制文件中手动删除位码
例如
xcrun bitcode_strip -r "/Users/alex/MyModule.framework/MyModule" -o "/Users/alex/MyModule.framework/MyModule"
// -r remove bitcode
// -o output file name
