从⽬前的数据来看，⽅案⼀消耗的时间已经⽐直接整包解压所消耗的时间⼤了⼀个数量级；⽽经过测试，整包解压 4.22 G ⽂件的实际运⾏时间是6.4 mins。假设解压过程的运⾏效率跟上⾯的测试⽂件⼀致，那么实际做⼀次系统调度和信息解析的时间因为⽂件⼤⼩的原因变成了 109257.168 ms，即为1.8 mins，使⽤⽅案⼀解压所需要消耗的时间需要 (109257.168 +1.456) * 188697 = 20616774572.928 ms，即为 238.6 天。
gzip是什么文件夹上⾯的计算过程写得如此不适合⼈类阅读，所以作者简单总结⼀下：
原本只运⾏⼀次的过程
⼀次性跑⼗⼏万次
你不慢谁慢！
因此，这个⽅案虽然逻辑上可以运⾏，但是实际上在效率⽅⾯存在很⼤的问题。上⾯的测试和数据有⼀⼤半都是为了写这篇⽂章做的，实际上，在看到使⽤⽅案⼀解压单个⽂件需要的时间后，这个⽅案便已经被放弃了。
以上计算仅为估算，将进程并发产⽣的效率和消耗均摊在每个进程中，⽤于在数量级上对程序运⾏时间进⾏评估。实际上解压单个⽂件的消耗应该⽐上⾯计算的结果⾼。⽽且，计算机硬件的配置(包括C
PU内核和线程个数、内存⼤⼩、磁盘类型)对实际运⾏效率都有巨⼤的影响，所以该计算结果不能作为程序的实际运⾏时间。
如果要对该⽅案进⾏优化，需要考虑减少单个⽂件解压时的重复消耗。
改进⽅案⼀：使⽤ tar(with gzip) + openssl + dd
这个⽅案需要修改原先的资源包。
打包⽅案流程
使⽤tar -zcvf命令将⽂件打包压缩，并将结果传给 openssl
openssl使⽤aes256进⾏加密，并使⽤dd写⼊磁盘
解压⽅案流程
与打包⽅案正好相反
使⽤dd读取压缩包，传给openssl进⾏解密
将解密的结果使⽤tar -zxvf进⾏拆包和解压
该⽅案使⽤ tar 将资源进⾏归档，并在归档时调⽤gzip对单个⽂件进⾏压缩; 使⽤ openssl 作为加密层，dd 作为读写层，避免⼤⽂件读写带来的问题。
因为使⽤gzip对单个⽂件进⾏压缩和解压，⼤⼤缩短了解析单个⽂件时的消耗。
不过这个⽅案依旧存在⼀个问题：openssl 加密后的⽂件⽆法使⽤ tar 事先提取有关信息。
改进⽅案⼆：使⽤zip对单个⽂件进⾏压缩和保护，使⽤tar进⾏归档
跟上⾯的⽅案相⽐，这个⽅案将加密和压缩放在了 zip 中，解决了上⾯先打包后加密造成的 tar ⽆法提取⽂件信息的问题。
然⽽，作者这个爱作死的家伙对 7z 不死⼼，还是决定试试⽅案⼆。
⽅案⼆
将进度输出到标准输出
其实，原则上说，要实现将进度输出到标准输出，最快的⽅式应该是从 7z 的帮助⽂档⾥寻相关配置项。但是，⼤概是因为作者的眼神不好，并没有在⽂档⾥到这⼀项配置，于是才有了⽅案⼀的产⽣。
然⽽，在作者想办法将进度条输出到标准输出到时候，不知为何，脑⼦⼀抽，没有重新查看帮助⽂档，⽽是决定去翻看 7z 的源代码。
7z 源码中使⽤⼀个叫做 PercentPrinter 的类管理解压进度的输出，对外暴露的⽅法除了构造函数和析构函数之外，还有两个⽅法，⼀个是 ClosePrint， ⼀个是 Print。其中，ClosePrint 是⽤来控制输出⽅式的，Print 是⽤来⽣成打印内容的。
这说明，7z 不能从 node 上获取进度条，跟单⾏输出⽆关。
然后，作者尝试在 7z 运⾏时的各个时机使⽤传统的 prinrf 和 c++ 标准的std::cout 输出，发现 7z 做环境配置的时候，所有输出都是正常

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。