1赂韵。Header Search Paths 和 User Header Search Path
名詞介紹： 這兩個關鍵詞是用來鏈接項目外的類文件的司顿。 就是 我們使用類一般都是加到項目中來护盈。 但是 我們還是 把 文件不放進項目來政钟。 項目中也想使用這個類 就可以在這兩個地方配置 路徑。 然后 在項目中 就可以使用該類了辜荠。 cocopoads 的pod 庫 就是利用這個原理做到的。
1.1抓狭。區(qū)別： 我們知道 OC 引入頭文件 有 #import <> 伯病， #import " " 和 #include < > ， #include " " 否过。共同之處 <> h和" ". 在 OC中 我們知道一般我們引用系統(tǒng)類用<> ,引用我們自己的類 用 " "午笛，那這是為什么呢？ 解釋這個問題 就能搞清楚 這倆個關鍵詞的 區(qū)別了苗桂。 在OC中药磺，文件 一共分為系統(tǒng)文件以及我們創(chuàng)建的文件兩類。 所以我們在 引入頭文件的時候誉察。OC最終 是要找到這個文件位置的与涡。所以它會拼接得到絕對路徑惹谐。 所以重點來了持偏。 用 <> 引入的方式 他只會從系統(tǒng)級別查找文件（就是只會拼接路徑的時候拼接系統(tǒng)目錄+<file.h>去找文件）和 我們在Header Search Paths 里面配置的路徑去找文件 是否存在驼卖。而用 "" 引入頭文件。 OC會在系統(tǒng)級別查找文件和從用戶目錄空間中搜索文件并且它也會在User Header Search Paths配置的路徑找文件鸿秆。
eg: 你試試 #import "UIKit/UIKit.h"也是ok的
總結：<> 是從系統(tǒng)目錄空間 （對應 Header Search Paths）中搜索文件酌畜， "" 是從用戶目錄空間（對應 User Header Search Paths）中搜索文件。若在Header Search Paths中設置SomeClass的路徑后, 上面兩種方式都可以使用. 但在User Header Search Paths中設置后, #import <SomeClass.h> 會編譯報錯卿叽。
2桥胞。Framework Search Paths 和Library Search Paths
2.1 名詞介紹： Framework Search Paths 項目中導入 *.Framework 的時候 需要告訴xcode Framework 路徑 就需要 把 Framework 路徑配置在這里 。 xcode 在add Framework的時候會自動添加考婴。 *** cocopoads 引入framework 這里也會自動添加路徑贩虾。
2.2 名詞介紹：Library Search Paths 項目中導入 *.a 庫 會在Library Search Paths 里面添加出 .a 庫的路徑。 在add的時候 xcode 也會自動添加沥阱。 ** cocopoads 導入.a的時候 也會自動添加路徑缎罢。 我們 可以再報錯找不到庫的時候 來檢查這里路徑是否正確。
2.2 Header Search Paths 咱們在往工程project 里面add framework 的時候 可以理解為 把 framework 跟系統(tǒng)的framework類比的處理邏輯考杉。 再我們把 framework 放到一個pod 庫里面 如果配置了 ”public_header_files“ 就類似要求 再Header Search Paths配置這些文件路徑 我們 就可以在代碼里面使用像自己創(chuàng)建的文件那樣引用了策精。(同事說這樣寫會swfit項目報錯。但是我看afn等第三方也是這么做的 待驗證)
3崇棠。recursive 咽袜。
3.1。名詞解釋：recursive：遍歷該目錄（以及子目錄）枕稀，non-recursive：默認路徑設置询刹；不遍歷該目錄（指的是 只找這個目錄下的文件不會遍歷子目錄的文件）。如果路徑的屬性為recursive抽莱，那么編譯的時候在找?guī)斓穆窂降臅r候范抓，會遍歷該目錄下的所有子目錄的庫文件。PS：在搭建項目的時候食铐，可以創(chuàng)建一個專門放庫文件的文件夾并且設置其屬性為recursive匕垫。
4。 Apple移動設備默認指令集
4.1 名詞解釋：蘋果各代設備的處理器（處理器可以理解處理代碼的軟件）都不同虐呻。在處理代碼上不同設備有著不同的指令集象泵。 指令集會影響設備能否處理代碼的一個東西。iOS使用了arm處理器斟叼，并根據(jù)設備的硬件性能開發(fā)了不同的指令集.
目前為止Apple移動設備默認指令集：
armv6：主要是用在早期的iOS上偶惠，如iPhone, iPhone2, iPhone3G, 第一代、第二代 iPod Touch or iPhone2G/3G朗涩、iPod 1G/2G忽孽；
armv7：iPhone 3GS/4/4s、iPod 3G/4G、iPad 1G/2G/3G兄一、iPad mini
armv7s：iPhone5厘线、iPhone5c、iPad4
arm64：iPhone5s及以后出革、iPad Air造壮、iPad mini2
arm64e:在iPhone XR, iPhone XS等，在arm64指令集基礎上引入了新的PAC機制
所有的指令集原則上向下兼容骂束，新的指令集會兼容原來的指令集耳璧，只是不能充分利用硬件的優(yōu)勢無法發(fā)揮更好的性能.如iPhone4S的CPU默認使用armv7指令集，但是也同時兼容armv6指令集展箱，之前使用armv6架構打包的軟件依然可以在iPhone4s上使用旨枯，只是會慢一點.而且arm指令集出現(xiàn)在真機設備上，模擬器使用X86架構混驰，沒有arm指令集(新版mac上的模擬器也是arm架構了).
4召廷。 Build Active Architecture Only
4.1。名詞解釋：Build 開頭的名詞,是指項目在build/或者打包的時候對生成產(chǎn)物的影響账胧。 （我們正常build項目 會在product 文件夾下邊生產(chǎn)竞慢。這些產(chǎn)物 framework /.a就是你這樣項目生成的。）（而在制作framework /.a庫的時候 也是通過build 生成產(chǎn)物得到framework /.a的） 而在得到產(chǎn)物的時候編譯器該如何生成產(chǎn)物 根據(jù)buildsettings 里面的設置 生成產(chǎn)物治泥。Build Active Architecture Only 就是影響其中一個的字段筹煮。Build Active Architecture Only value為 NO/YES 當設置為YES的時候你此時選擇的設備（模擬器/真機）build 的時候生產(chǎn)的產(chǎn)物就只有該（模擬器/真機）的指令集。 意思就是 比如你在build 一個framework或者是項目的時候選擇了iPhone4S 真機 生成的產(chǎn)物 只有 iPhone4S的armv7指令集居夹。 所以 這里生成的產(chǎn)物 就不能在armv6指令集的設備上下載 使用败潦。而當Build Active Architecture Only 設置為 NO 的時候 他就不根據(jù)你鏈接的設備build 構建產(chǎn)物了。 而是 根據(jù)build settings 里面的Architectures設置的生成產(chǎn)物准脂。Architectures后面介紹劫扒。
4.2 關于framework 以及說的項目build 的時候 產(chǎn)物問題 如果不理解。這里簡單解釋下狸膏。 framework 學習一下 制作framework 就會知道 前期做好準備 沟饥。 最后一步生成framework的時候 就是build 一下 就會在Products 文件目錄下生成framework 了。 而項目就會生成一個.app 這就是產(chǎn)物湾戳。 framework是可以給別人安裝的贤旷。所以 此framework 就需要包括 模擬器指令集。 否則模擬器運行不起來砾脑。 就要包括真機指令集 不然 跑不了缺失指令集的設備幼驶。如果主工程打包設置沖突 還會導致打包失敗。
5 bitcode
5.1 名詞解釋 ： 分享一篇文章 bitcode 是xcode在打包編譯的時候 最后形成可執(zhí)行文件過程中的的一種中間代碼韧衣。意思就是 咱們的 .h .m 文件 或者是framework靜態(tài)庫文件 在打包過程中 會先轉換成bitcode 代碼 然后bitcode 代碼 再轉換成 .o文件最后形成手機的可執(zhí)行文件盅藻。 我們xcode 里面的 設置bitcode 并不是上面的bitcode 中間代碼的概念购桑。 而是 我們把 bitcode 設置為YES 的時候 我們在打包的時候 我們在將代碼轉換成bitcode 代碼之后 bitcode 代碼會被蘋果再次進行優(yōu)化 然后轉換成可執(zhí)行文件.o 文件。
5.2 LLVM 編譯過程:
（1）預處理*****預先處理代碼氏淑。 比如 宏嵌入到對應的位置其兴，頭文件的導入，去除注釋等夸政。
（2）詞法分析。
（3）語法分析榴徐。
（4）生成語法書AST守问。
（5）靜態(tài)分析。利用clang 的 靜態(tài)分析工具 clang static analyzer 的checkers 進行代碼分
析坑资。并提出修改意見耗帕。
（6）生成 LLVM IR。將 AST 自上向下遍歷逐步翻譯成 LLVM IR袱贮。 就是生成bitcode中間代碼仿便。（.oc 的bitcode代碼） （如果打包的時候選擇了bitcode=YES 蘋果還會對bitcode 進行優(yōu)化 ）
（7）生成匯編。.s文件
（8）生成目標文件攒巍。 .o 文件嗽仪。（也稱為 鏈接。 利用連接器 鏈接 源代碼 跟靜態(tài)庫二進制 ）
（9）生成可執(zhí)行文件柒莉。 通過鏈接多個目標文件 形成mach-o 可執(zhí)行文件闻坚。
6 clang
6.1:名詞介紹：編譯架構LLVM前端 對oc代碼 進行編譯成bitcode 中間代碼的 編譯器 clang 命令行
7 MACH-O
7.1 名詞介紹： MACH-O 文件。 其實是指一類文件的統(tǒng)稱 類型 兢孝。 并不是特指某一個種格式文件窿凤。 MACH-O 文件 是指的是 能夠在蘋果設備上 直接執(zhí)行的文件的類型的一種統(tǒng)稱。 比如 咱們 熟知的 iOS 的 ipa包里面的 可執(zhí)行文件（就是黑色的那個文件）跨蟹。還有我們的framework .a 靜態(tài)庫/動態(tài)庫（.a 沒有動態(tài)庫）雳殊。以及我們 正常代碼打包成的 .O 文件（類型是 object類型） 都是MACH-O 文件的一種
7.2 MACH-O 文件一般包括四個部分組成
（1） MACH-O header 文件（頭文件）
（1.1） Magic Number 指的是 處理器 是 64位還是32位的
（1.2） CPU Type 指的是 CUP 類型 是指該可執(zhí)行文件 可在什么指令集的處理器下工作 arm64 arm v7 arm v7s arm v6 x86 i32
（1.3） file Type 指的是該文件的類型
（1.4） Number of load Commands 指的是 load Commonds（加載指令 ） 的數(shù)量 load Commonds 下邊有介紹 也是 MCH-O文件組成的一部分
（1.5） Size of load Commands load Commonds 占用的字節(jié) 。 指的是 下邊 load Commonds 里面 占用的字節(jié) 窗轩。[圖片上傳中...(load-command.png-e8044c-1621233703365-0)]
（1.6） flags 標識二進制文件所需要系統(tǒng)提供支持的功能記錄夯秃，主要與系統(tǒng)的加載、鏈接有關痢艺。（就是我二進制文件需要外部提供支持 這些東西該如何支持 等信息）
（2） load Commonds 文件（加載命令）文件寝并， 名詞介紹：執(zhí)行該可執(zhí)行文件 需要的依賴外部的二進制文件的加載命令（就是比如我們的framework .a 或者動態(tài)庫。系統(tǒng)動態(tài)庫）等改如何加載到進程中腹备。
（2.1） cmd 是load command的類型衬潦，LC_SEGMENT_64的含義是將這個64位的段映射到進程地址空間，即加載命令 64 代表是 64位 還有 32 的參數(shù)植酥。
（2.2）commandSize 72 // 代表load command的大小
（2.3）segment name __TEXT // 16字節(jié)的段名字 __TEXT
（2.4）vmaddr 0x0000000100000000 // 段的虛擬內存起始地址
（2.5） vmsize 0x00000000036a4000 // 段的虛擬內存大小
（2.6） fileoff 0 // 段在文件中的偏移量
（2.7） filesize 57294848 // 段在文件中的大小
（2.8） maxprot 0x00000005 // 段頁面所需要的最高內存保護（4=r,2=w,1=x）
（2.9） initprot 0x00000005 // 段頁面初始的內存保護
（2.10） nsects 8 // 段中包含section的數(shù)量 就是根據(jù)他導入所需二進制代碼的
（2.11） flags 0x0 // 其他雜項標志位
（2.12） 其他常見 load command
- LC_SEGMENT_64： 將該段(64位)映射到進程地址空間中
- LC_DYLD_INFO_ONLY：加載動態(tài)鏈接庫信息（重定向地址镀岛、弱引用綁定弦牡、懶加載綁定、開放函數(shù)等的偏移值等信息）
- LC_SYMTAB：載入符號表地址
- LC_DYSYMTAB：載入動態(tài)符號表地址
- LC_LOAD_DYLINKER：加載動態(tài)加載庫漂羊，可以看出示例使用的是/usr/lib/dyld
- LC_UUID：確定文件的唯一標識驾锰，crash解析中也會有這個，去檢測dysm文件和crash文件是否匹配
- LC_VERSION_MIN_MACOSX/LC_VERSION_MIN_IPHONEOS：確定二進制文件要求的最低操作系統(tǒng)版本
- LC_SOURCE_VERSION：構建該二進制文件使用的源代碼版本
- LC_MAIN：設置程序主線程的入口地址和棧大小
- LC_ENCRYPTION_INFO_64：獲取加密信息
- LC_LOAD_DYLIB：加載額外的動態(tài)庫
- LC_FUNCTION_STARTS：定義一個函數(shù)起始地址表,使調試器和其他程序易于看到一個地址是否在函數(shù)內
- LC_DATA_IN_CODE：定義在代碼段內的非指令的表
-
LC_CODE_SIGNATURE：獲取應用簽名信息
這一步 只是告知程序 如何使用mach-o可執(zhí)行文件走越。 而不是正常的 程序啟動調用順序椭豫。而是在程序啟動 到那一步 做什么 這里能正確執(zhí)行到，
（3）section 。名詞解釋 是指我們正常的代碼 打包成 .o文件最后鏈接起來成為可執(zhí)行文件 里面的.o 文件
sectname __text // 第一個是__text ,就是主程序代碼
segname __TEXT // 該section所屬的 segment名，第一個是__TEXT
addr 0x0000000100006110 // 該section在內存的啟始位置微饥，0x100006110
size 0x000000000358a268 // size 該section的大小酸舍，0x358a268
offset 24848 // 24848 0x6110
align 2^4 (16) // 字節(jié)大小對齊，16
reloff 0 // 重定位入口的文件偏移 0
nreloc 0 // 需要重定位的入口數(shù)量 0
flags 0x80000400 // 包含section的type和attributes
reserved1 0 // ...保留用
reserved2 0 // ...保留用
mach-o 可執(zhí)行文件 內存方向理解文字
從MCH-O文件角度 來理解程序啟動過程 。靜態(tài)庫會被最終打進可執(zhí)行文件里面 所以靜態(tài)庫 并不會影響速度。
裝載的過程也可以理解為進程建立的過程，操作系統(tǒng)只需要做以下三件事情：
1.創(chuàng)建一個獨立的虛擬地址空間
2.讀取可執(zhí)行文件頭呵晨，并且建立虛擬空間與可執(zhí)行文件的映射關系
3.將CPU的指令寄存器設置成可執(zhí)行文件的入口地址，啟動運行.
啟動速度有更好的文章
8 iOS 符號
名詞解釋：簡單來說熬尺，類摸屠、函數(shù)和變量的統(tǒng)稱；類名粱哼、函數(shù)名或變量名稱為符號名(Symbol Name)餐塘；
符號讓庫文件 framework .a 以及各個.o文件可以被引用，讓目標文件可以相互鏈接生成可執(zhí)行文件皂吮；
符號還可以幫助開發(fā)者定位問題戒傻，比較常見的是：將Crash日志中的地址信息轉化成對應的函數(shù)名以及文件名、文件行號信息蜂筹；
Release模式會將二進制中裁剪掉符號的需纳，不過Release模式下默認有dSYM文件，可以根據(jù)dSYM文件來做符號化艺挪。
按類型分不翩，符號可以分三類：
全局符號：目標文件外可見的符號，可以被其他目標文件引用麻裳，或者需要其他目標文件定義口蝠；
局部符號：只在目標文件內可見的符號，指只在目標文件內可見的函數(shù)和變量津坑；
調試符號：包括行號信息的調試符號信息妙蔗，行號信息中記錄了函數(shù)和變量所對應的文件和文件行號。
9 dSYM 文件
名詞解釋：在每次編譯完成之后疆瑰，都會生成一個 dsym 文件眉反。dsym 文件中昙啄，存儲了 16 進制的函數(shù)地址映射。
當 App 執(zhí)行打包后的二進制文件時寸五，實際是通過地址來調用方法的梳凛。我們可能會用三方的統(tǒng)計工具，例如 Fabric 在 App Crash 時會幫我們抓到 crash 時的調用棧梳杏，這些調用棧里會包含 crash 地址的調用信息韧拒。這時可以通過 dSYM 文件由地址映射到具體的函數(shù)位置。
所以我們在debug 模式下 可以將buildsettings 里面的 Debug Information Format 的 degug 下設置為 DWARF 不生省dsym 文件 以增加編譯速度十性。
編譯速度 關閉xcode 終端執(zhí)行 defaults write com.apple.dt.Xcode
DSYM 符號表文章
dSYM 文件是否會生成 根據(jù)xcode 以下幾個字段控制 名詞下邊會介紹
9.1 Generate Debug Symbols：設置為YES叛溢，編譯生成目標文件時會生成調試信息；設置為 NO烁试，那么 dwarf 段不會生成，也不會有 dSYM 文件生成拢肆，并且調試過程使用的斷點也不會生效减响，因為地址已經(jīng)無法和對應代碼行關聯(lián)起來了。這個設置為NO 后面都不起作用 設置為YES 后面的屬性才會有作用
9.2 Debug Information Format ： 如果設置為 DWARF 則不會把調試表導出 如果設置為 DWARF with dSYN File 就代表調試行數(shù)符號 生成到 dSYN文件里面 郭怪。
10 Generate Debug Symbols
名詞介紹：設置為YES支示，編譯生成目標文件時會生成調試信息；設置為 NO鄙才，那么 dwarf 段不會生成颂鸿，也不會有 dSYM 文件生成，并且調試過程使用的斷點也不會生效攒庵，因為地址已經(jīng)無法和對應代碼行關聯(lián)起來了嘴纺。（我們的斷點也是這么反編譯而來的）
11 Other Linker Flags
三個參數(shù) -ObjC 后面 的 -l --framework 意思死 -ObjC 的 參數(shù)的 那些庫 是走這個參數(shù) -l 是 .a庫 -framework 是framework -l 直接 是接在后面 -framework 是換一行接庫的名字
ShowBuildOperationDuration YES 然后就能看到xcode 編譯時間了 在xcode 的 上邊欄 的 那里
