【发布时间】:2016-06-17 06:51:23
【问题描述】:
我正在处理一个小项目,它处理一个非常大的数组(1024 个项目),将数组中的数据输出到文档上的 1024 个单独元素(是的,我尝试了画布,但它们太模糊了对于我正在做的事情)。
我需要的是尽可能优化这个循环的方法。
for(var i = 0; i < 1024; i++){
elems[i].style.height = data[i] + 'px';
elems[i].style.backgroundColor = 'rgb(0,' + data[i] + ',' + (255 - data[i]) + ')';
}
对于数组data 中的每个项目,它总是1024 个项目,循环设置存储在elems 中的页面上的1024 个div 之一的高度,并将其颜色设置为值越大越绿,值越低越蓝。 data 中的值始终介于 0 到 255 之间。循环在每个 animationFrame 运行,我不能让它随着时间的推移分段进行。数据必须实时更新。
我的主要问题是运行循环会输出非常低的 FPS 计数,通常约为 15fps。我的问题是:
我可以通过哪些方式优化上面的循环以尽可能快地运行?每个渲染帧都会实时更新数据。我将高 FPS 作为我的主要目标。这可能吗?
如果有帮助,我正在使用新的 Google Chrome 音频分析器制作音乐可视化工具。
我也可以在将来需要处理或显示非常大的数据集时看到这方面的帮助。每种方法,即使在很大程度上不可读(这就是 /*comments*/ 的用途),都有帮助!
【问题讨论】:
-
1024 一点都不大...
-
1024 项不是很大。画布以什么方式“模糊”?
-
为什么需要
Math.round?它不总是一个整数吗?另外,您能否创建一些我们可以自己测试的示例? -
画布总是模糊的,因为它们使用不同的像素比率 - 基于非常成功的网络搜索,我发现我需要来自浏览器的值以某种方式更改比率 - 我的浏览器没有报告的值准确,因此没有工作。我在制作项目时将 Math.round() 放在那里 - 在我意识到它是整数被减去之前,我对 JS 奇怪的浮点问题感到偏执。我忘了删除它。 1024 件物品对我来说似乎很大,因为我正在做的事情很激烈。 DOM 很慢 - 每个值两次 DOM 交互是每个动画帧 2048 次 DOM 交互。
-
查看这个关于延迟 dom 渲染的 SO。 stackoverflow.com/questions/1392068/… 您的问题可能源于 Chrome 如何在循环的每次迭代中重排 DOM。如果您先隐藏该元素或在父项的克隆上进行更改,然后立即全部更新,您可能会看到一些性能改进。
标签: javascript loops optimization