FileReader与window.URL.createObjectURL

Question

FileReader与window.URL.createObjectURL

我正在建立一个移动网站,我想使用Camera API拍照.图像应显示在网站上并上传到服务器.根据MDN上Camera API的介绍,可以使用FileReader或访问网站上的图像并显示window.URL.createObjectURL.我使用iPad(Safari和Chrome)和Android平板电脑(Chrome和Firefox)成功测试了这些可能的解决方案.

FileReader和之间有什么区别window.URL.createObjectURL？我认为window.URL.createObjectURL是更新但不是标准.性能有差异吗？

Answer 1

Ale*_*lin 57

有区别.

1次

createObjectURL 同步执行(立即)
FileReader.readAsDataURL 是异步执行的(一段时间后)

2)内存使用情况

createObjectURL 返回带有哈希的url,并将对象存储在内存中,直到文档触发卸载事件(例如文档关闭)或执行 revokeObjectURL
FileReader.readAsDataURL返回base64包含许多字符,并使用比blob url更多的内存,但在不使用它时从内存中删除(通过垃圾收集器)

3)支持

createObjectURL 来自IE 10和所有现代浏览器
FileReader.readAsDataURL 来自IE 10和所有现代浏览器

从我这里来说,最好使用blob url(via createObjectURL),它更高效,更快,但如果你使用很多对象网址,你需要释放这些网址revokeObjectURL(释放内存). 例如,您可以在Image onload处理程序中调用URL.revokeObjectURL,而Image对象将保留图像数据,而不会丢失它,Nahuel Greco(c).

注意,如图[链接](https://developer.mozilla.org/en-US/docs/Using_files_from_web_applications#Example_Using_object_URLs_to_display_images),可以调用`影像`onload`处理程序和图像对象将内部URL.revokeObjectURL`保留图像数据,而不会丢失它.然后您可以在不特别注意数据的情况下操纵Image对象,它将由通常的GC处理.另外考虑`URL.createObjectURL`是同步的,但它似乎几乎是瞬间完成的. (3认同)
我在js中调整许多图像的大小方面具有经验，因此我习惯于严格进行内存管理。 (2认同)
总是一个好习惯，是的。我只是想指出您没有在其他很棒的答案中写下的信息。也许只是一处修正。当您说 *createObjectURL 及时执行* 时，您的意思可能是 *createObjectURL 同步执行*。它也应该这样表述，因为 * 执行时间 * 是模棱两可的。因此*与回调一起工作*是*异步*执行的日常场景。 (2认同)

归档时间：	10 年，4 月前
查看次数：	10433 次
最近记录：	8 年，6 月前