Don’t Believe These Big Fat Lies About Performance Tuning
Last year, the Google Developer Relations and VetNet teams organized a free five-day crash course where military veterans and their spouses, with little to no coding experience, learned how to build Android apps. That’s right, the students in this class had never programmed before.
They wrote their apps mostly in XML, with a little bit of Java code to tie it all together. It’s pretty amazing what they came up with: good-looking and useful apps. In the image below you can see that their apps generally display a bunch of information and several images, and if you click a button or image, you will be led to a website with more detailed information.
The class was moving along happily, and then, before we knew it, our first student ran into … a blatantly visible performance problem. On the third day, the author of the Awesome Day app called for teaching assistant help, because their series of images was jittering and stuttering across the screen as they scrolled through them.
Solving this student’s problem uncovered four widely held beliefs about performance tuning that are simply not true. Let’s take a look.
Big Fat Lie #1: Performance Tuning is Only for Pros
As our story illustrates, performance problems can show up at every level of experience. Even when you are writing your very first app.
Because, as a beginner, hobbyist, amateur, or occasional developer, chances are you have not developed the algorithm, pattern, and coding fluency of a person who writes code from 10 a.m. to 11:59 p.m., which means, chances are that you also do not yet have the habits of a performant code developer.
On the other hand, seasoned developers have habits, and not all of them are good. And changing bad habits is a lot harder than learning the right ones from the start. So, new developers have the advantage here to do it right from the get-go.
Now, the KINDS of performance problems that beginners will run into are likely going to be very different from the ones encountered by the pros…which takes us to the second lie.
Big Fat Lie #2: Performance Tuning is Only for Big Complex Apps
Every single app has a huge potential for utterly dismal performance.
Now, you might think your app is too simple and small to have to worry about performance. However, a small app that, for example, stores all data locally and uses many views to display it, may be less performant than a huge app that is forced to use more advanced techniques.
What’s in your favor is that small apps are likely to have GLARING issues that you can track down quickly, and fix easily with a known-to-be-good code change. In big complex apps, the pros avoided those issues in the first place, and instead, there may be a dozen small issues that cumulatively add three milliseconds to the rendering of each frame. Sifting through a million lines of code and debugging logs, and sniffing out that one loop where you need to factor out a calculation, requires knowledge and experience.
To make my point, the Awesome Day app included a scrollable list of clickable images. The student called me over because their app was incredibly slow in scrolling. And they didn’t know what to do about it. After all, they had followed the instructions for the course and in the official documentation. The total code for this app is under 200 lines written by the developer. It is not just small, it’s tiny. So, this should be easy to fix…which takes us to the third lie.
Big Fat Lie #3: Performance Tuning is Hard
Well, it turns out that Awesome Day used the original, huge images squished onto the available screen estate.
This was an easy problem to find by guessing at a common beginner problem and then looking at the resources, no tools required. And it was an easy problem to explain to a brand new developer. And finally, it was a really easy problem to apply a proof-of-concept fix. The solution didn’t require fancy anythings, just downsizing the images to be closer to the screen size of their device.
Other rendering issues that are easy to find and fix, and that you can habitually pay attention to: only draw what you see, keep your view hierarchy from exploding, and move everything not directly related to showing stuff to the user away from the UI thread.
But it’s not always this obvious to see the effect and identify a direct and fixable cause. After the fix, Awesome Day was only marginally faster … which takes us to our fourth and final lie.
Big Fat Lie #4: Performance Tuning is Easy
The Awesome Day app illustrates beautifully, how performance tuning is an iterative process. You find and fix what is clearly a problem, just to uncover another, perhaps more important issue that was overshadowed.
With Awesome Day being so tiny, the answer had to be in the XML, which consisted of a ScrollView containing multiple TextViews with the images as backgrounds. Even for an app this small, this caused problems.
As an illustration, I wrote a test app and packed six TextViews with representative 44K background images into a ScrollView, and the app promptly complied by crashing on load. The logs tell the story using words such as “Throwing OutOfMemoryError”, but this Memory Monitor Tool graph tells all.
Replacing the ScrollView with a ListView finally solved the problem.
It also meant that the student had to learn about ListView and adapters, which was quite a steep hill to climb. Fortunately, this is what teaching assistants and friends are for … and stackoverflow, where every coding question in the world is answered.
So, fixing some problems is easy, and fixing others will make you a better developer, because they are an opportunity to learn about new, better ways of implementing your dream app.
So, there you have it.
The Truth is Out There
#perfmatters
Check out Supporting Multiple Screens to learn more about choosing image sizes for multiple screens. To raise your Android development skills to the next level, check out the Android Performance Course on Udacity and Android Performance Patterns on YouTube. But most importantly, join our Android Performance G+ Community for great tips about, you guessed it, building performant Android apps.
