Sponsored Tutorial: Improving Your App’s Performance with Pulse.io

Verifying Your Improvements

Here's a look at some sample data collected after making the code improvements and playing with the app for a bit:

The dashboard shows that the results above arrived a few hours after the first batch of results. Step One in any performance improvement process is to be sure you're looking at the right data! :]

At first glance things look like they might have improved, but you can't really tell until you dig down into the nitty gritty details.

Verifying Network and Memory

Take a close look at the number of network requests made now that you've reduced the excessive image loading:

That's a step in the right direction — you used the app for roughly the same amount of time and in approximately the same way that you did before, but the app made less than half of the network requests than before.

Drill down into Aggregate URL Response Times again and examine the queries made to flickr.com/* - are those URLs still exposing too much information?

All URLs logged now have the query part of the request stripped thanks to setURLStrippingEnabled:. You could easily share these results without exposing any details of your web API or compromising other secrets. And even if you didn't have any secrets to hide, at least URLs in this format are a heck of a lot easier to read! :]

Verifying Spinners

Spinners were particularly worrying — no user wants to waste five seconds of their life staring at a spinner. What does Pulse.io say about the end result of your spinner improvements?

The total spinner time is now 14 seconds, and average spinner time has dropped somewhat but not as dramatically as you might first think. Does that mean your improvements had no effect on average spinner time? How should you interpret these results?

You made two huge reductions to spinner time in the code: first, the new version of the app is making requests for thumbnail (small) images at about the same rate as the first version, but deferring the fetch of the large images to when the user taps on the thumbnail.

Second, you switched the route calculation to a much more sensible next-closest algorithm and only perform it once per set of points.

So the cost of bringing up a spinner and performing an operation has dropped, on average, as you're requesting smaller pieces of data, but the total number of spinners displayed has dropped dramatically as you're making far fewer image requests.

What was that previous result again?

Yep - that's a huge improvement; the app is now much more usable.

Although you've achieved some success with your spinner time, you really should aim to avoid any spinner time at all.

One possible way to cut down on spinner use in your app is to make the initial image request to Flickr and display the points on the map immediately. The route calculation would be performed in the background and leave the UI thread responsive so the user can interact with the map. You would then display the calculated route once the algorithm was done.

This would be a great change to attempt on your own to see the effect it has on spinner use. If you do choose to try this, please share your before and after performance results in the forum discussion below!

All that's left to check on is the frame rate issue that you solved by re-using annotations. What did Pulse.io detect as your improved frame rate?

Verifying Frame Rate

The small change you made to reuse annotation views has resulted in some performance gains, as shown below:

The recorded low frame rate time descending from Providing Annotation Views has dropped to around four seconds. That's not a bad improvement in the context of this tutorial, but you should be shooting for no recorded instances at all. On modern hardware, with some code tweaks appropriate to your app, this goal is well within your reach.

Where To Go From Here?

Here's the final version of the sample project that implements the changes discussed in this tutorial. If you use this version of the project, remember to set your own Pulse.io key, Flickr key and secret!

By adding Pulse.io reporting to this sample app, you've learned how an app that seems to work well enough on your simulator and test devices can fail to impress your users; in fact, it can lead to a really poor user experience. With Pulse.io in your toolbox, you can gather information about user experience issues on many fronts:

• Excessive memory usage
• Spinner time
• Low frame rates
• Network issues

It's incredibly important to gather metrics and identify fixes for you app before you start seeing these issues mentioned in the reviews of your app. Additionally, you won't waste time improving areas that, in actual fact, aren't causing any problems for your users.

Pulse.io is undergoing rapid development and improvement. While there's an impressive level of detail in the product already, the team is anything but idle. The Pulse.io team recently introduced the Weekly Performance Report as shown below:

This shows you the changes in app usage from week to week. There isn't much data here with just one user (i.e. the author) and an app still in the development stage, but you can see how useful this would be when your users number in the thousands.

Support for Swift is on the horizon, so keep an eye out for updated versions of the Pulse.io SDK and instructions on integrating Pulse.io into your Swift projects soon.

Have you used Pulse.io in your own apps and found any interesting performance issues or tuning tips? Share your experiences with us in the comments below!