通过移动监控提高应用程序性能[视频]

New Relic University刚刚发布了一个New Relic的移动该视频教程将引导您解决一些常见的应用程序性能问题。本教程重点介绍如何使用交互指示板、交互跟踪、崩溃报告和HTTP请求指示板来找出性能问题的根本原因。

你在教程中看到的数据来自New Relic Mobile team的测试应用，它被亲切地称为“世界上最糟糕的应用”。这个应用程序有几个常见的性能问题故意内置到它，以帮助您了解如何可以使用New Relic移动监控和诊断问题，以提高应用程序的性能。

观看下面的完整教程:

识别问题

乍一看这个应用程序的数据，很容易看出性能方面的问题。请注意执行时间图、崩溃率图和HTTP响应时间图。

这三个图表是最重要的，位于顶部的中心，因此您可以快速查看所需的性能数据。执行时间图表转到交互指示板，崩溃率图表转到崩溃指示板，HTTP响应时间图表转到HTTP请求指示板。

该仪表板的其余部分显示了额外的有用信息，但移动监控产品的核心是交互和崩溃仪表板，这是我们在本教程中花费大部分时间的地方。

熟悉交互指示板

首先，我们来看一下交互指示板。当你滚动到顶部互动平均时间，你会看到MDScrollListVC大约需要7.5秒——对于您的用户来说，这个响应时间会慢得令人沮丧。

当我们打开这个交互时，很明显UI线程或主线程上有一些大而耗时的东西可能不应该出现在那里。注意到wordlist.items在主线程上，响应时间超过6.5秒。用户等待应用的UI加载和运行有整整6秒。这看起来像是工作线程或后台线程上的东西。

从这里开始，我们打开了一个耗时超过7秒的交互跟踪，揭示了一些有趣的数据。

你可以在顶部一行看到，随着时间的推移，内存使用量在显著增长，因为它在主线程上一个接一个地调用整个字符串的方法。所以每次MDScrollListVC方法被调用时，它会阻止UI正确加载，使应用程序无响应，并创建总体糟糕的用户体验。

查看事故

接下来，我们将查看来自崩溃指示板的崩溃摘要报告。在顶部，我们可以看到这种崩溃已经发生了两次，影响了两个独特的用户。下面是关于设备和操作系统版本的信息，用户是在崩溃发生时。

崩溃图表在这里并不有趣，因为我们很少出现崩溃，但在流量较高的应用中，我们可以使用这张图表来查看崩溃次数或发生的天数和时间是否有明显的规律。

图表下面是导航按钮，您可以单击这些崩溃，从而查看交互轨迹和其他详细信息。

这个交互轨迹很有趣，因为它允许您看到用户到达崩溃的确切流程，这在您需要复制他们的步骤时很有帮助。可能存在一个复杂的流程，否则您无法复制，您从用户那里获得的崩溃报告只是一个堆栈跟踪，它不会告诉您用户事先做了什么导致了崩溃。

在流程不规范的情况下尤其如此，用户可能在应用中做一些你不希望他们做的事情。如果您需要在交互跟踪中找到正确的点，并查看特定的交互跟踪以查看控制器或代码中是否存在意外或错误，那么这也会很有帮助。

找到问题的根源

在交互跟踪的下面是异常的详细信息:名称不可能的例外,类和方法的名称MDPremiseVC.m和MDPremiseVC handleAction3,时间和信息“假装没有意义!”

下面是带有缺陷线程的堆栈跟踪。你会马上注意到有一行用红色突出显示;这就是代码中的缺陷被检测到的地方。它甚至告诉我们缺陷在哪一行代码中:第64行。

最后，我们在HTTP请求指示板上查看这个应用程序中的最后一个问题。

如果我们怀疑图像的大小是一个问题，我们可以使用列表来通过传输大小显示端点。果然，我们发现了这个地点insidefandb.com(用图表中的紫色线表示)不仅花费了大量的时间，而且在数据传输大小列表中排名第二。

通过查看平均数据传输图表insidefandb.com我们可以看到它传输了5.79兆字节，这是相当大的，特别是考虑到应用程序只显示缩略图。

很明显，这个应用程序可以通过请求更小的图像轻松地从所有端点恢复相当大的性能速度。

你准备好在自己的手机应用程序上尝试这个过程了吗?观看上面完整的New Relic大学教程，你可以学习如何用New Relic Mobile解决应用程序的性能问题。

想了解更多关于New Relic培训的信息，请访问New Relic的大学页面，您可以找到即将到来的网络研讨会列表，并可以查看按需培训视频。