[英]Why does Leakcanary state that a weakreference caused a leak?
LeakCanary报告了泄漏:
LeakingInstance(referenceKey=c0b17865-2174-494c-861b-e8bd96a894b2, referenceName=, instanceClassName=superfreeze.tool.android.userInterface.intro.IntroActivity, watchDurationMillis=5162, retainedDurationMillis=159, exclusionStatus=WEAKLY_REACHABLE, leakTrace=
┬
├─ android.view.ViewRootImpl$AccessibilityInteractionConnection
│ Leaking: NO (it's a GC root)
│ ↓ ViewRootImpl$AccessibilityInteractionConnection.mViewRootImpl
│ ~~~~~~~~~~~~~
├─ java.lang.ref.WeakReference
│ Leaking: UNKNOWN
│ Matches exclusion field java.lang.ref.WeakReference#referent
│ ↓ WeakReference.referent
│ ~~~~~~~~
├─ android.view.ViewRootImpl
│ Leaking: UNKNOWN
│ ↓ ViewRootImpl.mContext
│ ~~~~~~~~
╰→ superfreeze.tool.android.userInterface.intro.IntroActivity
Leaking: YES (RefWatcher was watching this and Activity#mDestroyed is true)
, retainedHeapSize=null)
但是第一个条目(AccessibilityInteractionConnection)似乎仅持有对第三个条目的弱引用(第二个条目),因此,应该对ViewRootImpl和IntroActivity进行垃圾收集! 泄漏从何而来?
在LeakCanary文档中说:
泄漏跟踪是从垃圾回收根到保留对象的最短强引用路径的另一个名称。
但我在这里甚至没有走强路!
我理解错了什么?
在v2 alpha2中,LeakCanary开始将WeakReferences纳入其最短路径的计算中: https ://square.github.io/leakcanary/changelog/#version-20-alpha-2-2019-05-21
回想起来,这是一个错误,后来被删除。 您需要更新LeakCanary。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.