播放页面的内存泄漏问题的讨论

[Empty-57]

关于播放页面和歌词渲染组件内存泄漏问题的讨论

[Empty-57]

问题概述

在此播放页面时，持续播放音频和切换音频均会造成内存泄漏情况（一次涨几MB到十几MB不等）。
但是通过DevTools观察到堆大小稳定，RSS大小逐渐增加，我无法使用DevTools的快照截取功能（一截取快照整个DevTools就会卡死），所以只能大致定位到泄漏源在这两个文件上（也有可能有其他泄漏源）

[qingyueyin]

这么晚了还没睡啊，我刚看完番（）

[Empty-57]

生物钟是这样的，明天得中午起来了

…

---原始邮件--- 发件人: ***@***.***> 发送时间: 2026年8月24日(周一) 凌晨2:00 收件人: ***@***.***>; 抄送: ***@***.******@***.***>; 主题: Re: [Empty-57/ZeroBit-Player] 播放页面的内存泄漏问题的讨论 (Discussion #50) 这么晚了还没睡啊，我刚看完番（） — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[qingyueyin]

我的做法很简单，因为切换音频的这个过程，若想要正确的解码封面和播放，溢出是正常的，接受他。
你要做的是，让他停下来之后可以减肥，不要一次性给他变成瘦子，容易触底反弹。
所以我才有做阈值回收处理，不能一直回收

[qingyueyin]

这就是我的处理思路，有跟你讲过的吧

[qingyueyin]

一直回收后重载，那能不爆炸吗（

[Empty-57]

我看你代码清理的大多是图片资源，我这的问题图片资源不是大头，我也不知道问题在哪了，该释放的也释放了，闭包也没拿什么长期生命资源

…

---原始邮件--- 发件人: ***@***.***> 发送时间: 2026年8月24日(周一) 凌晨2:01 收件人: ***@***.***>; 抄送: ***@***.******@***.***>; 主题: Re: [Empty-57/ZeroBit-Player] 播放页面的内存泄漏问题的讨论 (Discussion #50) 我的做法很简单，因为切换音频的这个过程，若想要正确的解码和播放，溢出是正常的，接受他。 你要做的是，让他停下来之后可以减肥，不要一次性给他变成瘦子，容易触底反弹。 所以我才有做阈值回收处理，不能一直回收 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[qingyueyin]

我这的问题图片资源不是大头，我也不知道问题在哪了

🤔那我也不清楚啊，只能猜
看看可视化频谱？
反正不要一直触发重建就对了

[Empty-57]

我没特意去做一个专门管理资源与内存的方法（除了图片缓存LRU），我认为只要管理好各种动画，计时器，监听器的生命周期，肯定就没有很严重的内存泄露

…

---原始邮件--- 发件人: ***@***.***> 发送时间: 2026年8月24日(周一) 凌晨2:04 收件人: ***@***.***>; 抄送: ***@***.******@***.***>; 主题: Re: [Empty-57/ZeroBit-Player] 播放页面的内存泄漏问题的讨论 (Discussion #50) 一直回收后重载，那能不爆炸吗（ — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[qingyueyin]

早点休息🌹
说不定明天就想出来了

[Empty-57]

我测试的时候，频谱都没开😭，频繁触发重建的只有当前唱的字和当前行

…

---原始邮件--- 发件人: ***@***.***> 发送时间: 2026年8月24日(周一) 凌晨2:07 收件人: ***@***.***>; 抄送: ***@***.******@***.***>; 主题: Re: [Empty-57/ZeroBit-Player] 播放页面的内存泄漏问题的讨论 (Discussion #50) 我这的问题图片资源不是大头，我也不知道问题在哪了 🤔那我也不清楚啊，只能猜 看看可视化频谱？ 反正不要一直触发重建就对了 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[qingyueyin]

我有空帮你看看吧

[Empty-57]

嗯嗯

…

---原始邮件--- 发件人: ***@***.***> 发送时间: 2026年8月24日(周一) 凌晨2:09 收件人: ***@***.***>; 抄送: ***@***.******@***.***>; 主题: Re: [Empty-57/ZeroBit-Player] 播放页面的内存泄漏问题的讨论 (Discussion #50) 早点休息🌹 说不定明天就想出来了 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[Empty-57]

嗯嗯，谢谢了，我这几天还在flutter的issue里面找有没有类似情况，也没进展

…

---原始邮件--- 发件人: ***@***.***> 发送时间: 2026年8月24日(周一) 凌晨2:13 收件人: ***@***.***>; 抄送: ***@***.******@***.***>; 主题: Re: [Empty-57/ZeroBit-Player] 播放页面的内存泄漏问题的讨论 (Discussion #50) 我有空帮你看看吧 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[qingyueyin]

给你些建议，参考着看：

1. _HighlightedWord 的 shaderCallback 里每帧都在调 LinearGradient.createShader()，返回的是 ui.Image 类型的 Skia shader 对象，Dart 侧看不见，但 native 侧会累积。不是关它，而是缓存这个 shader，只在颜色或进度区间变化时重建。

2. _BreathingDots 用了 AnimationController.repeat(reverse: true)，间奏可见后如果组件被 AnimatedSwitcher 从树上摘掉，dispose 理论上会执行，但间奏切换频繁时会出现创建-销毁-再创建的抖动，每次抖动都有一帧生命周期窗口。这个和内存关系小，但能解释"频繁触发重建的只有当前字和当前行"却还能涨——问题在 shader 对象，widget 树不是大头。

[Empty-57]

好的，谢谢

…

---原始邮件--- 发件人: ***@***.***> 发送时间: 2026年9月6日(周日) 中午12:09 收件人: ***@***.***>; 抄送: ***@***.******@***.***>; 主题: Re: [Empty-57/ZeroBit-Player] 播放页面的内存泄漏问题的讨论 (Discussion #50) 给你些建议，参考着看： _HighlightedWord 的 shaderCallback 里每帧都在调 LinearGradient.createShader()，返回的是 ui.Image 类型的 Skia shader 对象，Dart 侧看不见，但 native 侧会累积。不是关它，而是缓存这个 shader，只在颜色或进度区间变化时重建。 _BreathingDots 用了 AnimationController.repeat(reverse: true)，间奏可见后如果组件被 AnimatedSwitcher 从树上摘掉，dispose 理论上会执行，但间奏切换频繁时会出现创建-销毁-再创建的抖动，每次抖动都有一帧生命周期窗口。这个和内存关系小，但能解释"频繁触发重建的只有当前字和当前行"却还能涨——问题在 shader 对象，widget 树不是大头。 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>