Performance Issues with Android Mobile Apps

In this post, we are not concerned so much with how fast mobile apps respond. Rather we are going to write about how they can run down the battery, exhaust the memory on the mobile device, or just crash.

Cell phones and tablets does not have a long battery life—if someone could solve that problem, we would all be driving around in electric cars, with Google at the wheel. Short battery life is especially a problem for cell phones whose battery is smaller than the tablet. That is why you see so many people at the airport looking for a place to charge their phone or hanging around one of those charging facilities where different companies advertise their brand.

A mobile device app needs to be properly written, so that it does not use up the limited memory on the phone or run down the battery too fast.

An Android cell phone app has different stages in its life cycle.
• Create
• Started
• Resumed (running)
• Paused (still running but not in the foreground)
• Stopped (not visible at all)
• Destroyed

The programmer needs to know how to stop threads running in the background, destroy variables or save data, and the appropriate time to take each action. For example, when the app has lost focus (meaning it is no longer at the front of the screen) it has switched to the stopped status. This would be a good time to destroy the reference to the camera for an app that lets you upload images. The app would only do that by itself if the user had it open and then exited it with the back arrow, meaning it is destroyed.
Google Maps does a good job at this. When you flip to another screen, Maps turns off the GPS receiver, which consumes a lot of power.
You can see for yourself how limited is a mobile device with regards to memory and battery under settings/apps.
This screen below shows what processes are consuming the most battery in descending order. The screen is oblivious using the most.

Android-1-315x288

The next screen shows running background processes and how much memory they consume. You can see that my phone has only 286 MB free, which is not a lot, and I am not even running any applications. It shows I have only about 700 MB total. (This is strange, since this Nexus 4 was sold to me by BestBuy as having 1 GB RAM). It also shows that WhatsApp is always churning away, talking to the WhatsApp servers to check for new messages, taking up 8MB.

Android-2-317x288

When a business mobile app is paused, it should write updates to the cloud (Rarely does a mobile business app use local storage, except when working with a draft document.). It should also release handles to devices like Bluetooth and the NFC radio and broadcast receivers and the SQLite onboard database, if you are using that. (A broadcast receiver listens for message from other applications and the system. For example, one broadcast is that the battery is no longer running low, because the user has plugged in the charger.)

One writing apps for the mobile phone needs to keep memory usage in mind, as they are not free to consume lots of heap as they would be for an Java app running on giant application server. For example, you should probably not retrieve 100 customer records and keep them all in some kind of array. As with any app server, whenever the memory is low, the phone is going to do a garbage collection to purge from memory variables that have gone out of scope. Just like an app server this will cause the app to momentarily stop unlike the garbage collection is done. The user will notice that. (You can monitor Garbage Collection by installing the OS Monitor app from the Google Play Market.)

There are ways to write code to conserve memory and battery, documented by the Android project here.
One thing to know about Android is the device in nothing more than a Java application server, albeit it runs its own version of the Java virtual machine. Google calls it called Dalvik. Its compiler is designed to use less resources than a normal JVM. It also has something called a just-in-time (JIT) compiler, which means it compiles code to take advantage of some of the optimization built into the OS.

Mobile apps often crash: even Chrome, Twitter, and Netflix. Early versions of Firefox on Android crashed a lot too. When an app is down, by definition that is a performance hit. If the world’s best programmer’s working at Twitter and Google write apps that crash, then your world-class programmers too are going to have difficulties keeping your system working all the time too. One metric of monitoring an app is how often it is down. The Google Play Developer Console lets you access crash reports. That will give you some information about the state of your application when it went down, hopefully giving you enough information on to change the code to fix that, plus when it crashes the user has the chance to provide feedback. Google also have a private market and developer console for non-public apps that are for you and your customers only.

Beyond limited resources, another complicating factor with mobile apps is the need to keep track of what version of the OS the user is using. Corporate web sites might say they only support Internet Explorer and leave it at that. But if you use Android version 4 features on an Android version 3 device, they your program is going to crash, unless you either program an alternative or download the library onto the phone needed to support that. If the phone is too old, you cannot even download the library to plug the gap in available features.

These are just some of the issues to consider when trying to monitor your mobile apps and keep them running.