Cod*_*der 5 javascript browser ajax asynchronous
我支持基于HTML/JS浏览器的应用程序,当用户在应用程序中浏览时,该应用程序异步加载数据(SVG).(该应用程序是电子书阅读器,但用例类似于在线地图应用程序,例如).
理论上,如果用户花费很长时间使用应用程序,则用户可以请求比可用RAM更多的数据,因为可以总共下载的潜在数据量很大(GB,但每个K只有10s)请求,即每个SVG)
我有一些用户在长时间使用后遇到速度下降,浏览器挂起等问题的报告.浏览器或操作系统没有一致性.
这导致了一些相关的问题:
这种应用程序是否有任何"良好实践",以某种方式在一个会话中从内存中删除较旧或较少使用的数据?如何完成(在JS中)?是否足以从包含SVG的DOM中删除元素,以释放该SVG所使用的内存?这甚至是必要的吗?
当异步请求的数据量超过可用内存时,主浏览器(Chrome,FF,IE8/9/10 ......)究竟发生了什么?这只是硬盘分页的情况吗?
是否有任何测试可以在Javascript中完成,以了解何时达到"太多数据"?例如,我的开发平台有大量的RAM,所以我没有注意到这个问题,但是在测试装备(和一些用户机器)上RAM少得多,问题发现得更早(但不是每次都很容易重复) ,恼人地).
JavaScript 内存问题通常与异步数据关系不大,而更多地与正确的清理有关。
即使 JavaScript 被垃圾收集,您仍然可能会造成内存泄漏。内存分为 DOM 和 JavaScript。如果一侧的任何内容正在引用另一侧,则在完全释放两者之间的所有循环引用之前,它无法被 GC 处理。
一个实际的例子:如果任何事件监听器附加到 DOM 元素,那么 DOM 现在就有了对 JS 回调的引用。如果同一个回调还引用了存储在变量中的同一 DOM 对象,它将阻止相关 DOM 树和 JavaScript 回调中的任何内存/闭包被 GC。在这种情况下,即使 DOM 元素从树中删除并且您没有对 JavaScript 回调的引用,页面也会泄漏!
jQuery 使用 $() 函数的原因之一是包装 DOM 对象引用,避免用户在代码中直接引用 DOM 对象。这并不意味着如果您不留意就不会造成泄漏。由于包装,如果您不总是通过包装器进行 DOM 操作/清理,则可能会造成泄漏。
由于创建泄漏的方式多种多样,最好使用工具来诊断内存泄漏是否对您来说是一个问题。Chrome 开发工具允许您分析应用程序并查看内存的行为/使用情况。它甚至可以告诉您 GC 后哪些引用没有被清理。
如果您发现没有内存泄漏并且您的应用程序内存占用太大,您可以采取一些技术;延迟加载内容、通过克隆模板重用现有 DOM、使用单个事件回调来捕获冒泡事件而不是附加到所有子级等。
| 归档时间: |
|
| 查看次数: |
367 次 |
| 最近记录: |