I didn't notice meminfo shows 7 views the first time and 14 view the
second time the Activity is started.  So I do get that same results as
Mika (shown at the top of this thread).  But meminfo always shows 1
activity and at least 7 views and 1 activity even after the destroy
(when theoretically there should be no activity or views).

Thanks to Mark for the suggestion of using HierarchyViewer - The 7
views make sense including all the decoration and status bars, etc.
HierarchyViewer still shows 7 views when meminfo shows 14.

My conclusion - Without knowing where meminfo gets its statistics on
views and activities there is no way to determine whether the activity
is fully removed when it is destroyed.  We do know that memory usage
reported by meminfo has little correspondence with JVM free memory. So
Mika's concern about the memory leak doesn't seem to be verifiable
(true or false) with these tools.


On Oct 22, 7:43 am, Mika <mika.ristim...@tkk.fi> wrote:
> Thanks for everybody for helping me with this. I checked the memory
> also with a memory profiler and I suspect that it is SearchManager
> that is keeping a reference to the Activity. And it seems that
> SearchManager is created for default for all the apps even though it
> is never directly invoked.
>
> Anyway, I think I will also file a bug report, because there is
> something strange happening whether it is in the dev tools or in the
> platform. But my sample app is so simple that I'm positive it is not
> leaking anything. As it doesn't in 1.1 OS.
>
> > The size of your process doesn't make it more likely to be killed.
>
> Okey, this I didn't know. I though that when the OS decides to kill
> processes in order to reclaim memory it does it so that the "larger"
> processes are killed first. My mistake, should read the docs more
> carefully.
>
> > (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?
>
> I have these same results if I start the activity close it from back
> button and then start it again.
>
> Anyway, thanks for help everybody. Now it's time to go to fight
> MapActivity memory problems =)
>
> -Mika
>
> On Oct 22, 3:31 am, jotobjects <jotobje...@gmail.com> wrote:
>
> > That may be.  In this test the memory usage by Dalvik reported  by
> > meminfo never decreased even though the JVM Runtime memory usage did
> > fall when the Activity was destroyed.
>
> > The main point is that there is not a close correspondence between
> > memory usage reported by Linux process stats and JVM free memory.  So
> > meminfo is not the best way to detect application memory leaks.
>
> > On Oct 21, 4:27 pm, Mark Murphy <mmur...@commonsware.com> wrote:
>
> > > My understanding was that Dalvik VM returned memory to the OS, but I may
> > > be mistaken.
--~--~---------~--~----~------------~-------~--~----~
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