Memory management in Android

Let's discuss the memory management system in Android. It has a direct effect on the game development process. Games are treated like applications in Android. Very often, developers face memory issues in both the runtime and minimized states of the game. There are three main topics to discuss to understand the working principles:

  • Shared application memory
  • Memory allocation and deallocation
  • Application memory distribution

Shared application memory

Android uses the Linux kernel, and Linux uses "shared" pages to share the same memory segment within running processes or services. For example, Android often shares the "code" memory within processes. Very often, external libraries and JVM's executable code memory can be safely shared across processes without creating a deadlock. Data pages could be shared temporarily between processes, until a process modifies the shared memory.

Android allocates dedicated memory for each application or process. This is called private memory. The same process may also use shared memory. Android automatically sets a cap, depending on the total of both, to determine when the process or application will be killed, especially if it is in the background. This cap is called Proportionate Set Size (PSS):

Shared application memory

If an application's PSS is high, then there is a very high chance that the process might be killed by Android. This scenario can be handled programmatically to keep memory usage in check, especially if the application is relying on some background activities or services to carry out some task. The developer has to make sure that the game uses minimum possible memory at any point in time, especially when the application goes into the background. It may be a good idea to free memory and objects that you no longer need in the background, and disconnect from any shared memory that you no longer need when you go into the background. This will reduce the chances of your application getting unexpectedly killed by the Android system.

Memory allocation and deallocation

The Android memory management system defines a virtual cap for each application, which is the logical heap size. It can be increased if necessary, but only if there is free memory available. However, this logical heap size is not the actual allocated memory for the application. Calculated PSS is the actual physical cap that may vary during runtime and shared memory dependency.

Application memory cannot use more physical memory than PSS. So, after reaching this limit, if the application tries to allocate more memory, then it will receive OutOfMemoryError thrown by the system. Android might kill other empty or background processes to accommodate memory for the running application in a critical situation. Application memory will be deallocated in these scenarios:

  • If the application quits
  • If the process becomes inactive and some other process requires the memory
  • If the application crashes for any reason

Application memory distribution

Android sets a hard limit on the heap size for each app to maintain a multitasking environment. The exact heap size limit varies between hardware configurations based on the capacity of RAM of the device. If the application reaches the heap capacity and tries to allocate more memory, it will receive OutOfMemoryError, and the application will be killed by Android.

The developer needs to check the amount of memory available on the device and then determine an average target memory use. The developer can query the operating system for this amount of memory by calling getMemoryClass(). This returns an integer indicating the number of MBs available for the application's heap.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.93.141