Uncover Memory Leaks by Mobile Apps
Mobile apps can often crash for many reasons. Nothing is as excruciating as memory leaks. It starts with your app crashing often, or becoming slow or maybe making your entire phone slow down, taking longer time to load activities. Memory leaks are notoriously hard to detect, and thus can easily surprise you. Have we ever thought why most of the users uninstall the application after some use?
Which is why it is critical for Developers to understand the memory consumption by any mobile application. How do you detect memory leaks during Mobile Application Testing? And if so, how can you prevent them from hogging mobile resource consumption?
A little knack for Mobile Application Testing always comes handy.
Memory is critical to device
Memory is one of the key resources of the mobile device.And memory leaks in Android is an important thing to be kept in mind. Java is a garbage collecting language, which removes the need for developers to dig deep to manage allocated memory. This reduces the chances of any segmentation fault crashing an app or any unfreed memory allocation from eating up space of the heap area, thus creating a safer code.
However, a garbage collector is never an insurance against memory leaks. There are other ways by which memory can be leaked within Java. This means that your android mobile application is still pretty prone to wasting unnecessary memory allocation and crashing with out-of-memory (OOM) errors.
Why are Memory Leaks Bad?
Cause: Memory leaks occur when some variable of the application still has references to some objects that are unnecessary, no longer in use or used to be with the app anymore, is bloating the allocated memory heap and the Garbage Collector is not being able to release that memory.
Effect: Android devices mostly run on phones with limited memory, so as a result of too many leaks, the app runs out of available memory. This triggers more frequent Garbage Collector events which paralyze the device (Stop-the-world GC events) by almost stopping the rendering of UI and processing of events. This leads to an Out of Memory Exception and translates to the user as the app being unresponsive.
Testing for Memory Leaks
Memory Leaks are caused by the failure to not be able to de-allocate memory that is no longer in use, which is why they cannot be identified during black box testing. The best phase to find the memory leaks is when developers are developing the application, at a code level.
It’s best to check for memory leaks during unit testing. However, testers can follow these tips:
Release Unused Memory: Memory leaks can be present because of the bad design of the application and thus might consume lot of memory when the application is in use
Test on Multiple devices:The memory consumption by the application should be monitored while doing the system & functional testing. One shouldn’t rely on a single device testing as there are plethora of devices in the market.
Detecting Memory Leaks
There are quite a few techniques and tools devised by developers to pin point memory leaks. Android’s very own Android Studio has a powerful tool to monitor not only memory usage but also for network, GPU and CPU usage as well, called the Android Monitor.
Memory Monitor in this helps track memory usage, find de-allocated objects, identify memory leaks and helps get an overall sense of how your app allocates and frees memory. It’s done in three steps:
1. During and use and debugging of app, track the memory monitor. If the memory usage graph rises for your app and doesn’t fall even if put in background, it’s a memory leak.
2. Using the Allocation tracker, you can check the percentage of memory allocated to different types of variables in your app. This gives you a sense of how much memory is consumed by which object.
3. Create a Java Heap Option to create a heap dump that keeps a snapshot of the memory at any given point of time, thus providing the data consumption data.
Despite Android’s monitor to detect memory leaks, there are a few platforms from developers that help extract memory consumption data without so many steps for faster testing cycles.
pCloudy’s very own platform for example, generates the statistics for Memory consumption while doing the normal functional Mobile Application Testing on real mobile devices.It also generates other vital data such as CPU consumption, battery consumption & data consumption for testers and developers who reiterate several test cycles across multiple physical devices.
[A Device Rack in the Data center which contains pCloudy Hardware and set of devices]
[Data Center: All the above is located in a secure, 24×7 operated data center]
