3

I've written a pretty standard Android app that displays a bunch of pictures (from Contacts) in a GridView. The app doesn't do anything special to try to retain data on screen orientation changes, and just recreates the GridView, adapter and loader when the Activity is recreated.

However, after a few orientation changes, the app slows down; after a few more, it crashes with an out-of-memory error (at BitmapFactory.decodeStream()). This still happens if I leave it sit for a minute between rotations to let the garbage collector do its thing.

I was under the impression that Android would free all memory associated with an Activity when the Acitivty is destroyed during orientation changes. However, this seems not to be the case. My question is: what memory could I be inadvertently retaining despite Activity destruction?

(Note that the app runs fine so long as it is not subjected to too many orientation changes, so the general approaches to memory minimisation that I'm using are sufficient.)

Peter McLennan
  • 371
  • 4
  • 11
  • Usually, this is caused by using static references to bitmaps or by passing the activity context to some other class which retains a reference to it. Are you doing anything like this? Posting onCreate() and onResume() would help. MAT will show you what is not being collected. PS. Garbage collection works just fine. – Simon Oct 21 '13 at 07:56
  • Take a look at this and my answer about unbinding the drawables. http://stackoverflow.com/questions/14759601/proper-ondestroy-how-to-avoid-memory-leaks/14759756#14759756 – Simon Oct 21 '13 at 08:51
  • @Simon: thanks! I think you're right: I'm using a non-static inner class as a ViewHolder as per http://developer.android.com/training/contacts-provider/display-contact-badge.html. However, as I now understand it, the Views therein will retain references back to the context. I'll try to rework this as a static inner class and see what happens. I've also studied my onCreate and onResume but I don't think there's anything of interest there. And if I knew how I could easily extract the on-screen bitmaps from within the GridView during onDestroy, I'd explicitly unbind them. – Peter McLennan Oct 23 '13 at 06:18

1 Answers1

1

I think you forgot add bitmap.recycle();

Also easy method fix this, add to AndroidManifest, activity parameter: android:configChanges="orientation|screenSize"

artemiygrn
  • 1,036
  • 7
  • 18
  • How will this hack, which even Google says should be used only as a last resort, fix a memory leak? – Simon Oct 21 '13 at 07:58
  • Activity don't be re-create, this means bitmap don't be created, and will use the old. You can avoid this, if will be use **recycle** method, like above – artemiygrn Oct 21 '13 at 08:00
  • The activity will be re-created in a lot more scenarios than just changing the orientation. All this does is hide the bug. You add this, change the screen and it doesn't crash. But the bug is still there. Now try plugging in a car docking station, or putting the app in the background and receiving a call, or changing the region etc etc. This is a hack which does not fix the problem. – Simon Oct 21 '13 at 08:03
  • No, this options that you suggested, activity not will be re-created. In this options activity will be call **start**, **stop**. – artemiygrn Oct 21 '13 at 08:07
  • Why don't you just try it? Run your app. Put a breakpoint in onCreate(). Now change the region. What happens? However, it's pointless debating this. If you want to use a hack which Google say should not be used, you just go ahead. The app store is already littered with apps that have this bug. – Simon Oct 21 '13 at 08:16
  • 2
    I personally checked, when calling is **not** called **onDestroy** **onCreate** methods. This is not a hack, because this **configChanges** **need not** use if your activity have a difference layout, if one layout, this **configChanges** only accelerate your app. – artemiygrn Oct 21 '13 at 08:24
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/39625/discussion-between-kvirair-and-simon) – artemiygrn Oct 21 '13 at 08:34
  • I don't know to which conclusion you both came, but this worked perfectly in my case. – AndacAydin Apr 11 '16 at 20:04