1. Android Overview:
Android is the most widely used smartphone OS, but it has always lacked behind iOS due to poor memory management. Many memory management techniques have been proposed until now such as Managing GPU Buffers, Detecting and Fixing Memory Duplication's, Dynamic Caching etc.
2. Background and Motivation
Since the adoption of hardware-accelerated features (e.g., hardware codec) improves the performance and quality of mobile devices, it revives the need for contiguous memory allocation. However, physical memory in mobile systems is highly fragmented due to the frequent spawn and exit of processes and the lack of proactive anti-fragmentation scheme. As a result, the memory allocation for large and contiguous I/O buffers suffer from the highly fragmented memory, thereby incurring high CPU usage and power consumption
Current Linux memory management algorithms have been applied for many years. Android inherits Linux kernel, and thus the memory management algorithms of Linux are transplanted to Android smartphones.
Modern mobile platforms run dozens of concurrent VMs. Those concurrent VMs share a set of constrained and over-committed resources such as memory. Mobile system relies mostly on caching the processes to reduce the latency of loading the applications hence mobile systems increase their own responsiveness.
When an Android app is closed, the process stays in memory to reduce the start-up overhead when the application is used again. To clean up the physical memory, Android uses a controlled low-memory-killer (LMK) which kills processes when the available free RAM reaches a low threshold. The LMK allows specifying a set of “out of memory thresholds (OOM)” to decide on which and how many processes to kill.
There is another process which kicks in when android is running on low memory that’s KSWAPD
Kswapd is a thread used to reclaim free space when the number of free pages is lower than a threshold limit. Kswapd and LMK are mostly used to free up the space when your android phone is running low in memory. So, let’s discuss what happens to our apps when android is running low on main memory and How does it make some space so that it handles new requests.
3. Physical Memory on device
Let’s consider a device with 2GB RAM, we start doing nothing on device and then start launching apps which will utilize more and more memory.
At the begging there is plenty of memory available, so this is a happy device. If application needs more memory kernel can satisfy that request by allocating the available free memory
After some time when we start launching different apps the free memory gets exhausted.to avoid bad things from happening Linux kernel has a mechanism that kicks in Kswapd.
Its job is to find more free memory. This kicks in when the free memory goes below a certain threshold called as kswapd threshold
The main mechanism which kswapd uses to find the free memory is to release the free cache memory. Now if the app is going to access the cache page which is reclaimed by kswapd its going to take a bit of time to reload that data, as this time is not that large which user can notice, user might not be aware sometime what happened in the background. But as we continue using more and more apps the memory is getting utilized, the number of cache pages is going to fall as kswapd starts freeing more space by freeing the cache pages. If it gets too low, as there are few cache pages then the device is going to thrash, and the device will get completley lock up. So, avoid this we have a process called as LOW MEMORY KILLER(LMK). LMK kicks in when the cache memory falls too low.
LMK gets triggered when LMK threshold is hit. it’s going to pick up the process in the device and kill it. And get back all the memory the process was using
This is unhappy state to be in because if LMK kills the process which user cares, its not going to be good end user experience.
4. How LMK decides which process to kill
To decide which process to kill, LMK uses an “out of memory” score called oom_adj_score to prioritize the running processes. Processes with a high score are killed first. Background apps are first to be killed, and system processes are last to be killed. The following table lists the LMK scoring categories from high-to-low. Items in the highest-scoring category, in row one, will be killed first:
5. Suggestion to improve overall memory usage
1. Profile your Java Heap size: you can check the java heap size using android profiler when your app is running.
2. Reduce the size of APK: a lot of things that take space in APK also takes space in memory during runtime.
3. A preliminary idea could be implemented by reducing the number and the reclaim size of kswapd by tuning its thresholds. There is a tradeoff between the reclaim size and the overall performance:
· If the reclaim size and the number of kswapd are too small, the free pages will be consumed quickly. Thus, when an allocation failed because of insufficient free pages, the heavy-weight direct reclaiming will be triggered and thus degrades the performance;
· On the other hand, if the reclaim size and the number of kswapd are too large, the ratio of page re-fault will be high and thus degrades the performance. To further illustrate the tradeoff, the latency of launching seven apps are tracked when kswapd is turned on or turned off. The results are shown in Figure
The results show that at the beginning, the latency when kswapd is turned on is similar to when it is turned off. This is because free pages are sufficient at the beginning. As the number of launching operations increases, the free pages in memory will be consumed. Thus, during this period, the performance when kswapd is turned off is better than that when kswapd is turned on. This is because when kswapd is turned on, reclaim operations are triggered and the page re-fault ratio becomes higher than that when kswapd is turned off. When the free pages are used up, without kswapd, direct reclaiming will be triggered to reclaim free pages and thus the performance will be worse than with kswapd