There is nothing special in my sample app. It is bare born simple app that consits of may be 50 lines of code and two classes. If you wish, I can send you source code, you can see for yourself. Again, there is no static or non-static members in any of the classes.
On May 17, 6:26 pm, Romain Guy <romain...@android.com> wrote: > There must be something else going on in your app. All standard apps > rely on onDestroy() being called and certainly do not do all you > mentioned in your message. > > Be very careful with what you do with the Context. An Activity is a > Context and you might be leaking it without knowing it. What you are > observing is definitely not a normal behavior. > > > > > > On Mon, May 17, 2010 at 3:20 PM, ls02 <agal...@audible.com> wrote: > > We found there are very nasty memory and resource leaks in activities > > and views that we don't know how to handle. I have test app that > > basically starts activity A, that immediately starts activity B and B > > starts A and so forth in infinite loop. Each activity displays its own > > bitmap in image view. After X cycles JVM runs out of memory. There are > > no static or any other references to bitmaps or views or anything > > else. > > > It seems that when one activity launches another a new instance of > > that activity is created (constractor is called, then onCreate, then > > onResume, the launching activity is paused and its onPause is called). > > onDestroy is almost never called. When new instance is created old one > > probably still holds references to view and bitmap so they are not > > freed. > > > The only way we found to prevent JVM from running out of memory is to > > do ALL this from onPause and onDestroy: > > > 1. Get image view drawable and set its callback to null. > > > 2. Set image view background drawable to null. > > > 3. Set ANOTHER view to activity (probably this removes activity > > reference from the image view). > > > 4. Get the bitmap, call its recycle() method, set its handle to null > > and then run GC with System.gc(). > > > If ALL these steps are executed JVM flips these image activities > > infinitely without running out of memory. Obviously, it is very hard > > to implement this solution when you have complex view with zillion of > > different images and more then a dozen of activities. > > > What's the best and proper solution to aforementioned problem? > > > -- > > 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 > > -- > Romain Guy > Android framework engineer > romain...@android.com > > Note: please don't send private questions to me, as I don't have time > to provide private support. 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 > athttp://groups.google.com/group/android-developers?hl=en- Hide quoted text - > > - Show quoted text - -- 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
