Memory Leaks

🧠 When Can Memory Leaks Happen?

Memory leaks in Android typically happen when an object that holds a reference to a Context (especially Activity) outlives its lifecycle, preventing the system from garbage collecting the Activity.

🧩 Types of Context and When to Use Which

✅ 🚫 Avoid Memory Leaks with These Tips

✅ 1. Use applicationContext when:

• You don’t need to access UI

• You're working in long-lived classes: e.g., repositories, databases, analytics trackers
  

val context = context.applicationContext

✅ 2. Avoid Anonymous Inner Classes in Activities

Use static classes or top-level classes to avoid holding implicit references to Activities.

✅ 3. Clear Resources in Lifecycle

Always clear:

• Observers (LiveData, BroadcastReceiver)

• Coroutine scopes (Job.cancel())

• Ad SDKs (nativeAd.destroy())

✅ 4. Don’t Hold Context in Singletons

If you must, store applicationContext, not Activity.

class MySingleton private constructor(private val context: Context) {
    companion object {
        fun init(appContext: Context): MySingleton {
            return MySingleton(appContext.applicationContext)
        }
    }
}

1. Holding a reference to an Activity or View in a Singleton ❌ Problem:

object MyManager {
    var context: Context? = null // holding activity context
}

📌 Real-World Example:

You create a singleton for analytics or ads that stores an Activity context to show a Toast or dialog — but forget to clear it.

✅ Solution:

Always use context.applicationContext in singletons.

context = context.applicationContext

1. Inner classes or anonymous classes (e.g. Runnable, Listener) holding implicit reference to outer Activity

❌ Problem:

class MyActivity : AppCompatActivity() {
    private val handler = Handler(Looper.getMainLooper())

    fun start() {
        handler.postDelayed({
            // 'this' refers to Activity, leak if Activity is destroyed
        }, 10000)
    }
}

✅ Solution:

Make the runnable a static class or cancel delayed tasks in onDestroy().

override fun onDestroy() {
    super.onDestroy()
    handler.removeCallbacksAndMessages(null)
}

1. Long-running background tasks (Coroutines, AsyncTask, Threads) holding context

❌ Problem:

You start a coroutine in a ViewModel or plain class and hold an Activity context.

fun loadData(context: Context) {
    CoroutineScope(Dispatchers.IO).launch {
        // Holding context across configuration change or after activity is gone
        val db = DB.getInstance(context)
    }
}

✅ Solution:

• Pass applicationContext if needed.
• Cancel coroutine on lifecycle.

fun loadData(appContext: Context) {
    CoroutineScope(Dispatchers.IO).launch {
        val db = DB.getInstance(appContext)
    }
}

1. LiveData or Flow observing with lifecycle issues

❌ Problem:

You observe LiveData from ViewModel in a Context-based class (like a custom manager), not tied to lifecycle.

viewModel.data.observeForever {
    // Forever means it never stops -> leak
}

✅ Solution:

Always observe with LifecycleOwner (Activity or Fragment) unless you manually remove observers.

viewModel.data.observe(viewLifecycleOwner) { ... }

1. Dialogs or Toasts shown after Activity is destroyed ❌ Problem:

fun showDialog(context: Context) {
    AlertDialog.Builder(context)
        .setMessage("Hello")
        .show()
}

If context is an Activity and it’s already finishing, the window leaks.
✅ Solution:

Check context:

if (context is Activity && !context.isFinishing) {
    AlertDialog.Builder(context)
        .setMessage("Safe")
        .show()
}

1. Static Views or holding binding in fragments after view is destroyed ❌ Problem:

class MyFragment : Fragment() {
    private lateinit var binding: FragmentMyBinding

    override fun onDestroyView() {
        super.onDestroyView()
        // Forget to clear binding -> view leak
    }
}

✅ Solution:

Clear binding in onDestroyView():

override fun onDestroyView() {
    super.onDestroyView()
    _binding = null
}

1. Custom callbacks or listeners not removed ❌ Problem:

someView.setOnClickListener {
    // Holds reference to outer Activity
}

If the view lives longer (e.g., part of an SDK), it keeps the activity alive.
✅ Solution:

Remove listeners:

override fun onDestroy() {
    someView.setOnClickListener(null)
}

class MySingleton private constructor(private val context: Context) {

    companion object {
        @Volatile
        private var INSTANCE: MySingleton? = null

        fun getInstance(appContext: Context): MySingleton {
            return INSTANCE ?: synchronized(this) {
                INSTANCE ?: MySingleton(appContext.applicationContext).also { INSTANCE = it }
            }
        }
    }

    // Example usage of application context
    fun doSomethingGlobal() {
        Toast.makeText(context, "Doing something!", Toast.LENGTH_SHORT).show()
    }
}

private var weakActivity: WeakReference<Activity>? = null

fun bindActivity(activity: Activity) {
    weakActivity = WeakReference(activity)
}

fun doSomething() {
    val activity = weakActivity?.get() ?: return
    // Use it safely
}

❌ Problem: 🔴 Without Job — সমস্যা:

👉 যদি user ৪ সেকেন্ডের মধ্যে বারবার call করে, সব coroutine queue তে ঢুকে যাবে → multiple popups → 😵 UI bug!

lifecycleScope.launch {
    delay(4000)
    getDrugDetailPopupImage(genericId)
}

🟢 With Job — Smart & Controlled: 👉 একবারে শুধুমাত্র একটা popup চলবে। নতুন কাজ এলে পুরনোটা কেটে যাবে।

private var popupJob: Job? = null

popupJob?.cancel() // পুরনো চলমান coroutine বন্ধ
popupJob = lifecycleScope.launch {
    delay(4000)
    getDrugDetailPopupImage(genericId)
}

📌 এর উদ্দেশ্য:

• আগের popup coroutine চলমান থাকলে তা cancel করে ফেলা
• নতুন coroutine দিয়ে popup image delayed show করা
• একই সময় একটির বেশি popup না দেখানো
• 🧠 Memory leak রোধ না চাইতেও চলতে থাকা coroutine বন্ধ করে দে

মেমোরি লিক কী?

মেমোরি লিক তখন হয়, যখন আপনার অ্যাপের অবজেক্টগুলো গারবেজ কালেক্টর (Garbage Collector) রিমুভ করতে পারে না, কারণ এখনও কেউ সেই অবজেক্টের রেফারেন্স ধরে রেখেছে — যদিও সেই অবজেক্ট দরকার নেই। ফলে অ্যাপের RAM ব্যবহার বাড়ে, পারফরম্যান্স কমে, এমনকি অ্যাপ ক্র্যাশও করতে পারে।

LeakCanary হল Square কোম্পানির বানানো একটা open-source Android library যা মেমোরি লিক অটো ডিটেক্ট করতে পারে ডেভেলপমেন্ট বিল্ডে।

// build.gradle (app)
dependencies {
    debugImplementation "com.squareup.leakcanary:leakcanary-android:2.13"
}

Leak Report দেখতে কেমন হয়?

// ➡️ এই report বলছে MyActivity destroy হওয়ার পরেও mContext রেফারেন্সে থাকার কারণে release হয়নি।
ActivityLeakActivity has leaked:
↳ xyz.MyActivity instance
   |   mContext → xyz.MyActivity
   |   mDestroyed → true

Tip1: Leak Canary Debug Log:

D LeakCanary: Watching instance of xyz.MyActivity (Activity) with key XYZ123...

┬
├─ com.example.MyActivity
│    Leaking: YES
│    Retaining 1.2 MB in 10060 bytes
│    ↓ MyActivity.someStaticReference
│                        ~~~~~~~~~~~~~
├─ android.widget.SomeView
│    ↓ View.mContext
│               ~~~~~~~~
...

- MyFragment.binding null করা হয়নি, তাই View এর মধ্যে থাকা context (Activity) leak হয়েছে।

✅ সমাধান: onDestroyView() এ binding = null করে দিন।

┬
├─ MyFragment
│    Leaking: YES
│    ↓ MyFragment.binding
│                 ~~~~~~~
├─ MyFragmentBinding
│    ↓ binding.textView
│              ~~~~~~~~
├─ TextView
│    ↓ View.mContext
│              ~~~~~~~

প্রতিটি লাইন দেখুন যেটাতে ↓ (down arrow) আছে, LeakCanary এই arrows দিয়ে বোঝায় কার মাধ্যমে রেফারেন্স ধরে আছে:

StrictMode.setThreadPolicy(
    StrictMode.ThreadPolicy.Builder()
        .detectDiskReads()      // ডিস্ক থেকে ডাটা পড়া হলে সতর্ক করবে
        .detectDiskWrites()     // ডিস্কে লেখা হলে সতর্ক করবে
        .detectNetwork()        // নেটওয়ার্ক কল হলে সতর্ক করবে
        .penaltyLog()           // এসব ঘটনার সময় লগ করবে
        .build()
)

StrictMode.setVmPolicy(
    StrictMode.VmPolicy.Builder()
        .detectLeakedSqlLiteObjects()    // যেসব Sqlite অবজেক্ট বন্ধ হয়নি, সেগুলো চিনবে
        .detectLeakedClosableObjects()   // যেসব ক্লোজেবল অবজেক্ট (যেমন ফাইল, স্ট্রীম) বন্ধ হয়নি সেগুলো চিনবে
        .penaltyLog()                    // এসব ইস্যু হলে লগ করবে
        .build()
)

- মেইন থ্রেডে ডিস্ক বা নেটওয়ার্ক অপারেশন হলে তোমাকে জানাবে

- যেসব ডেটাবেস বা ফাইল রিসোর্স তুমি ভুলে বন্ধ করো নি, সেগুলোও ধরবে

- সবই লগ করে ডেভেলপারকে ইস্যু সম্পর্কে সচেতন করবে

কেন দরকার?
অ্যাপ ঠিকঠাক এবং দ্রুত কাজ করুক আর ইউজার ভালো অভিজ্ঞতা পায়, সেজন্য যেসব কাজ মেইন থ্রেড ব্লক করে সেগুলো খুঁজে বের করা খুব জরুরি। StrictMode সেই কাজে সাহায্য করে।