
LeakCanary: Detect all Android memory leaks - juandg
https://corner.squareup.com/2015/05/leak-canary.html
======
pilif
Seeing yet another android related open source project by square, I'd like to
use the opportunity to leave a huge "thank you" here.

Between Picasso, Retrofit and especially okhttp, square has done such an
amazing job to make android developers lives so much easier. The three
projects are a pleasure to work with, have excellent documentation and very
clear APIs.

So, yeah, a huge heartfelt "thank you" from me.

~~~
amenghra
Want to come build the next great Android project?
[https://squareup.com/careers](https://squareup.com/careers) ;)

------
wyldfire
Is this a true "leak"? Maybe I'm naive but I would think you couldn't have a
leak without using JNI. Maybe a reference cycle is hard/impossible to GC?

>Later, in a background thread, it checks if the reference has been cleared
and if not it triggers a GC. > If the reference is still not cleared ...

Sounds to me like it's not a leak so much as unbounded-memory-growth.

But sounds like a useful tool. And I guess you can suppress warnings using
AndroidExcludedRefs.java if you have intentional cycles.

~~~
georgemcbay
> Is this a true "leak"?

By most people's definition of the term, sure. It ends up being a loss of
memory within an object or set of objects that no longer have any practical
use to the application and the irreclaimable memory can grow over time.

> Maybe a reference cycle is hard/impossible to GC

This is basically the issue.

It is relatively common (particularly among younger programmers who haven't
been bitten by this already) to have a situation where you have an Android
Activity that creates and holds a reference to an event listener which traps a
reference to the activity itself. If the Activity doesn't clean up the the
listener reference in its onDestroy (which is an Android lifecycle callback,
not related to the Java GC) and neither reference is a WeakReference you wind
up with a listener object which references the activity and an activity which
references the listener object, neither of which is suitable for naive garbage
collection... so now you have this lingering Activity object that is probably
no longer associated with the application's window but lives on. If the app is
designed such that the user keeps pathing through this Activity and the
activity consumes lots of memory, it isn't hard to get fatal OOMs from this
situation.

~~~
gumballhead
From what I've seen, Java's GC is smart enough to clean up circular
references. That actually surprised me. The main danger I've seen in Android
is that there is a lot of passing around Contexts as a dependency for
accessing Android resources, many of which are meant to be short lived, like
Activities. Sometimes a class will save that context as an instance variable.
And sometimes you might want to cache that class statically, so if you aren't
careful, you'll prevent something like an Activity from garbage collection.

