Введение в LeakMonitor

Используйте проблему утечки собственной памяти для мониторинга приложения. Основной принцип:

• перехватывайте вызовы malloc/free и другие методы выделения памяти, чтобы записывать метаданные о выделении собственной памяти («размер», «стек», «адрес» и т. д.);
• периодически используйте алгоритм mark-and-sweep для анализа собственной кучи всего процесса и получения информации о «адресе», «размере» недоступного блока памяти;
• используйте адрес, размер и т.д. недоступного блока памяти, чтобы получить его стек выделения из записанных нами метаданных и создать данные об утечке («адрес недоступного блока памяти», «размер», «стек выделения» и т. д.).

Область применения LeakMonitor:

• Android N и выше (API level >= 24);
• только arm64-v8a.

Начало работы с LeakMonitor

1. Настройка зависимостей:
   • добавьте mavenCentral в репозитории корневого каталога проекта build.gradle:

repositories {
    mavenCentral()
}

* добавьте зависимость в проект app/build.gradle:

dependencies {
    implementation "com.kuaishou.koom:koom-native-leak:${latest_version}"
    implementation "com.kuaishou.koom:xhook:${latest_version}"
}

2. Использование кода:
   • инициализируйте MonitorManager, см. здесь;
   • поскольку LeakMonitor зависит от MonitorManager, убедитесь, что MonitorManager был инициализирован;
   • инициализируйте LeakMonitor:

......
LeakMonitorConfig config = new LeakMonitorConfig.Builder()
    .setLoopInterval(50000) // Устанавливаем интервал опроса, единица измерения — миллисекунды
    .setMonitorThreshold(16) // Устанавливаем порог отслеживаемого блока памяти, единица измерения — байт
    .setNativeHeapAllocatedThreshold(0) // Устанавливаем порог объёма памяти, выделенной собственной кучей, для начала мониторинга, единица измерения — байт
    .setSelectedSoList(new String[0]) // Устанавливаем библиотеки мониторинга, такие как мониторинг libcore.so, просто напишите 'libcore'
    .setIgnoredSoList(new String[0]) // Устанавливаем библиотеки, которые необходимо игнорировать при мониторинге
    .setEnableLocalSymbolic(false) // Включаем локальный символьный режим, это полезно в режиме отладки. Не включайте в режиме выпуска
    .setLeakListener(leaks -> { }) // Устанавливаем прослушиватель утечек для получения записей об утечках
    .build();
MonitorManager.addMonitorConfig(config);
......

* запустите LeakMonitor для периодического мониторинга:

......
LeakMonitor.INSTANCE.start()
......

* остановите LeakMonitor, обычно этого делать не нужно:

LeakMonitor.INSTANCE.stop()

* активно получите утечки и получите информацию об утечках в `LeakListener`, обычно нет необходимости активно проверять:

LeakMonitor.INSTANCE.checkLeaks()

Часто задаваемые вопросы

• Почему устройства ниже Android N не поддерживаются?
  • AOSP добавил модуль libmemunreachable после Android N. Конечно, вы также можете извлечь его самостоятельно и протестировать в приложении. Учитывая распространённость утечек памяти, мониторинг только устройств с Android N или выше должен решить большинство проблем.
• Почему не поддерживается armeabi-v7a?
  • При получении стека выделения памяти мы использовали FP Unwind (frame pointer unwind) из соображений производительности. В то время как armeabi-v7a использует смешанные инструкции ARM/Thumb, а FP Unwind ненадёжен на смешанном методе стека инструкций ARM/Thumb. AArch32 (Arm 32-bit Architecture) также не определяет поведение FP.
• Каковы накладные расходы на производительность LeakMonitor?
  • Из-за необходимости получать и сохранять метаданные, такие как стек блока памяти, возникают определённые накладные расходы на производительность. Согласно нашему тесту, общие потери производительности составляют <5%, что в основном не влияет на работу пользователя. Для онлайн-использования настоятельно рекомендуется включить «Выборка на устройствах с лучшей производительностью».
• Обнаруживаются ли утечки на 100%?
  • Согласно принципу обнаружения и опыту, точность обнаружения утечек может достигать в основном 90%+ и могут быть отдельные плохие случаи. Используется неточный алгоритм mark-and-sweep, и анализ достижимости всегда выполняется в соответствии с 8 байтами во время анализа, что не является точным на 100%. Грязная память аллокатора памяти, некоторая утечка памяти может быть доступна и влиять на результат.