WWDC 2018 Behind the Scenes of t

Xcode Build Process

Xcode Build Process

• Build System

• Clang Build

• Swift Build

• Linking

Build System

Build Process是一系列工作的集合，从build task的执行顺序来看就是编译和链接两个过程：

编译过程 链接过程

Build Process可以通过有向图来展示：

Build Process任务有向图

Build Process面临的问题是：如何缩短Build Process时间。

为了加快Build，可以将互不影响的task并行来执行，将任务有向图中同一层级的任务并行执行来加快速度。这需要确定任务有向图中的任务依赖关系。

并行build

发现依赖

在发现任务依赖关系时，.m文件的编译任务不仅仅依赖于.m文件，而且还依赖于.m文件所引入的头文件构成的.d文件。这样做的好处是，编译器如果发现.d文件中没有发生变化，那么.m文件也没有发生变化的情况下，就无需重复编译.m文件，减少重复编译时间。

依赖.d文件避免重复编译

增量编译

Build任务有向图中的每一个任务都有一个signature，这个signature是这个任务相关信息(path,metaData等)的哈希。Build System通过跟踪任务signature，判断当次build和上次build此任务的signature是否发生了变化，来决定任务是否需要重新执行。

开发者需要关注什么？

开发者应该从Build任务依赖的角度来看待Build Process，而不是从任务执行顺序的角度来考虑问题。因此，需要设置好任务的依赖，比如target依赖，库依赖。

不要依靠“Link Frameworks Automatically”来处理你自己的framework，这个选项并不会设置build依赖，并不会保证你自己的库会被先编译。

Clang Builds

Clang是针对于C，C++，Objective-C和Objective-C++的编译器。

header maps

编译中头文件的作用：头文件只是一个promise，编译器不会去理会头文件，但是当链接时，头文件有错误的话，会报出来。

更改目录的结构不会影响头文件的查找，那么如何查找头文件？

头文件查找

头文件位置 ---> search path ---> header maps

header maps用来和build system进行沟通，告诉其header files在哪里。

header maps中有一部分头文件指向framework中的头文件，有一部分指向source code中的头文件。系统SDK的头文件不会包含在header maps。

clang modules

先来描述一下目前存在的问题，.m文件引入一个普通的系统sdk头文件'#import <Foundation/Foundation.h>'时，clang需要查找800多个头文件，超过9MB的数据，每一个.m引入该头文件，clang都会做这些工作，这些工作是耗时的，重复的，如何优化这部分工作来缩短build time。

所以引入了clang modules，clang modules将头文件的展示缓存在了磁盘上，来达到可重用，加快build的目标。

clang module还有一些特性：

-> context-free：可以理解为不同宏定义中相同的头文件引用在编译时会忽略掉宏定义。

context-free

-> Self-contained：引用一个头文件A时，不需要再引用头文件A需要的头文件B，头文件A所需要的头文件依赖自己来处理。

clang是如何知道需要创建一个module的？

比如引入了"#import <Foundation/NSString.h>"头文件，会去Frameworks的目录中找到NSString.h，然后找到了module.modulemap(modulemap文件描述了某一类头文件如何映射到modules)，modulemap中存在umbrella header "Foundation.h"，说明需要去Foundation.h中查找'NSString.h'，然后找到了，NSString.h的module包含在了Foundation的module中，说明需要为Foundation.h创建一个module。

查找modulemap modulemap的具体格式

如何创建一个头文件对应的module？

比如创建Foundation.h这个头文件的module，Foundation.h中的依赖如下图所示：

Foundation头文件的依赖

可以从上图发现Security和CoreFoundation共同依赖于ObjectiveC，所以可以只创建ObjectiveC的Module，在CoreFoundation和Security中共同引用它。

Module的创建是依赖于clang命令的哈希，创建好的module被缓存在对应的哈希路径下；如果clang命令发生了变化(参数变化)，那么就会重新build一份module，缓存在另一个clang命令哈希路径下。

开发者需要注意什么？

#import <PetKit/PetKit.h>
#import "Cat.h"

对一个Framework中的头文件，有的引用使用了Framework的名字，有的没有，这时可能会报出重复引用的问题。开发者在引用Framework中的头文件时，一定要加上Framework的名字。

Swift Build

项目中没有大规模使用Swift，通过这个Session发现，之前的Xcode对Swift项目的编译时间应该比Objective-C项目多很多。

Xcode10之前对Swift的编译：

Xcode10之前的Swift编译

对于Objective-C，clang独立地编译每一个Objective-C文件，所以想要引用另一个文件里的方法，必须引入头文件。而Swift中没有头文件，所以swiftc在编译一个Swift文件时，会编译其中所有声明相关的其他Swift文件，会有很多重复编译发生。

Xcode10对Swift的编译:

Xcode10的Swift编译

在Xcode10上，将Swift文件的编译放在了不同的进程上，进程内的Swift文件不会重复编译，进程之间的会由于声明产生重复编译，所以减少了一部分重复编译的工作。

Linking

链接是创建一个可执行Mach-O文件工作中的最后一个步骤，链接过程的输入有两类文件：1> 目标文件(.o)，2> Libraries(.dylib，.tbd，.a)

Symbols(符号)

符号是code and data fragments，是对源码中函数或者变量在目标文件中的统一命名。源码中声明的函数或者变量在编译后的目标文件中通过符号表现，在链接过程中，这些符号与实现了对应变量和函数的目标文件中的符号相对应。

Object Files(目标文件)

• 目标文件是编译阶段的输出

• 编译阶段输出的非可执行的Mach-O文件包含了code and data fragments。

-> code and data fragments通过symbol表现出来(一个打印函数就是一个symbol)

-> fragments会引用一些"未定义"(定义在其他Mach-O中)的symbol(.o文件中引用了另一个.o文件中的symbol)

Libraries

Libraries define symbols that are not built as part of your target.(Library定义了symbols，Library不会在你的target中编译)

• Dylibs：Dynamic libraries(Mach-O file that expose code and data fragments executables can use)。app的可执行文件可以直接使用动态库中的code and data fragments，不需要链接，所以是code and data fragments而不是symbols。

• TBDs：只包含了symbols(是symbols，说明需要链接过程）

• Static archives：静态库

->an archive of multiple .o files built with the 'ar' tool

->only the .o files with symbols you reference are included in your app.