iOS編譯器

Objective-C 和 Swift都是編譯語言模塊化

編譯語言在執行的時候,必須先經過編譯器生成機器碼函數

CPU執行機器碼工具

LLVM 編譯編譯語言優化

LLVM 是一個模塊化和可重用的編譯器和工具鏈技術的集合code

LLVM 核心庫提供一個優化器,對流行的 CPU 作代碼生成支持orm

Clang 是 LLVM 的子項目,是 C,C++ 和 Objective-C 編譯器對象

clang static analyzer 主要是進行語法分析,語義分析和生成中間代碼,對代碼進行檢查,出錯的和須要警告的會標註出來。資源

lld 是 Clang / LLVM 的內置連接器,clang 必須調用連接器(lld)來產生可執行文件開發

 

1,編譯源文件的時候,編譯器首先作的是一些預處理工做。好比預處理器會處理源文件中的宏定義,將代碼中的宏用其對應定義的具體內容進行替換。編譯器

2,.m 源文件裏都有一堆的聲明和定義,這些代碼文本都會從string 轉化成特殊的標記流,每個標記流都包含了對應的 源碼內容 和在源碼中的位置.

注意這裏的位置是宏展開以前的位置,這樣一來,若是編譯過程當中遇到什麼問

題,clang 可以在源碼中指出出錯的具體位置

3,標記流將會被解析成一棵抽象語法樹 (abstract syntax tree -- AST),在抽象語法樹中的每一個節點都標註了其對應源碼中的位置,一樣的,若是產生了什麼問題,clang 能夠定位到問題所在處的源碼位置.

4,一旦編譯器把源碼生成了抽象語法樹,編譯器能夠對這棵樹作分析處理,以找出代碼中的錯誤,好比類型檢查:即檢查程序中是否有類型錯誤。例如:若是代碼中給某個對象發送了一個消息,編譯器會檢查這個對象是否實現了這個消息(函數、方法)。此外,clang 對整個程序還作了其它更高級的一些分析,以確保程序沒有錯誤。

細化:

類型檢查(動態的和靜態的)

每當開發人員編寫代碼的時候,clang 都會幫忙檢查錯誤。其中最多見的就是檢查程序是否發送正確的消息給正確的對象,是否在正確的值上調用了正確的函數。若是你給一個單純的 NSObject* 對象發送了一個 hello 消息,那麼 clang 就會報錯。一樣,若是你建立了 NSObject 的一個子類 Test,而後試圖給這個子類中某個屬性設置一個與其自身類型不相符的對象,編譯器會給出

一個可能使用不正確的警告

動態的在運行時作檢查,靜態的在編譯時作檢查。以往,編寫代碼時能夠向任意對象發送任何消息,在運行時,纔會檢查對象是否可以響應這些消息。因爲只是在運行時作此類檢查,因此叫作動態類型。

靜態類型,是在編譯時作檢查。當在代碼中使用 ARC 時,編譯器在編譯期間,會作許多的類型檢查:由於編譯器須要知道哪一個對象該如何使用。例如,若是 myObject沒有 hello 方法,那麼就不能寫以下這行代碼

clang 在靜態分析階段,除了類型檢查外,還會作許多其它一些分析。若是你把 clang的代碼倉庫 clone 到本地,而後進入目錄 lib/StaticAnalyzer/Checkers,你會看到全部靜態檢查內容。好比 ObjCUnusedIVarsChecker.cpp 是用來檢查是否有定義了,可是從未使用過的變量。而 ObjCSelfInitChecker.cpp 則是檢查在 你的初始化方法中中調用

self 以前,是否已經調用 [self initWith...] 或 [super init] 了。編譯器還進行了一些其它的檢查,例如在 lib/Sema/SemaExprObjC.cpp 的 2,534 行,有這樣一句:Diag(SelLoc, diag::warn_arc_perform_selector_leaks);這個會生成嚴重錯誤的警告 「performSelector may cause a leak because its selector

is unknown」 。

5,clang 完成代碼的標記,解析和分析後,接着就會生成 LLVM 代碼。

6,LVVM優化器會進行BitCode的生成,連接期優化等等。

 

 

 

 

 手機執行IPA包的簡單過程

一個手機,拿到IPA包裏面的OC代碼以後,編譯器Clang進行編譯連接成機器語言後,在手機顯示屏中顯示,

Xcode執行源代碼的簡單過程

Xcode軟件裏面有個編譯器(clang)把項目裏面的代碼資源編譯成機器語言後,利用mac電腦的CPU來執行機器語言,而後在經過模擬器顯示.

相關文章
相關標籤/搜索