Android Canary 漏洞——计费和 ViewBinding

Question

我将 LeakCanary 导入到我的项目中，以了解我内部有哪些内存泄漏以及有多少内存泄漏，然后能够修复它们。我注意到这两个我无法修复。更好地说，我不知道如何用代码来解决它们。有人知道如何给我一些建议吗？

LeakCanary: 2 APPLICATION LEAKS
LeakCanary: References underlined with "~~~" are likely causes.
LeakCanary: Learn more at https://squ.re/leaks.
LeakCanary: 16523886 bytes retained by leaking objects
LeakCanary: Signature: 4594f3337285a2a3dd854a7bf9c944f5598ae18b
LeakCanary: ┬───
LeakCanary: │ GC Root: Global variable in native code
LeakCanary: │
LeakCanary: ├─ android.app.LoadedApk$ServiceDispatcher$DeathMonitor instance
LeakCanary: │    Leaking: UNKNOWN
LeakCanary: │    Retaining 144 bytes in 4 objects
LeakCanary: │    ↓ LoadedApk$ServiceDispatcher$DeathMonitor.this$0
LeakCanary: │                                               ~~~~~~
LeakCanary: ├─ android.app.LoadedApk$ServiceDispatcher instance
LeakCanary: │    Leaking: UNKNOWN
LeakCanary: │    Retaining 622 bytes in 8 objects
LeakCanary: │    mContext instance of com.example.packagename.ApplicationContext
LeakCanary: │    ↓ LoadedApk$ServiceDispatcher.mConnection
LeakCanary: │                                  ~~~~~~~~~~~
LeakCanary: ├─ com.android.billingclient.api.BillingClientImpl$zza instance
LeakCanary: │    Leaking: UNKNOWN
LeakCanary: │    Retaining 41 bytes in 3 objects
LeakCanary: │    ↓ BillingClientImpl$zza.zzd
LeakCanary: │                            ~~~
LeakCanary: ├─ com.example.packagename.fragments.ShopFragment$setupBillingClient$1 instance
LeakCanary: │    Leaking: UNKNOWN
LeakCanary: │    Retaining 12 bytes in 1 objects
LeakCanary: │    Anonymous class implementing com.android.billingclient.api.BillingClientStateListener
LeakCanary: │    ↓ ShopFragment$setupBillingClient$1.this$0
LeakCanary: │                                        ~~~~~~
LeakCanary: ╰→ com.example.packagename.fragments.ShopFragment instance
LeakCanary: ​     Leaking: YES (ObjectWatcher was watching this because com.example.packagename.fragments.ShopFragment received
LeakCanary: ​     Fragment#onDestroy() callback and Fragment#mFragmentManager is null)
LeakCanary: ​     Retaining 16523886 bytes in 33489 objects
LeakCanary: ​     key = b2ebfeff-4177-4587-b7f5-e4c89bc4afaa
LeakCanary: ​     watchDurationMillis = 40425
LeakCanary: ​     retainedDurationMillis = 35424
LeakCanary: 2804 bytes retained by leaking objects
LeakCanary: Signature: 71c80305d50d16354a6bec910e7f529c72e4296
LeakCanary: ┬───
LeakCanary: │ GC Root: Local variable in native code
LeakCanary: │
LeakCanary: ├─ android.os.HandlerThread instance
LeakCanary: │    Leaking: NO (PathClassLoader↓ is not leaking)
LeakCanary: │    Thread name: 'queued-work-looper'
LeakCanary: │    ↓ HandlerThread.contextClassLoader
LeakCanary: ├─ dalvik.system.PathClassLoader instance
LeakCanary: │    Leaking: NO (ViewDataBinding↓ is not leaking and A ClassLoader is never leaking)
LeakCanary: │    ↓ PathClassLoader.runtimeInternalObjects
LeakCanary: ├─ java.lang.Object[] array
LeakCanary: │    Leaking: NO (ViewDataBinding↓ is not leaking)
LeakCanary: │    ↓ Object[].[881]
LeakCanary: ├─ androidx.databinding.ViewDataBinding class
LeakCanary: │    Leaking: NO (a class is never leaking)
LeakCanary: │    ↓ static ViewDataBinding.sReferenceQueue
LeakCanary: │                             ~~~~~~~~~~~~~~~
LeakCanary: ├─ java.lang.ref.ReferenceQueue instance
LeakCanary: │    Leaking: UNKNOWN
LeakCanary: │    Retaining 724 bytes in 30 objects
LeakCanary: │    ↓ ReferenceQueue.head
LeakCanary: │                     ~~~~
LeakCanary: ├─ androidx.databinding.ViewDataBinding$WeakListener instance
LeakCanary: │    Leaking: UNKNOWN
LeakCanary: │    Retaining 52 bytes in 2 objects
LeakCanary: │    ↓ ViewDataBinding$WeakListener.mObservable
LeakCanary: │                                   ~~~~~~~~~~~
LeakCanary: ├─ androidx.databinding.ViewDataBinding$LiveDataListener instance
LeakCanary: │    Leaking: UNKNOWN
LeakCanary: │    Retaining 16 bytes in 1 objects
LeakCanary: │    ↓ ViewDataBinding$LiveDataListener.mLifecycleOwner
LeakCanary: │                                       ~~~~~~~~~~~~~~~
LeakCanary: ╰→ com.example.packagename.fragments.InventoryFragment instance
LeakCanary: ​     Leaking: YES (ObjectWatcher was watching this because com.example.packagename.fragments.InventoryFragment
LeakCanary: ​     received Fragment#onDestroy() callback and Fragment#mFragmentManager is null)

如您所见，主要有 2 个漏洞，但我不确定我知道如何修复它们。

Answer 1

第一个 leaktrace 显示 ShopFragment 在 ShopFragment$setupBillingClient 中设置了一个 BillingClientStateListener，可能是通过调用 BillingClient#startConnection() 。匿名类中的 BillingClientStateListener 实现，并引用其外部类 ShopFragment 的实例。看着 Javadoc ，似乎您需要在完成后调用 BillingClient#endConnection()，即当 fragment 被销毁时。计费documentation根本没有提及这一点，因此您可能想要提交文档错误。

第二个泄漏跟踪显示与被销毁的 InventoryFragment 关联的 ViewDataBinding.LiveDataListener 由 ViewDataBinding.sReferenceQueue 保存在内存中(参见 sources here。事实 ViewDataBinding$WeakListener 在队列中意味着 ViewDataBinding.WeakListener 不是强可达的。ViewDataBinding.processReferenceQueue() 负责这样做，所以它看起来好像有一段时间没有被调用了。如果没有堆转储，很难确定，但这看起来像是一个 DataBinding 库错误，您应该提交一张票。