Finding Memory Leaks in Mobile Apps (Part 1: Visualization)
What is Memory Leak?
The phrase “memory leak” simply describes a situation in which software is unable to efficiently manage allocation/reallocation of the RAM (Random Access Memory), resulting in a decline in both the application’s and its host machine’s (in our case mobile’s) overall performance. An application that continuously consumes mobile’s memory without freeing any of it will eventually use up all of the memory. If not dealt with, the application will eventually exhaust its resources and it will crash, throwing an OOM (Out Of Memory) error.
Consequences of having memory leaks:
- Severe performance degradation when the application is continuously running for a long time
- OOM crashes
- Application’s crash-free rate decrease
- User retention rate decline
- User complaints increase
- Stores’ positive review decrease
- App uninstall rate increase
Creating the best way to detect memory leaks in mobile apps.
In Picsart, we have come up with a great solution where anyone can easily find a memory leak and report it to the developers. It’s called: Memory Monitoring Tool. This tool shows real-time memory usage, automatically collects and stores used memory data, and gives the possibility to export and analyze stored data. For now, we started with iOS.
Our main goals were:
1. Track the amount of memory that application uses at any time:
We used the code mentioned below to store the exact amount of the device’s memory(RAM) that the application uses by Megabytes. We compared the memory value with the value of the memory gauge in Xcode’s Debug navigator just to be sure, and both values are closely matched!
Xcode memory profiler is widely accessible for developers, but what if you want to be able to see real-life memory consumption when you are not attached to Xcode debug as well?
That’s why we developed a tool that provides a memory consumption view even when you are not attached to Xcode. Therefore, the team members other than developers(Quality engineers, Product managers etc.) can easily use the tool.
Now that we have the memory usage value in hand, we have to show it!
2. Show the calculated amount of memory on the screen:
In order to visualize current memory allocation, we have created AssistiveTouch and GraphView custom classes.
- AssistiveTouch: It is a class that offers an assistive view that can easily collapse and expand to whatever size you want.
- GraphView: It is a class that gives us a simple graph that lets you very easily generate a graph from real-time data.
Using these instruments, we have successfully created two tools. Let’s see how they look.
-The First Tool (Demonstrating AssistiveTouch):
As you can see, it is a small view showing the amount of memory that is getting used(in MB). It stays on the screen and reports memory’s value(every second) on any section of the app. There is an on/off toggle in our app’s developer settings section, and we can enable or disable it whenever we want.
-The Second Tool (Demonstrating GraphView):
For the second tool, we wanted to monitor memory usage changes more closely. Using the GraphView Library, we have created a tool that graphically displays the amount of memory.
Here’s what it looks like:
As you can see, the tool tracks the actions happening in the background and generates the memory usage graph based on the collected data.
With the help of these tools, we can identify memory-intensive flows, and more importantly, we can determine whether memory is still not being freed for terminated actions. In other words, using these tools, we can easily find Memory Leaks.
Below are some examples of open 3rd party graph visualization components for iOS:
We have the perfect tool, what‘s next?
In our team, which is called the “Mobile Core” team, our primary purpose is always to find the best ways to enhance the company’s major processes’ performance to make everyone’s life easier. That’s the main reason that we wanted to create this tool. Now that we have this great tool, we need to use it properly to discover the memory leaks in our application. At first, as Quality Engineers, my co-worker and I ensured the tool worked fine. Afterward, we decided to merge the tool to our main branch and test it by asking all the other teams’ quality engineers to perform an exploratory testing by using it.
Now, we have dozens of quality engineers, each of which will cover the app section they are responsible for and report back if they find any memory leaks in their flows.
Later, when all the quality engineers finished performing the exploratory testing, we got dozens of memory leak cases(critical/non-critical) reported by them. One thing was crystal clear. The tool’s impact was huge. We started working on the reported memory leak cases and fixed them as quickly as possible. After fixing those issues, we were able to significantly increase the crash-free rate of our app in only two weeks.
Lastly, as the tool has a huge impact on our application and helps us significantly reduce memory leaks, in order to keep it that way and prevent future memory leak issues, we have decided to use it regularly, and we have also decided to collect the main flows of our application and write automated test cases to detect any anomalies faster, track the memory tool’s performance, and improve the process consistently.
But how exactly are we planning to automate this tool?
I will cover it in part 2 of this article.
