I'm developing android applications for a while, and followed a lot of posts about activity life cycle, and application's life cycle.
I know Activity.finish()
method calls somewhere in the way to Activity.onDestroy()
, and also removing the activity from stack, and I guess it somehow points to operating system and garbage collector that he can "do his trick" and free the memory when it find it a good time doing so....
I came to this post - Is quitting an application frowned upon? and read Mark Murphy's answer.
It made me a bit confused about what exactly the finish()
method actually does.
Is there a chance I'll call finish()
and onDestroy()
won't be called?
It seems that the only correct answer here so far has been given by romnex: "onDestroy() may not be called at all". Even though in practice, in almost all cases it will, there is no guarantee: The documentation on finish() only promises that the result of the activity is propagated back to the caller, but nothing more. Moreover, the lifecycle documentation clarifies that the activity is killable by the OS as soon as onStop() finishes (or even earlier on older devices), which, even though unlikely and therefore rare to observe in a simple test, might mean that the activity might be killed while or even before onDestroy() is executed.
So if you want to make sure some work is done when you call finish(), you cannot put it in onDestroy(), but will need to do in the same place where you call finish(), right before actually calling it.
My 2 cents on @K_Anas answer. I performed a simple test on finish() method. Listed important callback methods in activity life cycle
What I mean to say is that counterparts of the methods along with any methods in between are called when finish() is executed.
eg:
Also notice if you call finish() after an intent you can't go back to the previous activity with the "back" button
When calling
finish()
on an activity, the methodonDestroy()
is executed this method can do things like:Also,
onDestroy()
isn't a destructor. It doesn't actually destroy the object. It's just a method that's called based on a certain state. So your instance is still alive and very well* after the superclass'sonDestroy()
runs and returns.Android keeps processes around in case the user wants to restart the app, this makes the startup phase faster. The process will not be doing anything and if memory needs to be reclaimed, the process will be killedIn addition to @rommex answer above, I have also noticed that
finish()
does queue the destruction of the Activity and that it depends on Activity priority.If I call
finish()
afteronPause()
, I seeonStop()
, andonDestroy()
immediately called.If I call
finish()
afteronStop()
, I don't seeonDestroy()
until 5 minutes later.From my observation, it looks like finish is queued up and when I looked at the
adb shell dumpsys activity activities
it was set tofinishing=true
, but since it is no longer in the foreground, it wasn't prioritized for destruction.In summary,
onDestroy()
is never guaranteed to be called, but even in the case it is called, it could be delayed.Finish() method will destroy the current activity. You can use this method in cases when you dont want this activity to load again and again when the user presses back button. Basically it clears the activity from the.current stack.