Kumakain ng memorya at namamaga — ano ito, mga sanhi at paano iwasan

Ano ang memory leak at pamamaga ng app?

Memory leak — sitwasyon kung saan ang isang object na hindi na kailangan ng app ay nananatili sa heap dahil may aktibong reference mula sa root set (GC Root). Itinuturing ng garbage collector na buhay ang naturang object at hindi ito tinatanggal.

Pamamaga ng memorya (memory bloat) — mas malawak na problema kapag ang app ay kumokonsumo ng mas maraming memorya kaysa kinakailangan para sa kasalukuyang mga gawain. Mga sanhi: labis na caching, pagdoble ng mga object, hindi optimal na mga istruktura ng data, at fragmentation ng heap.

Sa Android bawat app ay inilalaan ng limitadong heap (karaniwang 64-512 MB depende sa device at bersyon ng OS). Sa iOS ang limitasyon ay hindi gaanong mahigpit, ngunit ang system ay nagpapadala ng babala sa memorya kapag papalapit sa limitasyon.

Ayon sa Facebook Engineering Blog, ang memory leak ay sanhi ng ~15% ng mga crash report sa mobile app. Sa Android, idinagdag ang ANR dahil sa madalas na GC pause kapag kulang sa memorya.

Mga tipikal na pattern ng memory leak sa Android at iOS

Static na reference sa Activity — klasiko ng Android leaks. Kung ang isang static na field o singleton ay nag-iimbak ng reference sa Activity, hindi ito kokolektahin ng GC kahit pagkatapos ng finish(), habang buhay ang singleton. Ang Activity ay isang mabigat na object na naglalaman ng View hierarchy, resources, at Context.

object LeakHolder {
    var activityRef: Activity ?= null // leak: static na reference sa Activity
}

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle ?= null) {
        super.onCreate(savedInstanceState)
        LeakHolder.activityRef = this // ❌ Ang MainActivity ay hindi kailanman makokolekta ng GC
    }
}

Mga anonymous na klase at lambda — implicitly na nag-iimbak ng reference sa panlabas na klase. Kung ang Runnable o Callback ay ipinasa sa panlabas na serbisyo at ang Activity ay nawasak, ang anonymous class object ay nakabitin pa rin sa queue at hindi pinapayagan ang Activity na ma-garbage collect.

• Handler na may delay — kung nawasak ang Activity ngunit hindi pa naisakatuparan ang Handler.postDelayed, tumutulo ang Activity
• Thread at AsyncTask — sa pag-ikot ng screen, muling nilikha ang Activity, ngunit ang lumang Thread ay patuloy na humahawak ng reference sa lumang Activity
• Retrofit/Callback — isang anonymous na Callback ay nag-iimbak ng reference sa presenter o fragment
• Mga tagamasid (Observers) — LiveData o RxJava subscription nang walang pag-kansela sa onDestroy

Sa iOS ang pangunahing problema ay retain cycles: dalawang object ang nag-iimbak ng malalakas na reference sa isa't isa at hindi mababawasan ng ARC ang reference count para sa alinman. Karaniwang kaso: isang closure na malakas na kumukuha ng self, at self na may hawak na reference sa closure.

Paano matukoy ang mga memory leak?

LeakCanary — library mula sa Square para sa awtomatikong pagtuklas ng leak sa Android. Pagkatapos ng pagkasira ng Activity o Fragment, sinusuri nito kung ang object ay nakolekta ng GC. Kung hindi — gumagawa ito ng heap dump at nagpapakita ng leak trace.

// LeakCanary 2.x — auto-integration sa pamamagitan ng Application
class ExampleApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        // Awtomatikong nag-i-install ang LeakCanary sa debug build
        // sa pamamagitan ng ContentProvider — zero code setup
    }
}

// Sapilitang tawag sa pagsusuri
AppWatcher.objectWatcher.watch(watchedObject, "leak description")

Android Studio Profiler — built-in na tool para sa real-time na pagsubaybay sa memorya. Nagbibigay-daan sa pag-record ng heap dump, paghahanap ng mga kahina-hinalang object (Retained Size > 1 MB), at pagsubaybay sa GC root path papunta sa bawat object.

Para sa iOS gamitin ang Xcode Memory Graph Debugger. Binibigyang-diin nito ang graph ng mga object sa memorya, ipinapakita ang retain cycles at pinapayagan ang agarang pagtuklas ng mga circular reference. Available din ang Instruments > Allocations para sa pangmatagalang pagsubaybay.

Mga estratehiya sa pagpigil ng leak

WeakReference — pangunahing mekanismo para sa mga reference na hindi dapat hadlangan ang garbage collection. Kung magpasya ang GC na tanggalin ang object, ang WeakReference ay nagbabalik ng null. Ginagamit para sa mga callback, listener, at reference sa mga UI component mula sa mga background thread.

Mga Lifecycle-aware na component — arkitektural na diskarte na ipinatupad sa Android Jetpack (Lifecycle, LiveData, Flow, coroutines). Awtomatikong kinakansela ang mga subscription sa onDestroy, na inaalis ang pangunahing klase ng leaks.

class MyViewModel : ViewModel() {
    private val _data = MutableLiveData<List<User>>()
    val data: LiveData<List<User>> get() = _data

    fun loadData() {
        viewModelScope.launch {
            val result = repository.fetchData()
            _data.postValue(result)
            // awtomatikong kinakansela ang coroutine sa onCleared()
        }
    }
}

viewModelScope at lifecycleScope — built-in na CoroutineScope sa Android na kinakansela sa kaukulang lifecycle event. Inaalis nito ang mga leak sa pamamagitan ng coroutine — ang pinakakaraniwang senaryo sa modernong Android development.

• Huwag gumamit ng static na reference sa Context, Activity, View o Fragment
• Kanselahin ang lahat ng RxJava subscription sa disposeBag / CompositeDisposable sa onDestroy
• Gamitin ang [weak self] / [unowned self] sa iOS closures para maiwasan ang retain cycles
• Suriin ang Bitmap at malalaking object — dapat i-recycle o i-null ang mga ito

Mga tool sa profiling ng memorya

Memory Profiler in Android Studio — pangunahing tool para sa pagsubaybay sa heap. Nagpapakita ng live allocations, heap snapshot, bilang ng mga object ayon sa uri. Pinapayagan ang pag-record ng dump at pagsusuri nito sa MAT (Memory Analyzer Tool) para sa paghahanap ng mga kahina-hinalang object.

Eclipse MAT — desktop analyzer ng heap dump. Pagkatapos mag-load ng HPROF file mula sa Android Studio, nagtatayo ang MAT ng dominator tree, ipinapakita ang retain size ng bawat object, at nag-aalok ng awtomatikong pagsusuri ng mga kahina-hinalang leak sa pamamagitan ng Leak Suspects Report.

Xcode Memory Graph — visual debugger para sa retain cycles. Sa pag-click sa Memory Graph Debugger button, itinitigil ng Xcode ang app, nagtatayo ng kumpletong graph ng mga object sa memorya, at itinatampok ang retain cycles sa pula.

Ayon sa Google I/O 2023, ang mga app na gumagamit ng LeakCanary sa debug build ay nakakabawas ng bilang ng memory-related crash ng 30-50% sa unang 2 buwan pagkatapos ng implementasyon. Inirerekomenda na idagdag ang LeakCanary sa onboarding phase ng proyekto.