有没有用EXT做过大型企业级应用的高手？

目前我们的项目前端使用的是EXT2.0结合DWR, 并且采用完全OPOA的结构,即一个模块对应一个独立的JS文件,在用户访问时才动态载入并生成Tab页面. 这种结构在应付项目初期的简单模块时还是游刃有余的, 但是随着项目的发展, 页面设计越来越过于复杂, 有些页面甚至需要用到一百多个Field组件，于是现在各种问题也凸现了出来，尤其是浏览器的内存泄露。我们目前暂时想到了两种解决方案：

一是采用“隐藏”的方式替代“关闭”，即模块页面打开后再关闭时只对其做隐藏，再次打开时只需做页面数据的刷新， 因此不会占用新的内存和页面初始化时间。虽然项目庞大，但是实际使用时使用者拥有的模块权限不会很多，因此是不会出现打开所有模块将内存消耗殆尽的情况的。

二是舍弃OPOA的结构，在Tab页中嵌入IFRAME，将每个模块独立成单个页面。目前发现这种方法在处理内存泄露问题上的效果是比较好的，但是由于每个页面都必须重新引入EXT库的原因，单个模块占用的内存较之前增加了十多兆。而我们已经使用到了EXT的绝大部分功能，因此再对库文件做裁减意义已经不大。

不知道各位高手有没有更好的建议，烦请不吝赐教。

评论

23 楼 dboylx 2008-03-17  

bevin_b 写道

dboylx 写道

bevin_b 写道

pheyrol所说的性能提升根本是另外一回事吧

另外EXT的部分组件在销毁时存在DOM节点删除不彻底的bug，以前就注意到了，这个问题在2.0版本中仍然存在，其官方论坛的说法是会在下一个版本中系统解决．

现在最为头疼的还是内存泄露的问题．就以其自身的API文档为例,如果你打开了大量的标签页然后全部关闭,你会发现浏览器的内存根本没有减少,至少在IE6和FF2中是这样的. API文档里的标签页只是简单的文本页面, 即使你打开再多的页面, 也不会耗用多少的内存. 可是在我们这样的系统中, 一个复杂的模块页面在不做任何数据库读取操作的情况下, 单只是页面初始化之后所占用的内存就达到了十多M, 在反复的打开关闭之后, 系统的性能可想而知. 但是这样的问题, 从其官方论坛来看目前还是没有得到足够的重视, 有人说建议更换浏览器, 不要用IE6了. 是的, IE是内存泄露之王, 可是你的客户会明白这些吗?

一个FORM, 三十个字段, 如果处理不好, 很可能一个更新的操作就会带来几M的内存泄露. 如果是个熟练的录入人员, 半小时就有可能开销一个G的客户机内存.

很正常, 大胖不是说过么, EXT是非常优秀的架构. 但优秀的架构也需要有相应的能力与团队去驾驭它.

并不是官方不重视, 如果您足够关心, 可以看到JACK与Animal在去年中经常讨论与解决客户的类似问题. 在2.0时甚至在Composite设计里加入了Destroy内存回收的调用 (1.x Animal建议自己扩展基础组件), 但这也是在一个工作区内JS架构设计所能做的极限. 如果您使用了iFrame(Jack也建议使用它), 那么您的内存回收就要自己想办法了. 官方有很优秀的单例实现, 与CACHE的解决方法归避客户端的内存泄露. www.extjs.com

你所说的这些，即使是一个刚刚接触Ext的人都会明白

即使自认为是高手，也请仔细看明白了问题再发表意见好吗？

言语不恭，向您道歉~~~

22 楼 bevin_b 2008-03-17  

dboylx 写道

bevin_b 写道

pheyrol所说的性能提升根本是另外一回事吧

另外EXT的部分组件在销毁时存在DOM节点删除不彻底的bug，以前就注意到了，这个问题在2.0版本中仍然存在，其官方论坛的说法是会在下一个版本中系统解决．

现在最为头疼的还是内存泄露的问题．就以其自身的API文档为例,如果你打开了大量的标签页然后全部关闭,你会发现浏览器的内存根本没有减少,至少在IE6和FF2中是这样的. API文档里的标签页只是简单的文本页面, 即使你打开再多的页面, 也不会耗用多少的内存. 可是在我们这样的系统中, 一个复杂的模块页面在不做任何数据库读取操作的情况下, 单只是页面初始化之后所占用的内存就达到了十多M, 在反复的打开关闭之后, 系统的性能可想而知. 但是这样的问题, 从其官方论坛来看目前还是没有得到足够的重视, 有人说建议更换浏览器, 不要用IE6了. 是的, IE是内存泄露之王, 可是你的客户会明白这些吗?

一个FORM, 三十个字段, 如果处理不好, 很可能一个更新的操作就会带来几M的内存泄露. 如果是个熟练的录入人员, 半小时就有可能开销一个G的客户机内存.

很正常, 大胖不是说过么, EXT是非常优秀的架构. 但优秀的架构也需要有相应的能力与团队去驾驭它.

并不是官方不重视, 如果您足够关心, 可以看到JACK与Animal在去年中经常讨论与解决客户的类似问题. 在2.0时甚至在Composite设计里加入了Destroy内存回收的调用 (1.x Animal建议自己扩展基础组件), 但这也是在一个工作区内JS架构设计所能做的极限. 如果您使用了iFrame(Jack也建议使用它), 那么您的内存回收就要自己想办法了. 官方有很优秀的单例实现, 与CACHE的解决方法归避客户端的内存泄露. www.extjs.com

你所说的这些，即使是一个刚刚接触Ext的人都会明白

即使自认为是高手，也请仔细看明白了问题再发表意见好吗？

21 楼 1314520ln 2008-03-17  

为什么非要用ext作开发呢?

20 楼 dboylx 2008-03-14  

bevin_b 写道

pheyrol所说的性能提升根本是另外一回事吧

另外EXT的部分组件在销毁时存在DOM节点删除不彻底的bug，以前就注意到了，这个问题在2.0版本中仍然存在，其官方论坛的说法是会在下一个版本中系统解决．

现在最为头疼的还是内存泄露的问题．就以其自身的API文档为例,如果你打开了大量的标签页然后全部关闭,你会发现浏览器的内存根本没有减少,至少在IE6和FF2中是这样的. API文档里的标签页只是简单的文本页面, 即使你打开再多的页面, 也不会耗用多少的内存. 可是在我们这样的系统中, 一个复杂的模块页面在不做任何数据库读取操作的情况下, 单只是页面初始化之后所占用的内存就达到了十多M, 在反复的打开关闭之后, 系统的性能可想而知. 但是这样的问题, 从其官方论坛来看目前还是没有得到足够的重视, 有人说建议更换浏览器, 不要用IE6了. 是的, IE是内存泄露之王, 可是你的客户会明白这些吗?

一个FORM, 三十个字段, 如果处理不好, 很可能一个更新的操作就会带来几M的内存泄露. 如果是个熟练的录入人员, 半小时就有可能开销一个G的客户机内存.

很正常, 大胖不是说过么, EXT是非常优秀的架构. 但优秀的架构也需要有相应的能力与团队去驾驭它.

并不是官方不重视, 如果您足够关心, 可以看到JACK与Animal在去年中经常讨论与解决客户的类似问题. 在2.0时甚至在Composite设计里加入了Destroy内存回收的调用 (1.x Animal建议自己扩展基础组件), 但这也是在一个工作区内JS架构设计所能做的极限. 如果您使用了iFrame(Jack也建议使用它), 那么您的内存回收就要自己想办法了. 官方有很优秀的单例实现, 与CACHE的解决方法归避客户端的内存泄露. www.extjs.com

19 楼 zenny 2008-03-14  

这个帖子里有“高手”二字，不知道是怎么发上去的。记得我当初发贴，MS不能有这个词。——题外话，打扰了，毙了我吧......

18 楼 bevin_b 2008-03-14  

pheyrol所说的性能提升根本是另外一回事吧

另外EXT的部分组件在销毁时存在DOM节点删除不彻底的bug，以前就注意到了，这个问题在2.0版本中仍然存在，其官方论坛的说法是会在下一个版本中系统解决．

现在最为头疼的还是内存泄露的问题．就以其自身的API文档为例,如果你打开了大量的标签页然后全部关闭,你会发现浏览器的内存根本没有减少,至少在IE6和FF2中是这样的. API文档里的标签页只是简单的文本页面, 即使你打开再多的页面, 也不会耗用多少的内存. 可是在我们这样的系统中, 一个复杂的模块页面在不做任何数据库读取操作的情况下, 单只是页面初始化之后所占用的内存就达到了十多M, 在反复的打开关闭之后, 系统的性能可想而知. 但是这样的问题, 从其官方论坛来看目前还是没有得到足够的重视, 有人说建议更换浏览器, 不要用IE6了. 是的, IE是内存泄露之王, 可是你的客户会明白这些吗?

17 楼 pheyrol 2008-03-13  

我也最近做了一个EXT的项目，个人认为： Ext 性能提升还有很大的潜力，只要你愿意花功夫。
比如，你使用Struts2.0的化，在struts.xml定义action时通过execludeProperty把一些不需要的列出来的属性把它过滤掉，这样在存在ManyToMany或oneToMany时就快了很多。
还有就是对一些不需要范围JSON对象（如update某些类的信息。删除某个类）的，在struts.xml定义action时，使用<result type="httpheader"/>可以避免一些内存溢出，因为很多的内存溢出是由于在读取数据发生死循环，而这些读数据操作很多是不需要的，

16 楼 nihongye 2008-03-13  

经过一夜一天的查找，毫无结果。
首先：http://www.softwareverify.com/javascript/memory/index.html
这个工具，能检测firefox的内存使用情况,试用版也挺好用，不过我再它上面花了一个晚上，还是没解决问题。
另外还有一个地址：http://developer.mozilla.org/en/docs/Debugging_memory_leaks
可以深入研究这个问题。
我的测试例子是这样的：
   总的页面由一个BorderLayout布局控制，其Center Region将加载一个Html片断，该Html片断使用BorderLayout建立一个列表的管理界面，点击导航菜单后触发该区域的更新（先移除旧的组件，再加入新的）。
通过重新控制Ext带的垃圾回收，确认了Ext.Element的缓存中的孤子元素会定时的清除;通过firebug，确认每次点击后页面中残留有SplitBar产生的Tag。
firefox2,3,opera都测试过，内存涨，但不会导致应用缓慢，firefox2上平均每次点击增长500k内存，大家遇到相同的问题吗？

15 楼 bevin_b 2008-03-12  

sp42可否告知一下联系方式，我的MSN: [e-mail],　或者QQ:　45425168

14 楼 sp42 2008-03-11  

是的 autoLoad －》HTML片段
配合模块化的设计lazyModule使用。
甚至可以利用ext组件render on Demand进行组件的设计（服务器返回JSON的组件配置项）

13 楼 bevin_b 2008-03-11  

autoLoad? 你是说结合使用HTML片段吗？
我们现在有部分模块的Form区是通过载入HTML片段生成的，在用户打开Tab Form的相应标签页时才将其中的组件转化成Ext组件．效果会比直接生成Ext组件好很多，只是还是不能完全解决问题

12 楼 sp42 2008-03-11  

bevin_b 写道

那请教一下sp42，你有没有更好的建议呢?

客气！
我当前的方案是lazyModule＋autoLoad
至于OO in JS，我整理的资料不是很多，－－EXT OO在1.x时大概是照搬YUI的，到了2.0某些组件取消了构造器而是重写initComponent()
edit:修正单词错误

11 楼 gdipkf1986 2008-03-11  

使用IFrame的话，文件也不是缓存的。

A页面加载的ext-all和ext.css文件，只提供A布面使用，如果IFrame重新加载到B页面，那B页面还是会重新加载一次ext-all与ext-css,不可能使用A页面的缓存。只有当再次IFrame加载A页面的时候，A页面才有可能使用己经存在的缓存。如果有十个页面，使用iFrame方法加载，那ext-all与ext-css至少要各被加载十次。

10 楼 lonelyblue 2008-03-11  

我这边有一个页面有一个TabPanel，共包括6个Tab页，39个Field分布在tab页中，其中包括两个表格；并且有4个弹出window。

简单表单的销毁比较容易，直接调用formPanel的销毁方法或者viewPort的，由于EXT2的组件树架构，会逐层的自动调用destroy方法。

复杂界面有些Field由于没有加入这棵树（而直接renderTo到div或者别的dom节点里），所以创建了资源的同时，要记得在formPanel组件的beforedestroy方法中进行销毁就可以有效的缓解泄漏的问题。

9 楼 bevin_b 2008-03-11  

看过你们的demo了，想知道在你们实际的产品里边，会出现有一百多个Field的Tab Form吗？如果有的话，你们是怎么解决的啊

8 楼 nihongye 2008-03-11  

bevin_b 写道

楼上的，你的产品演示在哪儿呢，很想看一下

我个人是从EXT2.0Alpha版发布才接触这个框架的，所以不大了解EXT1.1，destroy动作是组件销毁时自动完成的，是不需要手工调用的啊，但是模块关闭时内存并没有释放．我们的每个模块都是一个Panel对象

另外文件压缩是项目后期的事情，目前在局域网内开发暂时不考虑网络的影响

演示在上面给出的地址里啊。我现在正用selenium，用脚本重复的动作，看几百个操作下来，ext的情况如何;你也可以试试。可惜ext1.1不是组件树,羡慕ext2。

7 楼 bevin_b 2008-03-11  

楼上的，你的产品演示在哪儿呢，很想看一下

我个人是从EXT2.0Alpha版发布才接触这个框架的，所以不大了解EXT1.1，destroy动作是组件销毁时自动完成的，是不需要手工调用的啊，但是模块关闭时内存并没有释放．我们的每个模块都是一个Panel对象

另外文件压缩是项目后期的事情，目前在局域网内开发暂时不考虑网络的影响

6 楼 nihongye 2008-03-11  

我们的应用也是opoa的，用的是ext1.1。
在linux、1g内存、firefox2.0.11、的机器上跑，只见内存彪升,但是firefox的内存泄漏检测插件没有报告泄漏现象;在windowsxp 256m内存(有100m的可用内存)，firefox2.0.12上保持在50m的内存占用。
这现象或者是firefox本身的内存管理的特性，并不是泄漏。另外注意destroy ComboBox，因为combo的layer是建立在body下，感觉destroy掉好些吧。
另外，将应用所有模块的js使用jsa打包并压缩成一个文件，再用gzip(apache deflate)压缩，385k经过两次压缩后，30k，相当好。
应用的地址是http://www.abestek.com，进入演示...

5 楼 bevin_b 2008-03-11  

那请教一下sp42，你有没有更好的建议呢?

4 楼 i_love_sc 2008-03-11  

这个问题该如何解决呢？