手机性能测试之iOS应用测试的相关方法、工具及技巧-职坐标

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

小坐标 2018-03-08 来源：阅读 1169 评论 0

摘要：作为开发者，我们希望对我们辛苦开发的 app 感到自豪。然而，性能优化是一个棘手的问题。大多数的瓶颈是反直觉的。如果没有合适的度量，找出拖慢 app 的原因是非常困难的。要优化你的 app 的性能，你应该基于数据做决定。本章中小坐标将会通过度量你的 app 的不同方面的性能，做一下手机性能测试,来展示如何得到这个数据。

　　作为开发者，我们希望对我们辛苦开发的 app 感到自豪。然而，性能优化是一个棘手的问题。大多数的瓶颈是反直觉的。如果没有合适的度量，找出拖慢 app 的原因是非常困难的。要优化你的 app 的性能，你应该基于数据做决定。本章中小坐标将会通过度量你的 app 的不同方面的性能，做一下手机性能测试,来展示如何得到这个数据。

　　我将谈及的方面是：

CPU，GPU，内存以及 app 的能源消耗；
响应性；
启动时间；
从你的用户那里收集的性能指标；

　　让我们开始吧！

　　CPU，GPU，内存以及能源消耗

　　分析你的 app 的第一个任务，是找出过度使用 CPU， GPU 或者内存的低效代码。Apple 有一个很棒的工具 Instruments 来完成这个任务：

　　有4个主要的方面需要重点考虑：

　　CPU (“Time Profiler” 工具);

　　GPU (“Core Animation” 工具);

　　内存使用 (“Allocations” 工具);

　　电量使用 (“Energy diagnostics” 工具)。

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

　　关于使用 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，它们也可能会占用时间。如果主线程有同步调用，测量这些调用耗费的时间。

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

　　Objective-C
　　CFAbsoluteTime startTime = CFAbsoluteTimeGetCurrent();
　　// Your method
　　NSUInteger milliseconds = (NSUInteger)((CFAbsoluteTimeGetCurrent() — startTime) * 1000);
　　NSLog(“Done in %lu ms”, milliseconds);

　　Viber 的开发者描述了另一种方法。他们有一个特殊的线程用来监视主线程，并监测主线程的阻塞不会超过 400 毫秒。

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

　　更多信息请参考 PPT原文 (PDF, 7MB)。

　　使用这个数据来监测耗时太长的调用（400毫秒是一个不错的阈值，你可以读一下这本书获取更多信息），然后优化它们或者将其从主线程移出去。

　　启动时间

　　下一个需要测量的重要的事情是你的app启动有多快。典型的用户只会在你的app花费几分钟时间。过长的启动时间会招致失望。

　　你的app有两种被启动的情况：

冷启动：你的 app 的进程没有在运行，它现在被操作系统启动。
热启动：你的 app 被最小化而没有杀死。它是从后台恢复的。

　　本章节主要讨论冷启动，因为这是更加资源密集的操作。

　　下图是一个 iOS app 的启动时序。

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

　　1. 测量启动花费的总时间

　　我们应当测量从 main() 的开头到 applicationDidBecomeActive: 末尾之间花费的时间。

　　Objective-C
　　int main(int argc, char * argv[]) {
　　    // Save the initial time for startup
　　    [[StartipTimeMonitor sharedMonitor]   appWillStartLoading];
　　    @autoreleasepool {
　　        return UIApplicationMain(argc, argv,   nil, NSStringFromClass([AppDelegate class]));
　　    }
　　}

　　Objective-C
　　- (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 在真实世界不是孤立存在的。