[Performance/Memory Consumption] setVisibility(View.GONE) vs setVisibility(View.INVISIBLE) vs parent.removeView()

There are three ways to hide views. Let's find out which one is the most efficient in performance.

Is there performance difference between setVisibility(View.GONE), setVisibility(View.INVISIBLE), and parent.removeView()? If so, which one is the fastest?

Short Answer: It depends.


View.GONE vs View.INVISIBLE

• View.GONE This view is invisible, and it doesn't take any space for layout purposes.
• View.INVISIBLE This view is invisible, but it still takes up space for layout purposes.

In general, making unused views to View.GONE is more efficient, because you are skipping measuring the view size step.
However, if the view is frequently changing its visibility from View.GONE to View.VISIBLE, then it requires re-measuring the view size and the layout location of other views in-relation to the view. When you change from View.INVISIBLE to View.VISIBLE, you are skipping this measuring process.

View.GONE vs parent.removeView()

View in View.GONE will still consume memory whereas parent.removeView() will release its view memory. So, if the view is a large memory consuming view (eg. webview) it is a good idea to remove it from its parent view.
However, if you know you're going to show the view again, then it is better to use View.GONE.

Android: Manifest accelerate Hardware &

android:largeHeap="true"

=> Increase application memory heap. more
android:hardwareAccelerated="true"

=> Accelerate the hardware.
=> However, it limits the size of texture. For example, Bitmap cannot load bigger than 2048x2048.
      see here

Android: (Memory Management) memory leak - free ImageView resource

In order to free ImageView/Drawable object to gain memory space:

        ImageView v = (ImageView) _________;
        ((BitmapDrawable) v.getDrawable()).setCallback(null);
        

Usually you do it on onDestroy()

private void unbindDrawables(View view) {
    if (view.getBackground() != null) {
        view.getBackground().setCallback(null);
    }
    if (view instanceof ViewGroup) {
        for (int i = 0; i < ((ViewGroup) view).getChildCount(); i++) {
            unbindDrawables(((ViewGroup) view).getChildAt(i));
        }
        ((ViewGroup) view).removeAllViews();
    }
}

For Bitmap, you use recycle().

Android: (Memory Management) code dump hprof file

android.os.Debug.dumpHprofData("/sdcard/heapdump.hprof");

Android: (Memory Management) How to interpret D/dalvikvm log

D/dalvikvm log is shown in the Log whenever GC happens.

Reason for GC
D/dalvikvm( 9050): GC_CONCURRENT freed 2049k, 65% free 3571K/ 9991K, external 4703K/5261K, paused 2ms+2ms

Reason for GC:
- GC_CONCURRENT : heap has been mostly filled up, so GC runs before heap is full.
- GC_FOR_MALLOC : heap is entirely filled up, we had to STOP and GC.
- GC_EXTERNAL_ALLOC : (Won't see this in Honeycomb+) Bitmap are externally allocated momory.
- GC_HPROF_DUMP_HEAP
- GC_EXPLICIT : called when you call 'System.gc()';

Amount freed
D/dalvikvm( 9050): GC_CONCURRENT freed 2049k, 65% free 3571K/ 9991K, external 4703K/5261K, paused 2ms+2ms

External Memory Information
D/dalvikvm( 9050): GC_CONCURRENT freed 2049k, 65% free 3571K/ 9991K, external 4703K/5261K, paused 2ms+2ms

(amount of external memory your app has allocated)/(Soft limit)

Pause Time
D/dalvikvm( 9050): GC_CONCURRENT freed 2049k, 65% free 3571K/ 9991K, external 4703K/5261K, paused 2ms+2ms

(beginning pause) + (during pause)

Android: (Memory Management) Larger Heap size

To make lager heap:

 <application
        android:icon="@drawable/icon"
        android:label="@string/app_name"
        android:largeHeap="true"
        android:hardwareAccelerated="true">

Warning:
- Larger heap size means longer GC(Garbage Collection) time.
- If you make your app heap size bigger, it will significantly slow down other apps and users will soon know your app is the problem.
- Don't use this option just because you get memory error.

To check heap size on your device:

  ActivityManager am = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
  int memoryClass = am.getMemoryClass();
  int memoryClass2 = am.getLargeMemoryClass();
  Log.v("onCreate", "memoryClass:" + Integer.toString(memoryClass) + " large: " + memoryClass2);