ios動態庫編譯
Ⅰ iOS 靜態庫和動態庫打包framework流程（純swift版/swift、OC混編版）
選擇 iOS -- Framework&Library , 點擊 next
如果打包文件中使用了第三方庫，建議pod管理，並告知用戶使用pod安裝，避免用戶重復導入。跟平時開發邏輯一樣，打開 .xcworkspace 工程。
操作完之後工程目錄顯示
把打包需要的文件添加到項目中。 如果想要這個類或類裡面的方法被外面使用，需要配合pubic修飾供外面使用
由於以上獲取的framework只能在對應的版本上運行（即真機只能在設備上運行模擬器版本只能在模擬器上面運行使用），所以需要合並framework版本。
合並framework版本：
sudo lipo -create (此處請填寫真機AppVest文件路徑) (此處填寫模擬器AILLSDK文件路徑) -output 自定義合成文件存儲路徑（合成文件的名字AILLSDK）
因為真機版本和模擬器版本的framework都存在arm64架構，導致架構重復，不出意外，會提示合並失敗。如下
處理合並失敗的問題
最後，將 XX.framework（真機或者模擬器framework都可）文件夾 拷貝出來，替換AILLSDK(本文使用的)為剛才合並的新文件。
查看替換後的framework支持全部真機模擬器架構。
我在合並binary文件之後，僅拷貝出 Release-iphoneos 文件夾下的 XXX.framework ，並替換掉AILLSDK二進制文件。導入項目中使用模擬器運行，報錯，顯示找不到架構。
解決方案
拷貝所有的moles到
再替換掉AILLSDK二進制文件，導入項目，如果framework中內含第三方庫，需要在所在的工程中使用pod載入，否則會提示編譯失敗。
至此，編譯成功。🎉🎉🎉🎉🎉
不管是在framework封裝的內部，內部swift類調用內部的OC類，還是內部的OC類使用內部的swift類，還是外部工程swift類使用framework內部OC類，還是外部工程OC類使用framework內部swift類。原理是一致的，以下來介紹下：
在 AILLSDK.h(你自己創建framework時候生成的.h文件) 中添加import導入
#import <AILLSDK/OC類名.h>
在oc的 .m 或 .h 文件中，導入 #import <AILLSDK/AILLSDK-Swift.h> , 也就是 你自己framework名-Swift.h
Ⅱ 百度APP iOS端包體積50M優化實踐(七)編譯器優化
網路APP iOS端包體積優化系列文章深入探討了包體積優化的整體方案、圖片優化、資源優化、代碼優化、無用類優化、HEIC圖片優化實踐以及無用方法清理。本篇將著重於編譯器優化在網路APP實踐中的應用。
編譯器優化
編譯器優化包括GCC語言編譯優化、Swift編譯優化、LTO優化、剝離調試符號、剝離符號表、剔除未引用的代碼、Asset優化、C++虛函數優化和三方SDK編譯器方向瘦身。
2.1 方案綜述
2.2 GCC語言編譯優化
2.2.1 綜述
通過GCC編譯優化，可以生成體積更小的二進制產物，對Objective C、C、C++均有效。
2.2.2 Objective C++編譯優化
在XCode中編輯和編譯Objective C++代碼時，優化配置路徑為：Build Settings -> Apple Clang -> Code Generation。可選參數包括：
默認優化等級為-Os，但我們使用-Oz優化方式。WWDC 2019《What's New in Clang and LLVM》詳細解釋了這種優化原理，它通過識別跨函數的相同代碼序列減少代碼大小。重復的連續機器指令被外聯為函數，原始代碼序列被替換為外聯函數，雖然增加函數調用棧深度，但在當前高配置的iPhone設備上，這種性能損失是可以接受的。
實踐表明，編譯優化參數 -Oz對Objective C++代碼有10%體積收益，對C和C++代碼有30%收益。
2.2.3 C/C++編譯優化
對於底層模塊（如網路庫、播放內核、視覺處理和端智能），常使用C和C++實現。這些模塊支持跨平台，採用Cmake和GN編譯。對於C++語言，cppFlags選項設置為'-Oz'；對於C語言，cFlags選項設置為"-Oz"。
2.3 Swift編譯優化
Swift優化包括Optimization Level和Compilation Mode，配置路徑為：Build Settings -> Swift Compiler -> Code Generation。
Optimization Level可選參數值有：Optimize for Size，其核心原理與GCC語言編譯優化類似，通過外聯和復用重復的連續機器指令降低大小。Compliation Mode可選參數值有：Optimize for Size[-Osize]和Whole Mole，同時開啟可減少10%的Swift包體積大小。
2.4 LTO優化
LTO是蘋果官方提出的一種優化策略，通過在鏈接階段進行跨模塊優化，減少代碼大小和提高執行效率。配置路徑為：Build Settings -> Apple Clang -> Code Generation -> Link-Time Optimization，設置為Incremental。
LTO優化體現在：函數內聯化、去除無用代碼、全局優化。但負面影響包括：降低Link Map的可讀性、增加編譯和鏈接時間。
2.5 剝離調試符號
默認設置Symbols Hidden by Default為YES，可減少包大小。動態庫設置為NO，否則會引發鏈接錯誤。
2.6 剝離符號表
配置路徑為：Build Settings -> Strip Linked Proct。選擇屬性值為YES。
Strip Linked Proct用於去除不必要的符號信息，去除後只能使用dSYM文件進行符號化，因此需將"Debug Information Format"修改為"DWARF with dSYM file"。
2.7 剔除未引用的代碼
配置路徑為：Build Settings -> Dead Code Stripping。選擇屬性值為YES。
該優化主要在鏈接時剔除C、C++、Swift等靜態語言的無用代碼，但在處理Objective-C時無效，因其基於Runtime機制編譯。
2.8 Asset優化
配置路徑為：Build Settings -> Asset Catalog Compiler -> Optimization。選擇Space以優化包大小，收益較小。
2.9 C++減少虛函數的使用
減少虛函數使用可減少虛函數表佔用空間，最終減小程序包大小。
2.10 三方SDK編譯器瘦身
需對每個框架進行優化配置和微調，確保庫和依賴項也正確配置，以確保與編譯器優化兼容。
網路APP內部集成了眾多第三方SDK，需優化SDK以實現應用瘦身。
指令集架構優化
支持arm64和x86_64架構，通過優化指令集架構減小上傳到AppStore的包體積。
3.2 指令集架構設置
使用lipo命令從舊的framework中拆分指定架構的二進制文件，合並後替換老的framework的mach-o文件。
3.3 去除無用架構
通過驗證AbcArm64和AbcArmX86_64架構信息。
XCode升級優化
蘋果Xcode版本持續優化，如Xcode 14，提供更強大的並行編譯能力，顯著提高構建速度，優化包體積。
Swift內置動態庫優化
自2014年發布以來，Swift語言發展迅速，成為iOS開發的首選語言。優化Swift內置動態庫，只需將APP支持的最低版本修改為12.2。
優化後，網路APP包體積減少30M+，提交AppStore後，有顯著收益。
編譯器優化在網路APP包體積優化中的ROI最高，但影響范圍廣泛。通過實踐，成功減少了30M的包體積，實現了自身庫的全部收益，同時優化了前15個三方SDK。
總結了網路APP的編譯器優化方案，包括多種優化手段，後續將繼續深入探討其他優化方法。