目前碰到的大问题：组件切换时，IE6内存一直在增长

按常规界面布局来做的，登录后的页面是一个frame框架，左边frame放功能菜单，右边frame放具体业务操作区。
尝试过两个方案：
1.一个三级菜单小项，一个GWT模块（GWT模块数很多，整体编译速度慢死了）。单击左边的菜单项，右边换一个 html 。
2.一个一级菜单，一个GWT模块（GWT模块数是一级菜单的数量，整体编译速度提供了很多，能承受了）。单击一个一级菜单下的 三级菜单小项时，是 GWT组件 的 切换，不再是 html之间的 切换了。

   发现：切换三级菜单时，IE6 内存 不断在以500K的速度在增长，不释放。当最小化IE后，再最大化，内存就能降回去。也许是什么变量没有释放导致的。但查了很多次了，也找不出原因。

   看了 GWT 提供的 showcase 例子，它的菜单的切换就没有导致内存一直增长。它采用了  History 组件 来缓存 所有菜单项的组件。

   谁有类似的痛苦？

评论

5 楼 eyes1842 2009-01-22  

个人认为，使用GWT的项目一般都不是门户之类的针对广泛用户的，而是类似与管理系统之类的针对特定用户。
既然是针对特定用户，那么可以要求客户使用非IE内核的浏览器。这样的话运行大js程序非常有优势，IE6运行js
的内存泄漏确实是个问题，不过不要紧，IE6正在慢慢淡出历史舞台了。何况现在客户端的机器配置越来越高了，
内存应该不成为瓶颈。况且这是在客户端，死了从来。

在编程时，完全可以使用一个模块。就像楼上说的，各个叶面用到时再加载，用完了可以remove掉。如果使用
谷歌浏览器的话，内存使用在200M以内都是稳定的，是IE6的话，早就崩溃了。

编译时间的话，一个模块的话，最多就是几分钟了（如果很大的话），还可以接受。
在调试的时候可以只编译一个浏览器的的js这样的话时间会减少很多。

4 楼 aibozeng 2009-01-01  

如果整个系统（60个菜单）是一个GWT模块，编译对机器的性能要求太高了。debug也有问题。


这个内存的问题，基本搞掂了，是使用了 GXT 的 一个组件的问题( Composite的root widget不能是 gxt提供的组件)。

3 楼 stone 2008-12-21  

为什么要用frame来做布局呢？frame本身就有占用内存而不释放的问题，何况一个gwt的模块涉及了太多的资源。

可以采用一个完整的gwt模块来做，菜单也使用gwt，一个完整的gwt应用，切换只发生在gwt的组件之间，而且gwt的组件可以采用lazy的形式进行控制，没有用到的就不要初始化，第一次用到的，初始化它，下一次用的时候无须再初始化了

2 楼 abo 2008-12-21  

没用gwt作过这么复杂的应用，暂时还没有这么痛苦。

1 楼 Durian 2008-12-21  

做it的,谁没痛苦过.
天天痛苦.头发都少了