LeakCanary — bu nima, Android-da oqishlarni qidirish kutubxonasi

LeakCanary nima?

LeakCanary — bu Square kompaniyasi tomonidan ishlab chiqilgan Android ilovalarida xotira oqishlarini avtomatik aniqlash uchun kutubxonadir. U ilova qurish jarayoniga integratsiyalanadi va yo'q qilinishi kerak bo'lgan ob'ektlar (Activity, Fragment, View) xotirada qolib ketganda avtomatik kuzatib boradi. Oqish aniqlanganda, LeakCanary heap dump yaratadi va ob'ektni ushlab turgan havolalar zanjirini tahlil qiladi.

Kutubxona Android jamoasida standartga aylandi: GitHub ma'lumotlariga ko'ra, loyiha 28 mingdan ortiq yulduz to'plagan va Google, Uber, Airbnb va Facebook ilovalarida qo'llaniladi. LeakCanary ikkita asosiy versiyada mavjud: klassik 1.x (qo'lda sozlash bilan) va zamonaviy 2.x (ContentProvider orqali avtomatik integratsiya). 2.x versiyasi Application sinfini o'zgartirishni talab qilmaydi — to'liq ishlash uchun bitta bog'liqlik yetarli.

LeakCanary-ning asosiy vazifasi — ob'ektning hayotiy sikli tugaganidan keyin ham xotirada mavjud bo'lish holatini aniqlash. Bu statik maydonlar, singletonlar, ro'yxatdan o'tkazilmagan callbacklar, anonim sinflar va tashqi ob'ektlarni tutib oluvchi yopilishlar orqali oqishlar uchun xosdir.

Nega LeakCanary Android rivojlanishi uchun muhim

Android-da xotira oqishlari mobil qurilmalardagi cheklangan RAM hajmi tufayli desktop-ga qaraganda muhimroqdir. Har bir ekran almashinuvida atigi 5–10 MB oqish ham ilovadan 30–40 daqiqa foydalanishdan keyin OutOfMemoryError-ga olib kelishi mumkin. LeakCanary bunday muammolarni rivojlanish bosqichida aniqlaydi, ishlab chiqarishdagi nosozlikni kutmasdan.

LeakCanary qanday ishlaydi?

LeakCanary majburiy garbage collector chaqiruvi bilan birgalikda zaif havolalardan (WeakReference) foydalanadi. Activity yoki Fragment onDestroy chaqirganda, LeakCanary ushbu ob'ektga WeakReference yaratadi va qisqa kechikishdan keyin (standart 5 soniya) GC-ni ishga tushiradi. Agar GC-dan keyin ob'ekt hali ham WeakReference orqali mavjud bo'lsa, demak u kuchli havola bilan ushlab turilgan — oqish qayd etiladi.

Oqish aniqlangandan so'ng, LeakCanary heap dump (HPROF formatidagi ilova xotirasining to'liq surati) yaratadi. Keyin o'rnatilgan analizator (2.x versiyasi uchun Shark) GC Roots-dan oqqan ob'ektgacha erishish grafigini quradi va eng qisqa yo'lni — ob'ektni xotirada ushlab turgan havolalar zanjirini topadi.

// LeakCanary aniqlash mantiqining soddalashtirilgan versiyasi
class ObjectWatcher {
    private val watchedReferences = CopyOnWriteArrayList<KeyedWeakReference>()

    fun watch(watchedObject: Any, description: String) {
        val reference = KeyedWeakReference(watchedObject, description)
        watchedReferences.add(reference)
        BackgroundHandler.postDelayed({
            checkForLeaks()
        }, 5000)
    }

    private fun checkForLeaks() {
        GcTrigger.runGc() // majburiy GC
        for (ref in watchedReferences) {
            if (ref.get() != null) {
                onLeakFound(ref) // ob'ekt GC dan omon qoldi — bu oqish
            }
        }
    }
}

Asosiy nuqta — majburiy GcTrigger.runGc() chaqiruvidir. Usiz, haqiqatan oqqan ob'ektni GC hali yig'ishga ulgurmagan ob'ektdan farqlash mumkin emas. LeakCanary buni uch martagacha bajaradi: agar uchta GC siklidan keyin ob'ekt hali ham xotirada bo'lsa — oqish tasdiqlanadi.

Shark nima — heap dump analizatori

Shark — bu Kotlin tilida yozilgan LeakCanary 2.x ga o'rnatilgan heap dump analizatoridir. Oldingi HAHA analizatoridan farqli o'laroq, Shark butun HPROF faylini xotiraga yuklamaydi, balki uning ob'ekt grafigini minimal ajratmalar bilan aylanib chiqadi. Bu tahlil paytida RAM iste'molini 50 MB dan 2–5 MB gacha kamaytiradi va tahlil vaqtini 30 soniyadan 1–3 soniyagacha qisqartiradi.

LeakCanary-ni qanday o'rnatish va sozlash?

Zamonaviy Android loyihasida LeakCanary 2.x o'rnatish build.gradle-da bir satrni oladi. Kutubxona avtomatik ishga tushirish uchun ContentProvider-dan foydalanadi — Application sinfini o'zgartirish yoki MainActivity-ga kod qo'shish shart emas. Ulanish faqat debug-build uchun amalga oshiriladi, release APK-da ortiqcha kod bo'lmasligi uchun.

// build.gradle (app/module)
dependencies {
    // debugImplementation — kutubxona faqat debug-build uchun
    debugImplementation "com.squareup.leakcanary:leakcanary-android:2.14"
}

Bog'liqlik qo'shilgach va loyiha qayta qurilgach, LeakCanary avtomatik ravishda ilovada paydo bo'ladi. Birinchi ishga tushirishda kutubxona faollashtirish haqida tizim bildirishnomasini ko'rsatadi. Barcha aniqlangan oqishlar bildirishnomalar shaklida ko'rsatiladi — bildirishnomaga bosish batafsil hisobot (LeakTrace) ekranini ochadi.

Moslashtirish uchun o'zingizning AppWatcherInstaller-ingizni yaratib, parametrlarni o'zgartirishingiz mumkin: GC kutish muddati, kuzatiladigan ob'ekt turlari ro'yxati, heap dump-ni diskka saqlashni yoqish. Biroq, loyihalarning 90% i uchun standart konfiguratsiya optimaldir.

Koroutinlar va Jetpack Compose uchun sozlash

2.12 versiyasidan boshlab, LeakCanary ViewModel, koroutin skoplari va Compose State ob'ektlarini avtomatik kuzatishni qo'llab-quvvatlaydi. Qo'shimcha bog'liqliklar talab qilinmaydi — kutubxona loyihada qaysi Jetpack komponentlari ishlatilayotganini o'zi aniqlaydi va tegishli detektorlarni faollashtiradi.

LeakCanary hisobotini qanday o'qish kerak

LeakCanary hisoboti (LeakTrace) — bu GC Root-dan oqqan ob'ektgacha bo'lgan ko'p satrli havolalar zanjiridir. Har bir satr kuchli havola o'tadigan sinf va maydonni ko'rsatadi. Dasturchi zanjirni pastdan yuqoriga o'qishi kerak: pastki satr — oqqan ob'ekt, yuqori satr — kirish nuqtasi (GC Root).

Oddiy LeakTrace shunday ko'rinadi: GC Root → statik Application maydoni → singleton → callback → Activity. Agar dasturchi bunday zanjirni ko'rsa, muammo aniq: singleton Activity-ga havolani tutib olgan callbackni ushlab turibdi. Yechim — singletonda kuchli havolani zaif bilan almashtirish.

┬
├─ android.app.Application
│    Leaking: NO (Application — singleton)
│    ↓ Application.leakedActivities
├─ java.util.ArrayList
│    Leaking: NO (ArrayList — normal)
│    ↓ ArrayList[0]
├─ com.example.MainActivity
│    Leaking: YES (Activity destroyed but still in memory)
│    ↓ MainActivity.mCallback
├─ com.example.CallbackWrapper
│    Leaking: UNKNOWN
│    ↓ CallbackWrapper.mListener
│              ~~~~~~~~~~
├─ com.example.MyCallback (anonymous)
│    Leaking: UNKNOWN
│    ↓ MyCallback.this$0
├─ com.example.MainActivity
│    Leaking: YES (MainActivity is the leak)
╰

Ushbu misolda LeakCanary MainActivity zanjir orqali ushlab turilganini ko'rsatadi: Application → ArrayList → MainActivity → CallbackWrapper → MyCallback → yana MainActivity. this$0 o'qi anonim MyCallback sinfi Activity-ga tashqi havolani tutib olganini ko'rsatadi. Yechim — callbackni zaif havola qilish yoki uni onDestroy-da bekor qilish.

LeakCanary shuningdek zanjirning har bir elementi uchun oqish holatini ko'rsatadi: NO (oqish yo'q — bu ildiz element), YES (ob'ekt yo'q qilinishi kerak), UNKNOWN (holatni aniqlash imkonsiz). UNKNOWN holati muammo emas — bu LeakCanary bir ma'noda tasniflay olmaydigan oraliq ob'ektdir.

LeakCanary 2.x vs 1.x: asosiy farqlar

1.x versiyasidan 2.x ga o'tish tubdan edi: dasturchilar kutubxonani noldan qayta yozdilar, eskirgan HAHA analizatorini Kotlin tilida yozilgan o'zining Shark dvigateli bilan almashtirdilar. Shark ancha tez ishlaydi, tahlil uchun kam xotira talab qiladi va oqishlarning asosiy sabablarini aniqroq belgilaydi.

Shark-ning asosiy afzalligi — butun heap dump-ni xotiraga yuklamaydi, balki uning havola grafigini minimal ajratmalar bilan aylanib chiqadi. Bu LeakCanary 2.x ni tahlil paytida OutOfMemoryError xavfisiz kam RAM hajmli qurilmalarda foydalanishga yaroqli qiladi.

2.x versiyasida shuningdek Android Studio Memory Profiler-da keyingi tahlil uchun heap dump-ni faylga eksport qilish imkoniyati paydo bo'ldi. Buning uchun AppWatcher konfiguratsiyasida dumpHeapWhenLeakFound sozlamasini yoqish kerak.

LeakCanary topadigan tipik oqishlar

LeakCanary Android uchun xos bo'lgan bir necha sinf oqishlarni samarali aniqlaydi. Eng ko'p uchraydigan — Activity-ga statik havolalar orqali oqish: dasturchilar Activity kontekstiga havolani singletonda saqlaydi va Activity hayotiy sikli tugaganidan keyin GC tomonidan yig'ila olmaydi.

Chastota bo'yicha ikkinchi kategoriya — ro'yxatdan o'tkazilmagan tinglovchilar orqali oqishlar. Agar onStart-da registerListener chaqirilgan bo'lsa, lekin onStop/onDestroy da unregisterListener chaqirilmagan bo'lsa — tinglovchi ob'ekti aktivlik yo'q qilinganidan keyin ham tizim tomonidan ushlab turiladi. LeakCanary qaysi tinglovchi va qaysi tizim xizmatida faol qolganini bir ma'noda ko'rsatadi.

// Tipik oqish: Activity singleton callbackida tutib olingan
object AnalyticsManager {
    private var callback: ((String) -> Unit)? = null

    fun register(callback: (String) -> Unit) {
        this.callback = callback // callbackga kuchli havola
    }

    fun unregister() {
        callback = null // onDestroy-da CHAQIRISHNI UNUTMANG!
    }
}

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        AnalyticsManager.register { event ->
            logEvent(event) // lambda thisni tutib oladi
        }
        // onDestroy-da unregister chaqirilmasa → Activity oqishi
    }
}

Uchinchi kategoriya — BackStack-dagi Fragment orqali oqishlar. Agar FragmentTransaction.addToBackStack() qaytishda Fragment o'chirilmasdan chaqirilsa, eski Fragment nusxalari xotirada qoladi. LeakCanary rivojlanishning dastlabki bosqichlarida bunday yashirin oqishlarni aniqlashga yordam beradi.

Har bir aniqlangan oqish uchun LeakCanary tavsif va tuzatish bo'yicha tavsiyalar taklif qiladi. 2.14 versiyasida Android Lint bilan integratsiya qo'shilgan — kutubxona CI-da oqish aniqlanganda issue tracker-da avtomatik vazifalar yaratishi mumkin.