11

我正在构建一个 Web 应用程序，它使用 EvaporateJS 使用 Multipart Uploads 将大文件上传到 Amazon S3。我注意到一个问题，每次启动新块时，浏览器都会冻结约 2 秒。我希望用户能够在上传过程中继续使用我的应用程序，而这种冻结会造成糟糕的体验。

我使用 Chrome 的 Timeline 来查看造成这种情况的原因，发现它是 SparkMD5 的散列。所以我将整个上传过程移到了一个 Worker 中，我认为这可以解决这个问题。

这个问题现在在 Edge 和 Firefox 中得到了解决，但 Chrome 仍然存在完全相同的问题。

这是我的时间轴的屏幕截图： 时间线

如您所见，在冻结期间，我的主线程基本上什么都不做，在此期间运行的 JavaScript 时间不到 8 毫秒。所有的工作都发生在我的 Worker 线程中，即使它只运行了大约 600 毫秒左右，而不是我的框架需要的 1386 毫秒。

我真的不确定是什么导致了这个问题，工人有什么我应该注意的问题吗？

这是我的工人的代码：

var window = self; // For Worker-unaware scripts

// Shim to make Evaporate work in a Worker
var document = {
    createElement: function() {
        var href = undefined;

        var elm = {
            set href(url) {
                var obj = new URL(url);
                elm.protocol = obj.protocol;
                elm.hostname = obj.hostname;
                elm.pathname = obj.pathname;
                elm.port = obj.port;
                elm.search = obj.search;
                elm.hash = obj.hash;
                elm.host = obj.host;
                href = url;
            },
            get href() {
                return href;
            },
            protocol: undefined,
            hostname: undefined,
            pathname: undefined,
            port: undefined,
            search: undefined,
            hash: undefined,
            host: undefined
        };

        return elm;
    }
};

importScripts("/lib/sha256/sha256.min.js");
importScripts("/lib/spark-md5/spark-md5.min.js");
importScripts("/lib/url-parse/url-parse.js");
importScripts("/lib/xmldom/xmldom.js");
importScripts("/lib/evaporate/evaporate.js");

DOMParser = self.xmldom.DOMParser;

var defaultConfig = {
    computeContentMd5: true,
    cryptoMd5Method: function (data) { return btoa(SparkMD5.ArrayBuffer.hash(data, true)); },
    cryptoHexEncodedHash256: sha256,
    awsSignatureVersion: "4",
    awsRegion: undefined,
    aws_url: "https://s3-ap-southeast-2.amazonaws.com",
    aws_key: undefined,
    customAuthMethod: function(signParams, signHeaders, stringToSign, timestamp, awsRequest) {
        return new Promise(function(resolve, reject) {
            var signingRequestId = currentSigningRequestId++;

            postMessage(["signingRequest", signingRequestId, signParams.videoId, timestamp, awsRequest.signer.canonicalRequest()]);
            queuedSigningRequests[signingRequestId] = function(signature) {
                queuedSigningRequests[signingRequestId] = undefined;
                if(signature) {
                    resolve(signature);
                } else {
                    reject();
                }
            }
        });
    },
    //logging: false,
    bucket: undefined,
    allowS3ExistenceOptimization: false,
    maxConcurrentParts: 5
}

var currentSigningRequestId = 0;
var queuedSigningRequests = [];

var e = undefined;
var filekey = undefined;
onmessage = function(e) {
    var messageType = e.data[0];
    switch(messageType) {
        case "init":
            var globalConfig = {};
            for(var k in defaultConfig) {
                globalConfig[k] = defaultConfig[k];
            }
            for(var k in e.data[1]) {
                globalConfig[k] = e.data[1][k];
            }

            var uploadConfig = e.data[2];

            Evaporate.create(globalConfig).then(function(evaporate) {
                var e = evaporate;

                filekey = globalConfig.bucket + "/" + uploadConfig.name;

                uploadConfig.progress = function(p, stats) {
                    postMessage(["progress", p, stats]);
                };

                uploadConfig.complete = function(xhr, awsObjectKey, stats) {
                    postMessage(["complete", xhr, awsObjectKey, stats]);
                }

                uploadConfig.info = function(msg) {
                    postMessage(["info", msg]);
                }

                uploadConfig.warn = function(msg) {
                    postMessage(["warn", msg]);
                }

                uploadConfig.error = function(msg) {
                    postMessage(["error", msg]);
                }

                e.add(uploadConfig);
            });
            break;

        case "pause":
            e.pause(filekey);
            break;

        case "resume":
            e.resume(filekey);
            break;

        case "cancel":
            e.cancel(filekey);
            break;

        case "signature":
            var signingRequestId = e.data[1];
            var signature = e.data[2];
            queuedSigningRequests[signingRequestId](signature);
            break;
    }
}

请注意，它依赖调用线程为其提供 AWS 公钥、AWS 存储桶名称和 AWS 区域、AWS 对象密钥和输入文件对象，这些都在“init”消息中提供。当它需要签名的东西时，它会向父线程发送一条“signingRequest”消息，一旦从我的 API 的签名端点获取签名，它就会在“签名”消息中提供签名。

4

1 回答 1

4

我不能给出一个很好的例子或分析你只使用 Worker 代码所做的事情，但我强烈怀疑这个问题要么与读取主线程上的块有关，要么与你正在做的一些意外处理有关在主线程上的块上做。也许发布调用postMessageWorker 的主线程代码？

如果我现在正在调试它，我会尝试将您的FileReader操作转移到 Worker 中。如果您不介意 Worker 在加载块时阻塞，您也可以使用FileReaderSync.

评论后更新

生成预签名 URL 是否需要散列文件内容 + 元数据 + 密钥？散列文件内容将占用 O(n) 的块大小，如果散列是从 读取的第一个操作，Blob则文件内容的加载可能会延迟到散列开始。除非您被迫将签名保留在主线程中（您不信任具有密钥材料的工作人员？），否则将其引入工作人员将是另一件好事。

如果将签名移到 Worker 中太多，您可以让 Worker 做一些事情来强制Blob读取和/或将文件内容的ArrayBuffer（或Uint8Array您拥有的）传递回主线程进行签名；这将确保读取块不会发生在主线程上。

于 2017-01-20T16:10:29.417 回答