最好是纯扩展形式运行，最好用事件驱动而无需常驻后台，最好能在下载大文件时能流式解压以节省时间。
手搓个wasm不就好了。。。关键是浏览器默认不支持本地文件流，以前是要弹窗授权，现在不知道了。
弹窗授权应该还能用，比较麻烦的就是处理大型固实压缩包在多线程下载时的流式解压。
主要想问问有没有成品，没有成品就写一个
qq浏览器自带解压
固实包没戏，后面的文件跟前面共用字典，只能顺着解，多线程下载也白搭。tar.gz 倒是能流式，浏览器自带 DecompressionStream 就够，不用手搓 wasm。
我感觉这个需求有点挑场景。像 tar.gz 这种本来就很适合一边下来一边处理，确实挺顺手的。可放到 Windows 日常下载里，平时碰到的 zip、7z、rar 比较多，实际体验未必有想象中那么好。
尤其大文件，下载的时候后台还一直解压，CPU、磁盘什么的都一起跑，机器忙的时候感觉反而更容易突然卡一下。再加上下载暂停、断点续传、解压失败、磁盘空间之类的问题，感觉事情一下就复杂起来了。
CPU 确实多跑，磁盘反倒省了。下完不用再读一遍整包。
首先，其实大多数是小文件，流式解压和整个下载完再解压体验差不多。
其次，解压的速度比下载的速度快得多。可以把文件分成多个小块（如16MB），由多个线程顺次领取一个小块，下完一个小块就按序推入磁盘、推入解压器。
如下面的伙伴所述，CPU占用会被提前到下载阶段，考虑到wasm的额外开销，可能要翻倍，但时间上会节约很多。对于磁盘，能节省相当于一次压缩文件大小的磁盘读取。
考虑到CPU比较方便调度，卡顿应该是能缓解。
见前一条回复，只要服务器支持多线程下载或者断点续传，对于绝大部分压缩包格式都能支持。
7z需要下头尾部元数据，需要服务器断点续传支持或者多线程下载支持，其余部分流式解压。
zip，bzip，rar原生可流式解压。
关于断点续传等问题，确实要维护两个游标，指示解压到何处和写入到何处。
下载器很简单，以已写入的游标为准继续下载。
解压器的读取函数已被接管，内存有就取内存，内存没有取磁盘，磁盘没有等下载。这样解压器看到的是一个完整的压缩包，只不过读取有点慢。
固实压缩包解压被中断就没办法了，只能从头来过。顶多可以验证完整性然后跳过一些文件，但是数据完整性考虑没什么必要
还有很多时候下载的压缩包并不需要马上解压缩，甚至完全不需要解压缩，这上来自动解压缩一遍，变成浪费电+浪费ssd的PE了
safari好像就是这个设定， 下载的zip直接变成文件夹了
这是一个好考量。可以设定一个时间阈值，如果超时还没解压完就显示一个弹窗，提醒用户正在解压大型压缩包，用户可以手动终止本次解压。
用户来不及反应就解压完成的小压缩包就不需要提醒了
按序喂确实成立，我那句没戏说的是并行解压。
1 个赞