【问题标题】:LeakCanary not giving enough information to identify leakLeakCanary 没有提供足够的信息来识别泄漏
【发布时间】:2021-03-13 07:38:10
【问题描述】:

我正在使用 LeakCanary,但堆分析结果没有提供足够的信息来检测任何泄漏。它只提到活动正在泄漏。

D/LeakCanary: ​
    ====================================
    HEAP ANALYSIS RESULT
    ====================================
    1 APPLICATION LEAKS
    
    References underlined with "~~~" are likely causes.
    Learn more at https://squ.re/leaks.
    
    298153 bytes retained by leaking objects
    Signature: a610bac3ef989ac5dc5a69244fc2882de5617
    ┬───
    │ GC Root: System class
    │
    ├─ android.provider.FontsContract class
    │    Leaking: NO (MyApplication↓ is not leaking and a class is never leaking)
    │    ↓ static FontsContract.sContext
    ├─ com.example.MyApplication instance
    │    Leaking: NO (Application is a singleton)
    │    mBoundService instance of com.example.services.SessionService
    │    mBase instance of android.app.ContextImpl
    │    ↓ Application.mLoadedApk
    │                  ~~~~~~~~~~
    ├─ android.app.LoadedApk instance
    │    Leaking: UNKNOWN
    │    Retaining 302.8 kB in 4641 objects
    │    mApplication instance of com.example.MyApplication
    │    ↓ LoadedApk.mReceivers
    │                ~~~~~~~~~~
    ├─ android.util.ArrayMap instance
    │    Leaking: UNKNOWN
    │    Retaining 301.7 kB in 4615 objects
    │    ↓ ArrayMap.mArray
    │               ~~~~~~
    ├─ java.lang.Object[] array
    │    Leaking: UNKNOWN
    │    Retaining 301.7 kB in 4613 objects
    │    ↓ Object[].[2]
    │               ~~~
    ╰→ com.example.activities.SelectActivity instance
    ​     Leaking: YES (ObjectWatcher was watching this because com.example.activities.SelectActivity received
    ​     Activity#onDestroy() callback and Activity#mDestroyed is true)
    ​     Retaining 298.2 kB in 4579 objects
    ​     key = 68660c30-bc17-4a74-a5e2-c54f6d676c59
    ​     watchDurationMillis = 5185
    ​     retainedDurationMillis = 183
    ​     mApplication instance of com.example.MyApplication
    ​     mBase instance of androidx.appcompat.view.ContextThemeWrapper
    ====================================
    0 LIBRARY LEAKS

我从这条踪迹中只知道SelectActivity 正在泄漏。但我想不通为什么?活动本身有 1000 多行,我希望除了遍历每一行并检查可能的泄漏候选之外是否有任何捷径。

【问题讨论】:

  • 尝试更改查找this(作为上下文)在活动中使用的位置并检查多线程行。我建议重构它并尝试使用 ViewModel 和其他模式来减少代码的活动行。否则,我希望上帝帮助:D
  • 哈哈。我已经尝试了几天了。除了适配器和异步任务之外,我已经从活动中删除了几乎所有内容,并且这些也没有对活动的任何引用。但它仍然在泄漏。有没有其他方法可以更好地追踪泄漏?上面的痕迹根本没有帮助。

标签: android android-activity memory-leaks memory-profiling java-memory-leaks


【解决方案1】:

活动是否注册了任何广播接收器?泄漏跟踪显示 LoadedApk.mReceivers,它是接收器到接收器调度器的 ArrayMap,活动是接收器调度器。

【讨论】:

  • 不,它现在不使用任何接收器。它之前使用了位置监听器,但我完全删除了它,它仍然在某处泄漏:(
  • 你确实是对的。有一个基本活动注册了一个接收器两次并导致了这个泄漏。谢谢!
  • 谢谢!您可以在github.com/square/leakcanary/issues/new/choose 提出问题吗?我会检查我是否可以复制,如果可以,如果其他人遇到错误,我是否可以使错误更加明显。也可以随意验证答案:)
  • 更新:我在这里提交:github.com/square/leakcanary/issues/2091
  • 哦,很抱歉我错过了你的最后一条消息。但感谢提交。要添加更多信息,该寄存器已在 onResumeonActivityResult 中注册,而在 onPause 中未注册。而这一切都在基础活动中,这就是为什么我一开始就错过了。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2017-11-11
  • 1970-01-01
  • 1970-01-01
  • 2020-06-18
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多