Утечка памяти наверное одна и самых неприятных ошибок которую можно совершить при разработке. Она может привести к лагам на устройстве и порой даже крэшу. В предыдущих постах я упоминал, что сделать утечку памяти можно даже не подозревая об этом. Насколько бы вы внимательно не относились к коду из-за человеческого фактора такая ошибка рано или поздно всплывет. Причем утечка памяти может быть даже в библиотеках от гугла.

Естественно эту проблему нужно было как-то решать. Поэтому был создан инструмент, который позволяет находить утечки памяти во время тестирования работы приложения. Возможно вы уже натыкались на этот инструмент – LeakCanary. Библиотека максимальна проста в использовании при этом позволяет быстро найти корень проблемы. LeakCanary следит за приложением, проводит анализ в фоне, сохраняет результаты, даже строит путь до ссылки из-за которой произошла утечка.

При всем при этом, со стороны клиента ничего не нужно делать. Просто указал либу в зависимостях gradle, и она сама начинает работать. Естественно инженерное любопытство заставляет задаться вопрос, а как работает эта технология?

Я планировал сделать один пост по тому, как работает leak canary, но в ней перемешано столько интересных технологий, что я решил разбить на несколько постов. Каждый их которых будет разбирать отдельную часть библиотеки и отвечать на конкретный вопрос:

👉 Как она запускается, хотя мы в коде ничего не прописывали?
👉 Откуда берется отдельный ярлык, который позволяет посмотреть историю всех утечек конкретного приложения?
👉 Как leak canary вообще находит утечки?
👉 Как находится ссылка из-за которой произошла утечка?