先聊点相关的背景知识。Android 应用的内存资源是有限的，这一点大家都很清楚。一次看似不起眼的内存泄漏，短期内或许没什么影响，但用户频繁打开关闭页面、旋转屏幕、切换账号，或者长时间将应用挂在后台，泄漏的对象就会越积越多。最终结果往往是页面卡顿、图片加载失败，严重时甚至直接抛出 OutOfMemoryError。
内存泄漏的本质与 LeakCanary 的价值
为什么内存泄漏值得单独关注
简单来说，内存泄漏就一件事——那些本应该被垃圾回收器回收的对象，因为被某些引用强拽着不放，导致无法被释放。
举个例子：一个 Activity 已经执行了 onDestroy()，按理说它关联的 View、Bitmap、Adapter 都应该一并释放。但如果某个全局单例、静态变量、后台任务或者回调仍然死死地持有这个 Activity 的引用，那它就没法被回收。而且 Activity 一旦泄漏，往往不是孤立的一个对象，而是一整棵页面对象树都跟着遭殃。
先理解引用链
垃圾回收器判断对象能否被回收，看的不是这个对象“有没有用”，而是它能不能从 GC Roots 被访问到。常见的 GC Roots 包括：
- 当前运行线程的栈变量
- 静态字段
- JNI 引用
- 系统类加载器持有的对象
- 正在运行的线程对象
如果一个已经销毁的 Activity 还能通过类似下面这条链路被找到，那它就是泄漏了：
GC Root -> Singleton.instance -> callback -> MainActivity
这正是 LeakCanary 的价值所在——它不光告诉你“有泄漏”，还把这整条引用链完完整整地展示出来，让你一眼就能看出是谁在背后“搞鬼”。
引入 LeakCanary
接入过程非常简单。你只需要在应用模块的 build.gradle 里加上 debug 依赖即可：
dependencies { debugImplementation("com.squareup.leakcanary:leakcanary-android:2.14") }
通常不需要额外初始化。安装 debug 包后，LeakCanary 会自动监听 Activity、Fragment、ViewModel 等关键对象的生命周期。一旦发现某个对象在应该释放后仍然活着，它会先触发一次 GC，再分析堆内存，最后生成通知。
有一点需要特别提醒：只在 debug 或内部测试包里启用 LeakCanary，千万别放到正式发布包里。堆转储和分析虽然是它的强项，但这种操作对性能有一定影响，不适合常驻生产环境。
如何读懂 LeakCanary 报告
报告里最重要的部分就是泄漏引用链。一个典型报告大概长这样：
┬───
│ 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
错误写法：
object UserManager { var context: Context? = null }
class MainActivity : AppCompatActivity() {
override fun onCreate(sa vedInstanceState: Bundle?) {
super.onCreate(sa vedInstanceState)
UserManager.context = this
}
}
UserManager 是全局对象，它的生命周期几乎等同于进程。一旦持有 Activity，哪怕 Activity 关闭了也没法释放。
修复方案是改用 applicationContext，或者干脆不要在单例里保存 Context：
object UserManager {
private var appContext: Context? = null
fun init(context: Context) {
appContext = context.applicationContext
}
}
如果确实需要页面能力，比如弹窗、跳转、权限请求，不要硬把 Activity 塞进单例，而应该由当前页面主动调用对应方法。
匿名内部类和延迟任务
在 Kotlin 或 Java 中，匿名内部类、Lambda、Runnable 都很容易“捕获”外部的 Activity。
class MainActivity : AppCompatActivity() {
private val handler = Handler(Looper.getMainLooper())
override fun onCreate(sa vedInstanceState: Bundle?) {
super.onCreate(sa vedInstanceState)
handler.postDelayed({ updateUi() }, 60_000)
}
}
这个延迟任务持有 MainActivity。如果页面在 60 秒内关闭了，消息队列里的 Runnable 仍然可能导致 Activity 无法释放。
正确做法是在销毁时移除任务：
class MainActivity : AppCompatActivity() {
private val handler = Handler(Looper.getMainLooper())
private val updateTask = Runnable { updateUi() }
override fun onCreate(sa vedInstanceState: Bundle?) {
super.onCreate(sa vedInstanceState)
handler.postDelayed(updateTask, 60_000)
}
override fun onDestroy() {
handler.removeCallbacks(updateTask)
super.onDestroy()
}
}
更现代的做法是利用生命周期感知的协程，避免手动维护 Handler：
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 树就会泄漏。
常见写法：
class ProfileFragment : Fragment(R.layout.fragment_profile) {
private var _binding: FragmentProfileBinding? = null
private val binding get() = _binding!!
override fun onViewCreated(view: View, sa vedInstanceState: Bundle?) {
_binding = FragmentProfileBinding.bind(view)
binding.name.text = "Lulu"
}
override fun onDestroyView() {
_binding = null
super.onDestroyView()
}
}
关键点在于：绑定对象对应的是 View 的生命周期，不是 Fragment 的周期。只要在 onDestroyView() 里置空，就能避开大多数 Fragment View 泄漏。
另外，观察 LiveData 或 Flow 时，一定要绑定 viewLifecycleOwner：
viewModel.user.observe(viewLifecycleOwner) { user ->
binding.name.text = user.name
}
千万不要在 Fragment 里用 this 作为 LifecycleOwner 去观察页面 View 数据，否则 View 销毁后仍可能被回调。
RecyclerView Adapter 持有页面对象
Adapter 的生命周期经常比页面 View 更难判断。如果 Adapter 里保存了 Activity、Fragment 或者某个 View，就很容易造成泄漏。
风险写法：
class UserAdapter(private val activity: Activity) : RecyclerView.Adapter
fun openDetail(user: User) {
activity.startActivity(Intent(activity, DetailActivity::class.ja va))
}
}
更推荐的做法是让 Adapter 只暴露事件，把页面行为交给 Fragment 或 Activity：
class UserAdapter(private val onUserClick: (User) -> Unit) : RecyclerView.Adapter
override fun onBindViewHolder(holder: UserViewHolder, position: Int) {
val user = getItem(position)
holder.itemView.setOnClickListener { onUserClick(user) }
}
}
页面里处理跳转：
val adapter = UserAdapter { user ->
findNa vController().na vigate(ProfileFragmentDirections.toDetail(user.id))
}
这种写法也更符合职责划分：Adapter 负责展示列表，页面负责导航和业务动作。
注册监听后忘记反注册
很多系统服务、第三方 SDK、事件总线都采用注册回调的方式。如果注册和反注册不成对，泄漏就找上门了。
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() 是否一定能走到，以及是否符合业务时机。
协程作用域用错
协程本身不等于安全。用错了作用域，同样会泄漏页面或让后台任务失控。
class MainActivity : AppCompatActivity() {
fun load() {
GlobalScope.launch {
val data = repository.fetch()
withContext(Dispatchers.Main) {
render(data)
}
}
}
}
GlobalScope 不跟随页面生命周期取消。页面关闭后，请求可能还在执行，回到主线程时就会持有 Activity。
页面层推荐使用 lifecycleScope，ViewModel 层使用 viewModelScope：
class MainActivity : AppCompatActivity() {
fun load() {
lifecycleScope.launch {
val data = repository.fetch()
render(data)
}
}
}
如果任务属于业务状态而不是页面状态，放进 ViewModel：
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 和协程相关的泄漏，都能被稳稳地解决。
