Floorp浏览器内存泄漏问题分析与解决方案

问题背景

在Floorp浏览器11.17.6及更高版本中，用户报告了一个严重的性能问题：浏览器UI会周期性地出现数秒的卡顿，导致浏览器在这段时间内完全无法使用。经过深入分析，发现问题与浏览器处理大量Blob URL的方式有关，特别是在拥有大量标签页(约8个窗口，每个窗口100个标签页)的情况下尤为明显。

问题现象

用户观察到的主要症状包括：

1. 浏览器UI周期性卡顿，每次持续数秒
2. 主进程内存使用量异常增长，最高可达20GB
3. 性能分析显示卡顿发生在Blob URL处理相关函数中

技术分析

通过性能分析和调试，我们定位到问题的核心在于mozilla::dom::BlobURLProtocolHandler::ForEachBlobURL()和mozilla::dom::PContentParent::SendInitBlobURLs()函数。这些函数在尝试序列化Blob URL时，需要遍历一个非常大的链表结构。

进一步调试发现：

1. 系统中存在大量形式为blob:null/<guid>的Blob URL
2. Blob URL哈希表中存在40402个条目
3. 这些Blob URL是由browser-favicon-color.mjs模块中的代码创建的

根本原因

问题的根本原因在于browser-favicon-color.mjs模块中使用了URL.createObjectURL()API来创建临时URL，但没有及时调用URL.revokeObjectURL()来释放这些资源。根据Web API规范，通过URL.createObjectURL()创建的URL生命周期与创建它的文档绑定，必须显式调用URL.revokeObjectURL()来释放。

具体来说，该模块在处理标签页图标颜色时，会创建Blob对象来表示图标数据，然后使用URL.createObjectURL()为这些Blob创建临时URL。由于没有及时释放，这些URL会不断累积，最终导致：

1. 内存占用持续增长
2. 在需要序列化或传输Blob URL时性能急剧下降
3. 主进程响应变慢，UI卡顿

解决方案

解决此问题的关键在于正确管理Blob URL的生命周期。具体修改应包括：

1. 在browser-favicon-color.mjs中，为每个通过URL.createObjectURL()创建的URL添加对应的URL.revokeObjectURL()调用
2. 确保在不再需要Blob URL时立即释放它
3. 优化图标处理逻辑，减少不必要的Blob URL创建

实施建议

对于开发者而言，处理类似问题时应注意：

1. 任何使用URL.createObjectURL()的地方都必须配对的URL.revokeObjectURL()调用
2. 考虑使用try-finally块确保资源释放
3. 对于频繁创建/释放的场景，可以考虑对象池或缓存机制
4. 在性能敏感的代码路径中，避免创建大量临时对象

总结

这个案例展示了Web平台API使用不当可能导致的内存泄漏和性能问题。通过正确的资源管理实践，可以避免这类问题。Floorp浏览器团队已经注意到这个问题，并将在后续版本中修复。对于遇到类似问题的用户，建议检查自己的扩展或自定义脚本中是否存在未释放的Blob URL。