LeakCanary — این چیست، کتابخانه جستجوی نشت در Android

LeakCanary چیست؟

LeakCanary — کتابخانه‌ای برای تشخیص خودکار نشت‌های حافظه در برنامه‌های Android است که توسط شرکت Square توسعه یافته است. این کتابخانه در فرآیند ساخت برنامه ادغام می‌شود و به طور خودکار ردیابی می‌کند که آیا اشیایی که باید نابود شوند (Activity، Fragment، View) در حافظه باقی می‌مانند. هنگام تشخیص نشت، LeakCanary یک heap dump ایجاد کرده و زنجیره ارجاعات نگهدارنده شیء را تحلیل می‌کند.

این کتابخانه به استانداردی در جامعه Android تبدیل شده است: طبق داده‌های GitHub، این پروژه بیش از 28 هزار ستاره جمع‌آوری کرده و در برنامه‌های Google، Uber، Airbnb و Facebook استفاده می‌شود. LeakCanary در دو نسخه اصلی موجود است: کلاسیک 1.x (با پیکربندی دستی) و مدرن 2.x (ادغام خودکار از طریق ContentProvider). نسخه 2.x نیاز به تغییر کلاس Application ندارد — یک وابستگی برای عملکرد کامل کافی است.

وظیفه اصلی LeakCanary تشخیص وضعیتی است که یک شیء پس از پایان چرخه حیات خود همچنان در حافظه وجود دارد. این امر برای نشت‌ها از طریق فیلدهای ایستا، سینگلتون‌ها، callbackهای ثبت‌نشده، کلاس‌های ناشناس و بسته‌هایی که اشیاء خارجی را ضبط می‌کنند، معمول است.

چرا LeakCanary برای توسعه Android مهم است

نشت‌های حافظه در Android به دلیل حجم محدود RAM در دستگاه‌های موبایل بحرانی‌تر از دسکتاپ هستند. حتی نشت ۵–۱۰ مگابایت در هر جابه‌جایی بین صفحات می‌تواند پس از ۳۰–۴۰ دقیقه استفاده از برنامه منجر به OutOfMemoryError شود. LeakCanary چنین مشکلاتی را در مرحله توسعه شناسایی می‌کند، بدون اینکه منتظر خرابی در تولید بماند.

LeakCanary چگونه کار می‌کند؟

LeakCanary از ارجاعات ضعیف (WeakReference) در ترکیب با فراخوانی اجباری garbage collector استفاده می‌کند. هنگامی که Activity یا Fragment onDestroy را فراخوانی می‌کند، LeakCanary یک WeakReference برای آن شیء ایجاد کرده و پس از تأخیر کوتاه (پیش‌فرض ۵ ثانیه) GC را اجرا می‌کند. اگر پس از GC شیء همچنان از طریق WeakReference قابل دسترسی باشد، به این معنی است که توسط یک ارجاع قوی نگه داشته شده است — نشت ثبت می‌شود.

پس از تشخیص نشت، LeakCanary یک heap dump (تصویر کامل حافظه برنامه در قالب HPROF) ایجاد می‌کند. سپس تحلیلگر داخلی (Shark برای نسخه ۲.x) یک گراف دسترسی از GC Roots تا شیء نشت‌یافته ساخته و کوتاه‌ترین مسیر — زنجیره ارجاعات نگهدارنده شیء در حافظه — را پیدا می‌کند.

// منطق ساده‌شده تشخیص LeakCanary
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() // GC اجباری
        for (ref in watchedReferences) {
            if (ref.get() != null) {
                onLeakFound(ref) // شیء از GC جان سالم به در برد — این نشت است
            }
        }
    }
}

نکته کلیدی — فراخوانی اجباری GcTrigger.runGc() است. بدون آن نمی‌توان شیء واقعاً نشت‌یافته را از شیئی که GC هنوز فرصت جمع‌آوری آن را نداشته تشخیص داد. LeakCanary این کار را تا سه بار انجام می‌دهد: اگر پس از سه چرخه GC شیء همچنان در حافظه باشد — نشت تأیید می‌شود.

Shark چیست — تحلیلگر heap dump

Shark — تحلیلگر heap dump تعبیه‌شده در LeakCanary 2.x است که به زبان Kotlin نوشته شده است. برخلاف تحلیلگر قبلی HAHA، Shark کل فایل HPROF را در حافظه بارگذاری نمی‌کند، بلکه گراف اشیاء آن را با حداقل تخصیص‌ها پیمایش می‌کند. این امر مصرف RAM را در هنگام تحلیل از ۵۰ مگابایت به ۲–۵ مگابایت کاهش داده و زمان تحلیل را از ۳۰ ثانیه به ۱–۳ ثانیه می‌رساند.

چگونه LeakCanary را نصب و پیکربندی کنیم؟

نصب LeakCanary 2.x در یک پروژه مدرن Android یک خط در build.gradle طول می‌کشد. کتابخانه از ContentProvider برای راه‌اندازی خودکار استفاده می‌کند — نیازی به ویرایش کلاس Application یا افزودن کد در MainActivity نیست. اتصال فقط برای debug-build انجام می‌شود تا در APK انتشار کد اضافی وجود نداشته باشد.

// build.gradle (app/module)
dependencies {
    // debugImplementation — کتابخانه فقط برای debug-build
    debugImplementation "com.squareup.leakcanary:leakcanary-android:2.14"
}

پس از افزودن وابستگی و بازسازی پروژه، LeakCanary به طور خودکار در برنامه ظاهر می‌شود. در اولین اجرا، کتابخانه یک اعلان سیستمی درباره فعال‌سازی نشان می‌دهد. تمام نشت‌های شناسایی‌شده به صورت اعلان نمایش داده می‌شوند — کلیک روی اعلان صفحه‌ای با گزارش جزئیات (LeakTrace) باز می‌کند.

برای سفارشی‌سازی می‌توانید AppWatcherInstaller خود را ایجاد کرده و پارامترها را بازنویسی کنید: مهلت انتظار GC، لیست انواع اشیاء ردیابی‌شده، فعال‌سازی ذخیره heap dump روی دیسک. با این حال، برای ۹۰٪ پروژه‌ها پیکربندی پیش‌فرض بهینه است.

پیکربندی برای کروتین‌ها و Jetpack Compose

از نسخه ۲.۱۲ به بعد، LeakCanary از ردیابی خودکار ViewModel، اسکوپ‌های کروتین و اشیاء State Compose پشتیبانی می‌کند. وابستگی اضافی مورد نیاز نیست — کتابخانه خود تشخیص می‌دهد که کدام مؤلفه‌های Jetpack در پروژه استفاده می‌شوند و آشکارسازهای مربوطه را فعال می‌کند.

چگونه گزارش LeakCanary را بخوانیم

گزارش LeakCanary (LeakTrace) — یک زنجیره چندخطی از ارجاعات از GC Root تا شیء نشت‌یافته است. هر خط کلاس و فیلدی را نشان می‌دهد که ارجاع قوی از آن عبور می‌کند. برنامه‌نویس باید زنجیره را از پایین به بالا بخواند: خط پایین — شیء نشت‌یافته، خط بالا — نقطه ورود (GC Root).

LeakTrace معمولی به این شکل است: GC Root → فیلد ایستا Application → سینگلتون → callback → Activity. اگر برنامه‌نویس چنین زنجیره‌ای ببیند، مشکل واضح است: سینگلتون یک callback را نگه می‌دارد که ارجاعی به Activity را ضبط کرده است. راه‌حل — جایگزینی ارجاع قوی با ضعیف در سینگلتون.

┬
├─ 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)
╰

در این مثال LeakCanary نشان می‌دهد که MainActivity از طریق زنجیره نگه داشته شده است: Application → ArrayList → MainActivity → CallbackWrapper → MyCallback → دوباره MainActivity. فلش this$0 نشان می‌دهد که کلاس ناشناس MyCallback یک ارجاع خارجی به Activity را ضبط کرده است. راه‌حل — تبدیل callback به ارجاع ضعیف یا لغو آن در onDestroy.

LeakCanary همچنین وضعیت نشت را برای هر عنصر زنجیره نشان می‌دهد: NO (نشتی نیست — این عنصر ریشه است)، YES (شیء باید نابود شود)، UNKNOWN (تعیین وضعیت ممکن نبود). وضعیت UNKNOWN به معنای مشکل نیست — این یک شیء میانی است که LeakCanary نمی‌تواند به طور قطعی طبقه‌بندی کند.

LeakCanary 2.x در مقابل 1.x: تفاوت‌های کلیدی

انتقال از نسخه 1.x به 2.x اساسی بود: توسعه‌دهندگان کتابخانه را از نو نوشتند و تحلیلگر قدیمی HAHA را با موتور اختصاصی Shark که به زبان Kotlin نوشته شده جایگزین کردند. Shark بسیار سریع‌تر کار می‌کند، حافظه کمتری برای تحلیل نیاز دارد و علل ریشه‌ای نشت‌ها را دقیق‌تر تعیین می‌کند.

مزیت کلیدی Shark — این است که کل heap dump را در حافظه بارگذاری نمی‌کند، بلکه گراف ارجاعات آن را با حداقل تخصیص‌ها پیمایش می‌کند. این امر LeakCanary 2.x را برای استفاده در دستگاه‌های با RAM کم بدون خطر OutOfMemoryError در هنگام تحلیل مناسب می‌سازد.

در نسخه 2.x همچنین امکان صادرات heap dump به فایل برای تحلیل بعدی در Android Studio Memory Profiler اضافه شده است. برای این کار باید پارامتر dumpHeapWhenLeakFound را در پیکربندی AppWatcher فعال کنید.

نشت‌های معمولی که LeakCanary پیدا می‌کند

LeakCanary به طور مؤثر چندین کلاس از نشت‌های مشخصه Android را شناسایی می‌کند. شایع‌ترین آنها نشت از طریق ارجاعات ایستا به Activity است — توسعه‌دهندگان ارجاع به زمینه Activity را در سینگلتون ذخیره می‌کنند و Activity پس از پایان چرخه حیات خود نمی‌تواند توسط GC جمع‌آوری شود.

دومین دسته از نظر فراوانی — نشت‌ها از طریق شنوندگان ثبت‌نشده. اگر در onStart متد registerListener فراخوانی شده باشد اما در onStop/onDestroy متد unregisterListener فراخوانی نشده باشد — شیء شنونده حتی پس از نابودی فعالیت توسط سیستم نگه داشته می‌شود. LeakCanary به طور واضح نشان می‌دهد کدام شنونده و در کدام سرویس سیستم فعال باقی مانده است.

// نشت معمولی: Activity در callback سینگلتون ضبط شده است
object AnalyticsManager {
    private var callback: ((String) -> Unit)? = null

    fun register(callback: (String) -> Unit) {
        this.callback = callback // ارجاع قوی به callback
    }

    fun unregister() {
        callback = null // فراخوانی در onDestroy را فراموش نکنید!
    }
}

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        AnalyticsManager.register { event ->
            logEvent(event) // lambda این را ضبط می‌کند
        }
        // اگر unregister در onDestroy فراخوانی نشود → نشت Activity
    }
}

دسته سوم — نشت‌ها از طریق Fragment در BackStack. اگر FragmentTransaction.addToBackStack() بدون حذف Fragment در هنگام بازگشت فراخوانی شود، نمونه‌های قدیمی Fragment در حافظه باقی می‌مانند. LeakCanary به شناسایی چنین نشت‌های پنهانی در مراحل اولیه توسعه کمک می‌کند.

برای هر نشت شناسایی‌شده، LeakCanary توضیحات و توصیه‌هایی برای رفع ارائه می‌دهد. در نسخه ۲.۱۴ یکپارچه‌سازی با Android Lint اضافه شده است — کتابخانه می‌تواند هنگام تشخیص نشت در CI به طور خودکار وظایفی در issue tracker ایجاد کند.