Memory leak on configuration change...

[Nevro]

After 25 rotations, sample gets out of memory...

Any workaround?

On sample start...

After 10 rotations...

[Nevro]

@nostra13 ??

[shem8]

Same here, any suggestions?

[nostra13]

I'll investigate this issue when I have free time.

[vitakot]

Hi,

I made a test with the MAT tool and found there are memory leaks even without a configuration change. I just started the sample app, selected ListView activity, then back and repeated it a few times. The heap grows by 25 kB, and the number of allocated objects increases from 55382 to 55680 per each 10 repetitions.

Device: Nexus 7, Android 4.2.2

[rvgrinsven]

Same issue for me here. Any pointers in what part of the code the problem is?

[Nevro]

Kicked out from project and replace with volley :)

[koded101]

@Nevro What's volley?

[varundroid]

@koded101 it looks like you didn't watch Google I/O. Volley is a new android library. It makes dev's life much easier now. Check it out on YouTube.

[shem8]

Volley is great, but we still need Universal-Image-Loader for local images

[koded101]

Volley looks nice but couldn't get it to work. Oh well UIL is still great!

[nostra13]

@Nevro These widgets "Foregroud App" and "CPU" are standard or it's special app? Which is?

[Nevro]

It's PerfMon by Chainfire

https://play.google.com/store/apps/details?id=eu.chainfire.perfmon

[cuceda]

Hi,

You're leaking the whole Activity because you are passing trough the ImageView. All views have a reference to the their Activity.

When a rotation is made the Activity is destroyed and recreated again. So this new Activity has a also a new ImageView object, whereas the ImageDownloading is retaining an old object which is not displayed any longer to the user.

If no cache is being used, a rotation while processing a download implies a new download request :(

Sorry because I like very much your code design, but is not correct.

[nostra13]

@cuceda Rotation doesn't cause any redundant downloading. Every image is loaded only once, UIL handles it.

@Nevro Thanks for your issue. I investigated it and reproduced this problem. Memory leak really exists because of many waiting threads which keep reference of ImageView (and hence whole Activity). This is true especially for tasksProcessingOrder(QueueProcessingType.LIFO). I created branch "weak_imageview_ref" for solution of this problem. I try to avoid keeping strong references of ImageViews in tasks/threads. And actually it shows great result, soon I'll merge it into "master" branch.

[cuceda]

"Memory leak really exists because of many waiting threads which keep reference of ImageView (and hence whole Activity)". Yeah, that is what I said, isn't it?

"I try to avoid keeping strong references of ImageViews in tasks/threads". This guy also tried that approach, and his code throws an error when the view is destroyed before the image is downloaded because the WeakReference is a null pointer:
http://android-developers.blogspot.com.es/2010/07/multithreading-for-performance.html