3

I've an application that has some foreground activities and also a service that updates some widgets. The problem is that, as the process remains for the service, the memory from the other activities ,if they are opened, is never reclaimed.

Looking at that response from Roman Guy it seems that can be normal. But it is? For how much time android keeps the resources of not used activities? They can live for hours?

How can I know easily if the activities are leaked or are simple not reclaimed? I've tried with a program from AndroidMarket (FreeMemoryRecover) and it's cleared but I suspect that it kills the process and then restart the service...

Any help or suggestion will be heavily appreciated.

Note 1: I've investigated with a HeapDump + Eclipse MAT and I don't see strange references holding my activities

Note 2: I've already asked some questions about this problem:

Community
  • 1
  • 1
lujop
  • 13,504
  • 9
  • 62
  • 95
  • Do you have any static objects / singletons that hold references to objects that were initialized with the activity's context? – Lior Jan 29 '11 at 10:16

3 Answers3

1

The ability for Android to have multiple Activities, in different states, is a design principle as it allows users to quickly switch between activities without consciously having to shutdown whatever they were doing before. They can then quickly return to a previous activity.

If Android needs to pause an Activity, and quickly unpause it, it's going to need to keep the Activity's resources available to it.

If the memory is part of a terminated Activity, then it's leaked (very unlikely as the Linux kernel will reclaim all memory that was used when the process terminates), else it's either being actively used or is potentially about to be used.

What is that concerns you about this memory?

trojanfoe
  • 120,358
  • 21
  • 212
  • 242
  • My concerns are best explained in post2 link but to be short: If the user opens some of the foreground activities the process can remain opened forever with more than 30Mb usage (native included). And what I wanted is to be sure if the memory from the activities isn't reclaimed because Android doesn't need it or because I am leaking something. – lujop Jan 29 '11 at 10:09
1

I would try the following :

Launch your app play with it to be sure it is fully loaded and use as much memory as it can.

Then hit the home button and launch the navigator, open techcrunch.com, lemonde.fr, youtube.com, dailymotion.com, launch a video from youtube, open up and play angry bird and last but not least open up a pdf document.

After that Android will have needed the memory back quite for sure. If your app is still there, you might have a problem, if its not, then everything went smoothly.

By the way, good on you to put so much concern in being a good citizen in AndroidLand !!

Yahel
  • 8,522
  • 2
  • 24
  • 32
0

  1. See my comment below your question.

  2. See Romain Guy's post about Android memory leaks.

  3. Specifically, look at the comment on the solution in the Launcher app. (look at unbindDrawables code here)

  4. Use Context.getApplicationContext() whenever possible instead of your activity's context.

Lior
  • 7,845
  • 2
  • 34
  • 34
  • I disagree with #4. Use the activity as the `Context` whenever possible. The application `Context` is effectively a static singleton. Using that `Context` could conceivably result in memory leaks, if whatever you are using that `Context` for results in a link from the application `Context` to other objects. However, the activity `Context` is not a static singleton, and so once the activity can be garbage collected, all references it might have no longer will keep other objects in memory. – CommonsWare Jan 29 '11 at 10:56
  • 1
    BTW, since I assume #4 is echoing Romain Guy's comments from the post you link to in #2, you took his statement out of, er, context. He indicates to use `Application` "if you plan on keeping long-lived objects that need a context", not as a general strategy. – CommonsWare Jan 29 '11 at 11:00
  • Your link in #3 is dead – stevebot Dec 02 '14 at 23:41