用戶不喜歡等待。他們不關(guān)心也不應(yīng)該關(guān)心一個(gè)應(yīng)用初始化的時(shí)候需要什么，他們只想盡快地完成他們的任務(wù)。你的應(yīng)用應(yīng)該幾乎是瞬間啟動(dòng)的，其界面應(yīng)當(dāng)如絲般順滑。在充滿競(jìng)爭(zhēng)的軟件市場(chǎng)中，應(yīng)用的性能是關(guān)鍵的優(yōu)勢(shì)之一。

?

作為開(kāi)發(fā)者，我們也希望對(duì)我們辛苦開(kāi)發(fā)的 app 感到自豪。

?

然而，性能優(yōu)化是一個(gè)棘手的問(wèn)題。大多數(shù)的瓶頸是反直覺(jué)的。如果沒(méi)有合適的度量，找出拖慢 app 的原因是非常困難的。

?

要優(yōu)化你的 app 的性能，你應(yīng)該基于數(shù)據(jù)做決定。在這篇文章中我將會(huì)通過(guò)度量你的 app 的不同方面的性能，來(lái)展示如何得到這個(gè)數(shù)據(jù)。

?

我將談及的方面是：

?

• CPU，GPU，內(nèi)存以及 app 的能源消耗；

• 響應(yīng)性；

• 啟動(dòng)時(shí)間；

• 從你的用戶那里收集的性能指標(biāo)；

?

讓我們開(kāi)始吧！

?

CPU，GPU，內(nèi)存以及能源消耗

?

分析你的 app 的第一個(gè)任務(wù)，是找出過(guò)度使用 CPU， GPU 或者內(nèi)存的低效代碼。Apple 有一個(gè)很棒的工具 Instruments 來(lái)完成這個(gè)任務(wù)：

?

有4個(gè)主要的方面需要重點(diǎn)考慮：

?

• CPU (“Time Profiler” 工具);

• GPU (“Core Animation” 工具);

• 內(nèi)存使用 (“Allocations” 工具);

• 電量使用 (“Energy diagnostics” 工具).

?

?

關(guān)于使用 Instruments 來(lái)分析 app 的最佳信息來(lái)源就是 WWDC 視頻。

?

有一些入門(mén)的精華：

?

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.

?

響應(yīng)性

?

下一個(gè)需要測(cè)量的重要的東西是 UI 的響應(yīng)性。觸摸的處理發(fā)生在主線程。主線程有耗時(shí)操作的時(shí)候，你的 app 變得反應(yīng)遲鈍。

?

即使有些操作并不使用 CPU，它們也可能會(huì)占用時(shí)間。如果主線程有同步調(diào)用，測(cè)量這些調(diào)用耗費(fèi)的時(shí)間。

?

要測(cè)量這個(gè)，你可以使用日志。

?

CFAbsoluteTime startTime = CFAbsoluteTimeGetCurrent();

?

// Your method

?

NSUInteger milliseconds = (NSUInteger)((CFAbsoluteTimeGetCurrent() — startTime) * 1000);

?

NSLog(“Done in %lu ms”, milliseconds);

?

Viber 的開(kāi)發(fā)者描述了另一種方法。他們有一個(gè)特殊的線程用來(lái)監(jiān)視主線程，并監(jiān)測(cè)主線程的阻塞不會(huì)超過(guò) 400 毫秒。

?

測(cè)試響應(yīng)性（來(lái)自 Viber 關(guān)于 NSSpain 的 PPT）

?

測(cè)試響應(yīng)性（來(lái)自Viber關(guān)于NSSpain的PPT）

?

更多信息請(qǐng)參考 PPT原文 (PDF, 7MB)。

https://dl.dropboxusercontent.com/u/3820193/VbierClientUnderTheHood.pdf

?

使用這個(gè)數(shù)據(jù)來(lái)監(jiān)測(cè)耗時(shí)太長(zhǎng)的調(diào)用（400毫秒是一個(gè)不錯(cuò)的閾值，你可以讀一下 這本書(shū) 獲取更多信息），然后優(yōu)化它們或者將其從主線程移出去。

?

啟動(dòng)時(shí)間

?

下一個(gè)需要測(cè)量的重要的事情是你的app啟動(dòng)有多快。典型的用戶只會(huì)在你的app花費(fèi) 幾分鐘時(shí)間。過(guò)長(zhǎng)的啟動(dòng)時(shí)間會(huì)招致失望。

?

你的app有兩種被啟動(dòng)的情況：

?

• 冷 啟動(dòng)：你的 app 的進(jìn)程沒(méi)有在運(yùn)行，它現(xiàn)在被操作系統(tǒng)啟動(dòng)。

• 熱 啟動(dòng)：你的 app 被最小化而沒(méi)有殺死。它是從后臺(tái)恢復(fù)的。

?

本章節(jié)主要討論冷啟動(dòng)，因?yàn)檫@是更加資源密集的操作。

?

下圖是一個(gè) iOS app 的啟動(dòng)時(shí)序。

?

?

The Application Startup Phases (from the documentation) 應(yīng)用啟動(dòng)階段（來(lái)自這篇文檔）

?

1. 測(cè)量啟動(dòng)花費(fèi)的總時(shí)間

?

我們應(yīng)當(dāng)測(cè)量從 main() 的開(kāi)頭到 applicationDidBecomeActive: 末尾之間花費(fèi)的時(shí)間。

?

int main(int argc, char * argv[]) {

?

????// Save the initial time for startup

????[[StartipTimeMonitor sharedMonitor] appWillStartLoading];

?

????@autoreleasepool {

????????return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));

????}

}

?

- (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];

??});

}

?

當(dāng)你引入新特性的時(shí)候，確保啟動(dòng)時(shí)間不會(huì)變得更糟。試著將冷啟動(dòng)時(shí)間控制在 1 秒以內(nèi)。

?

2. 測(cè)量啟動(dòng)時(shí)序階段的時(shí)間

?

通常來(lái)說(shuō)，只知道啟動(dòng)消耗的總時(shí)間是不夠的。搞清楚啟動(dòng)時(shí)序中的哪個(gè)階段拖慢了啟動(dòng)也很重要。

?

要考慮的最重要的階段是：

?

• -[AppDelegate application:didFinishLaunchingWithOptions:]?—?當(dāng)啟動(dòng)圖（或故事板）顯示的時(shí)候這個(gè)回調(diào)被調(diào)起。當(dāng)你的 app從這個(gè)方法返回的時(shí)候，實(shí)際的UI立刻開(kāi)始加載。

• -[UIViewController loadView] — 如果你的app加載一個(gè)自定義的 view，這里是 view 初始化的地方。

• -[UIViewController viewDidLoad]?— view 已經(jīng)被加載；最終的初始化的時(shí)間。

• -[AppDelegate applicationDidBecomeActive:]— UI 已經(jīng)被初始化，但是在這個(gè)

• 回調(diào)完成之前UI仍舊被阻塞著。當(dāng)你的 app 從后臺(tái)被恢復(fù)時(shí)，這個(gè)方法也會(huì)被調(diào)用。

?

如果這些方法中的某些占用了過(guò)多的時(shí)間，優(yōu)化它。

?

3. 測(cè)量“壓力下”的啟動(dòng)時(shí)間

?

真實(shí)世界與典型的測(cè)試環(huán)境相比有一個(gè)重要的不同。

?

你的 app 在真實(shí)世界不是孤立存在的。

?

用戶常常從另一個(gè) app 切換到你的 app。這個(gè)“另一個(gè) app”可能非常笨重。因此測(cè)量這些情景下的啟動(dòng)時(shí)間非常重要，那就是：你的 app 開(kāi)始啟動(dòng)的同時(shí)，另一個(gè)笨重的 app 正在切換到后臺(tái)，并試圖保存它的數(shù)據(jù)。

?

那樣的測(cè)試可以發(fā)現(xiàn)一些意想不到的結(jié)果。先前完全無(wú)害的代碼，在那種情境下可能會(huì)顯著地拖慢你的 app。

?

4. app 已經(jīng)啟動(dòng)，但仍然不可用

?

如果你的 app 在已經(jīng)加載完UI之后并不是立即可用，那么它并沒(méi)有真正地完成加載。即使 UI 已經(jīng)加載完畢并且有響應(yīng)，但仍需要加載一些數(shù)據(jù)才能準(zhǔn)備就緒，把這也算到啟動(dòng)階段去。

?

從你的用戶那里收集的性能指標(biāo)

?

前述的所有測(cè)量方法在測(cè)試環(huán)境都可以使用。這些是必須的，但是并不高效。如果你的 app 很流行，如果你的用戶群遍布全球，一些用戶的環(huán)境可能跟你預(yù)期中的相差巨大。

?

他們可能有不同的：

?

• 網(wǎng)絡(luò)狀況；

• 硬件；

• 軟件（操作系統(tǒng)版本，越獄……）；

• 設(shè)備上的可用空間

• 其他種種

?

他們也可能有不同的 app 使用方式。

?

即使你在實(shí)驗(yàn)環(huán)境中測(cè)試的所有指標(biāo)都處在安全區(qū)間，你仍有可能得到帶著抱怨的一星評(píng)價(jià)（“你的 app 太慢！”）。

?

對(duì)此應(yīng)該做些什么呢？

?

定義一套性能指標(biāo)（或 KPI），并從真實(shí)用戶那里收集數(shù)據(jù)。你可以利用幾乎任意的分析程序包來(lái)做這件事。

?

下面是你可以從用戶那里得到的 KPI 的例子：

?

總的冷啟動(dòng)時(shí)間。

總的熱啟動(dòng)時(shí)間。

啟動(dòng)階段的啟動(dòng)時(shí)間。

從服務(wù)器下載必要數(shù)據(jù)花費(fèi)的時(shí)間。

主線程阻塞超過(guò)400毫秒的次數(shù)。

內(nèi)存警告的次數(shù)。

FOOMS 的數(shù)量。

UI 阻塞或不可用時(shí)操作的長(zhǎng)度。

?

分析程序包將允許你把這些值以及設(shè)備類型、國(guó)家或網(wǎng)絡(luò)運(yùn)營(yíng)商一起，分散存儲(chǔ)到片段中。這些可能會(huì)讓你洞悉用戶遇到了什么樣的性能問(wèn)題，以及如何修復(fù)它。

?

結(jié)論

?

正如你看到的一樣，性能度量不僅僅是運(yùn)行 Instruments.app。還有其它有價(jià)值的地方值得考慮。

?

上述的一些方法實(shí)現(xiàn)起來(lái)簡(jiǎn)單快捷，另外一些則要求更多的時(shí)間和精力。然而，它們將幫助你監(jiān)控你的app的性能，找出并解決問(wèn)題，使你的app用起來(lái)更加有趣。

?

轉(zhuǎn)載于:https://www.cnblogs.com/fengmin/p/5500391.html

總結(jié)

以上是生活随笔為你收集整理的iOS 应用性能测试的相关方法、工具及技巧的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。