内存泄漏与 LeakCanary：从问题定位到修复思路
为什么内存泄漏值得单独关注
Android 应用运行在内存有限的移动设备上。一次小泄漏可能暂时看不出问题，但用户频繁打开页面、旋转屏幕、切换账号或长时间停留在应用里时，泄漏对象会不断堆积，最终表现为页面卡顿、图片加载失败，严重时直接触发 OutOfMemoryError。
内存泄漏的本质很简单：一个本该被释放的对象，仍然被某条引用链持有，导致垃圾回收器无法回收它。
例如 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 报告
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(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
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(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
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(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
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, 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：
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<UserViewHolder>() {
fun openDetail(user: User) {
activity.startActivity(Intent(activity, DetailActivity::class.java))
}
}
更推荐让 Adapter 只暴露事件，把页面行为交给 Fragment 或 Activity：
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) }
}
}
页面中处理跳转：
val adapter = UserAdapter { user ->
findNavController().navigate(
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 和协程相关的泄漏都能被稳定解决。
