本文将深入介绍.NET解压/压缩zip文件的技术选型和性能对比。尽管解压缩不是核心技术，但压缩性能和进度处理仍然需要引起关注。我们将验证使用较多的zip开源组件，为大家提供技术选型的参考。
之前在《 .NET WebSocket高并发通信阻塞问题 》一文中提到，团队曾遇到Zip文件解压进度频率过高的问题。在这里，我们将顺带讲解解决方法。
目前了解到的常用技术方案有System.IO.Compression、SharpZipLib以及DotNetZip。接下来我们将分别介绍它们的使用和性能。
解压耗时： 8484ms 。再将解压后的文件夹压缩，耗时： 28672ms 。性能整体上还是不错的，特别是解压速度很优秀。
所以，对于比较简单的业务场景，可以直接使用System.IO.Compression方案。大家可以将这个方案放在公司通用基础技术组件中。
解压耗时： 8484ms 。再将解压后的文件夹压缩，耗时： 28672ms 。性能整体上还是不错的，特别是解压速度很优秀。
所以，对于比较简单的业务场景，可以直接使用System.IO.Compression方案。大家可以将这个方案放在公司通用基础技术组件中。
SharpZipLib支持多种压缩格式（如ZIP、TAR、GZIP、BZIP2等），并提供了高级功能如加密、分卷压缩等。API设计可用性高，满足更多复杂定制化需求。社区里有很多小伙伴在使用，开发历史久远、组件稳定性较高。
引用下Nuget包SharpZipLib后，解压zip文件。
获取压缩包压缩后的文件的大小，这里Size是压缩前大小，还有一个属性CompressedSize压缩后大小。
解压Zip文件。
解压进度能反馈详细的文件写入进度值。另外，这里有个文件夹判断处理，也是支持空文件夹的。
Zip压缩，获取所有的文件夹/子文件夹、所有的文件，添加到ZipFile里保存。
值得一提的是，如有需要指定Zip压缩文件内的文件名以及文件路径，可以在文件时输入对应的压缩后路径定义，注意是指压缩包内的相对路径。
SharpZipLib虽然功能丰富，但接口设计较为复杂、学习曲线较高。
DotNetZip相对SharpZipLib，API设计更友好、容易上手。它停止维护了，但稳定性、性能真的很好。Zip文件解压。
这里获取压缩后文件大小，与上面SharpZipLib的zipEntry.Size对应，取的是zipEntry.UncompressedSize。
非常人性的提供了ExtractProgress事件进度，我们取的是Extracting_EntryBytesWritten类型，可以拿到细节进度。具体进度的处理看上方代码。
因为反馈的是详细字节写入进度，所以间隔很短。1ms都能给你爆几次进度，尤其是大文件。
所以需要限制下回调Action触发，可以加个计时器限制单个文件的进度回调，如100ms内最多触发一次，下面是优化后的代码。
解压进度就正常了很多，限制间隔只会优化单个文件解压过程中的进度，单个文件解压完成时最后还是有进度回调的。
再看看Zip压缩。如果不考虑加密、压缩进度，DotNetZip压缩zip文件只需要几行代码，所以是相当的易学易用、入手快。
还是同一个847M的zip文件，测试下解压缩性能，解压 11907ms ，压缩耗时 16282ms ，用数据说话性能强不强。
用表格把这三个方案的对比列下。
所以如果你需要处理简单的ZIP压缩和解压任务，且不需要高级特性，建议使用System.IO.Compression。
需要考虑解压缩性能，比如公司的大文件OTA功能，需要减少业务的处理时间， 推荐使用DotNetZip 。DotNetZip也能提供高级特性、进度显示等。至于停止维护的状况可以忽略，有BUG大家可以在公司内或者github维护下这个组件代码。
标签：游戏攻略
