本文源自本人的學(xué)習(xí)記錄整理與理解，其中參考閱讀了部分優(yōu)秀的博客和書籍辕近，盡量以通俗簡單的語句轉(zhuǎn)述。引用到的地方如有遺漏或未能一一列舉原文出處還望見諒與指出，另文章內(nèi)容如有不妥之處還望指教逾礁，萬分感謝 ！
安裝包：程序編譯打包后的文件访惜；比如：iOS平臺的IPA文件, 主要由可執(zhí)行文件和資源文件組成嘹履，資源文件包括圖片、音頻债热、視頻等固定資源
安裝包過大的會有什么缺點 植捎？
- 下載時耗費多余的流量，占用更大的手機內(nèi)存空間
- 超過一定限制會被禁止安裝
- 4G網(wǎng)絡(luò)不支持下載超過
200MB的APP !
關(guān)于構(gòu)建版本文件大小蘋果小哥哥是這么說的 Ｑ羧帷Ｑ媸唷！舌剂！
對于 iOS 和 Apple tvOS App济锄，請驗證您的 App 在支持的操作系統(tǒng)中不超過文件大小的上限。您 App 的完整未壓縮大小不得超過 4GB霍转。Apple Watch App 不得超過 75MB荐绝。此外，每個 Mach-O 可執(zhí)行文件（例如避消，app_name.app/app_name）不得超過這些文件大小的上限低滩。
要了解如何計算內(nèi)存用量，請參閱 Memory Usage Performance Guidelines（《內(nèi)存使用性能準(zhǔn)則》）中的“Viewing Virtual Memory Usage（查看虛擬內(nèi)存使用情況）”岩喷。
Architecture Slice（架構(gòu)片段）是針對特定架構(gòu)的胖二進制布局文件的一部分恕沫。例如，一個胖二進制文件可能會包含針對 32 位和 64 位架構(gòu)的片段纱意。
優(yōu)化思路:
- 采取無損壓縮
ImageOptim是一款優(yōu)秀的無損圖片壓縮工具婶溯，它通過優(yōu)化壓縮參數(shù)，移除無用的文件元數(shù)據(jù)和不必要的顏色配置來實現(xiàn)圖片的無損壓縮偷霉。
壓縮完之后效果還是很明顯的迄委，可能是美術(shù)提供之前沒壓縮過(哭臉狀），Assets.xcassets文件夾壓縮效果
如下：
但發(fā)現(xiàn)實際生產(chǎn)的安裝包體積沒有變小类少，因為COMPRESS_PNG_FILES和STRIP_PNG_TEXT設(shè)置成了YES叙身，Xcode會重新壓縮一次圖片，但是壓縮之后的圖反而比ImageOptim處理之后的圖更大。改成NO就能讓項目中的PNG保持不變。
圖片管理用
Assets.xcassets
主要有兩個方式管理圖片，一種是在項目中添加文件夾存放甲喝，另一種是放在Assets.xcassets管理虏两。推薦使用Assets.xcassets管理愧旦，因為它會把里邊的所有 png 格式的圖片壓縮成一個Assets.car文件，壓縮比率比其他方式管理圖片要高定罢，大大減少圖片體積笤虫。去除沒有用到的資源 LSUnusedResources
把所需資源存儲在服務(wù)端，安裝成功后祖凫；通過網(wǎng)絡(luò)下載緩存到本地
可執(zhí)行文件瘦身思路:
-
編譯器優(yōu)化
-
Strip Linked Product琼蚯、Make Strings Read-Only、Symbols Hidden by Default設(shè)置為YES惠况；目前Xcode已經(jīng)默認打開了遭庶，老項目需注意 - 去掉異常支持，
Enable C++ Exceptions稠屠、Enable Objective-C Exceptions設(shè)置為NO峦睡，Other C Flags添加-fno-exceptions
-
利用AppCode https://www.jetbrains.com/objc/
檢測未使用的代碼:菜單欄->Code- >Inspect Code
AppCode是 jetbrains 公司開發(fā)的，也可以用來開發(fā)iOS項目权埠；不過是付費的榨了，只有30天的試用期編寫LLVM插件檢測出重復(fù)代碼、未被調(diào)用的代碼
-
Xcode自帶LinkMap配置
LinkMap.png
LinkMap文件是Xcode產(chǎn)生可執(zhí)行文件的同時生成的鏈接信息攘蔽，用來描述可執(zhí)行文件的構(gòu)造成分龙屉，包括代碼段（__TEXT）和數(shù)據(jù)段（__DATA）的分布情況。只要設(shè)置Project->Build Settings->Write Link Map File為YES满俗，build完后就可以在設(shè)置的路徑看到LinkMap文件了转捕。
修改文件路徑就可以拿到檢測后的文件；找到比較大的文件后唆垃，針對它進行相應(yīng)的優(yōu)化
我們可以用腳本從linkmap中統(tǒng)計出每個.o目標(biāo)文件占用的體積和每個.a靜態(tài)庫占用的體積腳本鏈接】
借助第三方工具LinkMap文件: https://github.com/huanxsd/LinkMap
靜態(tài)庫瘦身
項目中多少都會引入一些第三方靜態(tài)庫五芝，比如交友項目中引入了第三方分享庫，通過lipo工具可以查看支持的指令集降盹，比如查看微信SDK
lipo -info libWeChatSDK.a
Architectures in the fat file: libWeChatSDK.a are: armv7 armv7s i386 x86_64 arm64
i386,x86_64,這不是模擬器的指令集么与柑？去掉看能不能減少體積谤辜？armv7可以兼容armv7s蓄坏，armv7s也可以刪了，只保留armv7和arm64
lipo libWeChatSDK.a -thin armv7 -output libWeChatSDK-armv7.a
lipo libWeChatSDK.a -thin arm64 -output libWeChatSDK-arm64.a
lipo create libWeChatSDK-armv7.a libWeChatSDK-arm64.a -output libWeChatSDK-device.a
ls -ll
-rw-r--r-- 1 Vic staff 5957080 Jan 6 14:40 libWeChatSDK-device.a
-rw-r--r-- 1 Vic staff 14410376 Nov 25 11:53 libWeChatSDK.a
由原來的14.4M降低到6M丑念！少了一半多涡戳。如果把所有的靜態(tài)庫都只保留armv7和arm64安裝包體檢豈不是大大減少了~！
解決模擬器無法使用
刪掉了i386和x86_64后模擬器將可能無法正常運行脯倚，目前想到的解決方法渔彰，有更好的方案請告訴我嵌屎！
如果是手工添加靜態(tài)庫的話可以在發(fā)布前將靜態(tài)庫替換
如果用 Cocoapods管理可以使用兩份podfile文件，一份包含模擬器指令集一份不包括恍涂，發(fā)布的時候更換podfile文件即可宝惰；或者用同一份podfile，分別配置環(huán)境設(shè)置庫
pod libWeChatSDK:configurations => ['Debug']
pod libWeChatSDK-device:configurations => ['Release']
protocolbuf精簡
由于歷史原因項目中用的protocolbuf還是C++版本了再沧，在3.0版本官方已經(jīng)出了OC版本并提供了生成工具尼夺，官方生成的文件大小只有現(xiàn)在的1/4，代碼行數(shù)大概是現(xiàn)在的1/10炒瘸。
總結(jié)：
iOS 底層 - 性能優(yōu)化之CPU淤堵、GPU
iOS 底層 - 性能優(yōu)化之啟動和電池能耗
也可以參考官方給出的方案
