背景
隨著項目規(guī)模越來越大 編譯速度越來越慢 是一個逃不過的問題 特別是硬件資源有限的情況下 首次編譯時間 十幾二十分鐘成了司空見慣的事 很大程度上影響了開發(fā)效率和寫代碼的心情 像我15款 mbp 編譯代碼量約20萬行 100個pod庫的項目 大概需要20分鐘 就算是第二次編譯 也基本需要3分鐘以上 占用了大量編寫代碼的時間 故優(yōu)化編譯速度至關(guān)重要
編譯原理
程序編譯一般需經(jīng)幾個步驟：預(yù)處理、編譯、匯編、鏈接。
編譯是通過編譯器 把一種編程語言(原始語言)轉(zhuǎn)換為另一種編程語言(目標語言)，編譯生成一份完整的機器碼 然后再執(zhí)行。
原始語言是程序員直接編程的語言 如OC Swift
目標語言是計算機可以執(zhí)行的二進制指令機器碼
編譯器大多由兩部分組成：編譯器前端 Clang、編譯器后端 LLVM
編譯器前端 Clang：預(yù)處理 --> 詞法分析 --> 語法分析 --> 生成IR（Clang Code Generator）
編譯器后端 LLVM：對IR優(yōu)化 --> 目標代碼--> 匯編器 --> 機器碼（LLVM Code Generator）--> 鏈接 --> Mac-O文件
優(yōu)化方案
1、提升硬件性能（換個好點的電腦）
這是最有效也是最便捷的優(yōu)化方案 只不過成本有點高 好電腦貴
2、組件二進制
組件二進制通常指的是 把我們使用的第三方pod庫或者自己項目下沉的業(yè)務(wù)庫由代碼格式 打包成framework格式提高編譯速度
組件二進制 就是在編譯階段把代碼先打包成庫 再導(dǎo)入到項目的過程
兩種方式：
一、自己制作
自己制作庫的參考方案
二、拿來主義：
1、cocoapods-packager
2、cocoapods-binary
3、cocoapods-imy-bin
3、Xcode參數(shù)設(shè)置
一、Debug Information Format設(shè)置
Debug改為DWARF，不生成dSYM
使用Instruments調(diào)試工具需要改回DWARF with dSYM file 不然會在Instruments中找不到調(diào)用堆棧
二、Precompile Prefix Header 設(shè)置為YES
預(yù)編譯頭文件，PCH 文件預(yù)編譯完成后，后面用到 PCH 文件的源文件編譯速度也會加快，缺點是 PCH 文件和 PCH 引用到的頭文件內(nèi)容一旦發(fā)生變化，引用到 PCH 的所有源文件都要重新編譯
三、Build Active Architecture Only設(shè)置
Debug改為YES，此項設(shè)置的是是否僅編譯當前架構(gòu)的版本，如果為No，會編譯所有架構(gòu)的版本。需要注意的是，此選項在Release模式下必須為NO。
四、Optimization Level設(shè)置
五、Enable Index-While-Building Functionality設(shè)置
全設(shè)為NO。此項默認打開，作用是 Xcode 編譯時會順帶建立代碼索引，但影響編譯速度。關(guān)閉后Xcode 會換回以前的方式，在空閑時間建立代碼索引
4、代碼層面的優(yōu)化
一、將常用代碼文件打包靜態(tài)庫
代碼組件化，切斷不同業(yè)務(wù)代碼之間依賴，使得每次編譯的時候就只需要編譯自己模塊下的代碼
二、能用@class就用@class，盡量減少文件引用關(guān)系
三、減少Storybord和xib文件的使用
四、清理未使用的圖片等資源，清理未使用的類，或者合并重復(fù)功能的類
