-
Notifications
You must be signed in to change notification settings - Fork 571
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
内存泄露问题 #1070
Comments
现在有解决方案吗?我这也是一样的问题 |
同求,影响用户体验 |
貌似维护者一直都没处理,相关issues也不少了,我也在源码没找到原因,现在我是把所有子应用keep-alive就不会有同一个子应用占用内存翻倍的问题了,但是需要处理下子应用激活和隐藏时路由同步 |
我使用的是官方推荐的UMD渲染模式,同时启用 iframe 加载,基本保证keep-alive等功能正常使用。 |
同问。为了实现多tab,打开了很多 micro-app标签,打开一个子应用就大概50M,unmount了不会减。非常容易就上1G内存了。 |
@bailicangdu 官方大佬,帮忙看看这个内存问题啊。没打开几个tab就 1个G内存了,关了还请不掉。是用umd的。 |
俺也出现了这个问题 |
你解决了么? |
问题描述
子应用已经设置了destory: true,都会出现这个问题。即使是手动调用unmountApp也一样
上述三种子应用配置组合都会出现这个问题,并且inline配置项、fibler配置项的true或false都对这个3种模式互相组合试过了,都会出现这个问题。
手动fork源码对unmount流程中添加了指定sandbox、iframe等属性都清空也避免不了这个问题。
估计在实现过程中的某个地方保留了对子应用的引用导致无法自动OC?
我发现这个问题是因为tdesign-icon在micro-app环境下自动请求svg精灵图时在子应用首页生成了90000个dom导致子应用在第二次挂载时已经卡死的异常。相关issues
麻烦尽快排查一下这个问题,貌似一直都存在这个现象。
相关issues
复现步骤
上传截图
复现仓库
环境信息
The text was updated successfully, but these errors were encountered: