iOS 应用性能测试的相关方法、工具及技巧

用户不喜欢等待。他们不关心也不应该关心一个应用初始化的时候需要什么,他们只想尽快地完成他们的任务。你的应用应该几乎是瞬间启动的,其界面应当如丝般顺滑。在充满竞争的软件市场中,应用的性能是关键的优势之一。

作为开发者,我们也希望对我们辛苦开发的 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 视频。

有一些入门的精华:

  1. Learning Instruments;
  2. iOS Performance 1, 2, 3;
  3. Improving You App With Instruments;
  4. Advanced Graphics & Animations for iOS Apps;
  5. Profiling In-Depth;
  6. Cocoa Touch Best Practices;
  7. iOS Performance and Power Optimization with Instruments;
  8. Polishing Your App.

响应性

下一个需要测量的重要的东西是 UI 的响应性。触摸的处理发生在主线程。主线程有耗时操作的时候,你的 app 变得反应迟钝。

即使有些操作并不使用 CPU,它们也可能会占用时间。如果主线程有同步调用,测量这些调用耗费的时间。

要测量这个,你可以使用日志。

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. 测量启动时序阶段的时间

通常来说,只知道启动消耗的总时间是不够的。搞清楚启动时序中的哪个阶段拖慢了启动也很重要。

要考虑的最重要的阶段是:

  • -[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 的例子:

  1. 总的冷启动时间。
  2. 总的热启动时间。
  3. 启动阶段的启动时间。
  4. 从服务器下载必要数据花费的时间。
  5. 主线程阻塞超过400毫秒的次数。
  6. 内存警告的次数。
  7. FOOMS 的数量。
  8. UI 阻塞或不可用时操作的长度。

分析程序包将允许你把这些值以及设备类型、国家或网络运营商一起,分散存储到片段中。这些可能会让你洞悉用户遇到了什么样的性能问题,以及如何修复它。

结论

正如你看到的一样,性能度量不仅仅是运行 Instruments.app。还有其它有价值的地方值得考虑。

上述的一些方法实现起来简单快捷,另外一些则要求更多的时间和精力。然而,它们将帮助你监控你的app的性能,找出并解决问题,使你的app用起来更加有趣。

祝你好运,5星好评!

1 5 收藏 评论

关于作者:east

简介还没来得及写 :) 个人主页 · 我的文章 · 10

可能感兴趣的话题



直接登录
跳到底部
返回顶部