iOS app的编译过程

在 iOS 开发的过程中，Xcode 为我们提供了非常完善的编译能力，正常情况下，我们只需要 Command + R 就可以将应用运行到设备上，即使打包也是一个相对愉快的过程。

但正如我们写代码无法避开 Bug 一样，项目在编译的时候也会出现各种各样的错误，最痛苦的莫过于处理这些错误。其中的各种报错都不是我们在日常编程中所能接触的，而我们无法快速精准的定位错误并解决的唯一原因就是我们根本不知道在编译的时候都做了些什么，都需要些什么。就跟使用一个新的类，如果不去查看其代码，永远也无法知道它到底能干什么一样。

这篇文章将从由简入繁的讲解 iOS App 在编译的时候到底干了什么。一个 iOS 项目的编译过程是比较繁琐的，针对源代码、xib、framework 等都将进行一定的编译和操作，再加上使用 Cocoapods，会让整个过程更加复杂。这篇文章将以 Swift 和 Objective-C 的不同角度来分析。

1.什么是编译

在开始之前，我们必须知道什么是编译？为什么要进行编译？

CPU 由上亿个晶体管组成，在运行的时候，单个晶体管只能根据电流的流通或关闭来确认两种状态，我们一般说 0 或 1，根据这种状态，人类创造了二进制，通过二进制编码我们可以表示所有的概念。但是，CPU 依然只能执行二进制代码。我们将一组二进制代码合并成一个指令或符号，创造了汇编语言，汇编语言以一种相对好理解的方式来编写，然后通过汇编过程生成 CPU 可以运行的二进制代码并运行在 CPU 上。

但是使用汇编语言开发仍然是一个相对痛苦的过程，于是通过上述方式，c、c++、Java 等语言就一层一层的被发明出来。Objective-c 和 Swift 就是这样一个过程，他们的基础都是 c 和 c++。

当我们使用 Objective-c 和 Swift 编写代码后，想要代码能运行在 CPU 上，我们必须进行编译，将我们写好的代码编译为机器可以理解的二进制代码。

1.1 LLVM

有了上面的简单介绍，可以发现，编译其实是一个用代码解释代码的过程。在 Objective-c 和 Swift 的编译过程中，用来解释代码的，就是 LLVM。点击可以看到 LLVM 的官方网站，在 Overview 的第一行就说明了 LLVM 到底是什么：

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Despite its name, LLVM has little to do with traditional virtual machines. The name “LLVM” itself is not an acronym; it is the full name of the project.

LLVM 项目是一个模块化、可重用的编译器、工具链技术的集合。尽管它的名字叫 LLVM，但它与传统虚拟机的关系并不大。“LLVM”这个名字本身不是一个缩略词; 它的全称是这个项目。

// LLVM 命名最早源自于底层虚拟机(Low Level Virtual Machine)的缩写。

简单的说，LLVM 是一个项目，其作用就是提供一个广泛的工具，可以将任何高级语言的代码编译为任何架构的 CPU 都可以运行的机器代码。它将整个编译过程分类了三个模块：前端、公用优化器、后端。（这里不要去思考任何关于 web 前端和 service 后端的概念。）

前端：对目标语言代码进行语法分析，语义分析，生成中间代码。在这个过程中，会进行类型检查，如果发现错误或者警告会标注出来在哪一行。我们在开发的过程中，其实 Xcode 也会使用前端工具对你的代码进行分析，并实时的检查出来某些错误。前端是针对特定语言的，如果需要一个新的语言被编译，只需要再写一个针对新语言的前端模块即可。

公用优化器：将生成的中间文件进行优化，去除冗余代码，进行结构优化。

后端：后段将优化后的中间代码再次转换，变成汇编语言，并再次进行优化，最后将各个文件代码转换为机器代码并链接。链接是指将不同代码文件编译后的不同机器代码文件合并成一个可执行文件。
虽然目前 LLVM 并没有达到其目标（可以编译任何代码），但是这样的思路是很优秀的，在日常开发中，这种思路也会为我们提供不少的帮助。

1.2 clang

clang 是 LLVM 的一个前端，它的作用是针对 C 语言家族的语言进行编译，像 c、c++、Objective-C。而 Swift 则自己实现了一个前端来进行 Swift 编译，优化器和后端依然是使用 LLVM 来完成，后面会专门对 Swift 语言的前端编译流程进行分析。

上面简单的介绍了为什么需要编译，以及 Objectie-C 和 Swift 代码的编译思路。这是基础，如果没有这些基础，后面针对我们整个项目的编译就无法理解，如果你理解了上面的知识点，那么下面将要讲述的整个项目的编译过程就会显得很简单了。

2.ios项目编译过程介绍

Xcode 在编译 iOS 项目的时候，使用的正是 LLVM，其实我们在编写代码以及调试的时候也在使用 LLVM 提供的功能。例如代码高亮（clang）、实时代码检查（clang）、代码提示（clang）、debug 断点调试（LLDB）。这些都是 LLVM 前端提供的功能，而对于后端来说，我们接触到的就是关于 arm64、armv7、armv7s 这些 CPU 架构了，记得之前还有 32 位架构处理器的时候，设定指定的编译的目标 CPU 架构就是一个比较痛苦的过程。

下面来简单的讲讲整个 iOS 项目的编译过程，其中可能会有一些疑问，先保留着，后面会详细解释：
我们的项目是一个 target，一个编译目标，它拥有自己的文件和编译规则，在我们的项目中可以存在多个子项目，这在编译的时候就导致了使用了 Cocoapods 或者拥有多个 target 的项目会先编译依赖库。这些库都和我们的项目编译流程一致。Cocoapods 的原理解释将在文章后面一部分进行解释。

1.写入辅助文件：将项目的文件结构对应表、将要执行的脚本、项目依赖库的文件结构对应表写成文件，方
便后面使用；并且创建一个 .app 包，后面编译后的文件都会被放入包中；

2.运行预设脚本：Cocoapods 会预设一些脚本，当然你也可以自己预设一些脚本来运行。这些脚本都在 Build Phases 中可以看到；

3.编译文件：针对每一个文件进行编译，生成可执行文件 Mach-O，这过程 LLVM 的完整流程，前端、优化器、后端；

4.链接文件：将项目中的多个可执行文件合并成一个文件；

5.拷贝资源文件：将项目中的资源文件拷贝到目标包；

6.编译 storyboard 文件：storyboard 文件也是会被编译的；

7.链接 storyboard 文件：将编译后的 storyboard 文件链接成一个文件；

8.编译 Asset 文件：我们的图片如果使用 Assets.xcassets 来管理图片，那么这些图片将会被编译成机器码，除了 icon 和 launchImage；

9.运行 Cocoapods 脚本：将在编译项目之前已经编译好的依赖库和相关资源拷贝到包中。

10.生成 .app 包

11.将 Swift 标准库拷贝到包中

12.对包进行签名

13.完成打包

在上述流程中：2 - 9 步骤的数量和顺序并不固定，这个过程可以在 Build Phases 中指定。Phases：阶段、步骤。这个 Tab 的意思就是编译步骤。其实不仅我们的整个编译步骤和顺序可以被设定，包括编译过程中的编译规则（Build Rules）和具体步骤的参数（Build Settings），在对应的 Tab 都可以看到。关于整个编译流程的日志和设定，可以查看这篇文章：Build 过程，跟着它的步骤来查看自己的项目将有助于你理解整个编译流程。后面也会详细讲解这些内容。

3.文件编译过程

Objective-C 的文件中，只有 .m 文件会被编译 .h 文件只是一个暴露外部接口的头文件，它的作用是为被编译的文件中的代码做简单的共享。下面拿一个单独的类文件进行分析。这些步骤中的每一步你都可以使用 clang 的命令来查看其进度，记住 clang 是一个命令行工具，它可以直接在终端中运行。这里我们使用 c 语言作为例子类进行分析，它的过程和 Objective-C 一样，后面 3.7 会讲到 Swift 文件是如何被编译的。

3.1预处理

在我们的代码中会有很多 #import 宏，预处理的第一步就是将 import 引入的文件代码放入对应文件。

然后将自定义宏替换，例如我们定义了如下宏并进行了使用：

#define Button_Height 44
#define Button_Width 100

button.frame = CGRectMake(0, 0, Button_Width, Button_Height);

那么代码将会被替换成

button.frame = CGRectMake(0, 0, 44, 100);

按照这样的思路可以发现，在自定义宏的时候要格外小心，尤其是一些携带参数和功能的宏，这些宏也只是简单的直接替换代码，不能真的代替方法或函数，中间会有很多问题。

在将代码完全拆开后，将会对代码进行符号化，对于分析代码的代码 (clang)，我们写的代码就是一些字符串，为了后面给这些代码进行语法和语义分析，需要将我们的代码进行标记并符号化，例如一段 helloworld 的 c 代码：

#include <stdio.h>
int main(int argc, char *argv[])
{
    printf("Hello World!\n");
    return 0;
}

使用 clang 命令 clang -Xclang -dump-tokens helloworld.c 转化后的代码如下（去掉了 stdio.h 中的内容）：

int 'int'    [StartOfLine]  Loc=<helloworld.c:2:1>
identifier 'main'    [LeadingSpace] Loc=<helloworld.c:2:5>
l_paren '('     Loc=<helloworld.c:2:9>
int 'int'       Loc=<helloworld.c:2:10>
identifier 'argc'    [LeadingSpace] Loc=<helloworld.c:2:14>
comma ','       Loc=<helloworld.c:2:18>
char 'char'  [LeadingSpace] Loc=<helloworld.c:2:20>
star '*'     [LeadingSpace] Loc=<helloworld.c:2:25>
identifier 'argv'       Loc=<helloworld.c:2:26>
l_square '['        Loc=<helloworld.c:2:30>
r_square ']'        Loc=<helloworld.c:2:31>
r_paren ')'     Loc=<helloworld.c:2:32>
l_brace '{'  [StartOfLine]  Loc=<helloworld.c:3:1>
identifier 'printf'  [StartOfLine] [LeadingSpace]   Loc=<helloworld.c:4:2>
l_paren '('     Loc=<helloworld.c:4:8>
string_literal '"Hello World!\n"'       Loc=<helloworld.c:4:9>
r_paren ')'     Loc=<helloworld.c:4:25>
semi ';'        Loc=<helloworld.c:4:26>
return 'return'  [StartOfLine] [LeadingSpace]   Loc=<helloworld.c:5:2>
numeric_constant '0'     [LeadingSpace] Loc=<helloworld.c:5:9>
semi ';'        Loc=<helloworld.c:5:10>
r_brace '}'  [StartOfLine]  Loc=<helloworld.c:6:1>
eof ''      Loc=<helloworld.c:6:2>

这里，每一个符号都会标记出来其位置，这个位置是宏展开之前的位置，这样后面如果发现报错，就可以正确的提示错误位置了。针对 Objective-C 代码，我们只需要转化对应的 .m 文件就可以查看。

3.2语意和语法分析

3.2.1AST

对代码进行标记之后，其实就可以对代码进行分析，但是这样分析起来的过程会比较复杂。于是 clang 又进行了一步转换：将之前的标记流转换为一颗抽象语法树（abstract syntax tree – AST）。

使用 clang 命令 clang -Xclang -ast-dump -fsyntax-only helloworld.c，转化后的树如下（去掉了 stdio.h 中的内容）：

`-FunctionDecl 0x7f8eaf834bb0 <helloworld.c:2:1, line:6:1> line:2:5 main 'int (int, char **)'
  |-ParmVarDecl 0x7f8eaf8349b8 <col:10, col:14> col:14 argc 'int'
  |-ParmVarDecl 0x7f8eaf834aa0 <col:20, col:31> col:26 argv 'char **':'char **'
  `-CompoundStmt 0x7f8eaf834dd8 <line:3:1, line:6:1>
    |-CallExpr 0x7f8eaf834d40 <line:4:2, col:25> 'int'
    | |-ImplicitCastExpr 0x7f8eaf834d28 <col:2> 'int (*)(const char *, ...)' <FunctionToPointerDecay>
    | | `-DeclRefExpr 0x7f8eaf834c68 <col:2> 'int (const char *, ...)' Function 0x7f8eae836d78 'printf' 'int (const char *, ...)'
    | `-ImplicitCastExpr 0x7f8eaf834d88 <col:9> 'const char *' <BitCast>
    |   `-ImplicitCastExpr 0x7f8eaf834d70 <col:9> 'char *' <ArrayToPointerDecay>
    |     `-StringLiteral 0x7f8eaf834cc8 <col:9> 'char [14]' lvalue "Hello World!\n"
    `-ReturnStmt 0x7f8eaf834dc0 <line:5:2, col:9>
      `-IntegerLiteral 0x7f8eaf834da0 <col:9> 'int' 0

这是一个 main 方法的抽象语法树，可以看到树顶是 FunctionDecl：方法声明（Function Declaration

这里因为截取了部分代码，其实并不是整个树的树顶。真正的树顶描述应该是：TranslationUnitDecl。
然后是两个 ParmVarDecl：参数声明。

接着下一层是 CompoundStmt：说明下面有一组复合的声明语句，指的是我们的 main 方法里面所使用到的所有代码。

再到里面就是每一行代码的使用，方法的调用，传递的参数，以及返回。在实际应用中还会有变量的声明、操作符的使用等。

3.2.2静态分析

有了这样的语法树，对代码的分析就会简单许多。对这棵树进行遍历分析，包括类型检查、实现检查（某个类是否存在某个方法）、变量使用，还会有一些复杂的检查，例如在 Objective-C 中，给某一个对象发送消息（调用某个方法），检查这个对象的类是否声明这个方法（但并不会去检查这个方法是否实现，这个错误是在运行时进行检查的），如果有什么错误就会进行提示。因此可见，Xcode 对 clang 做了非常深度的集成，在编写代码的过程中它就会使用 clang 来对你的代码进行分析，并及时的对你的代码错误进行提示。

3.3生成LLVM代码

当确认代码没有问题后（静态分析可分析出来的问题），前端就将进入最后一步：生成 LLVM 代码，并将代码递交给优化器。

使用命令 clang -S -emit-llvm helloworld.c -o helloworld.ll 将生成 LLVM IR。

其设计的最重要的部分是 LLVM 中间表示（IR），它是一种在编译器中表示代码的形式。LLVM IR 旨在承载在编译器的优化器中间的分析和转换。它的设计考虑了许多特定的目标，包括支持轻量级运行时优化，跨功能/进程间优化，整个程序分析和积极的重组转换等等。但它最重要的方面是它本身被定义为具有明确定义的语义的第一类语言。

例如我们上面的代码将会被生成为：

; ModuleID = 'helloworld.c'
source_filename = "helloworld.c"
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.12.0"

@.str = private unnamed_addr constant [14 x i8] c"Hello World!\0A\00", align 1

; Function Attrs: nounwind ssp uwtable
define i32 @main(i32, i8**) #0 {
  %3 = alloca i32, align 4
  %4 = alloca i32, align 4
  %5 = alloca i8**, align 8
  store i32 0, i32* %3, align 4
  store i32 %0, i32* %4, align 4
  store i8** %1, i8*** %5, align 8
  %6 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([14 x i8], [14 x i8]* @.str, i32 0, i32 0))
  ret i32 0
}

declare i32 @printf(i8*, ...) #1

attributes #0 = { nounwind ssp uwtable "correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false" "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-jump-tables"="false" "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="penryn" "target-features"="+cx16,+fxsr,+mmx,+sse,+sse2,+sse3,+sse4.1,+ssse3,+x87" "unsafe-fp-math"="false" "use-soft-float"="false" }
attributes #1 = { "correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false" "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" "no-signed-zeros-fp-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="penryn" "target-features"="+cx16,+fxsr,+mmx,+sse,+sse2,+sse3,+sse4.1,+ssse3,+x87" "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 8.1.0 (clang-802.0.42)"}

其实还是能实现我们功能的代码，在这一步，所有 LLVM 前端支持的语言都将会被转换成这样的代码，主要是为了后面的工作可以共用。下面就是 LVVM 中的优化器的工作。

在这里简单介绍一些 LLVM IR 的指令：

%：局部变量
@：全局变量
alloca：分配内存堆栈
i32：32 位的整数
i32**：一个指向 32 位 int 值的指针的指针
align 4：向 4 个字节对齐，即便数据没有占用 4 个字节，也要为其分配四个字节
call：调用

3.4优化

上面的代码是没有进行优化过的，在语言转换的过程中，有些代码是可以被优化以提升执行效率的。使用命令 clang -O3 -S -emit-llvm helloworld.c -o helloworld.ll，其实和上面的命令的区别只有 -O3 而已，注意，这里是大写字母 O 而不是数字 0。优化后的代码如下：

; ModuleID = 'helloworld.c'
source_filename = "helloworld.c"
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.12.0"

@str = private unnamed_addr constant [13 x i8] c"Hello World!\00"

; Function Attrs: nounwind ssp uwtable
define i32 @main(i32, i8** nocapture readnone) local_unnamed_addr #0 {
  %3 = tail call i32 @puts(i8* getelementptr inbounds ([13 x i8], [13 x i8]* @str, i64 0, i64 0))
  ret i32 0
}

; Function Attrs: nounwind
declare i32 @puts(i8* nocapture readonly) #1

attributes #0 = { nounwind ssp uwtable "correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false" "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-jump-tables"="false" "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="penryn" "target-features"="+cx16,+fxsr,+mmx,+sse,+sse2,+sse3,+sse4.1,+ssse3,+x87" "unsafe-fp-math"="false" "use-soft-float"="false" }
attributes #1 = { nounwind }

!llvm.module.flags = !{!0}
!llvm.ident = !{!1}

!0 = !{i32 1, !"PIC Level", i32 2}
!1 = !{!"Apple LLVM version 8.1.0 (clang-802.0.42)"}

可以看到，即使是最简单的 helloworld 代码，也会被优化。这一步骤的优化是非常重要的，很多直接转换来的代码是不合适且消耗内存的，因为是直接转换，所以必然会有这样的问题，而优化放在这一步的好处在于前端不需要考虑任何优化过程，减少了前端的开发工作。

3.5 生成目标文件

下面就是后端的工作了，将优化过的代码根据不同架构的 CPU 转化生成汇编代码，再生成对应的可执行文件，这样对应的 CPU 就可以执行了。

3.6可执行文件

在最后，LLVM 将会把这些汇编代码输出成二进制的可执行文件，使用命令 clang helloworld.c -o helloworld.out 即可查看，-o helloworld.out 如果不指定，将会被默认指定为 a.out。

可执行文件会有多个部分，对应了汇编指令中的 .section，它的名字也叫做 section，每个 section 都会被转换进某个 segment 里。这种方式用来区分不同功能的代码。将相同属性的 section 集合在一起，就是一个 segment。

使用 otool 工具可以查看生成的可执行文件的 section 和 segment：

Segment __PAGEZERO: 0x100000000 (vmaddr 0x0 fileoff 0)
Segment __TEXT: 0x1000 (vmaddr 0x100000000 fileoff 0)
    Section __text: 0x34 (addr 0x100000f50 offset 3920)
    Section __stubs: 0x6 (addr 0x100000f84 offset 3972)
    Section __stub_helper: 0x1a (addr 0x100000f8c offset 3980)
    Section __cstring: 0xe (addr 0x100000fa6 offset 4006)
    Section __unwind_info: 0x48 (addr 0x100000fb4 offset 4020)
    total 0xaa
Segment __DATA: 0x1000 (vmaddr 0x100001000 fileoff 4096)
    Section __nl_symbol_ptr: 0x10 (addr 0x100001000 offset 4096)
    Section __la_symbol_ptr: 0x8 (addr 0x100001010 offset 4112)
    total 0x18
Segment __LINKEDIT: 0x1000 (vmaddr 0x100002000 fileoff 8192)
total 0x100003000

上面的代码中，每个 segment 的意义也不一样：

__ PAGEZERO segment 它的大小为 4GB。这 4GB 并不是文件的真实大小，但是规定了进程地址空间的前 4GB 被映射为不可执行、不可写和不可读。

__ TEXT segment
包含了被执行的代码。它被以只读和可执行的方式映射。进程被允许执行这些代码，但是不能修改。

__ DATA segment 以可读写和不可执行的方式映射。它包含了将会被更改的数据。

__ LINKEDIT segment 指出了 link edit 表（包含符号和字符串的动态链接器表）的地址，里面包含了加载程序的元数据，例如函数的名称和地址。

4.静态库和动态库

说起来编译，就不得不说起动态库和静态库。这两个东西可是和编译过程息息相关的，这里有几篇文章的比较透彻，可以查看，想要了解整个编译过程，库是逃不开的：

iOS 静态库，动态库与 Framework：非常完美的讲解了静态库和动态库的概念，还有一些延伸阅读也非常好。https://skyline75489.github.io/post/2015-8-14_ios_static_dynamic_framework_learning.html

5.了解了这么多编译原理，除了写一个自动化编译脚本以外，还可以看懂很多之前完全看不明白的编译错误。在 Xcode 中，也可以对编译过程进行完整的设置，很多时候编译错误的解决就是在这里进行的。Xcode编译设置

5.1Build settings

这里是编译设置，针对编译流程中的各个过程进行参数和工具的配置：

1.Architectures：编译目标 CPU 架构，这里比较常见的是 Build Active Architectures Only（只编译为当前架构，是指你在 scheme 中选定的设备的 CPU 架构），debug 设置为 YES，Release 设置为 NO。

2.Assets：Assets.xcassets 资源组的配置。

3.Build Locations：查看 Build 日志可以看到在编译过程中的目标文件夹。

4.Build Options：这里是一些编译的选项设定，包含：

a.是否总是嵌入 Swift 标准库，这个在静态库和动态库的第一篇文章中有讲，iOS 系统目前是不包含 Swift 标准库的，都是被打包在项目中。

b.c/c++/objective-c 编译器：Apple LLVM 9.0

c.是否打开 Bitcode

…

5.Deployment：iOS 部署设置。说白了就是安装到手机的设置。

6.Headers：头文件？具体作用不详，知道的可以说一下。

7.Kernel Module：内核模块，作用不详。

8.Linking：链接设置，链接路径、链接标记、Mach-O 文件类型。

9.Packaging：打包设置，info.plist 的路径设置、Bundle ID 、App 显示名称的设置。

10.Search Paths：库的搜索路径、头文件的搜索路径。

11.Signing：签名设置，开发、生产的签名设置，这些都和你在开发者网站配置的证书相关。

12.Testing：测试设置，作用不详。

13.Text-Based API：基于文本的 API，字面翻译，作用不详。

14.Versioning：版本管理。

15.Apple LLVM 9.0 系列：LLVM 的配置，包含路径、编译器每一步的设置、语言设置。在这里 Apple LLVM 9.0 - Warnings 可以选择在编译的时候将哪些情况认定为错误（Error）和警告（Warning），可以开启困难模式，任何一个小的警告都会被认定为错误。

16.Asset Catalog Compiler - Options：Asset 文件的编译设置。

17.Interface Builder Storyboard Compiler - Options：Storyboard 的编译设置。

18.以及一些静态分析和 Swift 编译器的设定。

5.2Build Phases

编译阶段，编译的时候将根据顺序来进行编译。这里固定的有：

1.Compile Sources：编译源文件。

2.Link Binary With Libraries：相关的链接库。

3.Copy Bundle Resources：要拷贝的资源文件，有时候如果一个资源文件在开发过程中发现找不到，可以在这里找一下，看看是不是加进来了。

如果使用了 Cocoapods，那么将会被添加：

1.[CP] Check Pods Manifest.lock：检查 Podfile.lock 和 Manifest.lock
文件的一致性，这个会再后面的 Cocoapods 原理中详细解释。

2.[CP] Embed Pods Frameworks：将所有 cocoapods 打的 framework 拷贝到包中。

3.[CP] Copy Pods Resources：将所有 cocoapods 的资源文件拷贝到包中。

5.3Build Rules

编译规则，这里设定了不同文件的处理方式，例如：

Copy Plist File：在编译打包的时候，将 info.plist 文件拷贝。

Compress PNG File：在编译打包的时候，将 PNG 文件压缩。

Swift Compiler：Swift 文件的编译方式，使用 Swift 编译器。

6. Cocoapods 原理

使用了 Cocoapods 后，我们的编译流程会多出来一些，虽然每个 target 的编译流程都是一致的，但是 Cocoapods 是如何将这些库导入我们的项目、原项目和其他库之间的依赖又是如何实现的仍然是一个需要了解的知识点。下面这几篇文章从不同角度解释了 Cocoapods 是如何工作的：

1.深入理解 CocoaPods https://www.objccn.io/issue-6-4/

2.Cocoapods原理总结 https://juejin.im/entry/59dd94b06fb9a0451463030b

3.CocoaPods 都做了什么？ https://zhuanlan.zhihu.com/p/22652365

人面猴
序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
沈念sama阅读 158,117评论 4赞 360
死咒
序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
沈念sama阅读 66,963评论 1赞 290
救了他两次的神仙让他今天三更去死
文/潘晓璐我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
开封第一讲书人阅读 107,897评论 0赞 240
道士缉凶录：失踪的卖姜人
文/不坏的土叔我叫张陵，是天一观的道长。经常有香客问我，道长，这世上最难降的妖魔是什么？我笑而不...
开封第一讲书人阅读 43,805评论 0赞 203
港岛之恋（遗憾婚礼）
正文为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
茶点故事阅读 52,208评论 3赞 286
恶毒庶女顶嫁案：这布局不是一般人想出来的
文/花漫我一把揭开白布。她就那样静静地躺着，像睡着了一般。火红的嫁衣衬着肌肤如雪。梳的纹丝不乱的头发上，一...
开封第一讲书人阅读 40,535评论 1赞 216
城市分裂传说
那天，我揣着相机与录音，去河边找鬼。笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。我是一名探鬼主播，决...
沈念sama阅读 31,797评论 2赞 311
双鸳鸯连环套：你想象不到人心有多黑
文/苍兰香墨我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
开封第一讲书人阅读 30,493评论 0赞 197
万荣杀人案实录
序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
沈念sama阅读 34,215评论 1赞 241
护林员之死
正文独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋以下内容为张勋视角年9月15日...
茶点故事阅读 30,477评论 2赞 244
白月光启示录
正文我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
茶点故事阅读 31,988评论 1赞 258
活死人
序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
沈念sama阅读 28,325评论 2赞 252
日本核电站爆炸内幕
正文年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
茶点故事阅读 32,971评论 3赞 235
男人毒药：我在死后第九天来索命
文/蒙蒙一、第九天我趴在偏房一处隐蔽的房顶上张望。院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
开封第一讲书人阅读 26,055评论 0赞 8
一桩弑父案，背后竟有这般阴谋
文/苍兰香墨我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。一阵脚步声响...
开封第一讲书人阅读 26,807评论 0赞 194
情欲美人皮
我被黑心中介骗来泰国打工，没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。一个月前我还...
沈念sama阅读 35,544评论 2赞 271
代替公主和亲
正文我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
茶点故事阅读 35,455评论 2赞 266

iOS app的编译过程

iOS app的编译过程

1.什么是编译

1.1 LLVM

1.2 clang

2.ios项目编译过程介绍

3.文件编译过程

3.1预处理

3.2语意和语法分析

3.2.1AST

3.2.2静态分析

3.3生成LLVM代码

3.4优化

3.5 生成目标文件

3.6可执行文件

4.静态库和动态库

5.了解了这么多编译原理，除了写一个自动化编译脚本以外，还可以看懂很多之前完全看不明白的编译错误。在 Xcode 中，也可以对编译过程进行完整的设置，很多时候编译错误的解决就是在这里进行的。Xcode编译设置

5.1Build settings

5.2Build Phases

5.3Build Rules

6. Cocoapods 原理

推荐阅读更多精彩内容