Saturday, December 7, 2013

memory usage of my app in Android

Memory usage on modern operating systems like Linux is an extremely complicated and difficult to understand area. Android apps have more memory available to them than ever before, but are you sure you're using it wisely? This talk will cover the memory management and explore tools and techniques for profiling the memory usage of Android apps.

first question is in my mind is how to know application heap size available to an Android app. ofcourse it may vary on the basis of phone device.

  1. How much heap can my app use before a hard error is triggered? And
  2. How much heap should my app use, given the constraints of the Android OS version and hardware of the user's device?
For item 1 above: maxMemory()
which can be invoked (e.g., in your main activity's onCreate() method) as follows:
Runtime rt = Runtime.getRuntime();
long maxMemory = rt.maxMemory();
Log.v("onCreate", "maxMemory:" + Long.toString(maxMemory));
This method tells you how many total bytes of heap your app is allowed to use.
For item 2 above: getMemoryClass()
which can be invoked as follows:
ActivityManager am = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
int memoryClass = am.getMemoryClass();
Log.v("onCreate", "memoryClass:" + Integer.toString(memoryClass));
This method tells you approximately how many megabytes of heap your app should use if it wants to be properly respectful of the limits of the present device, and of the rights of other apps to run without being repeatedly forced into the onStop() / onResume() cycle as they are rudely flushed out of memory while your elephantine app takes a bath in the Android jacuzzi.
At runtime, the heap grows dynamically in size as the Dalvik VM requests system memory from the operating system. The Dalvik VM typically starts by allocating a relatively small heap. Then after each GC run it checks to see how much free heap memory there is. If the ratio of free heap to total heap is too small, the Dalvik VM will then add more memory to the heap (up to the maximum configured heap size).

Memory Anatomy

PSS : Proportional Set Size

Amount of memory shared with other processes, account in a way that the amount is divided evenly between the processes that share it. This is memory that would not be released if the process was terminated, but is indicative of the amount that this process is “contribution” to overall memory load.

USS : Unique Set Size

USS is the set of pages that are unique to a process. This is the amount of memory that would be freed if the application gets terminated.


Runtime memory available for allocation (Used by applications, services, daemons)

Dalvik Heap

The dalvik heap is preloaded with classes and data by zygote. 

Commands for run time memory usage

  • To spit out a bunch of information about the memory use of each JAVA process
$adb shell dumpsys meminfo 
  • To see memory for particular process: ( e.g. System)
$adb shell dumpsys meminfo system
  • Summary of the overall memory
$adb shell cat /proc/meminfo 

Run Time Memory: Gallery Use Case

Rum time memory usage will depends on kind of use case running on android system. Following are the context where – run time memory will be allocated by android system.
  • All java process will run with the instance of DVM. DVM will again have its own run time heap requirement based on java application code complexity.
  • Binder IPC will allocate run time memory for marshalling objects
  • Service or daemon will allocated run time memory for internal usage
  • Following example will show run time heap change with respect to gallery application use case.
    • Size : Total size of particular heap
    • Allocated : Portion of heap is allocated to process
    • Native Usage : Usage by application or service code
    • Dalvik Usage : Usage by Dalvik virtual machine (libdvm)

Android's inbult API ActivityManager.getProcessMemoryInfo return few more interesting numbers.

The Pss number is a metric the kernel computes that takes into account memory sharing -- basically each page of RAM in a process is scaled by a ratio of the number of other processes also using that page. This way you can (in theory) add up the pss across all processes to see the total RAM they are using, and compare pss between processes to get a rough idea of their relative weight.
The other interesting metric here is PrivateDirty, which is basically the amount of RAM inside the process that can not be paged to disk (it is not backed by the same data on disk), and is not shared with any other processes. Another way to look at this is the RAM that will become available to the system when that process goes away (and probably quickly subsumed into caches and other uses of it).
Android added this crucial topic in detail.
Here is nice youtube link

No comments:

Post a Comment