相关疑难解决方法(0)

我有一个项目,我需要在浏览器中显示djvu模式.

我在Github上找到了这个旧库,据我所知,它将djvu文件转换为bmp,然后将它们放入canvas元素中.

正如我所说,库是旧的(最后提交是5年前),所以我需要做一些修正.主要问题是lib使用过时的BlobBuilder.

我为解决这个问题而采取的步骤:

1. 通过Chrome DevTools解压缩此库
2. 初始错误在第3774行 var c = "undefined" != typeof MozBlobBuilder ? MozBlobBuilder : "undefined" != typeof WebKitBlobBuilder ? WebKitBlobBuilder : console.log("warning: cannot build blobs")
3. 我评论了这一行
4. 接下来,我也注释掉了一行c = new c;以及下面的一些行.

所以,现在它看起来像这样(变量I是数组缓冲区,ololo1和ololo2是某种偏移和限制)

var c = new Blob(new Uint8Array(new Uint8Array(I,ololo1,ololo2)))
              , b = b.createObjectURL(c)
              , c = document.getElementById(kb)
              , f = c.getContext("2d")
              , h = new Image
              , g = a[Ea >> 2]
              , i = a[Fa >> 2]
              , j = c.width …

使用 Fetch API，我能够为大量二进制数据资产（比如超过 500 MB）发出网络请求，然后将其转换Response为 aBlob或ArrayBuffer.

之后，我可以worker.postMessage让标准结构化克隆算法将其复制Blob到 Web Worker 或将其ArrayBuffer转移到工作器上下文（使主线程不再有效）。

起初，似乎将数据作为ArrayBuffera获取会更可取，因为 aBlob不可传输，因此需要复制。但是，blob 是不可变的，因此，浏览器似乎没有将其存储在与页面关联的 JS 堆中，而是存储在专用的 blob 存储空间中，因此，最终被复制到工作线程上下文的内容只是一个参考。

我准备了一个演示来尝试两种方法之间的区别：https : //blobvsab.vercel.app/。我正在使用这两种方法获取价值 656 MB 的二进制数据。

我在本地测试中观察到的一些有趣的事情是，复制 Blob 甚至比传输 更快ArrayBuffer：

Blob 从主线程到工作线程的复制时间：1.828125 毫秒

ArrayBuffer 从主线程到工作线程的传输时间：3.393310546875 毫秒

这是一个强有力的指标，表明处理 Blob 实际上非常便宜。由于它们是不可变的，浏览器似乎足够聪明，可以将它们视为引用，而不是将覆盖的二进制数据链接到这些引用。

以下是我在作为 a 获取时拍摄的堆内存快照Blob：

前两个快照是在Blob使用postMessage. 请注意，这些堆都不包含 656 MB。

后两个快照是在我使用 aFileReader实际访问底层数据之后拍摄的，并且正如预期的那样，堆增长了很多。

现在，这就是直接作为一个 fetch 发生的情况ArrayBuffer：

在这里，由于二进制数据只是通过工作线程传输，主线程的堆很小，但工作堆包含全部 656 …