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