Does onDestroy() or finish() actually kill the activity?
Asked Answered
P

3

6

Actually I know i am asking about the simple and basic concept of Android. But I am a little bit confused about these finish() and onDestroy() methods. Whether this will kill the activity and free the resources associated with these activity?

I tried with a simple application which contains only one activity. I thought the concept is like When the application runs, the activity will start. and when we click on back button, it will finish. And I gave some toast message inside each life cycle methods for knowing the memory usage . And when I clicked on the back button it executed onPause(), onStop(), and onDestroy(). I thought this activity finished. But when i relaunched the application again, then it took more memory than the previous time. This happens every time when I run the app from eclipse or relaunch the application from home screen.

Why is it happening? How can i actually destroy the application / activity to free the memory?


I am including my code. I just give only one toast message inside the class. Then also memory usage is increasing.

Each time when I run the application the allocated size is increasing like : 3302744, 3442384, 3474552

 public class myActivity extends Activity
   {
         @Override
         public void onCreate(Bundle savedInstanceState)
         {
             super.onCreate(savedInstanceState);     
        Toast.makeText(getBaseContext()," allocated size  = " + Debug.getNativeHeapAllocatedSize(), 1).show();      
         }

   }

manifest:

<application android:icon="@drawable/icon" android:label="@string/app_name">
        <activity android:name=".myActivity "  
                  android:label="@string/app_name"  >
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity> 
 </application>

Why is the memory increasing every time?

Pinchbeck answered 24/5, 2011 at 10:9 Comment(0)
L
20

The finish() kills the activity and releases memory... unless you have some reference stored that is leaked... for example on methods like onRetainNonConfigurationInstance()

When you press the back button what is called is the finish() method that than calls onPause, onStop, onDestroy.

Licit answered 24/5, 2011 at 10:14 Comment(1)
+1 for conveying so much critical information in very few sentences. The art of concise yet accurate.Lilybelle
F
10

The default behavior is that back button will cause the activity to exit and it'll be destroyed. Displaying a toast in onDestroy or onPause is not a good idea though. It'll alter the lifecycle the of your activity in a way you don't want it to happen. Use logging instead, so you'll see what's really happening. BTW, finish() is something that you call explicitly from your code and onDestroy() is a lifecycle event/method which gets called as a result of finishing/destoying the activity in any way.

Firelock answered 24/5, 2011 at 10:17 Comment(2)
thank u for the info.. but if the activity is actually finished (the resources are set as free), why the memory is increasing every time?Pinchbeck
I suggest to use the MAT plugin for Eclipse to troubleshoot memory leaks. Your method may not be reporting what you're trying to observe. (first leave the Toasts out and switch to log lines)Firelock
C
3

Finish() will literally finish your activity and if no references are present a GC will recover resources. onDestory() is actually a method that the system will call when it is destroying your activity and you are supposed to implement this function. You dont need to worry avout destroying your app , android does it for you.

Carpospore answered 24/5, 2011 at 10:14 Comment(2)
destroy means whether it will free the memory?Pinchbeck
The Garbage Collector will reclaim memory of all objects that do not have any reference to them. But as I said you cant call/should not call onDestroy , that is the framework's jobCarpospore

© 2022 - 2024 — McMap. All rights reserved.