关于使用SYDialog的内存泄漏问题

[jxoday]

new SYDialog.Builder(context)
.setDialogView(R.layout.dialog_garbage_details)
//设置动画
.setAnimStyle(R.style.AnimUp)
//设置屏幕宽度比例
.setScreenWidthP(1.0f)
//设置屏幕高度比例
.setScreenHeightP(1.0f)
//设置背景透明度
.setWindowBackgroundP(0.5f)
//设置是否屏蔽物理返回键 true不屏蔽 false屏蔽
.setCancelable(true)
//设置dialog外点击是否可以让dialog消失
.setCancelableOutSide(true)
.setBuildChildListener((dialog, view, layoutRes) -> initView(dialog, view))
.setOnDismissListener(dialog -> GarbageDetailsDialog.this.context = null)
.show();

写了 GarbageDetailsDialog.this.context = null 还是有内存泄漏

[crazyqiang]

用的是leakcanary吗 看一下是报的是哪里 可以截张图 leakcanary有时候会先给提醒 但是最后本身不是内存泄漏

[jxoday]

用的是leakcanary吗看一下是报的是哪里可以截张图

LibraryLeak(className=com.ninetripods.sydialoglib.SYDialog, leakTrace=
┬
├─ android.os.HandlerThread
│ Leaking: UNKNOWN
│ Thread name: 'Chrome_ProcessLauncherThread'
│ GC Root: Java local variable
│ ↓ thread HandlerThread.
│ ~~~~~~~~~~~~
├─ android.os.Message
│ Leaking: UNKNOWN
│ ↓ Message.obj
│ ~~~
╰→ com.ninetripods.sydialoglib.SYDialog
​ Leaking: YES (Fragment#mFragmentManager is null and ObjectWatcher was watching this)
​ key = a8b2475b-d0be-4c12-bcb5-ae44b905c804
​ watchDurationMillis = 8891
​ retainedDurationMillis = 3843
, retainedHeapByteSize=387314, pattern=instance field android.os.Message#obj, description=A thread waiting on a blocking queue will leak the last dequeued object as a stack local reference. So when a HandlerThread becomes idle, it keeps a local reference to the last message it received. That message then gets recycled and can be used again. As long as all messages are recycled after being used, this won't be a problem, because these references are cleared when being recycled. However, dialogs create template Message instances to be copied when a message needs to be sent. These Message templates holds references to the dialog listeners, which most likely leads to holding a reference onto the activity in some way. Dialogs never recycle their template Message, assuming these Message instances will get GCed when the dialog is GCed. The combination of these two things creates a high potential for memory leaks as soon as you use dialogs. These memory leaks might be temporary, but some handler threads sleep for a long time. To fix this, you could post empty messages to the idle handler threads from time to time. This won't be easy because you cannot access all handler threads, but a library that is widely used should consider doing this for its own handler threads. This leaks has been shown to happen in both Dalvik and ART.)

[Licarey]

这个应该是系统级fragmentManger内部的泄露