Some observations after writing and testing a slightly modified
version of the app shown at the beginning of this thread.

(1) As Dianne points out the BACK key always destroys the Activity and
the HOME key only stops the Activity (correcting my previous
misstatement).

(2) The Dev Tools app setting to "immediately destroy activities"
apparently causes the Activity to be destroyed anytime it is not on
top.  But that doesn't add much to this test because you can use the
BACK key to cause a destroy anyway.

(3) Meminfo has very little to do with JVM memory use.   For one thing
the process has allocated memory for native code and well as for the
JVM itself and for the actual application.  Most JVM's do not return
memory to the OS when their memory use declines -- the JVM just has
more free memory available for future object allocations.  In other
words the JVM high water allocation mark does not recede.  Android
apparently just kills off the whole JVM and the process when it needs
more memory (using a priority ranking for activities and processes
that is documented).  If you want to see what is happening with the
JVM memory use, do something like this before and after garbage
collection -

Runtime rt = Runtime.getRuntime();
Log.d("Service memtest",
     "--- Service Running - memory usage="
     +(rt.totalMemory()-rt.freeMemory()));

In my case the memory usage drops by more than 100Kb after the
Activity is destroyed and GC runs.  So the app really is freeing up
the resources when it is destroyed (this was Mika's concern).

(4)  My meminfo results were slightly different than what Mika
reported at the beginning of this thread.  When the Activity is the
foreground my process had 14 views, 4 AppContexts, 2 ViewRoots, and 2
Activities.  After the Activity was destroyed it had 7 views, 3
AppContexts, 1 ViewRoots, and 1 Activities.  So SOMETHING happened
but I don't know how to interpret theses numbers - why would there be
so many views, etc. for a simple 1 TextView application?



On Oct 21, 10:22 am, Dianne Hackborn <hack...@android.com> wrote:
> On Wed, Oct 21, 2009 at 3:43 AM, Mika <mika.ristim...@tkk.fi> wrote:
> > Well basically because if I want to do some background processing
> > (playing music, tracking location etc.) while the user is doing other
> > things I would want my process to use memory as little as possible so
> > that the system wouldn't kill it. But if my UI i.e. Activities stay in
> > the memory even when they are not used it makes the background process
> > more likely to be killed.
>
> The size of your process doesn't make it more likely to be killed.
>
> And again, if your activity is actually being finished (by you calling
> finish() or the system doing that for you as a result of you pressing back
> in it), then all of the objects associated with the activity will be
> released.  Unless you have leaked some references to it, such as in static
> variables.  You can use the hat tool to look at the objects in your process,
> and follow the references to see why some aren't being garbage collected.
>
> Of course if you press home to leave the app, then the activity is still in
> use, and will remain around if or until the process is killed.  If you want
> to reduce memory use while in this state, you can put code in onStop() to
> free up any heavy-weight resources (such as large bitmaps), and reload them
> on onStart() on onRestart().
>
> > I also tried using some memory extensive
> > apps (Maps, Browser, Camera) but the system still didn't free the
> > activities of my app.
>
> Using memory in other apps has -nothing- to do with "freeing" memory in your
> app.  All it can result in is some not-needed processes being killed if the
> kernel is running low on available memory.
>
> Sorry, I don't have time to debug your app.
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support, and so won't reply to such e-mails.  All such
> questions should be posted on public forums, where I and others can see and
> answer them.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to