首页 > 解决方案 > Toast.mNextView 和 FrameLayout 可能泄漏——如何追查原因?

问题描述

我的应用程序有泄漏,我不确定它来自哪里。我正在使用 Leak Canary 来追踪泄漏,但仍然无法查明确切的原因。

任何关于如何解决该问题的新建议将不胜感激!

这是来自 Leak Canary 的泄漏:

┬───
│ GC Root: Global variable in native code
│
├─ android.database.ContentObserver$Transport instance
│    Leaking: UNKNOWN
│    Retaining 85 B in 4 objects
│    ↓ ContentObserver$Transport.mContentObserver
│                                ~~~~~~~~~~~~~~~~
├─ io.flutter.view.AccessibilityBridge$3 instance
│    Leaking: UNKNOWN
│    Retaining 57 B in 3 objects
│    Anonymous subclass of android.database.ContentObserver
│    ↓ AccessibilityBridge$3.this$0
│                            ~~~~~~
├─ io.flutter.view.AccessibilityBridge instance
│    Leaking: UNKNOWN
│    Retaining 626 B in 16 objects
│    ↓ AccessibilityBridge.accessibilityChannel
│                          ~~~~~~~~~~~~~~~~~~~~
├─ io.flutter.embedding.engine.systemchannels.AccessibilityChannel instance
│    Leaking: UNKNOWN
│    Retaining 24 B in 1 objects
│    ↓ AccessibilityChannel.flutterJNI
│                           ~~~~~~~~~~
├─ io.flutter.embedding.engine.FlutterJNI instance
│    Leaking: UNKNOWN
│    Retaining 144 B in 10 objects
│    ↓ FlutterJNI.platformMessageHandler
│                 ~~~~~~~~~~~~~~~~~~~~~~
├─ io.flutter.embedding.engine.dart.DartMessenger instance
│    Leaking: UNKNOWN
│    Retaining 8.0 kB in 113 objects
│    ↓ DartMessenger.messageHandlers
│                    ~~~~~~~~~~~~~~~
├─ java.util.HashMap instance
│    Leaking: UNKNOWN
│    Retaining 7.9 kB in 110 objects
│    ↓ HashMap.table
│              ~~~~~
├─ java.util.HashMap$Node[] array
│    Leaking: UNKNOWN
│    Retaining 7.8 kB in 109 objects
│    ↓ HashMap$Node[].[7]
│                     ~~~
├─ java.util.HashMap$Node instance
│    Leaking: UNKNOWN
│    Retaining 6.8 kB in 67 objects
│    ↓ HashMap$Node.next
│                   ~~~~
├─ java.util.HashMap$Node instance
│    Leaking: UNKNOWN
│    Retaining 6.8 kB in 65 objects
│    ↓ HashMap$Node.value
│                   ~~~~~
├─ io.flutter.plugin.common.MethodChannel$IncomingMethodCallHandler instance
│    Leaking: UNKNOWN
│    Retaining 6.7 kB in 62 objects
│    ↓ MethodChannel$IncomingMethodCallHandler.handler
│                                              ~~~~~~~
├─ io.github.ponnamkarthik.toast.fluttertoast.MethodCallHandlerImpl instance
│    Leaking: UNKNOWN
│    Retaining 6.7 kB in 61 objects
│    context instance of com.example.app.Application
│    ↓ MethodCallHandlerImpl.mToast
│                            ~~~~~~
├─ android.widget.Toast instance
│    Leaking: YES (This toast is done showing (Toast.mTN.mWM != null && Toast.
│    mTN.mView == null))
│    Retaining 6.7 kB in 60 objects
│    mContext instance of com.example.app.Application
│    ↓ Toast.mNextView
╰→ android.widget.FrameLayout instance
​     Leaking: YES (ObjectWatcher was watching this because android.widget.
​     FrameLayout received View#onDetachedFromWindow() callback)
​     Retaining 6.3 kB in 54 objects
​     key = f2d26abf-ece1-4929-b7bd-bb66cd4a300b
​     watchDurationMillis = 68439
​     retainedDurationMillis = 63437
​     View not part of a window view hierarchy
​     View.mAttachInfo is null (view detached)
​     View.mWindowAttachCount = 1
​     mContext instance of com.example.app.Application

导致泄漏的事件链似乎始于几个不同的进程,但 Leak Canary 总是最终在 Toast 和 FrameLayout 中检测到相同的泄漏。

标签: androidfluttermemory-leaksleakcanary

解决方案


此 toast 泄漏是由ponnamkarthik/FlutterToast中的 MethodCallHandlerImpl.mToast 引起的。

我在这里提出了一个问题:https ://github.com/ponnamkarthik/FlutterToast/issues/292


推荐阅读