Android Lollipop’s Memory Leak: What Does That Mean?
I’ve recently written about my Nexus 10 and how Android Lollipop has transformed how the device feels and works in use; it’s made a whole new device from it and improved it across the board. After the last few weeks, I have noticed one area that the Nexus 10 is less great with compared with running on Android 4.4 Kit Kat: over time between reboots, the device becomes noticeably less fluid. Sometimes, applications will close either once or multiple times. This is most obvious running Google Docs, when I’ll start to edit a relatively long document and it’ll close out on me. It’s something my wife‘s Nexus 5 suffers from and I have both good and bad news about this. The good news is that Google is aware of the problem and has already worked out the fix. But the bad news is that it’s because of memory leaks and requires an update to Android.
By a memory loss, this means that over time the amount of available memory to Android for running applications becomes less and less. But in order to explain the problem, we first need to consider how our Android devices work when it comes to applications, memory and processor time. And I’m going to throw something out there: Android, especially the later versions, is generally very efficient at managing processes and memory. When an application is launched, Android releases enough memory and allocates it to the application to allow it to run: applications generate temporary files and require “space to breathe.” This memory is allocated from the pool of memory available to applications, first from free memory but then if there isn’t enough, Android will start to close dormant or cached applications, saving their user data first. When the user has finished working with an application, if he or she closes it (typically by tapping the back soft key), the app will close. If the user jumps back to the home page, Android marks the application as available to be closed by the operating system and they’re put into a suspended state, ready to release memory for new, foreground applications.
Unfortunately, things are not quite so simple because many applications have parts that either continue to run or are marked as not to (immediately) close by the operating system. I’m going to call these application stubs. Google have a system called Google Cloud Messaging that encourages this behaviour, as the application stub can be much, much smaller than the full blown application but provides the user with a better experience. I’ll use the example of a Twitter client; the full user experience allows us to work with our Twitter stream and all that this entails. It requires 50 MB of memory The stub application will occasionally synchronize our contact data and report notifications of re-tweets, mentions and direct messages; this requires only 10 MB of memory.
Where does the memory leak come into this? Let’s continue with my Twitter client example above. I launch my Twitter client, use it and then go back to doing something else. Android will close out most of the client but leave the stub running, however the closing of the application is less than perfect. Perhaps after opening and closing the application a few times in a day, it requires 12 MB of memory. Perhaps after a week, it’s requiring 20 MB of memory when idle. This is Android isn’t cleaning up after itself (I’ll ignore that it might be a badly written application at this juncture). If this small memory leak is compounded over the similar applications I run, suddenly the idle device has allocated much more memory and this starts to cause problems when I launch an application, because then Android has to figure out what running applications to close and what stubs to shut down (they are reopened later). This takes time, which is what we see when our device lags. And because the amount of memory that an application needs changes, so we may find that doing something with an application (such as loading a document in Google Docs) causes the application to pause and then close.
I wrote above that our Android devices are very good at managing the resources available to them. Each application requires processor time and memory; the more applications that are running, the greater the requirements. Don’t fall into the trap of thinking that you want to keep as much free memory available to your device at all times because this isn’t advantageous to Android; some applications want to run constantly, but this is only a problem if they require lots of processor time.
I’m going to close this article off with a couple of screen images taken when writing the article on my Nexus 10 and show running and cached applications. As you can see, Google Docs requires a lot of memory and this is why the application can pause, stutter and lag when Android is trying to provide it with the necessary RAM. My Nexus 10 has not been rebooted for ten days and it’s started to misbehave. I’m optimistic that the next update the tablet receives will solve the problem.