Question

I have read Android’s Developers Guide on Designing for Performance.

I am just wondering that if I have a large object, that I cannot avoid creating (which is expensive ) , it seems logical that I want to deallocate it immediately when I know I am done with it.

There seems to be no way of doing this.

Some suggest setting it to null so it will be immediately GC by the system, will this be truely “immediate”? Because if the system (Dalvik VM) has the option to NOT deallocate the large object that I just set to null, then setting it to null is not at all a solution.

Is it correct to say that setting it to null will ENCOURAGE and SPEED up GC?

Is this approach a “good enough” way to optimize Apps performance? Or is it worth going the extra mile (if at all possible ) , to force GC whenever applicable to squeeze the best performance out of any Android device?

Answer 1

I don’t think you should worry to the granular details when GC is executed as we don’t have control over when gc gets called. Even calling gc() will not guarantee a collection. Per documentation from System.gc()

Indicates to the virtual machine that it would be a good time to run the garbage collector. Note that this is a hint only. There is no guarantee that the garbage collector will actually be run.

In developing the application with large object allocation I would worry about the following instead:

1. Upon allocating the large object and subsequently after exit the scope of life cycle of that object, do I see it get reclaimed by the GC in later Activities? This could be easily checked by running dumpsys meminfo with adb shell. You basically check after deallocation if the memory is properly garbage collected typically signify by large spike and drop afterwards
2. Check if this large object has a clear path to GC. You could do this by checking the reference path of this object via dumping the hprof and check it in Memory Analyzer. If it does, you are safe as the GC will smart enough to collect.
3. After I allocate this large object, do I have enough padding in my heap to execute subsequent activity? If the object is too large, there is a chance that GC is not fast enough to collect it (this is actually related to your point) and the memory consumption from subsequent activity combined with the left over from the previous ones might actually cause out of memory error. Setting null with a clear path to GC will help to ensure that this object will get GC’ed appropriately. I admit this is a problem, but my view is if this becomes a problem, we might have to relook on how this particular section is designed and see if we could do any optimization on it.
4. Implement clean up on the activity via onDestroy as necessary and make sure the Activity is not referenced by others so it could get properly garbage collected. For example: we often pass activity context around forgetting that it will hold its reference. Things like calling recycle() on bitmap should also help. Remembering these points should help preparing more space in the case of #3 happens