sdk核心中, 对viper实例的销毁不彻底, 造成了goroutine泄漏以及内存泄漏。

[LuSrackhall]

目前, 在切换多个键音包时, 每切换一次, 就会使得内存不可逆的增加一部分, 这是明显的内存泄漏问题, 需要修复。

[LuSrackhall]

在切换键音包时, 会触发核心sdk中viper实例的销毁与重建。 经初步测试定位, 已确认 由于viper实例的销毁不彻底造成的内存泄漏问题。

后续将优先着手修复, 避免此bug出现在即将到来的1.0.0的版本中。

[LuSrackhall]

升级viper依赖后, 经测试, 无法解决当前存在的内存泄漏问题。

不过, 却实实在在地减小了0.2MB的打包体积。

[LuSrackhall]

已查明问题原因是出自viper库的 WatchConfig() 文件监听功能, 此函数的调用并不会在 viper=nil 后自动释放, 因此造成了相关的goroutine及内存泄漏。viper文档中却没有提到这个, 也没有给出主动结束此函数的方式方法。
总之,目前没有公开的方法来停止 WatchConfig(), 并且其似乎没暴露任何可能适合用于在外部停止相关goroutine的东西。

由于无法在viper之外解决WatchConfig的内存泄漏问题, 因此已在viper社区提了相关issues。

后续, 此问题只能暂时搁置并通过其它手段来尽避免——比如仅在键音专辑的制作界面引入带有WatchConfig()的键音专辑加载方法。

也就是说, 需要为主页所用的键音专辑切换选择器, 实现一个专门的加载方法。

[LuSrackhall]

目前, 可以做的事情, 在此处更新:

我打算, 让现有的键音专辑页面仍依赖当前的核心sdk代码中对于键音专辑更改功能的的现有实现主体代码。

但对于主页面中仅使用键音专辑的选择器场景而言, 需要一个更轻量的仅用于读取键音专辑的代码实现, 其读取的结构无需对ui做sse反馈, 顶多依赖个sdk内的WatchConfig来更新sdk内的内存读取值与硬盘文件保持同步即可

• 当然, 若是viper后续版本仍不提供WatchConfig的清理方法, 我们也可不依赖它进行同步保持。

  因为键音专辑内部的配置一般不涉及手动修改, 其修改逻辑仅限于键音专辑页面, 我们可以在退出键音专辑页面时, 清空主页面对于键音专辑所选项的相关列表并重新加载即可。

仅主界面选择键音专辑进行播放的功能, 感觉没必要依赖WatchConfig。

• 已验证, WatchConfig引入后, 可以实时更新sdk核心对于键音专辑的播放效果。(比如, 用户通过键音专辑页面修改某些配置后, sdk核心可立即基于修改后的新配置进行播放。 否则, 若没有WatchConfig的话, 只能通过手动刷新重新获取或重启应用来更新最新修改的配置了)

  这个当然有好处, 但绝大多数用户是不喜欢自己制作键音专辑的(或者说, 绝大部分用户可能并不会去修改某些专辑——从目前的键音专辑社区建设困难可以推断), 因此没修改后的实时加载似乎影响不大——但我个人仍希望有。

• 未验证的是, WatchConfig的引入, 是否会增加内存开销。不过我们的目的只是为了在修改某个键音专辑后, sdk核心可以实时应用已更改的配置, 鉴于键音专辑的修改场景单一且固定, 我总结了以下两种方式:
  • 如果不会增加内存开销, 使用WatchConfig是很好的选择。(前提仍是其能够提供彻底销毁的方法)
  • 如果会增加内存开销, 则可以通过退出键音专辑页面时, 清空主页面对于键音专辑所选项的相关列表并重新加载的方式来实现sdk核心对于修改后的键音专辑的实时应用。

[LuSrackhall]

由于无法在viper之外解决WatchConfig的内存泄漏问题, 因此已在viper社区提了相关issues。

由于viper社区最近不怎么活跃, 而我的项目近期又迫切需要发版。因此无法被动的等待viper社区来解决相关问题了, 我将 Fork Viper的官方仓库, 并维护自己的分支来为KeyTone项目解决此问题。

相关commit链接可见->https://github.com/LuSrackhall/viper/releases/tag/v1.20.1-custom

当然, 后续我会就相关问题回馈上游, 向viper官方仓库提交有关解决此问题的pr, 若能得到viper仓库的合并, 我会将当前KeyTone项目内的 viper依赖 重新切换为 官方viper最新发布的 包含相关解决方案的版本。

相关pr链接可见->spf13/viper#2039