Xcode Build Process
Build System
Clang Build
Swift Build
Linking
Build System
Build Process是一系列工作的集合，從build task的執行順序來看就是編譯和鏈接兩個過程：
Build Process可以通過有向圖來展示：
Build Process面臨的問題是：如何縮短Build Process時間。
為了加快Build，可以將互不影響的task并行來執行，將任務有向圖中同一層級的任務并行執行來加快速度。這需要確定任務有向圖中的任務依賴關系。
發現依賴
在發現任務依賴關系時，.m文件的編譯任務不僅僅依賴于.m文件，而且還依賴于.m文件所引入的頭文件構成的.d文件。這樣做的好處是，編譯器如果發現.d文件中沒有發生變化，那么.m文件也沒有發生變化的情況下，就無需重復編譯.m文件，減少重復編譯時間。
增量編譯
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：可以理解為不同宏定義中相同的頭文件引用在編譯時會忽略掉宏定義。
-> 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。
如何創建一個頭文件對應的module？
比如創建Foundation.h這個頭文件的module，Foundation.h中的依賴如下圖所示：
可以從上圖發現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的編譯：
對于Objective-C，clang獨立地編譯每一個Objective-C文件，所以想要引用另一個文件里的方法，必須引入頭文件。而Swift中沒有頭文件，所以swiftc在編譯一個Swift文件時，會編譯其中所有聲明相關的其他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.
