【问题标题】:html5 file system api - chrome hangs and crashes in multiple read and writeshtml5文件系统api - chrome在多次读写中挂起和崩溃
【发布时间】:2012-03-02 09:30:53
【问题描述】:

我有一个后台线程(网络工作者)从服务器获取大量图像并将它们同步写入文件系统。 同时,用户需要滚动浏览已经写入文件系统的图像。因此,每次触发滚动事件时,都会从文件系统中异步读取一个文件并显示在画布中。如果用户一次滚动浏览多个图像,则此过程会生成同时读取和写入,从而导致浏览器挂起并最终崩溃。如何在不让浏览器挂起的情况下完成此操作?

【问题讨论】:

    标签: html google-chrome fileapi


    【解决方案1】:

    请注意:这是对正在发生的事情的疯狂猜测,如果不知道您的代码实际做了什么,就永远无法 100% 确定。

    很有可能,您的方法需要大量 JS 堆内存(例如,您从不缓存已经读取的图像,而是重新读取它们丢弃以前的数据。)挂起可能是 V8 中的多个完整 GC 导致的,最终崩溃是 V8 造成的内存不足。

    我建议你使用 Chrome 开发者工具的 (Ctrl+Shift+I) Profiles 面板并拍摄一些堆快照在选项卡崩溃之前。然后你可以比较它们(底部状态栏中的正确SELECT,选择“在快照1和2之间分配的对象”),看看这个假设是否正确。

    【讨论】:

    • 实际上我可以通过查看 chrome 的 cpu 利用率来缩小范围。即使您使用文件系统 API 将单行文本写入文件,cpu 利用率也会在一秒钟内达到 100%,然后恢复正常。现在,在我连续写入 50 个文件的情况下,循环运行期间的 CPU 利用率约为 100%。所以如果我尝试在前台做一些操作,浏览器显然会挂起。我认为 chrome 会以更优化的方式处理写入。
    • 现在一切都清楚了。您能否在new.crbug.com 提交一个错误(您需要报告您的 Chrome 版本和操作系统,我不知道)?
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2013-10-13
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-12-26
    相关资源
    最近更新 更多