Yeah, a weak reference is fair game as soon as there are no "strong" references to the object. A soft reference is kept until it's "aged" a little. Different platforms have different algorithms for "aging out" soft references, but the idea is to let them persist for a few GC cycles at least.
On Jul 24, 4:56 pm, Agus <agus.sant...@gmail.com> wrote: > 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
