項目啟動優化是每個APP都可以接入的技術，只不過針對不同的業務邏輯我們需要有不一樣的解決方案，因為有大部分人的“優化”，是在處理自己放蕩不羈的代碼。 既然這裡我們要討論啟動優化，那麼我們從啟動檢測開始。啟動檢測一般我們會以main函數作為分割點，main之前和main之後。 main之前稱為per- ...
項目啟動優化是每個APP都可以接入的技術，只不過針對不同的業務邏輯我們需要有不一樣的解決方案，因為有大部分人的“優化”，是在處理自己放蕩不羈的代碼。
既然這裡我們要討論啟動優化，那麼我們從啟動檢測開始。啟動檢測一般我們會以main函數作為分割點，main之前和main之後。
main之前稱為per-main 階段。這個由dyld給你反饋應用的耗時。
main之後由開發者自己檢測。我們可以從main開始打點，到第一個頁面顯示為止。
pre-main階段檢測
main函數之前的檢測蘋果提供了支持，具體配置方式來來來！上圖！
-
首先進入Edit Scheme
Edit Scheme
-
然後配置的 key 為：DYLD_PRINT_STATISTICS
- 然後我們再運行項目，該項目 pre-main 的耗時就會在控制台輸出。
Edit Scheme
Total pre-main time: 123.34 milliseconds (100.0%)
dylib loading time: 46.83 milliseconds (37.9%)
rebase/binding time: 3.01 milliseconds (2.4%)
ObjC setup time: 18.58 milliseconds (15.0%)
initializer time: 54.91 milliseconds (44.5%)
slowest intializers :
libSystem.B.dylib : 5.00 milliseconds (4.0%)
libBacktraceRecording.dylib : 9.43 milliseconds (7.6%)
libMainThreadChecker.dylib : 17.72 milliseconds (14.3%)
libViewDebuggerSupport.dylib : 20.72 milliseconds (16.8%)
欄位含義
dylib loading time 動態庫載入耗時
載入動態庫，這個過程中，會去裝載app使用的動態庫，而動態庫之間有它自己的依賴關係，所以會消耗時間去查找和讀取。
系統的動態庫，做了優化。所以從效率的角度來說，儘可能使用系統庫。
而對於開發者定義導入的動態庫（dynamically linked shared library），則需要在花費更多的時間。Apple官方建議儘量少的使用自定義的動態庫，或者考慮合併多個動態庫，其中一個建議是當大於6個的時候，則需要考慮合併它們。
在性能上出發將動態庫編譯成靜態庫也會優化這部分時間。
rebase/binding time 修正符號和綁定符號耗時
Rebase：在鏡像（MachO文件）內部調整指針的指向，針對mach-o在載入到記憶體中不是固定的首地址（ASLR）這一現象做數據修正的過程。
iOS4.3後引入了 ASLR ，MachO會被載入到隨機地址，這個隨機的地址跟代碼和數據指向的舊地址會有偏差。dyld 需要修正這個偏差，做法就是將 dylib 內部的指針地址都加上這個偏移量。
binding：將指針指向鏡像（MachO文件）外部的內容，binding就是將這個二進位調用的外部符號進行綁定的過程。
ObjC setup time OC類註冊的耗時
主要做以下幾件事來完成Objc Setup：
1、讀取二進位文件的 DATA 段內容，找到與 objc 相關的信息
2、註冊 Objc 類，ObjC Runtime 需要維護一張映射類名與類的全局表。當載入一個 MachO 時，它定義的所有的類都需要被註冊到這個全局表中；
3、讀取 protocol 以及 category 的信息，把category的定義插入方法列表 (category registration)，
這一步的優化。
那麼針對這上面三個步驟，我們可以優化的方案是，不刻意的去減少幾個類，但是可以避免浪費。
隨著項目的不斷迭代，很多模塊和方法已經被廢棄但是卻一直留存在項目中，導致項目越來越臃腫。
我們可以使用一些工具來查找項目中沒有被用到的文件。從而達到優化。
initializer time
1、Objc的+load()函數
2、C++的構造函數屬性函數 形如attribute((constructor)) void DoSomeInitializationWork()
我們能做的就是將不必須在+load方法中做的事情延遲到+initialize中。
這是因為+load方法是在app啟動的時候就被調用，而+initialize方法則是在Class第一次使用的時候才調用，相當於是懶載入了。可以把+load中的代碼移到initialize中，並結合dispatch_once來防止重覆調用。
但是我們項目中只有在使用method swizzling的時候會在+load中調用方法。所以這一點也沒什麼好優化的。
針對main函數之後的時間檢測就通過打點記錄。
在main()、didFinishLaunchingWithOptions以及第一個頁面的viewDidAppear中打點，進行記錄，從而來計算Main函數之後的時間。
調試三方應用
文章的最後我想要補充一個小東西。就是三方應用的調試。因為既然我們可以檢測到性能，那麼看看別人的應用性能如何是一件不錯的事情。廢話不多說！
-
首先創建一個空工程運行到真機上！（我們要利用這個工程的描述文件）
-
然後我們需要一個腳本，腳本代碼如下:
# ${SRCROOT} 它是工程文件所在的目錄
TEMP_PATH="${SRCROOT}/Temp"
#資源文件夾，我們提前在工程目錄下新建一個APP文件夾，裡面放ipa包
ASSETS_PATH="${SRCROOT}/APP"
#目標ipa包路徑
TARGET_IPA_PATH="${ASSETS_PATH}/*.ipa"
#清空Temp文件夾
rm -rf "${SRCROOT}/Temp"
mkdir -p "${SRCROOT}/Temp"
#----------------------------------------
# 1. 解壓IPA到Temp下
unzip -oqq "$TARGET_IPA_PATH" -d "$TEMP_PATH"
# 拿到解壓的臨時的APP的路徑
TEMP_APP_PATH=$(set -- "$TEMP_PATH/Payload/"*.app;echo "$1")
# echo "路徑是:$TEMP_APP_PATH"
#----------------------------------------
# 2. 將解壓出來的.app拷貝進入工程下
# BUILT_PRODUCTS_DIR 工程生成的APP包的路徑
# TARGET_NAME target名稱
TARGET_APP_PATH="$BUILT_PRODUCTS_DIR/$TARGET_NAME.app"
echo "app路徑:$TARGET_APP_PATH"
rm -rf "$TARGET_APP_PATH"
mkdir -p "$TARGET_APP_PATH"
cp -rf "$TEMP_APP_PATH/" "$TARGET_APP_PATH"
#----------------------------------------
# 3. 刪除extension和WatchAPP.個人證書沒法簽名Extention
rm -rf "$TARGET_APP_PATH/PlugIns"
rm -rf "$TARGET_APP_PATH/Watch"
#----------------------------------------
# 4. 更新info.plist文件 CFBundleIdentifier
# 設置:"Set : KEY Value" "目標文件路徑"
/usr/libexec/PlistBuddy -c "Set :CFBundleIdentifier $PRODUCT_BUNDLE_IDENTIFIER" "$TARGET_APP_PATH/Info.plist"
#----------------------------------------
# 5. 給MachO文件上執行許可權
# 拿到MachO文件的路徑
APP_BINARY=`plutil -convert xml1 -o - $TARGET_APP_PATH/Info.plist|grep -A1 Exec|tail -n1|cut -f2 -d\>|cut -f1 -d\<`
#上可執行許可權
chmod +x "$TARGET_APP_PATH/$APP_BINARY"
#----------------------------------------
# 6. 重簽名第三方 FrameWorks
TARGET_APP_FRAMEWORKS_PATH="$TARGET_APP_PATH/Frameworks"
if [ -d "$TARGET_APP_FRAMEWORKS_PATH" ];
then
for FRAMEWORK in "$TARGET_APP_FRAMEWORKS_PATH/"*
do
#簽名
/usr/bin/codesign --force --sign "$EXPANDED_CODE_SIGN_IDENTITY" "$FRAMEWORK"
done
fi
#註入
#yololib "$TARGET_APP_PATH/$APP_BINARY" "Frameworks/HankHook.framework/HankHook"
這個腳本可以生成一個腳本文件，或者直接拷貝代碼去配置！腳本中每個功能都寫上了註釋，不要無腦粘貼。
-
在工程根目錄下新建文件夾，並將脫殼的三方iPA包放進去（我們已微信為例）
-
給工程添加腳本
-
配置腳本並執行
接下來就可以將三方的應用運行到真機了。下麵是微信的啟動時間。pre-main大概1.1秒。
