Software Technology Tips

Android applications are executed in dalvik virtual machine which is a modified Java virtual machine(JVM).
As each java applications are assigned fixed heap size to execute in JVM,
all android applications are also assigned a fixed heap size to execute in Dalvik virtual machine(DVM).
heap size is the amount of memory allocated to an application to execute.
 
The heap size for android applications are determined by the device RAM.
For example if the device has RAM of 179 MB, the android applications will only get the heap size of 18MB.
and example if the device has RAM of 1024 MB, the android applications will only get the heap size of 48MB.
 
 
Thus we must take care that memory utilization of the android application should not exceed heap size
or "Out of memory error exception " will be genrated by the DVM.
 
You can check how much memory application is consuming by using "MAT" tool which can be downloaded from android developer site.
 
In some image processing applications large amount of heap size is required.
Thus in Android Icecream Sandwitch and Android Honeycomb, in AndroidManifest under "application"
tag we can set "android:largeHeap" to true to allow application to to have larger heap size.
 
 
 
But with larger heap size the garbage collector(GC) will take more time to garbage collect. When
GC will operate on the application , the application stall for some time.
Thus when heap size is more then the GC garbage collection will cause the app to stall for longer period.
 
 
Bitmap object consume a lot of memory. Thus they should be allowed to Garbage collect once they have been used.
 
Bitmap object cannot be Garbage collected directly because it has a native portion which can not be released from memory by GC.
Thus once we have used a Bitmap object we must call Bitmap.recycle() method to release the native part within the Bitmap object
and mark the rest part of Bitmap object to be garbage collected.
 
 
Memory can also be optimized if we mark the objects as "Soft reference" so that if there is low memory then the object will be garbage colleceted instantly.
 
For example we have a object named "myOffice" of a class say "Office"
We want that the object "myOffice" to be allowed to be garbage collected once there is low memory.
 
We can pass the reference of "myOffice" in the SoftReference as follows:
 
SoftReference<Office> reference=new SoftReference<Office>(myOffice);
 
syntax of using SoftReference is as follows:
 
SoftReference<class name of the object you wish to pass to mark it as softreference> reference
=new SoftReference<class name of the object you wish to pass to mark it as softreference>(object you wish to pass to mark it as softreference);
 
you can latter check if "reference" variable is null or not,
if it is null that means the object has been garbage collected.
 
 
 
Memory can also be optimized if we mark the objects as "Weak reference" so that
as soon as the object is no longer used/referred it will be garbage collected.
 
For example we have a object named "myOffice" of a class say "Office"
We want that the object "myOffice" to be allowed to be garbage collected as soon as it is not referenced.
 
We can pass the reference of "myOffice" in the WeakHashMap to mark it as weak reference as follows:
 
1. we declare and initialize object of WeakHashMap.
 
private WeakHashMap<K, V> mWeakHashMap = new WeakHashMap<K, V>();
 
where k=key
 V=value
 mWeakHashMap = reference variable of WeakHashMap
 
For example:
 we want to pass "myOffice" in mWeakHashMap and key can be any thing say a string
 so we declare object of WeakHashmap as
private WeakHashMap<String, Office> mWeakHashMap = new WeakHashMap<String, Office>();
 
2. We pass the "myOffice" object to mWeakHashMap as follows:
 
mWeakHashMap.put("myOffice",myOffice);
 
We can also optimize memory usage by using minimum views in our layout.


Related Tags:

Memory Optimization

Author: Shubhankar Mazumdar

Android Apps Development

Let us Connect!

iso 9001 QA25 Red Herring STPI D&B Fastest Growing SME 2013 Award zinnov Nasscom

copyright (c) Mindfire Solutions 2007-2014. Login