Android Memory optimization tips and tricks

Android central process Zygote forked to allocate memory for every other process. Because of limited resource in mobile, memory optimization is necessary in android. Don't ask for more memory if you don't require it. Here are some tips which will help running your application smoothly

• Enums often require more than twice as much memory as static constants. You should strictly avoid using enums on Android.

• Every class in Java (including anonymous inner classes) uses about 500 bytes of code.  and every class instance has 12-16 bytes of RAM overhead.

• Putting a single entry into a HashMap requires the allocation of an additional entry object that takes 32 bytes 

• Use optimized container from android framework like  SparseArray, SparseBooleanArray, and LongSparseArray. generic HashMap use can be quite memory inefficient because it needs a separate entry object for every mapping so use  SparseArray.

• Release memory as memory becomes tight 

• onTrimMemory() callback of Activity help you finding way to release resource. Callbacks like TRIM_MEMORY_RUNNING_LOW, TRIM_MEMORY_RUNNING_MODERATE, TRIM_MEMORY_RUNNING_CRITICAL etc gives you way to release unused resource which eventually help improving performance of your app

• Load views on demand using ViewStub read about ViewStub

• Use multiple process in a single application. Name your background services as separate process like 

         <service android:name=".PlaybackService" android:process=":background" />

Garbage Collection, Heap in android and Java

Garbage collection (GC) is the process that aims to free up occupied memory that is no longer referenced by any reachable Java object, and is an essential part of the Java virtual machine's (JVM's) dynamic memory management system. In a typical garbage collection cycle all objects that are still referenced, and thus reachable, are kept.
 Object no longer have any reference are elligble for garbage collection.

Before going further we need to discuss some important term in Garbage  Collection in android as well java. it works similar
    
  Heap Size or Java Heap or Heap : Every device allocate a specific amount of memory to run a process. It does not allocate all memory to one  process to ensure multitasking. e.g Let an android example, a device with 2 GB memory have heap size of 48 MB(this is my assumption, Heap size depends on device density and other factor). So this device will allow 26  process to run at a time and rest memory used in running OS files. when a process load in memory. It start allocating memory to object. So heap size start increasing. Eventually, the Java heap will be full, which means that an allocating thread is unable to find a large-enough consecutive section of free memory for the object it wants to allocate.At that point, the JVM determines that a garbage collection needs to  happen and it notifies the garbage collector. A garbage collection can also be triggered when a Java program calls System.gc(). Using  System.gc() does not guarantee a garbage collection. Before any garbage collection can start, a GC mechanism will first determine whether it is  safe to start it
  
A garbage collector should never reclaim an actively referenced object; to do so would break the Java virtual machine specification. A garbage collector is also not required to immediately collect dead objects. Dead objects are eventually collected during subsequent garbage collection cycles. While there are many ways to implement garbage collection, these two assumptions are true for all varieties. The real challenge of garbage collection is to identify everything that is live (still referenced) and reclaim any unreferenced memory, but do so without impacting running applications any more than necessary

Two kinds of garbage collection are present to determine which object will garbage collect--

• Reference counting collectors

• Tracing collector algorithms

Displaying Bitmaps Efficiently and Avoiding java.lang.OutofMemoryError

java.lang.OutofMemoryError: bitmap size exceeds VM budget. This is most common error for us when we are decoding Bitmap more than 4 MB. In generally before decoding bitmap we do not know how much bigger the size of a bitmap will be. So its very difficult problem for us to handle this error in proactive approach

But good thing is that android provide a way to handle this problem.Before decoding bitmap we just decode it with options.inJustDecodeBounds = true. options is the instance of BitmapFactory. It does not load bitmap into memory but it help us to find the width and height of a bitmap so that we can reduce the height and width according to our device

As Bitmaps take up a lot of memory, especially for rich images like photographs. For example, the camera on the Galaxy Nexus takes photos up to 2592x1936 pixels (5 megapixels). If the bitmap configuration used is ARGB_8888 (the default from the Android 2.3 onward) then loading this image into memory takes about 19MB of memory (2592*1936*4 bytes), immediately exhausting the per-app limit on some devices.

So we will find actual height and width of a bitmap as follows...