LeakCanary 在此泄漏跟踪中抱怨什么？

Question

====================================
HEAP ANALYSIS RESULT
====================================
1 APPLICATION LEAKS
 
References underlined with "~~~" are likely causes.
Learn more at https://squ.re/leaks.
 
1349 bytes retained by leaking objects
Signature: fbba65ae31efd4f2c9cce2a7189127798c896c7f
┬───
│ GC Root: Global variable in native code
│
├─ android.telecom.InCallService$InCallServiceBinder instance
│    Leaking: UNKNOWN
│    Retaining 1.9 kB in 12 objects
│    this$0 instance of com.redacted.company.CallService
│    instance InCallService$InCallServiceBinder@317901080
│    ↓ InCallService$InCallServiceBinder.this$0
│                                        ~~~~~~
╰→ com.redacted.company.CallService instance
     Leaking: YES (ObjectWatcher was watching this because com.redacted.company.CallService received Service#onDestroy() callback and Service not held by ActivityThread)
     Retaining 1.3 kB in 11 objects
     key = 4658065d-2277-46cb-ad96-3de0440b039b
     watchDurationMillis = -3481823
     retainedDurationMillis = -3486830
     mApplication instance of com.redacted.company.MyApplication
     mBase instance of android.app.ContextImpl
     instance CallService@321294080
====================================
0 LIBRARY LEAKS
 
A Library Leak is a leak caused by a known bug in 3rd party code that you do not have control over.
See https://square.github.io/leakcanary/fundamentals-how-leakcanary-works/#4-categorizing-leaks
====================================
0 UNREACHABLE OBJECTS
 
An unreachable object is still in memory but LeakCanary could not find a strong reference path
from GC roots.
====================================

它是否在抱怨 android.telecom.InCallService$InCallServiceBinder 中存在泄漏？

我已将 CallService 类中的代码简化为简单的 super.() ，仅调用 onCallAdded 和 onCallRemoved 函数，因此我的泄漏不会在那里。

Answer 1

我想我找到了为什么会出现这个问题。

我的片段处于在配置更改时保留其内部状态的状态。 （不记得这个州的名字是什么）...

我正在从主 Activity 中获取一个 Service 实例。

如果我的预感是正确的，那么问题应该通过在“onStop”...或“onPause”期间清空 Service 实例来解决...为什么不使用 onDestroy()???

因为这个保留状态的配置...在配置更改期间似乎不会强制 onDestroy()...

这意味着绑定到先前 Activity 实例的旧 Service 实例...保存在 Fragment 的“尸体”内...在可重用 Fragment 的堆栈中...这仍然很奇怪...如果我的想法是正确的... Activity 的生命周期永远不会比 Fragment 短...无论哪种配置...

如果有效的话我会更新...