iOS 编译理解

r囧r小猫 2022-11-17 03:42 288阅读 0赞

iOS的编译,使用了基于LLVM的编译器。Clang(或者Swift)作为编译前端,LLVM作为后端,将代码文件编译为当前架构所对应的可执行文件。

**编译器** 通常分为 **前端** 和 **后端**。

>  *  前端: 分析代码，生成 **后端** 使用的中间码。
>  *  后端: 针对机器架构，生成对应的可执行机器码。
>  *  前后端分离: 这样设计的好处则是,支持新语言的时候,只需要修改前端;支持新底层架构,只需改后端了。

**Clang** 是一个C、C++、Objective-C和Objective-C++编程语言的编译器前端。它采用了LLVM作为其后端，而且由LLVM2.6开始，一起发布新版本。它的目标是提供一个GNU编译器套装（GCC）的替代品，支持了GNU编译器大多数的编译设置以及非官方语言的扩展。

Clang项目包括Clang前端和Clang静态分析器等.

Clang作为编译前端，完成 **语法分析，语义分析，生成中间代码** 等工作。比如我们常见的语法警告和错误提示就在这一过程中完成。

**LLVM** 是一个自由软件项目，它是一种以C++写成编译器基础设施。利用虚拟技术创造出编译时期、链接时期、运行时期以及“闲置时期”的最优化。它最早以C/C++为实现对象，而当前它已支持包括ActionScript、Ada、D语言、Fortran、GLSL、Haskell、Java字节码、Objective-C、Swift、Python、Ruby、Rust、Scala以及C\#等语言。

![6b75f5a74ba67ebfea0e9def9b1ffe45.png][]

在基于LLVM的编译器中，前端将代码进行检查(语法检查等)和解析，并生产中间代码LLVM IR。该IR选择对应的类型，对代码进行优化，然后被发送到代码生成器，根据本机的架构生成对应的机器代码。

iOS 编译采用了 **Clang+LLVM** 的方式。Clang作为前端，LLVM作为后端。

简单的文件编译过程: (Swift的话，前端则不是Clang，而是Swift)

>  *  代码文件 =>
>     
>      *  **Clang**
>         
>         1.  预处理(Preprocessor)
>             
>              *  宏的替换, 头文件的导入, 删除注释等
>         2.  词法分析(lexical anaysis)
>             
>              *  读入源程序的输入字符，将它们组成词素，生成并输出一个词法单元序列(Token)的过程。
>         3.  语法分析(semantic analysis)
>             
>              *  将Token生成抽象语法树(AST)
>              *  对这个树进行分析，找出代码中的错误。
>         4.  生成中间代码（LLVM IR）
>             
>              *  将语法树自顶向下遍历逐步翻译成 LLVM IR(中间码)
>      *  **LLVM Optimizer**
>         
>         1.  选择对应的类型
>      *  **LLVM Code Generator**
>         
>         1.  优化IR
>         2.  生成Target相关汇编码
>         3.  汇编器以汇编代码作为输入，将汇编代码转换为机器代码
>         4.  连接器把编译产生的.o文件和（dylib,a,tbd）文件Link，生成一个mach-o文件
>  *  => Mach-O格式的可执行文件

> **mach-o文件** 是记录编译后的可执行文件，对象代码，共享库，动态加载代码和内存转储的文件格式。不同于 xml 这样的文件，它只是二进制字节流，里面有不同的包含元信息的数据块，比如字节顺序，cpu 类型，块大小等。文件内容是不可以修改的，因为在 .app 目录中有个 \_CodeSignature 的目录，里面包含了程序代码的签名，这个签名的作用就是保证签名后 .app 里的文件，包括资源文件，Mach-O 文件都不能够更改。
> 
> Mach-O 文件包含三个区域:
> 
>  *  Mach-O Header：包含字节顺序，magic，cpu 类型，加载指令的数量等
>  *  Load Commands：包含很多内容的表，包括区域的位置，符号表，动态符号表等。每个加载指令包含一个元信息，比如指令类型，名称，在二进制中的位置等。
>  *  Data：最大的部分，包含了代码，数据，比如符号表，动态符号表等。

![79894416534bd99aa9a8e2edacdef621.png][]

> 完整全过程:
> 
> 1.  编译信息写入辅助文件，创建文件架构 .app 文件
> 2.  把Entitlements.plist写入到DerivedData里，处理打包的时候需要的信息（比如application-identifier）。
> 3.  处理文件打包信息
> 4.  执行 CocoaPod 编译前脚本，checkPods Manifest.lock
> 5.  编译.m文件，使用 CompileC 和 clang 命令
> 6.  链接需要的 Framework
> 7.  编译 xib
> 8.  拷贝 xib ，资源文件
> 9.  编译 ImageAssets
> 10. 处理 info.plist
> 11. 执行 CocoaPod 脚本
> 12. 拷贝标准库
> 13. 创建 .app 文件和签名

## xcode中的编译设置 ##

编译配置信息都存储在这个文件(.xcodeprog)里,例如CocoaPod就是通过修改(.xcodeprog)文件来完成相关第三方库的打包链接的。

### Build Phases ###

1.  Target Dependencies
    
    > 是用来指定编译顺序的。  
    > 是指需要先编译好Target Dependencies中的库，  
    > 才能编译当前Target。显式声明了依赖关系。
2.  Compile Sources
    
    > 需要编译的的代码文件(.m文件)
3.  Link Binary With Libraries
    
    > 项目中的静态库和动态库,它们会和编译生成的目标文件进行链接
4.  Copy Bundle Resources
    
    > 打包资源文件(StoryBoard,Xib,Strings,Assets等)
5.  \[CP\]Check Pods Manifest.lock
    
    > 用来检查cocoapod管理的三方库是否需要更新(在引入Pod后才有这个选项)\[CocoaPod的自定义脚本,所有前面有CP的都是。\]

### Build Rules ###

**Build Rules** 指定了不同的文件类型如何处理以及输出在哪。一般来说，开发者并不需要修改这里面的内容。如果你需要对特定类型的文件添加处理方法，那么可以在此处添加一条新的规则。

### Build Settings ###

**Build Settings** 指定了在 build 的过程中各个阶段的选项的设置,配置每个任务的详细内容.

### Link ###

Linker把编译器编译生成的多个文件，链接成一个可执行文件。

通常链接器的输入为：

*  .o 文件
 *  动态库
 *  静态库
 *  只包含符号的库文件(符号是一段代码或者数据的名称)

### Clang Module ###

从上面的内容可知，我们在导入头文件的时候，通常预处理器在处理的时候会把这一行替换成对应头文件的文本。

但是这种直接替换，在某些时候会产生一定的问题:

*  当头文件过多的时候，会产生大量的预处理消耗
 *  当头文件替换的时候，不同的头文件里面的宏定义可能会因为命名一样而被覆盖
 *  边界不明显。拿到一组.a和.h文件，很难确定.h是属于哪个.a的，需要以什么样的顺序导入才能正确编译。

clang module不再使用文本模型，而是采用更高效的语义模型。clang module提供了一种新的导入方式:@import，module会被作为一个独立的模块编译，并且产生独立的缓存，从而大幅度提高预处理效率。

在Target的build setting中，设置define module为YES，则可以启动Clang Module。

> `#import <Foundation/NSString.h>`的时候，编译器会检查`NSString.h`是否在一个module里，如果是的话，这一行会被替换成`@import Foundation`。

[6b75f5a74ba67ebfea0e9def9b1ffe45.png]: /images/20221022/7412bb74251f40d1b4b893e630d52463.png
[79894416534bd99aa9a8e2edacdef621.png]: /images/20221022/7d77b15e37874c75a01f231d27ca206c.png