leakcanary 中的 LIBRARY LEAKS 是什么?

what are LIBRARY LEAKS in leakcanary?

在 leakcanary 中,有时我收到的泄漏报告为 "Library leaks"

 HEAP ANALYSIS RESULT
    ====================================
    0 APPLICATION LEAKS

    References underlined with "~~~" are likely causes.
    Learn more at https://squ.re/leaks.
    ====================================
    1 LIBRARY LEAKS

    Library Leaks are leaks coming from the Android Framework or Google libraries.

    Leak pattern: instance field android.view.ViewGroup$ViewLocationHolder#mRoot
    Description: In Android P, ViewLocationHolder has an mRoot field that is not cleared in its clear() method. Introduced in https://github.com/aosp-mirror/platform_frameworks_base/commit/86b326012813f09d8f1de7d6d26c986a909d Bug report: https://issuetracker.google.com/issues/112792715
    66264 bytes retained by leaking objects
    Signature: 64becd25d6156daa91df6572a75b6a28ddb1
    ┬───
    │ GC Root: System class

在 leakcanary 网站上说:

LibraryLeak at leakcanary website

LibraryLeak

data class LibraryLeak :Leak

A leak found by HeapAnalyzer, where the only path to the leaking object required going through a reference matched by pattern, as provided to a LibraryLeakReferenceMatcher instance. This is a known leak in library code that is beyond your control.

这真的不是我能控制的吗?

可能是我做了什么导致的吗?

有什么办法可以预防吗?

leakcanry 有时会放置一个 link 来报告此内存泄漏,但我没有看到任何响应,这是 android 正常工作的东西吗?如果是这样,这些问题通常是如何解决的以及如何跟踪?

如果我确实无能为力解决或阻止它,有没有办法让 leakcanary 忽略 LIBRARY LEAKS?

这是一个很好的问题,实际上应该更好地记录这个问题,所以我创建了一个问题来跟踪这个问题:https://github.com/square/leakcanary/issues/1773

is it really out of my control?

是也不是。通常这意味着泄漏不是由代码中的错误或 API 错误使用引起的,而是由 Android X 或 Android SDK 中的错误引起的。话虽这么说,它并不总是不受您的控制,可以使用技巧/技巧来解决泄漏问题。

might there be something i did to cause it?

AndroidP 中的 ViewLocationHolder 是一个不幸的错误,它会在您使用视图时发生。所以是的,你并没有做任何特别的事情。

Is there anything i can do to prevent it?

有可能,但还没有人提出明确的破解方法来解决它。

leakcanry sometimes places a link to report this memory leak but i don't see any response, is it something that android normally working on? if so, how such issues normally solved and how to keep track?

不确定你的意思。如果您的意思是错误报告 (https://issuetracker.google.com/issues/112792715) 的 link 停止工作,是的,那是因为 Google 决定阻止访问。

if indeed there is nothing i can do to solve or prevent it, is there a way i can ask leakcanary to ignore LIBRARY LEAKS?

在转储堆和进行分析之前,LeakCanary 无法知道泄漏是否是库泄漏。重要的是要通知开发人员分析已完成(即使它只发现库泄漏而没有发现应用程序泄漏),否则他们想知道分析发生了什么。