前言
接到一份10年OC老代碼，具有以下幾個(gè)特點(diǎn)：
1 平均每過2年都有一個(gè)“架構(gòu)師”注入自己引以為傲的核心代碼。所以項(xiàng)目中林立著多套優(yōu)秀的網(wǎng)絡(luò)框架、方法名重復(fù)的各種工具類和類別、IT行業(yè)幾十年濃縮的各種架構(gòu)、通信模式。從這些框架中可以看到每一個(gè)架構(gòu)師不同的架構(gòu)思路，學(xué)到了很多。。。
2 重構(gòu)了又沒有完全重構(gòu)，充滿思想的代碼目錄里隱藏了許多妥協(xié)。
3 現(xiàn)在幾套架構(gòu)開始打架了。
4 由于pch預(yù)編譯頭文件的濫用，依賴鏈路完成多條路徑的閉環(huán)。想到了一個(gè)名詞：熵增。
5 還有swift混編。。。用了一些OC的橋接類，也有半套swift核心庫。
成果
優(yōu)化前：全量編譯時(shí)間： 2600s + xcode卡死
? ? ? ? ? ? ? 增量運(yùn)行時(shí)間：>40s+xcode卡死
優(yōu)化后：全量編譯時(shí)間：1800s
? ? ? ? ? ? ?增量運(yùn)行時(shí)間：<2s
本文不討論全量編譯的提升，網(wǎng)上有很多：包括buildSetting的設(shè)置、swift編碼規(guī)范等
1 導(dǎo)致XCode卡頓的原因：
直接說答案：編譯日志太大
因?yàn)镻CH文件、swift橋接文件通過各種隱藏路徑，基本包含了項(xiàng)目60%的頭文件，導(dǎo)致最終的每個(gè)類文件的編譯都天然的攜帶了這60%的頭文件，當(dāng)然也包括：警告（warning）。
這最終導(dǎo)致輸出的日志文件達(dá)到了500M
我們姑且不去研究這500M是在內(nèi)存還是在文件里。當(dāng)編譯結(jié)束后這500M文件的讀寫是造成XCode卡頓的罪魁禍?zhǔn)?。對了，增量編譯和運(yùn)行也是這份日志歐～～一樣卡。
解決方案：
1 模塊化、靜態(tài)包。（不推薦）
? ? 不建議做，搞到一半極有可能像前任一樣再給項(xiàng)目注入“半套架構(gòu)”。
2 解耦PCH，所有沒必要的引入下沉。（延后做）
? ? 延后做。因?yàn)镻CH的梳理和下沉，也是一個(gè)解耦的過程。工作量非常大，這個(gè)需要用到“職場向上管理”等技術(shù)。
3 給編譯日志瘦身
通過pch或buildsetting 屏蔽不必要的警告
屏蔽警告后（留下必要的警告），全量編譯的導(dǎo)出日志為40M。雖然因?yàn)镻CH濫用，日志仍然很大。但是40M日志在緩存里已經(jīng)無法造成xcode卡頓了。
增量編譯/運(yùn)行速度的提升
繞過Pod資源文件的copy
Target-Build phases-Copy Pods Resources
前后對比：
編譯速度主要消耗在了Pod腳本copy資源文件上，當(dāng)全量編譯后取消這個(gè)腳本，之后的運(yùn)行速度提升20倍以上！。
