Android应用Fragment内存泄漏致崩溃，寻求解决方案

Hey there, let's walk through how to diagnose and fix those memory leaks plaguing your Fragment-based Android app— I’ve dealt with similar issues in ViewPager + nested Fragment setups, so I know how frustrating it can be when the app crashes after running for a while.

You can’t fix what you can’t see, so start with these tools to pinpoint the leaks:

• Memory Profiler (built into Android Studio) : Open the Profiler tab, switch to the Memory section, and take a Java heap dump (Dump Java Heap) after navigating through your fragments (clicking categories, brands, products, then back). Search for your Fragment classes (like StoreCatalogFragment, BrandListFragment) and check if there are instances that shouldn’t exist anymore. The "References" tab will show you what’s holding onto the fragment instance.
• LeakCanary : This library is a lifesaver for automatic leak detection. Integrate it into your project, run the app, and it’ll notify you with a detailed report whenever a leak is detected—including the exact chain of references keeping the fragment alive. It’s way more user-friendly than manually digging through heap dumps.

Given your app’s structure—ViewPager with 3 fragments, nested fragment navigation for categories → brands → products—here are the most likely culprits:

1. ViewPager Fragment Caching & Strong References #

ViewPager defaults to caching 1 offscreen fragment (offscreenPageLimit = 1). If your Activity or ViewPager adapter holds strong references to fragments (like a list of fragments stored in the Activity), or fragments have lingering callbacks/listeners, those cached fragments might not get recycled properly.

• Fix :
  • Use FragmentStatePagerAdapter instead of FragmentPagerAdapter if you have many fragments or expect frequent navigation— it destroys fragment instances when they’re offscreen, reducing memory footprint.
  • Avoid storing fragment instances in a list in your Activity. Instead, retrieve fragments using supportFragmentManager.findFragmentByTag() when you need them.

2. Uncleaned Callbacks Between Fragments #

When you navigate from the catalog fragment to the brand fragment, you might be using interface callbacks to pass data (e.g., the catalog fragment telling the Activity to load the brand fragment). If the fragment holds a strong reference to the callback (or vice versa) and doesn’t clear it when destroyed, that creates a leak.

• Fix :
  • In your fragment’s onDestroyView() or onDestroy() method, set any callback references to null.
  • Replace interface callbacks with LiveData—it’s lifecycle-aware, so it automatically stops emitting events when the fragment is destroyed, eliminating the need to manually clean up references.

3. Uncancelled Async Tasks/Timers #

Loading category data, brand lists, or product info often involves async operations (AsyncTask, Handler, Coroutines, RxJava). If these tasks aren’t cancelled when the fragment is destroyed, they’ll hold a reference to the fragment’s context, preventing it from being garbage-collected.

• Fix :
  • For AsyncTask: Call cancel(true) in onDestroy().
  • For Handler: Use handler.removeCallbacksAndMessages(null) to clear all pending messages.
  • For Kotlin Coroutines: Launch coroutines in viewModelScope (if using ViewModel) or lifecycleScope—these scopes automatically cancel coroutines when the fragment/viewmodel is destroyed.
  • For RxJava: Use a CompositeDisposable to track all subscriptions, and call dispose() in onDestroy().

4. Static Variables Holding Fragment/Context References #

If you have a singleton class or static variable that holds a reference to your fragment or its context, that’s a guaranteed leak—static variables live as long as the app does, so the fragment can never be recycled.

• Fix :
  • Never store fragment instances in static variables. If you need a context in a singleton, use the Application context instead (it’s safe to hold static references to this).
  • If you must hold a reference temporarily, wrap it in a WeakReference so the garbage collector can still collect the fragment when it’s no longer needed.

5. Unremoved View Listeners #

Anonymous inner class listeners (like OnClickListener for category items) automatically hold a strong reference to the fragment. If the view is cached (e.g., in ViewPager’s offscreen cache) or referenced elsewhere, the fragment won’t be collected.

• Fix :
  • In onDestroyView(), explicitly remove listeners from views (e.g., categoryView.setOnClickListener(null)).
  • Use static inner classes for listeners, and wrap the fragment reference in a WeakReference to avoid holding a strong reference.

After implementing these changes, run the app and use LeakCanary to monitor for leaks. You can also take multiple heap dumps with the Memory Profiler as you navigate through the app—check that fragment instances are properly collected when you back out of them.

内容的提问来源于stack exchange，提问作者vmp