In the last couple of months, we’ve been describing a handful of common issues that slow down your Android app based on our analysisusing NimbleDroid. We conclude this series of posts by summarizing the issues here.

Java reflection. Reflection is, of course, an extremely useful aspect of Java and Android development. Yet it turns out that reflection, when used inappropriately, is very 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 Androidhere.

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 Androidhere.

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 methodshere.

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 slowhere.

Performance problems in libraries and SDKs . We found that many third-party libraries or SDKs suffer from performance problems. This isn’t that surprising, as third-party code is still code, liable to most of the pitfalls described above. However, debugging performance problems in third-party code isn’t fun. To help debugging, we’ve compiled a list of libraries and SDKs to help Android developers avoid problematic libraries and SDKs. Check out the listhere.