性能問題的處理流程
發現/重現問題
利用工具剖析
形成假設
改進代碼和設計
在以上的四個步驟中循環反覆，直到問題解決。
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的一個用詞是“卡頓”，很大的因素是因爲主線程被佔用了。用戶的事件