GC can reclaim WeakReference even memory is still plenty, but SoftReferences will only be cleared when the system is just about to starve out of memory..
On Sat, Jul 24, 2010 at 2:25 PM, Joseph Earl <joseph.w.e...@gmail.com> wrote: > I did say '(although I would use SoftReference for the purpose > described here).' But it wasn't clear enough I agree (and because I > admittedly wasn't sure enough about the differences) > > On Jul 23, 4:25 pm, Matt Quigley <matthew.quig...@gmail.com> wrote: >> On Jul 23, 2:37 am, Indicator Veritatis <mej1...@yahoo.com> wrote: >> >> > You left out something very important: the code hidden under "// >> > reload the image" must not assume that it is not itself interrupted by >> > yet another call to the garbage collector. That is, instead of simply >> > continuing to use the soft/weak reference, it should make a strong >> > reference to the same object, allowing this latter reference to either >> > go out of scope or be set to null when it is done. >> >> You are referring to the code that Joseph Earl wrote above. That code >> snippet is NOT a proper way to use weak references; that cache should >> be using soft references. >> >> On the other hand, in the example blog post referred to by the OP, >> which uses weak references, that IS a proper way to use weak >> references. The main Activity already has a strong reference to the >> objects. The secondary thread does not need to create a strong >> reference; in fact, that would make the weak reference useless. >> >> > But if we are making this strong reference, what was the point of >> > using the weak/soft reference in the first place? Ah, that is the >> > tricky thing about using them. Depending on when you can make and >> > release the strong reference, they might not buy you much; they might >> > not buy you anything at all. That is why they are not recommended for >> > much outside of caches and normalized mappings. >> >> You are referring to a soft reference, not a weak reference. Soft >> references are good for caches. Weak references are definitely >> recommended for the idea given in the article, where the main thread >> has a strong reference, and the background thread has a weak >> reference. That way if the main thread is killed (i.e. the app is >> finished), if the background thread is still running then it won't >> prevent the weakly referenced objects from being destroyed. >> >> I also hate to throw this bit of information into the mix, but it >> should be known that Android will kill your process, and hence >> background threads anyways, when all your main threads have been >> destroyed (i.e. all your activities are finished, and there aren't any >> services running). This means that, even if you did have a background >> thread running, it would be killed, implying that weak references >> wouldn't help because everything is going to get killed anyways. That >> being said, there are still circumstances where the weak references >> matter: just because one activity is finished, doesn't mean all of >> your app's activities are necessarily finished. So it would be good >> if you went from your main activity into another sub-activity which >> began a download. But then the user presses back, because they don't >> want to bother waiting on the download. In that case your main >> activity is still alive, but the background thread is working on the >> sub-activity that was already finished. If that background thread had >> weak references, then that background thread would no longer be >> holding on to the resources of the sub-activity with strong >> references, and the system could GC those resources already, before >> the background thread dies. >> >> -Matt >> >> -Matt > > -- > 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 -- 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
