背景
隨著項目規(guī)模越來越大 編譯速度越來越慢 是一個逃不過的問題 特別是硬件資源有限的情況下 首次編譯時間 十幾二十分鐘成了司空見慣的事 很大程度上影響了開發(fā)效率和寫代碼的心情 像我15款 mbp 編譯代碼量約20萬行 100個pod庫的項目 大概需要20分鐘 就算是第二次編譯 也基本需要3分鐘以上 占用了大量編寫代碼的時間 故優(yōu)化編譯速度至關(guān)重要
編譯原理
程序編譯一般需經(jīng)幾個步驟：預(yù)處理、編譯秤掌、匯編弃锐、鏈接。
編譯是通過編譯器 把一種編程語言(原始語言)轉(zhuǎn)換為另一種編程語言(目標(biāo)語言)奴拦，編譯生成一份完整的機(jī)器碼 然后再執(zhí)行兰怠。
原始語言是程序員直接編程的語言 如OC Swift
目標(biāo)語言是計算機(jī)可以執(zhí)行的二進(jìn)制指令機(jī)器碼
編譯器大多由兩部分組成：編譯器前端 Clang畦攘、編譯器后端 LLVM
編譯器前端 Clang：預(yù)處理 --> 詞法分析 --> 語法分析 --> 生成IR（Clang Code Generator）
編譯器后端 LLVM：對IR優(yōu)化 --> 目標(biāo)代碼--> 匯編器 --> 機(jī)器碼（LLVM Code Generator）--> 鏈接 --> Mac-O文件
優(yōu)化方案
1霸妹、提升硬件性能（換個好點(diǎn)的電腦）
這是最有效也是最便捷的優(yōu)化方案 只不過成本有點(diǎn)高 好電腦貴
2、組件二進(jìn)制
組件二進(jìn)制通常指的是 把我們使用的第三方pod庫或者自己項目下沉的業(yè)務(wù)庫由代碼格式 打包成framework格式提高編譯速度
組件二進(jìn)制 就是在編譯階段把代碼先打包成庫 再導(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 文件的源文件編譯速度也會加快杯矩，缺點(diǎn)是 PCH 文件和 PCH 引用到的頭文件內(nèi)容一旦發(fā)生變化，引用到 PCH 的所有源文件都要重新編譯
三袖外、Build Active Architecture Only設(shè)置
Debug改為YES史隆，此項設(shè)置的是是否僅編譯當(dāng)前架構(gòu)的版本，如果為No曼验，會編譯所有架構(gòu)的版本泌射。需要注意的是，此選項在Release模式下必須為NO鬓照。
四熔酷、Optimization Level設(shè)置
五、Enable Index-While-Building Functionality設(shè)置
全設(shè)為NO豺裆。此項默認(rèn)打開拒秘，作用是 Xcode 編譯時會順帶建立代碼索引，但影響編譯速度臭猜。關(guān)閉后Xcode 會換回以前的方式躺酒，在空閑時間建立代碼索引
4、代碼層面的優(yōu)化
一获讳、將常用代碼文件打包靜態(tài)庫
代碼組件化阴颖，切斷不同業(yè)務(wù)代碼之間依賴活喊，使得每次編譯的時候就只需要編譯自己模塊下的代碼
二丐膝、能用@class就用@class，盡量減少文件引用關(guān)系
三钾菊、減少Storybord和xib文件的使用
四帅矗、清理未使用的圖片等資源，清理未使用的類煞烫，或者合并重復(fù)功能的類
