内存泄漏与 LeakCanary：从问题定位到修复思路

为什么内存泄漏值得单独关注

Android 应用运行在内存有限的移动设备上。一次小泄漏可能暂时看不出问题，但用户频繁打开页面、旋转屏幕、切换账号或长时间停留在应用里时，泄漏对象会不断堆积，最终表现为页面卡顿、图片加载失败，严重时直接触发 OutOfMemoryError。

内存泄漏的本质很简单：一个本该被释放的对象，仍然被某条引用链持有，导致垃圾回收器无法回收它。

例如 Activity 已经执行了 onDestroy()，按理说页面相关的 View、Bitmap、Adapter 都应该一起释放。如果某个全局单例、静态变量、后台任务或回调还持有这个 Activity，它就不会被回收。Activity 一旦泄漏，通常不是只泄漏一个对象，而是一整棵页面对象树。

先理解引用链

垃圾回收器判断对象是否可回收时，不是看对象有没有"用处"，而是看它能不能从 GC Roots 访问到。常见 GC Roots 包括：

当前运行线程的栈变量
静态字段
JNI 引用
系统类加载器持有的对象
正在运行的线程对象

如果一个销毁后的 Activity 还能通过类似下面的链路被访问到，它就泄漏了：

text 复制代码

GC Root
  -> Singleton.instance
  -> callback
  -> MainActivity

LeakCanary 的价值就在这里：它不只是告诉你"有泄漏"，还会把这条引用链展示出来，让你知道是谁持有了不该持有的对象。

引入 LeakCanary

在应用模块的 build.gradle 中添加 debug 依赖即可：

kotlin 复制代码

dependencies {
    debugImplementation("com.squareup.leakcanary:leakcanary-android:2.14")
}

通常不需要额外初始化。应用安装 debug 包后，LeakCanary 会自动监听 Activity、Fragment、ViewModel 等对象的生命周期。当它发现某个对象在应该释放后仍然存活，会等待一次 GC，再分析堆内存并生成通知。

建议只在 debug 或内部测试包启用 LeakCanary，不要放进正式发布包。它会做堆转储和分析，适合定位问题，不适合常驻生产环境。

如何读懂 LeakCanary 报告

LeakCanary 报告最重要的部分是泄漏引用链。一个报告可能长这样：

text 复制代码

┬───
│ GC Root: System class
│
├─ com.example.AppSingleton class
│    Leaking: NO
│    ↓ static AppSingleton.listener
│                          ~~~~~~~~
├─ com.example.UserListener instance
│    Leaking: UNKNOWN
│    ↓ UserListener.activity
│                   ~~~~~~~~
╰→ com.example.MainActivity instance
     Leaking: YES (ObjectWatcher was watching this because MainActivity received Activity#onDestroy())

阅读时重点看三件事：

Leaking: YES：真正应该被释放却还活着的对象。
波浪线标出的字段：可疑引用位置。
从上到下的链路：谁通过谁间接持有了泄漏对象。

不要只盯着最后的 Activity。最后一行只是受害者，真正要改的通常是上游某个静态字段、回调列表、线程任务或第三方 SDK 注册点。

常见泄漏场景

单例持有 Activity

错误示例：

kotlin 复制代码

object UserManager {
    var context: Context? = null
}

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        UserManager.context = this
    }
}

UserManager 是全局对象，生命周期几乎等同于进程。它持有 Activity 后，Activity 即使关闭也无法释放。

修复方式是使用 applicationContext，或者干脆不要在单例中保存 Context：

kotlin 复制代码

object UserManager {
    private var appContext: Context? = null

    fun init(context: Context) {
        appContext = context.applicationContext
    }
}

如果确实需要页面能力，比如弹窗、跳转、权限请求，不应该把 Activity 塞进单例，而是由当前页面主动调用对应方法。

匿名内部类和延迟任务

在 Kotlin 或 Java 中，匿名内部类、Lambda、Runnable 很容易捕获外部 Activity。

kotlin 复制代码

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

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        handler.postDelayed({
            updateUi()
        }, 60_000)
    }
}

这个延迟任务会持有 MainActivity。如果页面在 60 秒内关闭，消息队列里的 Runnable 仍然可能让 Activity 无法释放。

可以在销毁时移除任务：

kotlin 复制代码

class MainActivity : AppCompatActivity() {
    private val handler = Handler(Looper.getMainLooper())
    private val updateTask = Runnable { updateUi() }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        handler.postDelayed(updateTask, 60_000)
    }

    override fun onDestroy() {
        handler.removeCallbacks(updateTask)
        super.onDestroy()
    }
}

更现代的写法是使用生命周期感知的协程，避免手动维护 Handler：

kotlin 复制代码

lifecycleScope.launch {
    delay(60_000)
    if (lifecycle.currentState.isAtLeast(Lifecycle.State.STARTED)) {
        updateUi()
    }
}

lifecycleScope 会在 Lifecycle 销毁时取消协程，比裸 Handler 更不容易出错。

Fragment View 泄漏

Fragment 的生命周期比它的 View 更长。onDestroyView() 后，Fragment 实例可能还在返回栈中，但它的 View 已经销毁。如果仍然保存 ViewBinding，就会泄漏整棵 View 树。

常见写法：

kotlin 复制代码

class ProfileFragment : Fragment(R.layout.fragment_profile) {
    private var _binding: FragmentProfileBinding? = null
    private val binding get() = _binding!!

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        _binding = FragmentProfileBinding.bind(view)
        binding.name.text = "Lulu"
    }

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

关键点是：绑定对象对应的是 View 生命周期，不是 Fragment 生命周期。只要在 onDestroyView() 里置空，就能避免大多数 Fragment View 泄漏。

同时，观察 LiveData 或 Flow 时也应绑定 viewLifecycleOwner：

kotlin 复制代码

viewModel.user.observe(viewLifecycleOwner) { user ->
    binding.name.text = user.name
}

不要在 Fragment 中用 this 作为 LifecycleOwner 观察页面 View 数据，否则 View 销毁后仍可能收到回调。

RecyclerView Adapter 持有页面对象

Adapter 生命周期经常比页面 View 更难判断。如果 Adapter 保存 Activity、Fragment 或某个 View，就可能造成泄漏。

风险写法：

kotlin 复制代码

class UserAdapter(
    private val activity: Activity
) : RecyclerView.Adapter<UserViewHolder>() {
    fun openDetail(user: User) {
        activity.startActivity(Intent(activity, DetailActivity::class.java))
    }
}

更推荐让 Adapter 只暴露事件，把页面行为交给 Fragment 或 Activity：

kotlin 复制代码

class UserAdapter(
    private val onUserClick: (User) -> Unit
) : RecyclerView.Adapter<UserViewHolder>() {
    override fun onBindViewHolder(holder: UserViewHolder, position: Int) {
        val user = getItem(position)
        holder.itemView.setOnClickListener { onUserClick(user) }
    }
}

页面中处理跳转：

kotlin 复制代码

val adapter = UserAdapter { user ->
    findNavController().navigate(
        ProfileFragmentDirections.toDetail(user.id)
    )
}

这种写法也更符合职责划分：Adapter 负责展示列表，页面负责导航和业务动作。

注册监听后忘记反注册

很多系统服务、第三方 SDK、事件总线都采用注册回调的方式。如果注册和反注册不成对，就容易泄漏页面。

kotlin 复制代码

class MainActivity : AppCompatActivity() {
    private val listener = object : LocationListener {
        override fun onLocationChanged(location: Location) {
            renderLocation(location)
        }
    }

    override fun onStart() {
        super.onStart()
        locationManager.requestLocationUpdates(provider, 1000L, 1f, listener)
    }

    override fun onStop() {
        locationManager.removeUpdates(listener)
        super.onStop()
    }
}

注册在哪个生命周期，就尽量在对应的反向生命周期里解除。onStart() 注册，通常 onStop() 解除；onResume() 注册，通常 onPause() 解除；onCreate() 注册，则要考虑 onDestroy() 是否一定会走到，以及是否符合业务时机。

协程作用域用错

协程本身不等于安全。错误的作用域同样会泄漏页面或让后台任务失控。

kotlin 复制代码

class MainActivity : AppCompatActivity() {
    fun load() {
        GlobalScope.launch {
            val data = repository.fetch()
            withContext(Dispatchers.Main) {
                render(data)
            }
        }
    }
}

GlobalScope 不跟随页面生命周期取消。页面关闭后，请求仍可能继续执行，并在回到主线程时持有 Activity。

页面层建议使用 lifecycleScope，ViewModel 层使用 viewModelScope：

kotlin 复制代码

class MainActivity : AppCompatActivity() {
    fun load() {
        lifecycleScope.launch {
            val data = repository.fetch()
            render(data)
        }
    }
}

如果任务属于业务状态而不是页面状态，放进 ViewModel：

kotlin 复制代码

class UserViewModel(
    private val repository: UserRepository
) : ViewModel() {
    val user = liveData {
        emit(repository.fetchUser())
    }
}

作用域选对了，生命周期取消就会自然发生。

定位泄漏的实战流程

遇到 LeakCanary 报告时，可以按这个顺序处理：

看最后的泄漏对象是谁，是 Activity、Fragment、View、ViewModel，还是业务对象。
沿引用链向上找第一个不合理的强引用字段。
判断这个引用属于哪类问题：静态持有、回调未解除、任务未取消、ViewBinding 未置空、Context 用错。
修改后重新复现页面打开和关闭流程。
等待 LeakCanary 再次检测，确认报告消失。

如果报告来自第三方 SDK，不要急着忽略。先确认自己是否按文档调用了释放方法，比如 destroy()、unregister()、removeListener()。只有确认是 SDK 内部问题，才考虑升级版本、隔离使用方式或在 LeakCanary 中加白名单。

什么时候可以忽略报告

LeakCanary 偶尔会看到一些系统级或第三方库内部的泄漏。是否忽略要谨慎判断：

能复现并且对象数量持续增长，不要忽略。
只出现一次，随后自动恢复，可以继续观察。
明确是系统已知问题，可以记录设备和系统版本后加排除规则。
涉及 Activity、Fragment、Bitmap、WebView 的泄漏，优先修复。

忽略报告的前提是你理解引用链，而不是看不懂就关掉提示。

预防比排查更重要

写代码时可以养成几个习惯：

单例不要保存 Activity、Fragment、View。
需要 Context 时优先确认是否可以使用 applicationContext。
Fragment 的 ViewBinding 在 onDestroyView() 置空。
注册监听必须能找到对应的反注册位置。
页面任务使用 lifecycleScope，业务状态任务使用 viewModelScope。
Adapter 不处理页面导航，不保存页面对象。
长生命周期对象不要直接持有短生命周期对象。

这条原则可以概括为：生命周期长的对象，不要强持有生命周期短的对象。

小结

内存泄漏不是玄学问题，它通常就是一条错误的引用链。LeakCanary 把这条链路展示出来，能帮助我们从"感觉页面变卡"走到"知道哪个字段持有了谁"。

真正有效的修复思路不是机械地加弱引用，而是重新梳理对象的生命周期：谁应该拥有谁，谁应该在什么时候注册、取消、释放。只要这层关系清楚，大多数 Activity、Fragment、View、Handler、Adapter 和协程相关的泄漏都能被稳定解决。