Discussion on "Callback leaks: cancel your Picasso requests!"

Pierre-Yves Ricau · 2023-01-17T21:06:14.461Z

👋 Hi, this is P.Y., I work as an Android Engineer at Block. Every month I organize an internal Ensemble Leak Hunting session where we look at the top leaks reported by LeakCanary to learn how to read

Thanks for your reply. I agree with your point that it is best practice to cancel the request once the ImageView is ready to be destroyed to save the network/cpu resource.

My concern here is

onDetachedFromWindow is the callback on View instead of Activity/Fragment. So it might be an issue when the ImageView is inside one of the ViewPager. Refer to "Android view - onAttachedToWindow and onDetachedFromWindow - when are they called in the activity lifecycle" in StackOverFlow.
Besides, I tried to understand why the leak happens here. The root cause seems to me that the ImageView instance gets referenced by the callback which is encapsulated into ImageViewAction. For example, if we did show a snackBar inside the callback instead of imageView.setBackgroundColor(), it would not be a memory leak because imageView is garbage collected properly and the callback too I think.

In my mind, the root cause is exactly the WeakHashMap warning you mentioned. But it is the best solution to cancel the request when Activity/Fragment arrives in the destroyed state.

Search Hashnode

Callback leaks: cancel your Picasso requests!

Responses