Fixing the "Fixing the First Impression"

Having more information on Android development published is generally a good thing, particularly when it comes to performance. Therefore today’s post from the Amazon team, First Impressions Count: Boost Your App’s Start-Up Time, should be a good thing.

And, indeed, the information conveyed in the post is good. However, it is going to lead developers to waste their time, and their users’ time, because of the manner in which that information is conveyed. Having the right information in the wrong order can drag down otherwise solid writing.

Rule #1: Measure Twice, Cut Once

The premise of the Amazon post is to help apps start quickly. Since a do-nothing app starts as quickly as possible, it stands to reason that apps that do not start quickly has to do with our code. Hence, if your app does not start quickly, you need to find out why.

Two of the more common solutions for this, Traceview and StrictMode are indeed covered in the Amazon post, but not until the very end.

In technical writing, do not “bury the lede” (to borrow a phrase from journalism). Developers, like anyone else, have a chance of abandoning reading before the end is reached. Put high-priority items first in article-length pieces, and there should be nothing higher priority than actually figuring out where your problem lies. Only once you know what you should fix should you figure out how to fix it.

Rule #2: Size Matters

The Amazon post offers many techniques for actually improving launch times, from using background threads to lazy-inflating views. Everything they list is good.

However, not all performance tweaks are created equal.

Some of the ones cited in the Amazon post fall in the area of micro-optimizations, such as “use static methods”. These can have benefits, but only if the affected code is run a zillion times (note: zillion here is shorthand for “some sufficiently large number to make the micro-optimization add up to a user-visible amount of time”).

Unfortunately, micro-optimizations like this and “minimize allocations” are lumped in with macro-optimizations like background threads in Amazon’s blog post.

When discussing performance improvement, try to point out which items are macro-optimizations and which are micro-optimizations. Macro-optimizations (e.g., move I/O to background threads) should be considered anywhere; micro-optimizations should only be considered for code that Traceview (or other diagnostic measures) have indicated are “hot spots” in your code.

Rule #3: Really Try to Fix Things, Before You Fake It

The technique the Amazon piece leads off with is to add a splash screen.

Having splash screens in an app has been decried by:

• Cyril Mottier
• Juhani Lehtimaki (in his book, Smashing Android UI)
• Reto Meier

and many others.

I too dislike splash screens, because they are too often used for purely branding purposes or as a crutch for developers.

Even if you are not opposed to splash screens on UX grounds, having a splash screen makes a slow-launching app even slower. After all, it’s not like splash screens are powered by tachyons and launch in negative time. Hence, in actual terms, a splash screen makes things worse.

Amazon’s contention, echoed by others, is that a splash screen gives the illusion of responsiveness to a less-responsive app. And this may be true, though I would argue that there could be something more useful that could be displayed initially than a splash screen.

But my primary concern is that Amazon presents this option first.

A splash screen to help hide launch time issues is like wearing stripes for the “slimming effect”: possibly useful, but as a last resort (compared to, say, actually losing weight). Non-solutions like splash screens may be worthy of discussion, but only when couched as being a “last resort” technique, and then probably at the end of the post to emphasize the point.

Now, I am sure that I have broken my own rules in any number of places, and I wil be happy to fix them as I encounter them. It is always easier to critique the work of others, and I do not mean my analysis here to indicate that I am free from blame or that Amazon’s post is useless. On the contrary, Amazon’s highlighting of these points is generally a good thing, but the organization of topics in their post unfortunately hinders what otherwise is a fine piece.

Sometimes, packaging does make the product.