What do you do when your PhoneGap app is running slow and you don’t know why?
It’s a problem that faces every mobile developer—your application has slowed down and is eventually brought to its knees.
But why? You’ve kept in mind all of the basic principles in creating a better PhoneGap app, but you’re still not getting the user experience you want. You think to yourself that your application is not that complicated. Surely if games like Infinity Blade III can run smooth as butter, then there’s no reason why your simple sliding animation can’t run just as well.
So what do you do? Start poking and prodding and guessing and checking? Maybe.
But before you start with that, let’s get out some of our tools and measure our application.
Measuring is an important principle—it’s one that I’ll be covering in my upcoming talk at DevLearn about Developing Better PhoneGap Applications.
A huge part of building a successful application is measuring where you’re currently at. This seems obvious when it comes to usage analytics, but it’s just as important when focusing on user experience.
There are a number of tools available to us to assist in measuring our application and highlighting problems.
Measuring CPU Usage
The time the CPU spends tending to your application is time that it cannot spend listening to the user.
As of Xcode 5, Apple has provided a really useful set of debugging tools that give us an overview of the current usage of system resources, including CPU usage. Since these are available anytime you debug on the device, it would be a good practice to get into the habit of simply monitoring these meters each time you debug on the device (which should be frequently).
These are high-level overviews of what’s going on. They are intended to give quick indications of new problems that may have risen during development. Let’s say after implementing a new feature, you notice a pattern like the following:
Over time, the CPU usage of the application continues to rise and remains consumed even when the application should just be waiting for user interaction. This alone doesn’t tell us anything beyond that the CPU is busy when we expected it to be idle. Off hand, we know that a burdened CPU could be the result of a few things:
Perhaps the rendering engine is having to do a lot of calculation and layout work (“reflow”) or painting when it doesn’t need to be.
Using Safari’s Remote Web Inspector
Safari has a remote Web inspector that can attach to a WebKit process running on a connected iOS device and give us valuable insight into what’s going on beneath the hood. This requires a little bit of setup get started.
Note: If your device isn’t appearing in the Develop menu, try quitting and relaunching Safari.
Typically, you should see a pattern that follows something like this:
As the user interacts with your application (events shown in yellow), it will likely require the interface to respond in someway, triggering new layout and rendering events (shown in purple). The table below the timeline shows what layout work is actually being down by the browser. The large white spaces indicate time that the Web view sat idle waiting for user interaction.
But let’s say you see a pattern that resembles something like this:
After some user interaction, your application continues to do a lot of layout and rendering work, even 10 seconds after the user has finished interacting with the application.
Depending on your application, this may be expected (perhaps it’s running through an animation sequence).
Maybe it comes as a surprise to you. If you’re in a state in your application where you expect it to be sitting idle and you see a pattern like this, then you know that something is up. Perhaps you already have an idea as to what’s going on. In which case, great! Now you’ve isolated the issue to unneeded layout and rendering work and can begin making changes in your code, all the while remeasuring to test your hypothesis.
You might still be unsure as to exactly what section of code is misbehaving. So let’s cover one last tool.
However, you still can get really useful information running the app in Safari on your computer (think of your computer as the “best case scenario”—if a problem shows up there, then it will definitely show up on the device).
You should focus on just one problem at a time. Run a number of actions that lead up to the problem.
You’ll want to start by focusing on the items with the highest amount of time, and especially be keeping an eye out for your own code to show up.
If you’re using a JS library (like jQuery or Zepto), you’ll likely see it appear a number of times, and often near the top. This is not (necessarily) because it’s running slowly, but because your code is probably making a number of calls to that library. Focus on your own code for now.
The “Self” column indicates the amount of time actually spent within the function. The total time indicates the amount of time spent evaluating the entire function, including calls it made to other functions.
As you dig down, you may start to find lines of your code that are taking up a lot of total time—functions that perhaps you did not expect to be so time-consuming.
And here is where we begin debugging our application. What changes if we skip calls to this function entirely? What specific pieces of this function are taking the most time, and how can we mitigate that?
You can even set breakpoints to stop execution within a given function to get an in-depth view of the execution path at that point. In fact, these breakpoints even work during remote debugging on the actual device.
Bringing it All Together
In all of this, we’re striving for the best user experience possible. The work we’re doing here is no different than the development and debugging process of a native application (and why should it be?). The goal is measuring is to save time spent guessing and checking so we can more precisely pinpoint problems when they exist.
Again, measuring is only one of many important steps in developing a better PhoneGap application.
If you’re interested in getting an overview of the others, be sure to check out my session at DevLearn, Friday morning at 8:30 a.m. Hope to see you there!
Latest posts by Daniel Pfeiffer (see all)
- A More Mobile-Friendly Captivate HTML Template - October 21, 2013
- 3 Tools To Help You Optimize Your PhoneGap App’s Performance - October 15, 2013
- Tin Can iOS Library Compatible With Version 1.0 - May 2, 2013