deepaktwr / BitFrames

Frame of Bitmaps, Facebook like image sequence.
https://play.google.com/store/apps/details?id=proj.me.bitframedemo
Apache License 2.0
17 stars 4 forks source link

WeakReference of items got collected in RV, without view item being recycled #7

Open deepaktwr opened 7 years ago

deepaktwr commented 7 years ago

In case of loading images in view items the weak reference implementation has been decided in case of creating handlers and getting messages.

Though it safe to keep weak references of callback to view items in handler, it got collected when multiple view item came a sequence. For example:

let say their are total 20 items, if RV currently showing item 10, 11 and 12 then 11th item would still be visible if we scroll to 9th or 13th item number. Now in the case when image loading process goes into action for 10, 11, 12 and before result came we again scroll down and up to 9th and 13th items, now more images to load in queue(10 and 12 reloading process will also got fired in case of 13th and 9th item scrolling). now due to memory requirement the Weak Reference passed to Handler got collected, regardless it's currently attached to the visible view item. but Issue of activity leak might come due to holding strong reference #6

deepaktwr commented 7 years ago

As the weak reference has no relation with view item attachment whenever the memory will be required it might get collected regardless of view attachment to it's strong reference.

Their should be a different solution to that.

The steps are:

call fetching -> fetching in background(has a weak reference as callback) -> passing to handler for setting or recycling(has a weak reference as callback).

these are in sequential steps when multiple image go into processing for a single frame. so that steps 2 and 3 might generate problem in case of RV as multiple position will fetch images and consume memory and might force Android system to collect weak reference.(we may try to reclaim those objects)

deepaktwr commented 7 years ago

A strong reference reachability is required to hold the next weak reference; may not be hold if it's not global as the life of weak reference is highly dependent on it's strong reference reachability.