iOS App啓動優化（三）：二進制重排

iOS App啓動優化（一）：檢測啓動時間

iOS App啓動優化（二）：物理內存和虛擬內存

iOS App啓動優化（三）：二進制重排

iOS App啓動優化（四）：編譯期插樁 && 獲取方法符號

iOS App啓動優化（五）：收集符號 && 生成 Order File

iOS App啓動優化（六）：實用黨直接看這裏

重排目的

二進制重排就是爲了減小啓動時的缺頁異常Page Fault從而減小啓動時間

查看 Page Falut

咱們能夠看到圖中項目的Page Fault 數量並很少，這是由於當前項目是一個demo，代碼和文件都極少。當代碼多起來的話，Page Fault的 數量和加載耗時都會隨着代碼增長而增長。

二進制重排 能夠很好優化這個問題，其中心思想是從新排列 方法符號的順序， 使啓動的相關方法排在最前面從而減小啓動Page Falut的數量。

咱們先來看看原來的符號順序，這須要用到 連接映射文件 Link Map File。

Link Map File

• Link Map File 是什麼？
• Link Map File 怎麼獲取？
• Link Map File 有什麼用？

請移步 Link Map File 文件說明

Link Map File 裏能夠看到方法符號的排序。知道了原來的符號排序，開發者怎麼去設置本身想要的順序呢？

order_file

Xcode提供了排列符號的設置給開發者，設置 order_file 便可。蘋果也一直身體力行，objc 源碼就採用了二進制重排優化。

設置order_file

在根目錄生成link.order文件，這裏面就是方法符號的排序

Target -> Build Setting -> Linking -> Order File 設置 order file 的路徑

編寫order_file

雖然知道了能夠經過設置 .order 文件調整符號的位置，可是並不知道怎麼編寫 order_file 。下載objc-750源碼（源碼下載地址），查看其 order_file 。

打開 libobjc.order，原來只須要填寫符號便可。

Link Map File 現實原來是先加載 AppDelegate application:didFinishLaunchingWithOptions: 後加載 [ViewController viewDidLoad]

編寫一下link.order試試

command + K 後 command + B 再查看一下 Link Map File，順序已經換過來了

一個個方法寫進去很容易出現筆誤，那麼當這個文件裏面出現異常的時候編譯會出問題嗎？

再編譯一下查看一下 Link Map File，編譯沒有出現問題，不存在的方法直接被忽略掉了，沒有出如今文件中。

自動生成order_file

全手寫必定是不可取的，想實現自動化就要解決下列問題：

• 保證不遺漏方法
• 保證方法符號正確
• 保證方法符號順序正確

解決方案可見 《抖音研發實踐：基於二進制文件重排的解決方案 APP啓動速度提高超15%》

抖音團隊使用的是 靜態掃描+運行時trace的方案， 可以覆蓋到80%～90%的符號。可是上述的方法也存在性能瓶頸

• initialize hook不到
• 部分block hook不到
• C++經過寄存器的間接函數調用靜態掃描不出來

爲了解決這個瓶頸，我打算嘗試一下在文末提到的 編譯期插樁

編譯期插樁

顧名思義，編譯插樁就是在代碼編譯期間修改已有的代碼或者生成新代碼。

具體可見 iOS App啓動優化（四）：編譯期插樁 && 獲取方法符號