1
cj1324 2013-03-31 20:10:38 +08:00
关注~ 这个环境下第三方库的选择应该谨慎
|
2
iinterest 2013-03-31 22:55:40 +08:00
OPOA——One Page,One Application
下面的问题好多,好复杂啊,先去洗澡了。。。 |
4
andy12530 2013-04-01 01:07:36 +08:00 via iPhone 1
我来歪个楼。
这种应该叫 富web应用 加载的话require js seajs之类有加载器,构建无刷新富应用采用backbone 轻量级框架。 每个页面要加载什么 需要开发者定义 也就是依赖。 |
5
0x0001 2013-04-01 07:49:10 +08:00 1
这叫Ria应用
其实真的必须都在一个页面么?不要为了炫技而开发… 用户体验才是重点,必要的跳转没发现什么不妥。 我更担心的日你代码的可读性和维护性 |
6
cmonday 2013-04-01 08:04:52 +08:00 via Android 1
都复杂到这个程度了竟然没有引入 requirejs ozjs 或者 seajs 这种依赖管理库么?你的这些问题前人早就遇到过而且解决过了
不可控的第三方库丢进 iframe 是对的,不过你仔细研究一下它的接口的话,我相信大多数时候都是可控的 |
7
est 2013-04-01 08:35:49 +08:00
有些内存泄露是浏览器js引擎的bug。你没法解决的。Google的GWT团队跟IE团队多次搞基成功修复了各种诡异bug。
|
8
anhulife 2013-04-01 10:00:00 +08:00 1
我们公司最近在做类似的应用
我们的解决方案是 每个页面、组件都是一个模块,模块之间有依赖关系 1 JS加载 RequireJS 负责加载JS和处理依赖,首先加载的是libs.js和app.all.js,都是些共用的JS,然后把分业务打包JS,按需加载 2 由于使用了RequireJS加载JS,所以不会出现重复加载的场景 3 每个模块都负责管理资源,比如模块里面有setInterval,那在模块销毁的时候,需要销毁setInterval,事件绑定也是这样的,这样能够有效地释放资源 我们使用的库有: RequireJS jQuery Backbone.js Underscore.js mustache.js Grunt |
9
Frannk 2013-04-01 10:07:23 +08:00
用Backbone常见的内存泄露是视图替换的时候没有删除view(相应的事件绑定),而只是删除了dom
把这个问题克服就够了 |
10
NemoAlex 2013-04-01 10:15:50 +08:00
我想,楼主说的是模块化管理代码和变量的问题吧?不是内存泄漏。
看标题我还以为现在写前端的人都要想着检查内存泄漏了... |
11
heroicYang 2013-04-01 10:28:56 +08:00
@Frannk 现在直接使用remove不仅会删除dom也会移除事件绑定
|
12
heroicYang 2013-04-01 10:29:57 +08:00
@NemoAlex 呃...为什么觉得写前端就不检查内存泄漏呢?
|
13
atom 2013-04-01 12:12:09 +08:00 1
google有内存泄漏检测工具,https://code.google.com/p/leak-finder-for-javascript/
不过我们用一个比较土但是很实在的方法,每隔15分钟自动刷新一下页面,然后,世界就重新来过了。 |
14
Frannk 2013-04-01 13:08:11 +08:00 1
@heroicYang 好像是的 但是没有泄漏意识的话 就不会经常使用 remove unbind off 之类的方法
我觉得js前端泄露造成的问题不大 不会影响性能 但是事件的绑定管理不好(算是一种leak吧)的话 会对程序产生干扰 |
15
breeswish OP @Frannk 主要是考虑都在一个页面上加载的话一旦内容较多,多加载几次以后Chrome内存就很高了= = 再下去不科学……(不过也许还没到浏览器自己的gc周期= =)
|
18
heroicYang 2013-04-02 10:39:47 +08:00
@anhulife 我们也基本上是这样的技术堆栈!
|