0

Which way is better programming for memory management when dealing with Android Views? I believe the second way is better because the TextView is only accessed when needed and then, hopefully, garbage collected. Would love to hear your views!

  public class MainActivity extends Activity {
     TextView tvHelp; 

     @Override
     public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main); 

        tvHelp = (TextView) layout.findViewById(R.id.ivHelp);
        tvHelp.setText("Started"); 
     }


     @Override
     public void onResume() {
        super.onResume();

        tvHelp.setText("Resumed");
     }
  }

Or this

  public class MainActivity extends Activity { 

     @Override
     public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main); 

        TextView tvHelp = (TextView) findViewById(R.id.ivHelp);
        tvHelp.setText("Started"); 
     }


     @Override
     public void onResume() {
        super.onResume();

        TextView tvHelp = (TextView) findViewById(R.id.ivHelp);
        tvHelp.setText("Resumed");
     }
  }
Nickmccomb
  • 1,467
  • 3
  • 19
  • 34

2 Answers2

1

It doesn't make that much difference. The first one will help you avoid multiple calls of findViewById() which is CPU consuming. The second one will help you preserve some bytes on the heap. But by doing this you will also create unreferenced objects which will stack on the heap until the GC passes (which is CPU consuming). GC will also starts when the memory is running out (when you create unreferenced objects for example). So the first solution is definitely the best one to use. You'll avoid:

  • Code repetition
  • Multiples calls to findViewById
  • Unreferenced objects which will stack in the heap until the GC passes
E-Kami
  • 2,529
  • 5
  • 30
  • 50
  • The problem is that i have a fairly big app and i was doing it the first way, which became very expensive on the heap because there are a lot of views. The app is running slow because it uses a lot of memory holding onto these views. I was thinking the second way is better because at least the memory usage will be more dynamic and objects won't stay around if they aren't being used – Nickmccomb Feb 13 '16 at 01:45
  • You will indeed gain some memory by using the second solution but I doubt it is what slows down your application. Are you using only 1 activity on your whole app? The views/resources you're holding will be GC when switching from one activity to another. You can also [convert your instance variables with the help of your IDE](http://www.myandroidsolutions.com/2015/01/30/android-studio-tip-2-extract-instance-variable/) and see if it makes any difference. – E-Kami Feb 13 '16 at 02:00
1

In your case, it won't really make any difference as far as memory consumption. The Activity is going to hold a reference to that view through its hierarchy until it's destroyed whether you keep a reference to it or not. Releasing your reference to it won't make it be garbage collected.

Once the Activity goes through onDestroy(), it and its view hierarchy will be garbage collected anyway, so for this case I wouldn't worry about the difference.

One case where this can make a difference is in Fragments where the View lifecycle differs from the component lifecycle. Holding a reference to a View from onCreateView() or onViewCreated() can temporarily cause additional memory usage once they go on the backstack. You can release the references in onDestroyView() since they won't be valid anyway -- unless you are keeping the whole view hierarchy around manually.

For more info: https://stackoverflow.com/a/26370042/321697

Community
  • 1
  • 1
Kevin Coppock
  • 133,643
  • 45
  • 263
  • 274