分块处理
上一篇曾提到，我们可对资源加密存储，然后在 SW 中进行解密。
理论上这当然可行，但事实上会出现一些问题：我们必须等整个资源下载完成后，才能开始解密操作。这对于用户体验，会产生很大的影响。
假如有个 1MB 的图片，通过 100 KB/s 的速度加载，那么要 10 秒后才能解密再展示；然而正常情况下，图片是边加载边显示的，并不会让用户等很久，然后一次性展示所有的。
为了解决这个问题，一个期待已久的新标准终于到来，那就是 Stream API。
有了流的支持，数据就可以渐进处理，而不必等待完整的。例如，我们使用 fetch 分块读取内容：
// fetch 分块读取演示
async function load(url) {
let res = await fetch(url);
console.log('response:', res);
let reader = res.body.getReader();
for (;;) {
let r = await reader.read();
if (r.done) {
break;
}
console.log('chunk:', r.value);
}
console.log('end');
}
load('https://raw.githubusercontent.com/EtherDream/_/master/pic.jpg');
同时，SW 也支持数据分块输出给下游：
// SW 分块输出
let stream = new ReadableStream({
start(controller) {
...
input.ondata = function(chunk) {
controller.enqueue(chunk);
};
input.onend = function() {
controller.close();
};
...
}
});
let res = new Response(stream, ...);
...
两者结合，我们就可以实现边下载、边解密、边输出的效果。于是对于加密的图片、视频等资源，也能循序渐进地展示了！
下载加速
除了解密、解压缩等场合，数据流还可用于传输优化。例如，用户下载大文件的场合。
由于免费空间单个节点的带宽是有限的，因此下载速度不会太快。这时就可以通过 SW 做加速了 —— 我们同时从多个节点获取相应的文件片段，然后依次输出到响应流里：
在用户看来，这只是浏览器默认的单线程下载，但事实上内部已通过 SW 加速，和传统的多线程下载软件并无本质区别！
当然，就算免费空间不支持 Range 请求也没关系，我们可事先把大文件分成多个小文件上传，然后分别加载即可。
动态加速
上一篇提到，通过 SW 可对故障节点「实时无缝」的切换。现在有了数据流，我们可将其发挥到极致，甚至能在传输的过程中进行调整。
例如，SW 默认选择节点 1 加载资源，但发现速度没有预期的那么快，于是可增加节点 2 参与加速：
这样，我们就能根据用户的实际网络情况，在端上动态调整，从而实现更智能的负载均衡！
插入脚本
有时候，我们希望给站点下所有页面的头部插入一个 JS 脚本。
这个功能，如果没有数据流支持的话，那么 SW 必须得下载整个 HTML 才能修改；而现在，我们只需改造最先返回的几个 chunk 即可！
不过需要注意的是，chunk 是二进制层面截断的，因此可能把多字节字符截成两半，导致出现乱码。
为此，我们需要用「流模式」解码字符串。例如：
// stream decode example
let dec = new TextDecoder();
let chunk1 = new Uint8Array([228, 189, 160, 229, 165]);
let chunk2 = new Uint8Array([189]);
dec.decode(chunk1, {stream: true}); // "你"
dec.decode(chunk2, {stream: true}); // "好"
如果 chunk 末尾的字符不完整，那么不足的部分则被暂存在内部，下次解码时会自动加在开头。
这样，我们就能用字符串方法，更方便地操作二进制数据了：
let dec = new TextDecoder();
let enc = new TextEncoder();
input.ondata = function(chunk) {
// 二进制 -> 字符串
let str = dec.decode(chunk, {stream: true});
// 插入脚本元素
str = str.replace(/<head/i, '<script ...><head');
// 字符串 -> 二进制
chunk = enc.encode(str);
...
};
当然，这里的逻辑还有点瑕疵 —— 假如 <head 这个字符串正好跨越两个 chunk，那就无法匹配到了。
由于 JS 不支持流模式的正则匹配，因此可以用个土办法：如果 str 匹配不到，则截掉末尾 5 个字符，然后将尾巴暂存起来，拼到下一次的头部。。。这样虽然没有流那么严格，但实现简单，并且也很高效。
此外，由于我们只需替换一次，因此之后可跳过这步，无需解码、匹配、编码了。
小结
在数据流的配合下，SW 可实现非常丰富的玩法。不过目前只有 Chrome 浏览器支持 Stream API，因此兼容性也是个较大的问题。相信随着新标准的普及，今后使用前端加速的网站，一定会越来越多。
然而对于我们的「免费空间」来说，除了兼容性问题之外，还有 SW 的各种使用限制也是一个挑战。因此如何绕过 SW 的使用限制，也是需要我们思考的。
下一篇