Debug.dumpHprofData. В эту функцию передаем путь к файлу, а дальше система все сделает за нас. Итак мы получили файл, в котором лежит информация в всех объектах JVM в определенный момент времени. Дальше нужно как-то начать поиск утечки. У нас куча объектов и не особо понятно с чего вообще нужно начинать поиск. LeakCanary использует не обычные Weakreferece а свой подкласс KeyedWeakReference. В этом классе есть дополнительная инфа о том, ссылается ли эта ссылка на утёкший объект, или нет.
Чтобы дальше понимать реализацию нужно вспомнить что такое GC root? GC root это корни от которых тянутся все ссылки в heap. В частности это ссылки в стеке, потоки, статические ссылки, сlassloaders, думаю суть понятна.
Анализатор утечек в полученной копии памяти ищет объекты класса KeyedWeakReference. Затем просто по ссылке смотрит на какой объект они ссылаются. Таким образом мы находим утекший объект, это либо может быть Activity, View и т.д все что можно утечь. После того как мы нашли что за объект утек, нужно простроить путь до GC root чтобы найти ссылку из-за которой он утек. Для этого используется алгоритмы графов для поиска кротчайщего пути ииии на этом все.
Сама концепция довольно простая, но реализация это целый rocket sciencе который я тут не буду описывать, потому как сам этот алгоритм тянет на целый доклад. Серьезно, можете разобрать этот алгоритм и выступить, я бы сходил послушать)