tgoop.com/dev_easy_notes/119
Last Update:
LeakCanary начинает поиск пути к ссылке из-за которой произошла утечка с получения копии (dump) памяти. Любая jvm предоставляет такой функционал. Так мы получаем копию всех объектов памяти JVM в удобном формате чтобы можно было проводить анализ. Чтобы получить копию памяти в Android достаточно вызвать функцию Debug.dumpHprofData. В эту функцию передаем путь к файлу, а дальше система все сделает за нас.
Итак мы получили файл, в котором лежит информация в всех объектах JVM в определенный момент времени. Дальше нужно как-то начать поиск утечки. У нас куча объектов и не особо понятно с чего вообще нужно начинать поиск. LeakCanary использует не обычные Weakreferece а свой подкласс KeyedWeakReference. В этом классе есть дополнительная инфа о том, ссылается ли эта ссылка на утёкший объект, или нет.
Чтобы дальше понимать реализацию нужно вспомнить что такое GC root? GC root это корни от которых тянутся все ссылки в heap. В частности это ссылки в стеке, потоки, статические ссылки, сlassloaders, думаю суть понятна.
Анализатор утечек в полученной копии памяти ищет объекты класса KeyedWeakReference. Затем просто по ссылке смотрит на какой объект они ссылаются. Таким образом мы находим утекший объект, это либо может быть Activity, View и т.д все что можно утечь. После того как мы нашли что за объект утек, нужно простроить путь до GC root чтобы найти ссылку из-за которой он утек. Для этого используется алгоритмы графов для поиска кротчайщего пути ииии на этом все.
Сама концепция довольно простая, но реализация это целый rocket sciencе который я тут не буду описывать, потому как сам этот алгоритм тянет на целый доклад. Серьезно, можете разобрать этот алгоритм и выступить, я бы сходил послушать)
BY Dev Easy Notes
Share with your friend now:
tgoop.com/dev_easy_notes/119