7

If I am not mistaken, Activity objects are never destroyed from memory, they are always there until the process is killed. So calling finish() or Android operating system destroying your Activity doesn't mean it's destroyed in memory but only means it's now in 'destroyed state' (unofficial name).

To demonstrate, I did override finalize method of my activity and then used System.gc() from a button click event of another activity. I see that finalize method of my activity is being called. If activity objects can't be destroyed while the process is running, how can activity be garbage collected?

Insignificant Person
  • 863
  • 2
  • 10
  • 24
  • Have you tried "use finish() and after that use System.exit(0) to clear static variables."? http://stackoverflow.com/a/12029017/866333 – John Oct 12 '15 at 18:47

2 Answers2

6

If there is no more reference to the activity then it gets Garbage-Collected - but leaking a activity is really easy - that said there is now a really good tool to find Activity leaks: https://github.com/square/leakcanary Also an Activity is only GCed after onDestroy() was called - not directly after finish() - hence your measurement is not working

ligi
  • 39,001
  • 44
  • 144
  • 244
  • 1
    This would be really bad as Activities are really heavy objects - this is either wrong or you just miss-understood them - can you give me a link? – ligi Oct 12 '15 at 18:35
  • http://stackoverflow.com/questions/7536988/android-app-out-of-memory-issues-tried-everything-and-still-at-a-loss/7576275#7576275 – Insignificant Person Oct 12 '15 at 18:43
  • 2
    @InsignificantPerson That answer says the OS memory management is only concerned with whole processes, not individual activities. It says nothing about in-process GC behavior. – Kevin Krumwiede Oct 12 '15 at 18:51
  • 2
    @InsignificantPerson: "Many people here including Dianne Hackborn (who also is/was a member of Android Developer group) said activities are never cleaned from memory while the process still runs" -- no, she does not. You can tell that by [actually reading what she wrote](http://stackoverflow.com/questions/7536988/android-app-out-of-memory-issues-tried-everything-and-still-at-a-loss/7576275#7576275). Activities are not *proactively* removed due to low memory conditions; beyond that, they behave like ordinary Java objects. – CommonsWare Oct 12 '15 at 18:53
  • Sorry then I misunderstood, ty for clarification. – Insignificant Person Oct 12 '15 at 19:15
  • "So calling finish() or Android operating system destroying your Activity doesn't mean it's destroyed in memory but only means it's now in 'destroyed state' (unofficial name)." Is this wrong too? Doesn't Android OS 'destroy' invisible (stopped) activities? – Insignificant Person Oct 12 '15 at 20:05
  • @InsignificantPerson I have suggested this in my answer. You were talking about a single `Activity` though your title mentioned the plural. http://stackoverflow.com/questions/7536988/ deals with plural, which I've always struggled to manage the launch type of (single-top, standard etc). These cases are a great motivator to use `Fragments`. – John Oct 12 '15 at 22:36
2

Each Activity's process is kept in memory until the space is needed or the user forcibly removes it from a process manager like the recents list (holding the home/middle button).

This is the MRU cache pattern. There won't be much left of the Activity after it has exited with finish() and/or onDestroy but the JVM required considerable setup and so is retained solely on the premise that if it was used before it is expected to be needed in future. Unless you need the memory for something else.

John
  • 6,433
  • 7
  • 47
  • 82