When your UI activity is killed as far as I am aware the GC will
collect your Views. The problem is (I think) if the GC closes your UI
thread while the downloader is still running - in this case your
downloader thread maintains a reference to the ImageView so the GC
cannot collect it - hence memory leak - the downloader thread cannot
actually do anything to the ImageView since the UI thread no longer
exists.
Thus the downloader thread should only store a weak reference to the
ImageView so that if the UI thread is killed the GC may reclaim the
memory associated with the ImageView.
On Jul 22, 8:34 pm, GodsMoon <godsm...@gmail.com> wrote:
> The blog post is confusing.
> "Note that this ImageView is stored as a WeakReference, so that a
> download in progress does not prevent a killed activity's ImageView
> from being garbage collected."
> I didn't know that would cause a memory leak. I thought the garbage
> collector would clean up ImageView if its activity gets killed.
> Am I wrong?
>
> David Shellabargerwww.nightshadelabs.com
>
> On Jul 22, 3:06 pm, Joseph Earl <joseph.w.e...@gmail.com> wrote:
>
> > No. I'm unsure as to what to use a WeakReference for exactly - as
> > Romain Guy said above it is too weak for this purpose, but I think
> > (hopefully Romain will correct me if I'm wrong) that a SoftReference
> > could be suitable for this purpose.
>
> > A ListView already does efficient management of your Views by
> > recycling. This means that you must ensure the correct details are set
> > in the view each time getView is called, even if you do not inflate a
> > view or call findViewById that time. Recycling does not mean that the
> > ListView caches all your items or their content.
>
> > Suppose you had a list of 10 items, all of the same type but only 5
> > will fit on the screen at a time. The ListView only really needs 5
> > views to show the rows since the other 5 won't be visible.
> > Thus at the top of the list the ListView might use 'View 1' for the
> > first item, but scroll down to the bottom and 'View 1' would now
> > contain item 6. As far as I understand it this is recycling.
>
> > Recycling does not take care of the amount time of it takes to get
> > content and set it to the view - thus if it takes a long time to get a
> > piece of information and display it in a list item (such as
> > downloading an image from the web), you will want to cache the result
> > in a way that does not adversely affect memory usage (as much as
> > possible). In this case you will also want to use a Thread or Async
> > task to download/get the info off the UI thread.
>
> > On Jul 22, 7:36 pm, GodsMoon <godsm...@gmail.com> wrote:
>
> > > So you'd only want to use WeakReference when you think your activity
> > > might run out of memory?
> > > But a list view already does efficient memory management for you
> > > right?
>
> > > You'd saying if I were create a large array or something like that
> > > then it would be good to use WeakReference. right?
>
> > > Thanks for the help guys,
> > > David Shellabargerwww.nightshadelabs.com
>
> > > On Jul 22, 2:26 pm, Romain Guy <romain...@android.com> wrote:
>
> > > > You definitely do NOT want to use a WeakReference to cache object. If
> > > > you do so, as soon as your data is put in the cache and not used
> > > > outside of the cache, it gets garbage collected.
>
> > > > On Thu, Jul 22, 2010 at 11:07 AM, Joseph Earl <joseph.w.e...@gmail.com>
> > > > wrote:
> > > > > Suppose you had a long list of images. As the user scrolled down you
> > > > > load the images from the net, and then display them.
> > > > > To avoid having to reload the images again if the user scrolls back
> > > > > up, you put the images in a cache (probably something like a
> > > > > Map<String, Drawable>)
>
> > > > > However because it is a long list you don't want to run into an out of
> > > > > memory situation if the user scrolls very far down and lots of images
> > > > > are put in the cache.
> > > > > So instead of storing the Drawables directly in the map, you create a
> > > > > Map<String, WeakReference<Type>> (although I would use SoftReference
> > > > > for the purpose described here).
> > > > > This means that if Android is going to encounter an out of memory
> > > > > situation it will clear all of the Soft/Weak references (and thus
> > > > > hopefully avoid running out of memory). You will have to load the
> > > > > images again since your cache has been cleared, but this is far better
> > > > > than your application running out of memory and crashing.
>
> > > > > So you do something like:
>
> > > > > // caching an image
> > > > > Map<String, SoftReference> cache = new HashMap<String,
> > > > > SoftReference<Drawable>>();
> > > > > cache.put("http://mysite.com/images/1.jpg";, new
> > > > > SoftReference<Drawable>.put(myDrawable));
>
> > > > > // retrieve an image
> > > > > if (cache.containsKey(url)) {
> > > > > // looks like we have this image cached
> > > > > Drawable drawable = cache.get(url).get();
> > > > > if (drawable == null) {
> > > > > // the softreference has been cleared by the GC, reload the
> > > > > image
> > > > > } else {
> > > > > // softreference is still valid, got our image
> > > > > }
> > > > > }
>
> > > > > Essentially a weak reference is a weaker reference than a soft
> > > > > reference - the GC should free weak references to regain memory before
> > > > > soft references.
>
> > > > > I think that's (mostly) correct, hope it helps.
>
> > > > > On Jul 22, 6:48 pm, GodsMoon <godsm...@gmail.com> wrote:
> > > > >> Google just posted a new blog post
> > > > >> onhttp://android-developers.blogspot.com/2010/07/multithreading-for-per....
> > > > >> I understand the AsyncTask and I'm even using one in a list with
> > > > >> images already.
>
> > > > >> But I don't understand what a WeakReference is. I gather is is a
> > > > >> garbage collector directive, but I thought I didn't need to manage
> > > > >> garbage collection on Android.
>
> > > > >>http://developer.android.com/reference/java/lang/ref/WeakReference.html
> > > > >> isn't as helpful as I was hoping it would be.
>
> > > > > --
> > > > > 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 at
http://groups.google.com/group/android-developers?hl=en
![http://mysite.com/images/1.jpg"](http://mysite.com/images/1.jpg"){kind=link}