前言
今天在Swift工程中不小心創(chuàng)建了一個(gè)OC文件，于是乎提示我創(chuàng)建一個(gè)橋接文件，那么為什么需要?jiǎng)?chuàng)建橋接文件呢，它的原理又是什么呢？
打開百度一搜，全是教你怎么創(chuàng)建橋接文件的，似乎找不到答案~
LVVM - Low Level Virtual Machine
Clang - C Lange Family Frontend for LVVM
編譯器探究
- GCC
GNU編譯器套件（GNU Compiler Collection）包括C、C++、Objective-C、Fortran、Java、Ada和Go語(yǔ)言的前端，也包括了這些語(yǔ)言的庫(kù)（如libstdc++、libgcj等等）
早起的OC 程序員都感受過(guò)GCC編譯程序，但是蘋果為什么好好的GCC不用，自己要搞一套呢？
1.GCC 的 Objective-C Frontend不給力：GCC的前端不是蘋果提供維護(hù)的，想要添加一些語(yǔ)法提示等功能還得去求GCC的前端去做。
2.GCC 插件、工具、IDE的支持薄弱：很多編譯器特性沒(méi)有，自動(dòng)補(bǔ)全、代碼提示、warning、靜態(tài)分析等這些流程不是很給力，都是需要IDE調(diào)用底層命令完成的，結(jié)果需要以插件的形式暴露出來(lái)，這一塊GCC做的不是很好。
3.GCC 編譯效率和性能不足：Apple的Clang出來(lái)以后，其編譯效率是GCC的3倍，編譯器性能好，編譯出的文件小。
4.Apple要收回去工具鏈的控制 （lldb, lld...）: Apple在早起從GCC前端到LLVM后端的編譯器，到Clang-LVVM的編譯器，以后后來(lái)的GDB的替換，一步一步收回對(duì)編譯工具鏈的控制，也為Swift 的出現(xiàn)奠定基礎(chǔ)。
- Three-Phase 編譯器架構(gòu)
上圖是最簡(jiǎn)單的三段式編譯器架構(gòu)。
首先，我們看到source 是我們的源代碼，進(jìn)入編譯器的前端Frontend；在前端完成之后，就進(jìn)入優(yōu)化器這一模塊；優(yōu)化完成之后進(jìn)入后端這一模塊；在這全部完成之后，根據(jù)你的架構(gòu)是x86，armv7等生產(chǎn)機(jī)器碼。
但是會(huì)有一個(gè)問(wèn)題：
M (Language) * N (Target) = M * N (Compilers)
就是如果你有M種語(yǔ)言(C、C++、Objective-C...)，N種架構(gòu)(armv7、armv7s、arm64、i386、x86_64...)，那么你就有M * N中編譯方式需要處理，顯然是不合理的。
-
apple 的
Clang/Swift - LLVM編譯器架構(gòu)：
其中優(yōu)化器部分(Common Optimizer)是共享的。而對(duì)于每一種語(yǔ)言都有其前端部分，假如新有一門語(yǔ)言，只需要實(shí)現(xiàn)該語(yǔ)言的前端模塊；如果新出一臺(tái)設(shè)備，它的架構(gòu)不同，那么也只需要單獨(dú)完成其后端模塊即可。改動(dòng)非常小，不會(huì)做重復(fù)的工作。
下面詳解：
藍(lán)色的部分：C語(yǔ)言家族系列的前端，屬于Clang部分。
綠色的部分： Swift語(yǔ)言的前端，其中還包含自己的SIL中間語(yǔ)言和Optimzer中間語(yǔ)言的優(yōu)化過(guò)程。
紫色的部分： 優(yōu)化階段和后端模塊統(tǒng)一是LLVM部分。
- 代碼規(guī)模
Clang + LLVM 代碼模塊總共有400W行代碼，其中主體部分是C++寫的，大概有235W行。如果將所有的target，lib等文件編譯出來(lái)，大概有近20G的大?。?/p>
對(duì)比Swift Frontend 代碼規(guī)模，就少很多，只有43W行左右。可能在后端，比如優(yōu)化器策略，生成機(jī)器碼部分就有很多代碼：
- Clang命令
Clang在概念上是編譯器前端，同時(shí)，在命令行中也作為一個(gè)“黑盒”的 Driver;
它封裝了編譯管線、前端命令、LLVM命令、Toolchain命令等，即一個(gè)Clang走天下；
方便從GCC遷移過(guò)來(lái)。
當(dāng)我們點(diǎn)擊run命令以后，如下圖：
就是我們?cè)?strong>build setting中的一些設(shè)置，組裝成命令，下面可以看到是一個(gè) oc文件在arc環(huán)境下的編譯過(guò)程：
- 拆解編譯過(guò)程
#import <Foundation/Foundation.h>
int main() {
@autoreleasepool {
id obj = [NSObject new];
NSLog(@"Hellow world: %@", obj);
}
}
1.Preprocess - 預(yù)處理
import 頭文件，include頭文件等
macro宏展開
處理'#'大頭的預(yù)處理指令，如 #if，#elseif等
終端輸入：
$ clang -E main.m
只會(huì)做預(yù)處理步驟，不往后面走，如下
可以看到一個(gè)頭文件要導(dǎo)入很多行代碼，這里就要說(shuō)到pch文件。本身Apple給出這個(gè)文件，是讓我們放入Foundation或者UIKit等這些根本不會(huì)變的庫(kù)，優(yōu)化編譯過(guò)程，但是開發(fā)者卻各種宏，各種頭文件導(dǎo)入，導(dǎo)致編譯速度很慢。以至于后來(lái)蘋果刪除了這個(gè)文件，只能開發(fā)者自己創(chuàng)建。但是蘋果提供modules這個(gè)概念，可以通過(guò)以下命令打開：
$ clang -E -fmodules main.m
默認(rèn)把一些文件打包成庫(kù)文件, 在build setting中默認(rèn)打開的，我們可以用@import Foundation:
2.Lexical Analysis - 詞法分析
詞法分析，也作Lex 或者 Tokenization
將預(yù)處理過(guò)得代碼文本轉(zhuǎn)化為Token流
不會(huì)校驗(yàn)語(yǔ)義
可以在終端輸入以下命令：
$ clang -fmodules -fayntax-only -Xclang -dump-tokens main.m
如下圖：
3.Analysis - 語(yǔ)法分析
語(yǔ)法分析，在Clang中有Parser和Sema兩個(gè)模塊配合完成，驗(yàn)證語(yǔ)法是否正確，并給出正確的提示。這就是Clang標(biāo)榜GCC，自己的語(yǔ)法提示友好的體現(xiàn)。
根據(jù)當(dāng)前的語(yǔ)法，生成語(yǔ)意節(jié)點(diǎn)，并將所有節(jié)點(diǎn)組合成抽象語(yǔ)法書(AST)
輸入命令：
$ clang -fmodules -fsyntax-only -Xclang -ast-dump main.m
如下圖：
可以通過(guò)語(yǔ)法樹，反寫回源碼，如下圖：
4.Static Analysis - 靜態(tài)分析(不是必須的)
通過(guò)語(yǔ)法書進(jìn)行代碼靜態(tài)分析，找出非語(yǔ)法性錯(cuò)誤
模擬代碼執(zhí)行路徑，分析出 contro-flow graph (CFG)
預(yù)置了常用的 Checker
在Xcode中如下操作可以實(shí)現(xiàn)：
5.CodeGen - IR 代碼生成
CodeGen負(fù)責(zé)將語(yǔ)法樹從頂至下遍歷，翻譯成LLVM IR，LLVMIR 是Frontend的輸入，也是LLVM Backend 的輸入，是前后端的橋接語(yǔ)言。
與Objective-C Runtime 橋接
①Class / Meta Class / Protocol / Category 內(nèi)存結(jié)構(gòu)生成，并存放在指定 session中(如Class： _DATA, _objc_classrefs)
②Method / Ivar / Property 內(nèi)存結(jié)構(gòu)生成
③組成 method_list / ivar_list / property_list并填入Class
④Non-Fragile ABI: 為每個(gè)Ivar合成 OBJC_IVAR_$_偏移常量
⑤存取 Ivar的語(yǔ)句(ivar = 123; int a = ivar;) 轉(zhuǎn)寫成base + **OBJC_IVAR$**的形式
⑥將語(yǔ)法樹中的 ObjCMessageExpr 翻譯成相應(yīng)版本的objc_msgSend，對(duì)super關(guān)鍵字的調(diào)用翻譯成objc_msgSendSuper
⑦處理@synthsynthesize
⑧生成 block_layout 的數(shù)據(jù)結(jié)構(gòu)
⑨變量 capture （__block/ __weak）
10.生成_block_invoke函數(shù)
11.ARC: 分析對(duì)象引用關(guān)系，將 objc_storeStrong/ objc_storeWeak 等ARC 代碼插入
12.將 ObjCAutoreleasePoolStmt 轉(zhuǎn)譯成objc_autoreleasePoolPush/Pop
13.實(shí)現(xiàn)自動(dòng)調(diào)用[super dealloc]
14.為每個(gè)擁有 ivar 的Class 合成.cxx_destructor 方法來(lái)自動(dòng)釋放類的成員變量，代替MRC 時(shí)代下的"self.xxx = nil"
舉個(gè)栗子，嘿嘿：
終端輸入：
$ clang -S -fobjc-arc -emit-llvm main.m -o main.m
輸入如下：
介于C和匯編的中間形態(tài)。
如果加入優(yōu)化：
$ clang -O3 -S -fobjc-arc -emit-llvm main.m -o main.m
明顯感覺(jué)少了很多。
6. LVVM Bitcode - 生成字節(jié)碼
輸入命令：
$ clang -emit-llvm -c main.m -o main.bc
相信大家在iOS 9之后都聽過(guò)這個(gè)概念，其實(shí)就是對(duì)IR生成二進(jìn)制的過(guò)程。
7.Assemble - 生成Target相關(guān)匯編
終端輸入：
$ clang -S -fobjc-arc main.m -o main.s
如下圖：
匯編代碼。
8.Assemble - 生成Target相關(guān) Object(Mach-o)
終端輸入：
$ clang -fmodules -c main.m -o main.o
匯編的main.o的形式。
9.Link 生成 Executable
終端輸入：
$ clang main.m -o main
$ ./main
總結(jié)一下吧：
至此，我猜測(cè)可能橋接文件是在Clang階段，將OC文件進(jìn)行編譯，生成語(yǔ)法樹，然后再返成Swift能識(shí)別的類文件。
- 我們能在Clang上做什么？
Apple給我們留了3個(gè)接口：
1.LibClang
功能：
①C 的API來(lái)訪問(wèn)Clang的上層能力，比如獲取Tokens、遍歷語(yǔ)法樹、代碼補(bǔ)全、獲取診斷信息；
②API穩(wěn)定，不受Clang源碼更新影響
③只有上層的語(yǔ)法樹可以訪問(wèn)，不能獲取到全部信息
④使用原始的 C的API
⑤腳本語(yǔ)言： 使用官方提供的 python binding 或開源的 node-js / ruby binding
⑥Objective-C： 開源庫(kù) ClangKit
2.LibTooling
①對(duì)語(yǔ)法樹 有完全的控制權(quán)
②可作為一個(gè) standalone 命令單獨(dú)使用，如 clang-format
③需要使用C++且對(duì)Clang源碼熟悉
3.ClangPlugin
①對(duì)語(yǔ)法樹有完全的控制權(quán)
②作為插件注入到編譯流程中，可以影響build和決定編譯過(guò)程
③需要使用C++且對(duì)Clang源碼熟悉
結(jié)語(yǔ)
??最后感謝孫源(我就叫Sunny怎么了)的分享，而且希望感興趣的小伙伴可以閱讀《程序員的自我修養(yǎng)》這本書，想要高階資料，那么“龍書”將是你的不二之選。
??如果本文中有錯(cuò)誤的地方，歡迎指正，郵箱: ed_sun0129@163.com，github: https://github.com/edsum！
參考資料：
http://clang.llvm.org/docs/index.html
http://blog.llvm.org/
https://www.objc.io/issues/6-build-tools/compiler/
http://llvm.org/docs/tutorial/index.html
https://github.com/loarabia/Clang-tutorial
http://lowlevelbits.org/getting-started-with-llvm/clang-on-os-x/
https://hevinaboos.wordpress.com/2013/07/23/clang-tutorial-part-i-introducation/
http://szelei.me/code-generator/
- 《Getting Started with LLVM Core Libraries》
- 《LLVM Cookbook》
