[This article was written by Erica Lauer Vose]

New Relic University just posted a New Relic Mobile video tutorial that will walk you through how to troubleshoot a few common application performance problems. The tutorial focuses on using the interactions dashboard, interaction traces, crash reports, and the HTTP requests dashboard to get at the underlying cause of performance problems.

The data you see in the tutorial comes from the New Relic Mobile team’s test app, affectionately nicknamed “The Worst App in the World.” This app has several common performance problems intentionally built into it to help you learn how you can use New Relic Mobile to monitor and diagnose problems to improve application performance.

Watch the full tutorial below:

Identifying the problem

At first glance at the data from this app, it’s easy to see that something is going on with performance. Notice the execution time chart, the crash rate chart, and the HTTP response time chart.

These three charts are the most important and are centered at the top so you can quickly see the performance data you need. The execution time chart goes to the interactions dashboard, the crash rate chart goes to the crash dashboard, and the HTTP response time chart goes to the HTTP requests dashboard.

click to enlarge

The rest of this dashboard displays additional helpful information, but the heart of the mobile monitoring product is the interactions and crashes dashboards, which is where we spend most of our time in this tutorial.

Getting familiar with the interactions dashboard

To begin, we look at the interactions dashboard. When you scroll over the top interactions by average time, you will see that MDScrollListVC is taking almost 7.5 seconds—a response time that would be frustratingly slow for your users.

click to enlarge

When we open this interaction, it becomes clear that there’s something big and time consuming on the UI Thread or Main Thread that probably shouldn’t be there. Notice the wordlist.items on the main thread, with a response time of over 6.5 seconds. That’s a whole 6 seconds users are waiting for the app’s UI to load and function. This looks like something that really should be on the worker thread or some kind of background thread.

click to enlarge

From here, we open an interaction trace that took over 7 seconds, which reveals some interesting data.

click to enlarge

You can see in the top row that memory usage is growing considerably over time as it’s calling a whole string of methods one after the other on the main thread. So every time the MDScrollListVC method gets called, it prevents the UI from loading properly, makes the app unresponsive, and creates an overall poor user experience.

Checking out crashes

Next, we look at a crash summary report from the crashes dashboard. At the top we can see this crash has happened two times and affected two unique users. Below this is information about the devices and OS version the users were on when the crashes occurred.

The crashes chart isn’t as interesting here because we have so few crashes, but in an app with higher traffic we might use this chart to see if there are noticeable patterns in the number of crashes or the days and times when they occurred.

click to enlarge

Below the chart are navigation buttons that let you click through each of these crashes, so you can view the interaction trail and other details.

This interaction trail is interesting because it allows you to see the exact flow the user went through to get to this crash, which is helpful when you need to duplicate their steps. There may be a complex flow you can’t reproduce otherwise, and the crash report you get from the user is just a stack trace that doesn’t tell you what the user did beforehand to cause a crash.

This is especially true in cases where the flow is nonstandard, and users are possibly doing something in the app you don’t necessarily want them to be able to do. This can also be helpful in cases where you need to find the right point in the interaction trail and look at a specific interaction trace to see if there might be something unexpected or wrong in the controller or in the code.

Getting to the source of the problem

Below the Interaction trail are the exception details: the name Impossible Exception, the class and method names MDPremiseVC.m and MDPremiseVC handleAction3, the time, and the message “no sense in pretending!”

Below this is the stack trace with the thread that had the flaw in it. You’ll notice right away that one row is highlighted in red; this is where the flaw in the code was detected. It’s even telling us what line of code the flaw is in: line 64.

click to enlarge

Finally, we look at one final problem in this app on the HTTP requests dashboard.

click to enlarge

If we suspect the size of the images is an issue, we can resort the list to show endpoints by transfer size. And, sure enough, we discover that the siteinsidefandb.com (indicated by the purple line in the chart) is not only taking an enormous amount of time, but it is also second in the list for data transfer size.

click to enlarge

By looking at the average data transfer chart for insidefandb.com we can see that it’s transferring 5.79 megabytes, which is quite large, especially considering the app is only displaying thumbnails.

click to enlarge

It seems clear here that this app could easily recover quite a lot of performance speed from all endpoints by requesting much smaller images.

Are you ready to give this process a try on your own mobile app? Watch the full New Relic University tutorial above and you can learn how to troubleshoot your app’s performance problems with New Relic Mobile.