這篇文章是對于自己學習 App編譯過程的一個總結

學習的相關文章

iOS App的編譯過程
iOS 編譯過程的原理和應用
iOS 中的靜態(tài)庫與動態(tài)庫，區(qū)別、制作和使用

本文的大綱

大綱.png

為何要了解

1. 自己的興趣，解開一些疑惑；
2. 有利于解決一些編譯過程中出現(xiàn)的問題；
3. 對于優(yōu)化App有很大的幫助。

什么是編譯

為什么要編譯

我們通常所使用的編程語言編寫的代碼，計算機的CPU(只能執(zhí)行二進制代碼)無法執(zhí)行，所以要編譯。
為什么要編譯

什么是編譯

利用編譯程序將高級語言所編寫的代碼變?yōu)镃PU可執(zhí)行的代碼的過程就叫編譯。

編譯_百度詞條.png

App的編譯過程

我分別用OC和Swift語言創(chuàng)建兩個Demo，通過BulidLog看一下整個編譯過程：

BuildLog_OC.png

BuildLog_Swift.png

Build的得到的.app也可以通過查看包內(nèi)容，直觀的看到得到的文件

.app包內(nèi)容.png

根據(jù)圖中和參考的文章總結一下 iOS 項目編譯過程：

1. 寫入輔助文件：將項目的文件結構對應表、將要執(zhí)行的腳本、項目依賴庫的文件結構對應表寫成文件，方便后面使用；
2. 創(chuàng)建App架構：為填充后面步驟編譯得到的文件等；
3. 運行預設腳本：Cocoapods 會預設一些腳本，當然你也可以自己預設一些腳本來運行。這些腳本都在 Build Phases 中可以看到；
4. 編譯.m文件:這個過程是由LLVM完成的，編譯成一個可執(zhí)行文件(Mach-0)；
5. 鏈接編譯后得到的文件；
6. 拷貝項目中的資源，比如 圖片資源；
7. 編譯 storyboard
8. 編譯 asset文件：圖片如果使用 Assets.xcassets 來管理圖片，那么這些圖片將會被編譯成機器碼，除了 icon 和 launchImage；
9. 處理info.plist ；
10. 執(zhí)行CocoaPod腳本；
11. 拷貝swift標準包；
12. 構建.app并簽名；
13. 完成打包。

以上，就是iOS項目大體的編譯過程，下面說一下解釋代碼用到的LLVM 。

什么是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，但它與傳統(tǒng)的虛擬機幾乎沒有關系?！癓LVM”這個名字本身并不是首字母縮略詞;這是項目的全稱。

LLVM在編譯過程中分為了三個模塊: 前端、中間優(yōu)化器和后端 。(跟web前端，service后端沒有任何關系)。
LLVM各個模塊的作用：

• 前端：對目標語言代碼進行語法分析，語義分析，生成中間代碼。在這個過程中，會進行類型檢查，如果發(fā)現(xiàn)錯誤或者警告會標注出來在哪一行；
• 中間優(yōu)化器：對中間代碼進行優(yōu)化，去除冗余代碼，這個過程會進行BitCode的生成，鏈接期優(yōu)化等；
• 后端：先進行與機器無關的代碼優(yōu)化，生成匯編語言，在生成匯編語言之后會再進次進行與機器相關的代碼優(yōu)化，最后將各個文件的機器代碼鏈接。

在iOS中，OC和Swift兩種語言的編譯在前端是有差別的:OC中使用的編譯器前端為:Clang,在Swift中使用的編譯器前端為swift自己編寫的，這個我們可以在BuildLog里面具體看到。

BuildLog_OC_compiler.png

BuildLog_Swift_compiler.png

OC的文件編譯處理過程：

Objective-C 的文件中，只有 .m 文件會被編譯 .h 文件只是一個暴露外部接口的頭文件，它的作用是為被編譯的文件中的代碼做簡單的共享，并且因為OC沒有private和public的用法，用.h和.m來實現(xiàn)private和public。

1. 預處理 ：處理一些預處理指令( 比如#define、#ifdef,#else,#endif等)并將預處理后的代碼進行符號化處理，以便下一步進行詞法分析和語義分析；
2. 詞法分析和語義分析：
   <1> 將符號化的代碼抽象為語法樹(abstract syntax tree – AST);
   <2> 靜態(tài)分析：對語法樹進行遍歷分析，包括類型檢查、實現(xiàn)檢查（某個類是否存在某個方法）、變量使用，還會有一些復雜的檢查，例如在 Objective-C 中，給某一個對象發(fā)送消息（調(diào)用某個方法），檢查這個對象的類是否聲明這個方法（但并不會去檢查這個方法是否實現(xiàn)，這個錯誤是在運行時進行檢查的），如果有什么錯誤就會進行提示。因此可見，Xcode 對 clang 做了非常深度的集成，在編寫代碼的過程中它就會使用 clang 來對代碼進行分析，并及時對代碼錯誤進行提示。
3. 生成 LLVM 代碼(也就是中間代碼LLVM Intermediate Representation LLVM IR)，并將代碼遞交給優(yōu)化器，這也是LLVM前端 Clang的最后一步；
4. 優(yōu)化：將一些不合適且消耗內(nèi)存的代碼進行優(yōu)化；
5. 生成目標文件：這之后就是由LLVM后端完成了，將優(yōu)化過的代碼根據(jù)不同架構的 CPU 轉化生成匯編代碼，再生成對應的可執(zhí)行文件，這樣對應的 CPU 就可以執(zhí)行了；
6. 生成可執(zhí)行文件（Mach - 0）。

以上的文件編譯流程在文章的開頭鏈接里有詳細步驟和說明。

Swift的文件編譯處理過程：

Swift 編譯器架構

Swift編譯器官方解釋.png

總體而言，Swift編譯器主要負責將Swift源代碼轉換為高效、可執(zhí)行的機器代碼。但是，Swift編譯器前端還支持許多其他工具，包括與語法著色、代碼完成和其他便利的IDE集成。本文件對Swift編譯器的主要組件進行了高層描述:

• 解析:解析器是一個簡單的遞歸解析器(在lib/Parse中實現(xiàn))，帶有一個集成的、手工編碼的lexer。解析器負責生成沒有任何語義或類型信息的抽象語法樹(AST)，并對輸入源的語法問題發(fā)出警告或錯誤。
• 語義分析:語義分析(在lib/Sema中實現(xiàn))負責將解析后的AST轉換為結構良好的、完全類型檢查的AST形式，為源代碼中的語義問題發(fā)出警告或錯誤。語義分析包括類型推斷，如果成功，則表明從生成的經(jīng)過類型檢查的AST生成代碼是安全的。
• Clang導入:Clang導入器(在lib/ClangImporter中實現(xiàn))導入Clang模塊，并將它們導出的C或Objective-C api映射到相應的Swift api中。產(chǎn)生的導入的ast可以通過語義分析來引用。
• SIL生成:Swift中間語言(SIL)是一種高級的、特定于Swift的中間語言，適用于Swift代碼的進一步分析和優(yōu)化。SIL生成階段(在lib/SILGen中實現(xiàn))將類型檢查的AST降低為所謂的“原始”SIL。SIL的設計在doc /SIL.rst中進行了描述。
• SIL保證轉換:SIL保證轉換(在lib/SILOptimizer/Mandatory中實現(xiàn))執(zhí)行影響程序正確性的附加數(shù)據(jù)流診斷(例如使用未初始化的變量)。這些轉換的最終結果是“規(guī)范的”SIL。
• SIL優(yōu)化:SIL優(yōu)化(在lib/Analysis、lib/ARC、lib/LoopTransforms和lib/Transforms中實現(xiàn))對程序執(zhí)行額外的高級特定于swift的優(yōu)化，包括(例如)自動引用計數(shù)優(yōu)化、去虛擬化和泛型專門化。
• LLVM IR生成:IR生成(在lib/IRGen中實現(xiàn))降低SIL到LLVM IR，此時LLVM可以繼續(xù)優(yōu)化并生成機器代碼。

生成LLVM IR 之后的步驟就跟OC一樣了。

與編譯相關 （內(nèi)容太多，未完待續(xù)）

Build Tabs

iOS Build Tabs -- Build Settings