这就是为什么使用 Blob 设置 <img> 内容，而不使用 FileReader 或 URL.createObjectURL答案

【问题标题】：There is why to use Blob to set <img> content, without using FileReader or URL.createObjectURL这就是为什么使用 Blob 设置 <img> 内容，而不使用 FileReader 或 URL.createObjectURL
【发布时间】：2019-07-09 08:49:22
【问题描述】：

我知道我可以使用FileReader 或URL.createObjectURL 将Blob 解析成一个字符串并用它设置image.src。

但我想知道是否可以直接使用Blob? 设置图像内容。

【问题讨论】：

有什么问题？为什么你需要这样做？我的意思是，直接把 blob 写成src。
'URL.createObjectUrl' 在 IE 中不支持，您必须稍后清除该 objectUrl 以避免内存泄漏。而“FileReader”是一个异步函数，需要一些时间并且会对性能产生一些影响（如果你想每秒显示很多帧）。所以如果我可以将它分配给“图像”对象，我会徘徊

标签： javascript html image blob

【解决方案1】：

使用您使用 URL.createObejctURL(blob); 创建的 blobURL。

您在 cmets 中表示您担心浏览器支持和内存使用（您甚至谈到内存泄漏......）。

浏览器支持

只有少数版本的 Chrome 支持 FileReader 对象，但不支持 URL.createObjectURL（IIRC 大约是 v14）。 Internet Explorer 在 IE10 中增加了对 Blob 对象和 FileReader 的支持。

内存使用

blobURL 只是指向已经在内存中或仅在磁盘上的数据的指针。指针在内存中没有分量。
另一方面，dataURL 是二进制数据的字符串表示形式。它的权重比它所代表的数据高 34% 左右（因为二进制需要映射到更安全的字符）。

现在，要绘制位于 URI 另一端的图像，

对于 blobURI，浏览器会直接解析它并从中生成位图 => 内存使用量约为图像大小的 2.5 倍（就像从服务器下载的一样）。
对于 dataURI，浏览器首先会解析字符串（但无法摆脱它）以获取二进制格式（1.34x + 1x），然后它会解析它并从中生成位图（+ 2.5 倍 => 4.84 倍）。

不仅如此，如果你要在多个地方分配这个 dataURI，那么每次你简单地复制字符串时，数据就会增加 1.34 倍，并且考虑到缓存 dataURI 的难度，你最终会使用大量内存来表示相同的二进制数据...

内存泄漏？
不，没有内存泄漏。很简单，当 blob 被 blobURL 引用时，只要 blobURL 没有被撤销，GarbageCollector 就不能收集这个 Blob。但鉴于 blobURL 的生命周期与创建它的文档相关联，它无论如何都会在下次刷新时消失。
此外，如果您正在处理来自用户磁盘的数据，那么 blobURL 实际上只是一个指针，并且没有数据存储在内存中。

FileReader 的 readAsDataURL 方法确实只有少数用例，除非您确定必须使用它，否则只需使用 blobURL。

【讨论】：

【解决方案2】：

您不能直接使用Blob 设置image.src。 image.src 需要您提供一个基于 http 链接、base64 数据或虚拟 blob url 地址的 url。 Blob 是一个二进制对象，不属于上述任何一种选项。正如你所说的Blob 需要URL.createObjectURL 将其转换为image.src 可以识别的虚拟blob url 地址。

【讨论】：