Guest Post: Slow mobile app = Millions in lost sales [Part 2]

Part 2 Causes and Remedies

In part one of this two-part post about on new HeadSpin’s App Speed Survey, we took a closer look at how we did the testing and at the detailed results.

In part two, we’ll look at common causes of sales-killing slowness in Android apps, and what you can do to avoid getting Grinched all year long.

FIVE CAUSES OF SLOWNESS

1) Java reflection

Reflection is, of course, an extremely useful aspect of Java and Android development. Yet it turns out that reflection, when used inappropriately, can often be the source of huge overhead within an Android application. For instance, if you use Gson to (un)serialize a lot of data, the reflective type adapters can significantly slow down your app. Use custom type adapters instead. Our recommendation here is to understand what you’re getting into when using reflection (or libraries that use reflection). Learn more about reflection overhead in Android here.

2) Dependency injection

Dependency injection reduces the amount you have to code (and hence, debug). This is great – dependency injection facilitates the production of better apps and leads to a smoother development process. However, it’s important to keep in mind the potential toll that dependency injections can have on your application’s performance. For instance, if you use Roboguice for dependency injections, your app could be significantly slower (up to 2000ms slower) than if you had chosen Dagger 1 (or, even better, Dagger 2). Besides higher performance overhead, Roboguice also contains 10K more methods than Dagger 1 or 2. Learn more about some best practices for dependency injection in Android here.

3) Hung methods in main thread

Hung methods are function calls that delay the main (UI) thread by over 32ms and cause temporal lags that users can detect. Hung methods can make your app appear choppy, detracting from the quality and professionalism associated with your brand. While Android’s StrictMode helps detect some hung methods, it won’t catch everything – there are many ways to hang your app’s main thread, and it’s important that you look out for all of them. Learn more about hung methods here.

4) ClassLoader.getResourceAsStream

ClassLoader.getResourceAsStream() is a nightmare for a plethora of apps, SDKs, and libraries. Essentially, the first time this method is called, Android unzips the APK file twice and verifies that the APK is properly signed. This call is thus extremely slow, and the slowdown is proportional to the size of the APK. It’s easy to see a one to two second delay for a 20MB APK. Learn about why ClassLoader.getResource is so slow here.

5) Performance problems in libraries and SDKs

ClassLoader.getResourceAsStream() is a nightmare for a plethora of apps, SDKs, and libraries. Essentially, the first time this method is called, Android unzips the APK file twice and verifies that the APK is properly signed. This call is thus extremely slow, and the slowdown is proportional to the size of the APK. It’s easy to see a one to two second delay for a 20MB APK. Learn about why ClassLoader.getResource is so slow here.

THREE REMEDIES

What can companies do to get around the business-choking traps described above? Here are three remedies we recommend.

1) Continuously monitor, diagnose, and fix for every build

In their haste to keep getting code out the door, companies often ignore performance monitoring. That’s a mistake. Many apps loose speed slowly and silently. If you don’t monitor constantly, you’re not going to notice if an app slows down by, say five percent. Then another five percent. Suddenly, it’s super-sluggish, even broken. Now you’ve got accumulated issues, which won’t be easy to fix.

Think about it this way: You can brush your teeth twice a day. Or you can wait until serious problems develop and you have to see a dentist.

Unfortunately, getting accurate apps performance measurements requires specialized expertise that even large, well-staffed companies lack. As a result, home-brewed measurement infrastructures are notoriously flaky, hard to manage, and typically only provide around 20% of needed functionality.

Many companies conclude sooner or later that giving the job to a company like HeadSpin (or actually HeadSpin) lets them concentrate on core competencies, and just makes more sense.

2) Know and avoid common pitfalls in your code

In their haste to keep getting code out the door, companies often ignore performance monitoring. That’s a mistake. Many apps loose speed slowly and silently. If you don’t monitor constantly, you’re not going to notice if an app slows down by, say five percent. Then another five percent. Suddenly, it’s super-sluggish, even broken. Now you’ve got accumulated issues, which won’t be easy to fix.

Think about it this way: You can brush your teeth twice a day. Or you can wait until serious problems develop and you have to see a dentist.

Unfortunately, getting accurate apps performance measurements requires specialized expertise that even large, well-staffed companies lack. As a result, home-brewed measurement infrastructures are notoriously flaky, hard to manage, and typically only provide around 20% of needed functionality.

Many companies conclude sooner or later that giving the job to a company like HeadSpin (or actually HeadSpin) lets them concentrate on core competencies, and just makes more sense.

3) Test geographically

In many parts of the world – especially Latin America, parts of Asia and Southeast Asia even China – real-life network conditions are complex and not fast. In these regions, and elsewhere, slow networks slow your apps (which will be blamed by users). An app that runs fine in the U.S. can easily encounter problems when it tries to speak to a server on a relatively slower network in Brazil, India and in many other places.

Other localization issues can also bite you in the app. Open-source Android invites creative customization by OEMs. Other apps on “foreign” phones may waste battery or CPU, to your unknowing detriment. Many phones sold in the U.S. have different resolutions than those used abroad. Network carriers themselves have a host of issues. While companies like Akamai can help ease problems by creating a copy of images, you may need more help.

If you’re doing business globally, you need to think about and know what’s really going on out there. That means testing in different geographies to understand the how local users experience your app. Do you need to customize code for local conditions? Create an automatic default to a lighter-weight, lower res version? These issues will only become more pressing with the global arrival of 5G and more complex AR/VR apps. The time to expand your testing and monitoring horizons is now.

Got a comment, suggestion or tweak to our Ecommerce Speed Test Study? We’d love to hear from you. Twitter:@HeadSpin_io