Open In App

Memory Usage in Android

Improve
Improve
Like Article
Like
Save
Share
Report

In order to make our app get liked by users and make the app famous Memory plays a very important role. Less the memory requirement for the application, the faster the app will run on a specific device. We need to be careful if the app is being run on an entry-level device and we know that most android users use entry-level devices. Here entry-level devices mean low-cost devices. So for providing a better user experience and for strengthening the Android system. Every good Android Developer must have an understanding of the memory usage of an app. So in this article, we will understand the memory usage in android. This could be complex so we will divide it into the following steps.

  • Why should we learn about memory usage?
  • How does memory use make an impact on the device?
  • Reducing memory impact on the app.

Why should we learn about memory usage?

So before understanding the usage of memory, we must understand why should we even care about understanding memory usage. Basically, there are three types of android devices on market. 

  • Entry Level
  • Mid Level
  • Premium Level

Out of these three types of devices the entry-level devices have low memory and these devices are only able to run only those applications that require low memory then if the memory usage of the application increases then it will be difficult for the entry-level device to run the application. As a result, users will have a really bad user experience and they might stop using the app due to such performance. This will also have a bad effect on the Android ecosystem. (i.e. a collection of apps, devices, and users).

Memory Availability and Usage

Despite this being a problem in low-level devices, A good android developer should do whatever he can to make the app perform better, be efficient in memory usage, and reduce memory use.

How does memory use make an impact on the device?

Now we will see how high memory requirements impact a device. Generally, the memory of an android device is divided into pages and each page is around 4 Kilobytes. There are three types of pages

Physical Memory On Device

  1. Used Pages: These are the pages that are currently being used by the processes.
  2. Cached Pages: These are the pages that the processes are using but some part of the memory is also present in the main memory. So, to have a fast retrieval of data, we use cached pages.
  3. Free Pages: These are the pages that are free i.e. these are the memory space that can be used to store something in the future.

Now, let’s see what is the impact of memory pressure on android devices. The following graph shows memory usage during the course of time. So, in the beginning, there is nothing to run but with the due course of time, we started using more applications and this, in turn, uses more and more memory over time.

From the above graph, we can clearly see that in the beginning, when the device starts running then there is already a lot of free memory available. But when we start using other applications then the free memory is being used and to avoid something bad that can happen due to low memory, the kernel performs an operation which is called kswapd.

In the process of kswapd, if the memory of the device goes down the kswapd threshold, then the Linux kernel will start finding some more free memory. So, what it does is, reclaim the cached pages and make them free. But the problem here is that if we want an app to reclaim the memory present in the cached pages then it will take some time because at present time there is nothing in the cached page and data will get loaded from the storage of the device. 

In Android, There is a process called low memory killer, and this will pick a process from the android device and it will completely kill that process. By doing that, we will get back all the memory that the process was using. But what if a low memory killer, kills the process that is important to the user? In Android, there is a priority list of apps, and based on the priority list we remove the app when the low memory killer comes into play. Following is the list of priority in Android: 

Whenever the low memory killer comes into play, then it will first delete the cached applications. Even after that, the memory usage will keep on increasing and the low memory killer will kill the previously opened applications. Now if the user wants to open the previously opened applications then it will take some time to launch the application because it is not currently present in the cached memory. 

Again if memory usage keeps on increasing, then the home application will get killed then after that service, perceptible, foreground, and persistent apps will be stopped or destroyed. Again, if the memory usage keeps on increasing, then the system app will be killed and our phone will be rebooted 🙁 This is the worst user experience that we can have in low memory devices or entry-level devices ). The example that we took was a 2GB device. The situation becomes worse when you are having a 512MB device.

152 MB device under memory pressure

In the example given above, we have very little memory and because of this the kswapd and low memory killer will come into play very earlier. So, low memory killer will always be active and this will result in a very bad user experience we should try our best to develop an app that will be able to perform well in low memory situations also.

Now we understand how to know what is the memory impact of our application on some entry-level devices, In the above section, we have seen that the memory of the device is divided into several pages and the Linux kernel system keeps a track of the pages used by a specific application.

But the situation will get worse when the application starts using some of the shared memory. Let’s take an example, you can have an application that calls the Google Play Services and this, in return, result in page sharing between these two applications.

Now, the problem that arises here now is how to deal with this shared memory. Is the application responsible for shared memory ? or the Google Play Services is responsible for this shared memory? There are a few different ways, that can be used to deal with these situations :

  • RSS (Resident Set Size): In this method, the application is responsible for all the shared memory in our example the Google Play Service will have to do nothing and the app that is using Google Play Service will be responsible for the sharing of memory.
  • USS (Unique Shared Set): In this method, the application is not responsible for any of the shared pages.
  • PSS (Proportional Set Size): In this method, the app will be responsible for the number of pages that are proportional to the number of processes sharing the shared memory. Like, if the shared memory contains 4 pages then the memory is shared among two processes and the app will be responsible for only two pages. If the shared page is 4 and the number of sharing processes will become 3 and then the app will handle 4/3 pages.

Reducing memory impact on the app

Up to now, we have seen how memory use makes a serious impact on a device. We saw how to evaluate the application’s memory impact. Now, we will find ways that can be used to reduce your application’s memory impact. Let’s take a look at how can we do this. The first step to reduce your application’s memory impact can be checking the Android Studio’s memory profiler.

Reducing memory impact on the app

This will give you a lot of information, for example, you will come to know about your java object, where are they allocated, what’s holding on to them, and almost everything that you can find about your Java object. Finding the PSS value, we only considered the Java heap. Now we know the importance of Memory usage.


Last Updated : 07 Mar, 2022
Like Article
Save Article
Previous
Next
Share your thoughts in the comments
Similar Reads