The Activity starts to change configurations - is mercilessly torn down and recreated - but the previously existing and held reference keeps the Activity context and all its inflated Views alive, the garbage collector cannot finalize them. By the way, what’s a memory leak in the context of Android anyway?įor those that don’t know, it can happen when you have a reference to an Activity context in something that outlives the Activity. So let’s embark on a journey and assess why using a WeakReference is not the right solution, and what other options we have to solve the memory leak and the real problem. In fact, the only articles that mention that this is not the correct approach are comments by Vasiliy Zukanov on some Medium posts. Once I explained the real problem, he said “this is a different problem, but now I know why we shouldn’t use WeakReference”.īut that brings us to here, because apparently people managed to NEVER write an article about why you shouldn’t use WeakReference (or WeakReference, or WeakReference) to “fix” your memory leaks (related to configuration changes and asynchronous callbacks, AsyncTask and the like)! Show me an article that explains the real problem you talk about and why I shouldn’t use a WeakReference”. To which I said, “that’s great, except that’s a hack, and it doesn’t solve the real problem, so don’t.”Īnd then he said: “But I don’t understand what you mean. I looked for a solution and saw that we can use a WeakReference to wrap the Activity context, that way it won’t leak.” My co-worker told me the following: “You said there can be a memory leak here.
Using WeakReference is just as hideous as this color scheme.
0 kommentar(er)
