iOS性能優化系列
一：性能優化策略
這一系列文章是我的讀書筆記，整理一下，也算是溫故而知新。
性能問題的處理流程
- 發現/重現問題
- 利用工具剖析
- 形成假設
- 改進代碼和設計
在以上的四個步驟中循環反復，直到問題解決。
Profile!不要猜!
性能優化的主要策略：
- 不要做無用功：不要在啟動時花幾百ms來做logging，不要為同樣的數據做多次查詢
- 試圖重用：對于創建過程昂貴的對象，要重用而不是重新創建
- Table View的cell
- Date/Number的formatter
- 正則表達式
- SQLite語句
- 使用更快的方式設計、編程：選擇正確的集合對象和算法來進行編程、選擇適合的數據存儲格式（plist、SQLite）、優化SQLite查詢語句
- 事先做優化
- 對于昂貴的計算，要進行事先計算。iCal中的重復事件，是預先計算出來的，并保存到數據庫中。
- 事先計算并緩存一些對象，可能會占用大量的內存。注意不要將這些對象聲明為static并常駐內存。
- 事后做優化：異步加載、懶加載
- 為伸縮性而做優化：當數據有10條、100條、1000條甚至更多的時候，應用程序的性能不應該對應的呈數量級式的增長，否則無法使用。
說起來慚愧，我真的很少遇到性能問題。以前假設中的性能問題，很多是根本不存在的。事前計劃也杜絕了不了性能問題的產生，所以不如暫時忘記它吧。當然對于一些常識性的提高性能的設計，仍然是必須的。
二：iOS應用啟動速度優化
很多app的開發者都不重視app的啟動速度，這對于碎片化使用情景的用戶來說，簡直是災難。
iOS應用的啟動速度
應用啟動時，會播放一個放大的動畫。iPhone上是400ms，iPad上是500ms。最理想的啟動速度是，在播放完動畫后，用戶就可以使用。
如果應用啟動過慢，用戶就會放棄使用，甚至永遠都不再回來。拋開代碼不談，如果抱著PC端游和單機游戲的思維，在游戲啟動時強加公司Logo，啟動動畫，并且用戶不可跳過，也會使用戶的成功使用率大大降低。
iOS系統的“看門狗"
為了防止一個應用占用過多的系統資源，開發iOS的蘋果工程師門設計了一個“看門狗”的機制。在不同的場景下，“看門狗”會監測應用的性能。如果超出了該場景所規定的運行時間，“看門狗”就會強制終結這個應用的進程。開發者們在crashlog里面，會看到諸如0x8badf00d這樣的錯誤代碼(“看門狗”吃了壞的食物，它很不高興)。
| 場景 | “看門狗”超時時間 |
|---|---|
| 啟動 | 20秒 |
| 恢復運行 | 10秒 |
| 懸掛進程 | 10秒 |
| 退出應用 | 6秒 |
| 后臺運行 | 10分鐘 |
值得注意的是，Xcode在Debug的時候，會禁止“看門狗”。
如何測試啟動時間
兩種方法：一種使用NSLog，另外一種使用Time Profiler。
- 使用NSLog
- 1 CFAbsoluteTime StartTime;
- 2 int main(int argc, char **argv) {
- 3 StartTime = CFAbsoluteTimeGetCurrent();
- 4 // ... 5 } 6
- 7 - (void)applicationDidFinishLaunching:(UIApplication *)app {
- 8 dispatch_async(dispatch_get_main_queue(), ^{
- 9
- NSLog(@"Launched in %f sec", CFAbsoluteTimeGetCurrent() - StartTime);
- 10
- }); 11 // ... 12 }
- 使用Time Profiler
- Instruments->Time Profiler
- Profile你的app
- 切換到CPU strategy view，找到你的app啟動的第一幀
- 搜索
-[UIApplication _reportAppLaunchFinished] - 找到包含
-[UIApplication _reportAppLaunchFinished]的最后一幀，即可計算出啟動時間
iOS App啟動過程
- 鏈接并加載Framework和static lib
- UIKit初始化
- 應用程序callback
- 第一個Core Animation transaction
鏈接并加載Framework及static lib時需要注意：
- 每個Framework都會增加啟動時間和占用的內存
- 不必要的Framework，不要鏈接
- 必要的Framework，不要票房為Optional
- 只在使用在Deployment Target之后發布的Framework時，才使用Optional（比如你的Deployment Target是iOS 3.0，需要鏈接StoreKit的時候）
- 避免創建全局的C++對象
初始化UIKit時需要注意：
- 字體、狀態欄、user defaults、main nib會被初始化
- 保持main nib盡可能的小
- User defaults本質上是一個plist文件，保存的數據是同時被反序列化的，不要在user defaults里面保存圖片等大數據
應用程序的回調：
application:willFinishLaunchingWithOptions:- 恢復應用程序的狀態
application:didFinishLaunchingWithOptions:
我一直認為設計的本質是折衷。當你為了100ms的啟動速度優化歡欣不已，而無視那長達10秒的啟動動畫時，應該想想究竟什么是應該做的。做正確的事情比把事情做好更重要。
三：事件處理-拯救主線程
用戶經常評論app的一個用詞是“卡頓”，很大的因素是因為主線程被占用了。用戶的事件是在主線程被處理的，包括點擊、滾動、加速計、Proximity Sensor。
為了保證事件的平滑處理，需要進行如下優化：
- 最小化主線程的CPU占用
- 將工作“搬離”主線程
- 不要阻塞主線程
最小化主線程的CPU占用
前面兩篇文章，我們接觸到了Time Profiler。使用它可以剖析不同線程的CPU使用情況，并給出調用堆棧的CPU時間占用百分比。如果app“卡頓”，并且在Time Profiler的結果可以找到明確的高占用堆棧，你需要把它優化掉。
將工作“搬離”主線程 - 隱式并發
為了得到更流暢的交互體驗，iOS已經幫我們做了很多事情，Android就沒有這么好運了。iOS將以下這些事情搬離了主線程：
- View和layer的動畫（動畫繪制前的計算，而不是drawing過程）
- Layer的組合計算（drawing后的疊加）
- PNG的解碼（是的，你沒看錯；而且利用了CPU的多核心）
注意滾動（Scrolling）不是一個動畫，而是在Main Run Loop中不斷接收事件并且處理。
將工作“搬離”主線程 - 顯式并發
這里是需要開發者們搞定的部分。磁盤、網絡等I/O會阻塞線程，不要把它們放到主線程里。常用的技術有：
- Grand Central Dispatch(GCD)
- NSOperationQueue
- NSThread
iOS 4.0后，易用的GCD技術被廣泛使用。例如：
- dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0),
- ^{
- // do something in background dispatch_async(dispatch_get_main_queue(), ^{
- // do something on main thread
- }); });
GCD的陷阱
GCD其實就是線程，只不過提供了一個更高層次的抽象。過多的線程一定會帶來性能損失，因此GCD設計了一個最高允許的線程值（對開發者透明，不用管到底有多少）。那么如何解決這個問題呢？
- 將隊列串行化
- 使用Dispatch sources
- 使用帶有限制的NSOperationQueue
- 使用Cocoa Touch提供的異步方法
另外一個陷阱是線程安全：
- UIKit必須要在主線程使用，除了UIGraphics，UIBezierPath，UIImage
- 大多數CG、CA、Foundation的類，不是線程安全的
- 如果你使用了ojbc runtime來進行introspection，由于它是thread safe的，可能會導致競爭
此外，iOS 4.3添加了DISPATCH_QUEUE_PRIORITY_BACKGROUND，它擁有非常低的優先級。這個優先級只用于不太關心完成時間的真正的后臺任務，如果要表示較低的優先級，你通常需要的是DISPATCH_QUEUE_PRIORITY_LOW。
不要阻塞主線程
即使占用了很少的CPU時間（如果你在Time Profiler中看到這些的數據），也可能會阻塞主線程。磁盤、網絡、Lock、dispatch_sync以及向其它進程/線程發送消息都會阻塞主線 程。Time Profiler只能檢測出占用CPU過多的堆棧，但檢測不了這些IO的問題。
大多數的阻塞事件，都會伴隨著一個系統調用，如：
read/write- 讀寫文件send/recv- 收發網絡數據psynch_mutex_wait- 獲得鎖mach_msg- IPC
System Trace這個Instrumentor，記錄了所有的系統調用，以及每次調用的等待時間。如果你在System Trace里面發現了CPU Time很低，但Wait Time很高的調用，說明在主線程處理I/O已經嚴重損害了app的性能。
保證主線程的低CPU占用，將I/O移至其它線程，可以大大地提高主線程對交互事件的處理能力。我建議開發者朋友們寫代碼的時候，除非是以前遇到過的問題，都沒有必要假設問題存在。80%的優化都是不必要的。
