使用者不喜歡等待。他們不關心也不應該關心一個應用初始化的時候需要什麼，他們只想儘快地完成他們的任務。你的應用應該幾乎是瞬間啟動的，其介面應當如絲般順滑。在充滿競爭的軟體市場中，應用的效能是關鍵的優勢之一。
作為開發者，我們也希望對我們辛苦開發的 app 感到自豪。
然而，效能優化是一個棘手的問題。大多數的瓶頸是反直覺的。如果沒有合適的度量，找出拖慢 app 的原因是非常困難的。
要優化你的 app 的效能，你應該基於資料做決定。在這篇文章中我將會通過度量你的 app 的不同方面的效能，來展示如何得到這個資料。
我將談及的方面是：
- CPU，GPU，記憶體以及 app 的能源消耗；
- 響應性；
- 啟動時間；
- 從你的使用者那裡收集的效能指標；
讓我們開始吧！
CPU，GPU，記憶體以及能源消耗
分析你的 app 的第一個任務，是找出過度使用 CPU， GPU 或者記憶體的低效程式碼。Apple 有一個很棒的工具 Instruments 來完成這個任務：
有4個主要的方面需要重點考慮：
- CPU (“Time Profiler” 工具);
- GPU (“Core Animation” 工具);
- 記憶體使用 (“Allocations” 工具);
- 電量使用 (“Energy diagnostics” 工具).
關於使用 Instruments 來分析 app 的最佳資訊來源就是 WWDC 視訊。
有一些入門的精華：
- Learning Instruments;
- iOS Performance 1, 2, 3;
- Improving You App With Instruments;
- Advanced Graphics & Animations for iOS Apps;
- Profiling In-Depth;
- Cocoa Touch Best Practices;
- iOS Performance and Power Optimization with Instruments;
- Polishing Your App.
響應性
下一個需要測量的重要的東西是 UI 的響應性。觸控的處理髮生在主執行緒。主執行緒有耗時操作的時候，你的 app 變得反應遲鈍。
即使有些操作並不使用 CPU，它們也可能會佔用時間。如果主執行緒有同步呼叫，測量這些呼叫耗費的時間。
要測量這個，你可以使用日誌。
|
1 2 3 4 5 6 7 |
CFAbsoluteTime startTime = CFAbsoluteTimeGetCurrent(); // Your method NSUInteger milliseconds = (NSUInteger)((CFAbsoluteTimeGetCurrent() — startTime) * 1000); NSLog(“Done in %lu ms”, milliseconds); |
Viber 的開發者描述了另一種方法。他們有一個特殊的執行緒用來監視主執行緒，並監測主執行緒的阻塞不會超過 400 毫秒。
測試響應性（來自 Viber 關於 NSSpain 的 PPT）
測試響應性（來自Viber關於NSSpain的PPT）
更多資訊請參考 PPT原文 (PDF, 7MB)。
使用這個資料來監測耗時太長的呼叫（400毫秒是一個不錯的閾值，你可以讀一下 這本書 獲取更多資訊），然後優化它們或者將其從主執行緒移出去。
啟動時間
下一個需要測量的重要的事情是你的app啟動有多快。典型的使用者只會在你的app花費 幾分鐘時間。過長的啟動時間會招致失望。
你的app有兩種被啟動的情況：
- 冷 啟動：你的 app 的程式沒有在執行，它現在被作業系統啟動。
- 熱 啟動：你的 app 被最小化而沒有殺死。它是從後臺恢復的。
本章節主要討論冷啟動，因為這是更加資源密集的操作。
下圖是一個 iOS app 的啟動時序。
The Application Startup Phases (from the documentation) 應用啟動階段（來自這篇文件）
1. 測量啟動花費的總時間
我們應當測量從 main() 的開頭到 applicationDidBecomeActive: 末尾之間花費的時間。
|
1 2 3 4 5 6 7 8 9 |
int main(int argc, char * argv[]) { // Save the initial time for startup [[StartipTimeMonitor sharedMonitor] appWillStartLoading]; @autoreleasepool { return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class])); } } |
|
1 2 3 4 5 6 7 8 9 |
- (void)applicationDidBecomeActive:(UIApplication *)application { // Your code // We assume that the app is loaded then the main thread become free // after this callback is finished. dispatch_async(dispatch_get_main_queue(), ^{ [[StartipTimeMonitor sharedMonitor] appDidFinishLoading]; }); } |
當你引入新特性的時候，確保啟動時間不會變得更糟。試著將冷啟動時間控制在 1 秒以內。
2. 測量啟動時序階段的時間
通常來說，只知道啟動消耗的總時間是不夠的。搞清楚啟動時序中的哪個階段拖慢了啟動也很重要。
要考慮的最重要的階段是：
- -[AppDelegate application:didFinishLaunchingWithOptions:] — 當啟動圖（或故事板）顯示的時候這個回撥被調起。當你的 app從這個方法返回的時候，實際的UI立刻開始載入。
- -[UIViewController loadView] — 如果你的app載入一個自定義的 view，這裡是 view 初始化的地方。
- -[UIViewController viewDidLoad] — view 已經被載入；最終的初始化的時間。
- -[AppDelegate applicationDidBecomeActive:]— UI 已經被初始化，但是在這個回撥完成之前UI仍舊被阻塞著。當你的 app 從後臺被恢復時，這個方法也會被呼叫。
如果這些方法中的某些佔用了過多的時間，優化它。
3. 測量“壓力下”的啟動時間
真實世界與典型的測試環境相比有一個重要的不同。
你的 app 在真實世界不是孤立存在的。
使用者常常從另一個 app 切換到你的 app。這個“另一個 app”可能非常笨重。因此測量這些情景下的啟動時間非常重要，那就是：你的 app 開始啟動的同時，另一個笨重的 app 正在切換到後臺，並試圖儲存它的資料。
那樣的測試可以發現一些意想不到的結果。先前完全無害的程式碼，在那種情境下可能會顯著地拖慢你的 app。
4. app 已經啟動，但仍然不可用
如果你的 app 在已經載入完UI之後並不是立即可用，那麼它並沒有真正地完成載入。即使 UI 已經載入完畢並且有響應，但仍需要載入一些資料才能準備就緒，把這也算到啟動階段去。
從你的使用者那裡收集的效能指標
前述的所有測量方法在測試環境都可以使用。這些是必須的，但是並不高效。如果你的 app 很流行，如果你的使用者群遍佈全球，一些使用者的環境可能跟你預期中的相差巨大。
他們可能有不同的：
- 網路狀況；
- 硬體；
- 軟體（作業系統版本，越獄……）；
- 裝置上的可用空間
- 其他種種
他們也可能有不同的 app 使用方式。
即使你在實驗環境中測試的所有指標都處在安全區間，你仍有可能得到帶著抱怨的一星評價（“你的 app 太慢！”）。
對此應該做些什麼呢？
定義一套效能指標（或 KPI），並從真實使用者那裡收集資料。你可以利用幾乎任意的分析程式包來做這件事。
下面是你可以從使用者那裡得到的 KPI 的例子：
- 總的冷啟動時間。
- 總的熱啟動時間。
- 啟動階段的啟動時間。
- 從伺服器下載必要資料花費的時間。
- 主執行緒阻塞超過400毫秒的次數。
- 記憶體警告的次數。
- FOOMS 的數量。
- UI 阻塞或不可用時操作的長度。
分析程式包將允許你把這些值以及裝置型別、國家或網路運營商一起，分散儲存到片段中。這些可能會讓你洞悉使用者遇到了什麼樣的效能問題，以及如何修復它。
結論
正如你看到的一樣，效能度量不僅僅是執行 Instruments.app。還有其它有價值的地方值得考慮。
上述的一些方法實現起來簡單快捷，另外一些則要求更多的時間和精力。然而，它們將幫助你監控你的app的效能，找出並解決問題，使你的app用起來更加有趣。
祝你好運，5星好評！