Android and Mobile Optimization Concepts
Android and Mobile Optimization Concepts
Before you start developing your mobile app comes the planning stage. These tips will help you organize and strategize to optimize your app's performance.
Join the DZone community and get the full member experience.Join For Free
There is a difference between learning how to make a mobile app, and how you create one from scratch. It is always the case in development that there are many opinions of how to do something the "right" way. In this article, I am going to discuss what I believe are some of the best practices to create a highly optimized Android application.
1. Less is More
Before you begin, the simple concept that less is more should always be applied. Do you need to support Android 2.3 when Android 4.1 reaches 97% of all Android users? Will you actually need the advanced scene animation framework provided by the compatibility library? Do you really need libraries to handle dependency injection for you?
Every library that you add increases the resulting size of your application, how fast it can load into a device's memory, and brings you closer to the Android DEX method limit. It's much better to start your application with the absolute minimum of libraries and dependencies, and only add what you need. Even libraries like the AppCompat library which brings features from the new versions of Android to older versions can always be added later if needed. Very often, though, you'll find that the vast majority of features that you need are already present or that you only need a very specific part of AppCompat.
Besides making your app smaller and usually faster, not relying on too many external dependencies helps you keep your code simple and easy for other developers to understand. Know the tools you use inside-and-out, and you'll benefit from that as well.
2. Design With Less
Optimizing an app can be done in the design as well as the implementation. Before you begin to program your application, map out the design and determine what design components you will need. Reusing widgets, icons, layouts, and other design attributes throughout the application not only lends a more consistent feel to the application, but also helps reduce the amount of design resources you will need to include.
Beyond the number and size of resources, this is a good time to make design decisions that can reduce the number of libraries you need to add. For example, all versions of Android since Android 4 have solid support for the Action Bar. Android 5 introduced the Tool Bar. Using the Tool Bar will mean that you have to include AppCompat. If you are, however, needing a basic bar with shortcuts that can open an app drawer, it's likely that you do not need the Tool Bar, and the API provided by the Action Bar will suffice.
Similarly, look for opportunities to simplify design attributes that would require more complex resources. A complex gradient that can be replaced by a simpler one means you can use an Android XML drawable instead of an image. If you can replace similar icons with the same one, such as next/previous and menu icons, you can reuse the same resources in more places. Seek opportunities where an image filter can replace specialized designs for status indications and interactions.
3. Less Synchronous Loading
Mobile devices today pack processors with multiple cores. Android's application framework is well designed to use these cores. I've heard developers fear asynchronous code because it can be more difficult to understand when you are so used to procedural operations. That said, being able to make use of non-blocking operations is key to helping your mobile application feel fast and responsive.
As apps have gotten more complex, splash screens and loading transitions have become more common. Most, however, can be avoided. If a smaller API call will get basic data on-screen faster, use it and fill in the rest later. If you can load the layout that contains a list before you have the content that populates it, get the layout on-screen as fast as you can.
It may take some extra work to implement something asynchronously. You may need to fire an event when information is ready, or add smaller loading and progress indicators into the design, but it's worth it to get the presentation to the user as fast as possible, and without intermediate transitions.
4. Spend Less Time
One of the best tips I can give for optimization is actually to use tools, techniques, and designs that take less time to implement. Most of the time, if it's faster for you, the result is faster too.
Android's build system, for example, provides minification with ProGuard. Turn it on for development as well as for production. You can configure ProGuard so that it retains the information you need to debug while still making your application smaller. Using ProGuard in development means it takes less time to load on your device while you develop, and minimizes the differences between a development and production build.
Before spending hours on animation, decide which animations most impact the user experience. If it doesn't need to be animated, or if a simpler animation will suffice, the app will probably feel faster and smoother than if you take the extra time to create a more complex animation.
Before you add a whole new screen or specialized UI, discuss whether there is a part of your app that already exists that would make sense to house the feature. It's less for the user to learn, and less for you to develop.
5. Talk More
The only thing that doing more of will make your app better is discussion.
Before you code, make sure you know what the end result should be. Have an idea of how your classes will be structured. Know what your UI layout will be. Think through the interactions you will want to add in future versions.
The more you know before you begin, the better you will be able to optimize your code, using the tips outlined above. It will also mean that you will deliver something that more closely matches expectations. When you plan for consistency, the result will be a more optimized experience.
Opinions expressed by DZone contributors are their own.