对于Android常用的压缩格式ZIP，你了解多少？
Android的有两种解压ZIP的方法，你知道吗？
ZipFile和ZipInputStream的解压效率，你对比过吗？
带着以上问题，现在就开始ZIP的解压之旅。
1. Zip文件结构
ZIP文件结构如下图所示， File Entry表示一个文件实体,一个压缩文件中有多个文件实体。
文件实体由一个头部和文件数据组，Central Directory由多个File header组成，每个File header都保存一个文件实体的偏移，文件最后由End of central directory结束。
1.1 Local File Header
|
偏移 |
字节数 |
描述 |
|
0 |
4 |
固定值0x04034b50 |
|
4 |
2 |
解压缩版本 |
|
6 |
2 |
标志 |
|
8 |
2 |
压缩方式 |
|
10 |
2 |
文件最后修改时间 |
|
12 |
2 |
文件最后修改日期 |
|
14 |
4 |
CRC-32校验 |
|
18 |
4 |
压缩后大小 |
|
22 |
4 |
压缩前大小 |
|
26 |
2 |
文件名称长度(n) |
|
28 |
2 |
扩展字段长度(m) |
|
30 |
n |
文件名称 |
|
30+n |
m |
扩展字段 |
1.2. Data descriptor
当头部标志第3位(掩码0×08)置位时，表示CRC-32校验位和压缩后大小在File Entry结构的尾部增加一个Data descriptor来记录。
|
偏移 |
字节数 |
描述 |
|
0 |
0/4 |
固定值0x08074b50 |
|
0/4 |
4 |
CRC-32校验 |
|
4/8 |
4 |
压缩后大小 |
|
8/12 |
4 |
压缩前大小 |
1.3. Central Directory
Central Directory File Header
|
偏移 |
字节数 |
描述 |
|
0 |
4 |
固定值0x02014b50 |
|
4 |
2 |
压缩版本 |
|
6 |
2 |
解压缩版本 |
|
8 |
2 |
标志 |
|
10 |
2 |
压缩方式 |
|
12 |
2 |
文件最后修改时间 |
|
14 |
2 |
文件最后修改日期 |
|
16 |
4 |
CRC-32校验 |
|
20 |
4 |
压缩后大小 |
|
24 |
4 |
压缩前大小 |
|
28 |
2 |
文件名称长度(n) |
|
30 |
2 |
扩展字段长度(m) |
|
32 |
2 |
文件注释长度(k) |
|
34 |
2 |
文件开始的分卷号 |
|
36 |
2 |
文件内部属性 |
|
38 |
4 |
文件外部属性 |
|
42 |
4 |
对应文件实体在文件中的偏移 |
|
46 |
n |
文件名称 |
|
46+n |
m |
扩展字段 |
|
46+n+m |
k |
文件注释 |
End of Central Directory record
所有的File Header结束后是该数据结构
|
偏移 |
字节数 |
描述 |
|
0 |
4 |
固定值0x06054b50 |
|
4 |
2 |
当前分卷号 |
|
6 |
2 |
Central Directory的开始分卷号 |
|
8 |
2 |
当前分卷Central Directory的记录数量 |
|
10 |
2 |
Central Directory的总记录数量 |
|
12 |
4 |
Central Directory的大小 (bytes) |
|
16 |
4 |
Central Directory的开始位置偏移 |
|
20 |
2 |
Zip文件注释长度(n) |
|
22 |
n |
Zip文件注释 |
Q1：Central Directory的作用
通过Central Directory可以快速获取ZIP包含的文件列表，而不用逐个扫描文件，虽然Central Directory的内容和文件原来的头文件有冗余，但是当zip文件被追加到其他文件时，就只能通过Central Directory获取ZIP信息，而不能通过扫描文件的方式，因为central directory可能声明一些文件被删除或者已经更新。Central Directory中Entry的顺序可以和文件的实际顺序不一样。
Q2：ZIP如何更新文件
举例说明：一个ZIP包含A、B和C三个文件，现在准备删除文件B，并且对C进行了更新，可以将新的文件C 添加到原来ZIP的后面，同时添加一个新的Central Directory，仅仅包含文件A和新文件C，这样就实现了删除文件B和更新文件C。
在ZIP设计之初，通过软盘来移动文件很常见，但是读写磁盘是很消耗性能的，对于一个很大的ZIP文件，只想更新几个小文件，如果采用这种方式效率非常低。
2，ZIP文件解压
Android提供两种解压ZIP文件的方法：ZipFile和ZipInputStream
2.1 ZipInputStream
ZipInputStream通过流式来顺序访问ZIP，当读到某个文件结尾时（Entry）返回-1，通过getNextEntry来判断是否要继续向下读，ZipInputStream 的read方法的流程图如下。
Q3：为什么要判断是否是压缩文件？
因为文件在添加到ZIP时，可以通过设置Entry.setMethod(ZipEntry.STORED)以非压缩的形式添加到文件，所以在解压时，对于这种情况，可以直接读文件返回，不需要要解压。
这里要重点介绍一下InflaterInputStream.read()方法，其流程图如下。
从流程图可以看出，java层将待解压的数据通过我们定义的Buffer传入native层。每次传入的数据大小是固定值为512字节，在InflaterInputStream.java中定义如下：
static final int BUF_SIZE = 512;
对于压缩文件来说，最终会调用zlib中的inflate.c来解压文件，inflate.c通过状态机来对文件进行解压，将解压后的数据再通过Buffer返回。对inflate解压算法感兴趣的同学可以看源码，传送门http://androidxref.com/4.4.4_r1/xref/external/zlib/src/inflate.c，返回count字节并不等于buffer的大小，取决于inflate解压返回的数据。
2.2 ZipFile
ZipFile通过RandomAccessFile随机访问zip文件，通过Central Directory得到zip中所有的Entry， Entry中包含文件的开始位置和size，前期读Central Directory可能会耗费一些时间，但是后面就可以利用RandomAccessFile的特性，每次读入更多的数据来提高解压效率。
ZipFile中定义了两个类，分别是RAFStream和ZipInflaterInputStream，这两个类分别继承自RandomAccessFile和InflateInputStream，通过getInputStream()返回，ZipFile的解压流程和ZipInputStream类似。
ZipFile和ZipInputStream真正不同的地方在InflaterInputStream.fill()，fill源码如下：
188 protected void fill() throws IOException {
189 checkClosed();
190 if (nativeEndBufSize > 0) {
191 ZipFile.RAFStreamis = (ZipFile.RAFStream) in;
192 len = is.fill(inf, nativeEndBufSize);
193 } else {
194 if ((len = in.read(buf)) > 0) {
195 inf.setInput(buf, 0, len);
196 }
197 }
198 }
下面同样给出InflaterInputStream.read()的流程图，大家就能明白二者的区别之处。
从流程图可以看出，ZipFile的读文件是在native层进行的，每次读文件的大小是由java层传入的，定义如下：
Math.max(1024, (int) Math.min(entry.getSize(), 65535L));
即ZipFile每次处理的数据大小在1KB和64KB之间，如果文件大小介于二者之间，则可以一次将文件处理完。而对于ZipInputStream来说，每次能处理的数据只能是512个字节，所以ZipFile的解压效率更高。
3，ZipFile vs ZipInputStream效率对比
解压文件可以分三步：
1，从磁盘读出zip文件
2，调用inflate解压出数据
3，存储解压后的数据
因此两者的效率对比可以细化到这三个步骤来对比。
3.1 读磁盘
ZipFile在native层读文件，并且每次读的数据在1KB~64KB之间，ZipInputStream只有采用更大的Buffer才可能达到ZipFile的性能。
3.2 infalte解压效率
从上文可知，inflate每次解压的数据是不定的，一方面和inflate的解压算法有关，另一方面取决native层infalte.c每次处理的数据，以上分析可以，ZipInputStream每次只传递512字节数据到native层，而ZipFile每次传递的数据可以在1KB~64KB，所以ZipFile的解压效率更高。从java_util_zip_Inflater.cpp源码看，这是Android做的特别优化。
demo验证（关键代码）：
ZipInputStream：
FileInputStream fis =new FileInputStream(files);
ZipInputStream zis =new ZipInputStream(new BufferedInputStream(fis));
byte[] buffer = newbyte[8192];
while((ze=zis.getNextEntry())!=null){
File dstFile = newFile(dir+"/"+ze.getName());
FileOutputStreamfos = new FileOutputStream(dstFile);
while((count = zis.read(buffer)) !=-1){
System.out.println(count);
fos.write(buffer,0,count);
} }
ZipFile关键代码：
ZipFile zipFile = newZipFile(files);
InputStreamis = null;
Enumeratione = zipFile.entries();
while(e.hasMoreElements()) {
entry= (ZipEntry) e.nextElement();
is= zipFile.getInputStream(entry);
dstFile = newFile(dir+"/"+entry.getName());
fos= new FileOutputStream(dstFile);
byte[]buffer = new byte[8192];
while((count = is.read(buffer, 0, buffer.length)) != -1){
fos.write(buffer,0,count);
} }
我们用两个不同压缩率的文件对demo进行测试，文件说明如下。
|
组成 |
压缩前size（MB） |
压缩后size（MB） |
压缩率 |
|
|
低压缩率ZIP |
4个文本文件 |
17 |
1.25 |
7% |
|
高压缩率ZIP |
100个jpg图片 |
9.76 |
9.69 |
99% |
测试数据：
|
文件类型 |
低压缩率文件 |
高压缩率文件 |
||
|
对比指标 |
read调用次数 |
耗时（ms） |
read调用次数 |
耗时（ms） |
|
ZipInputStream |
3588 |
1082.8 |
19900 |
3548.8 |
|
ZipFile |
2181 |
848.4 |
1400 |
971.2 |
|
ZipFile减少百分比 |
39% |
22% |
93% |
73% |
结论：1，ZipFile的read调用的次数减少39%~93%，可以看出ZipFile的解压效率更高
2，ZipFile解压文件耗时，相比ZipInputStream有22%到73%的减少
3.3 存储解压后的数据
从上文可以知道，inflate解压后返回的数据可能会小于buffer的长度，如果每次在read返回后就直接写文件，此时buffer可能并没有充满，造成buffer的利用效率不高，此处可以考虑将解压出的数据输出到BufferedOutputStream，等buffer满后再写入文件，这样做的弊端是，因为要凑满buffer，会导致read的调用次数增加，下面就对ZipFile和Zipinputstream做一个对比。
demo（关键代码）：
ZipInputStream：
FileInputStream fis = new FileInputStream(files);
ZipInputStream zis = new ZipInputStream(newBufferedInputStream(fis));
byte[] buffer = new byte[8192];
while((ze=zis.getNextEntry())!=null){
File dstFile = newFile(dir+"/"+ze.getName());
FileOutputStream fos =new FileOutputStream(dstFile);
BufferedOutputStream fos = new BufferedOutputStream(dstFile);
while((count = zis.read(buffer))!= -1){
fos.write(buffer,0,count);
} }
ZipFile:
ZipFile zipFile = new ZipFile(files);
InputStream is = null;
Enumeration e = zipFile.entries();
while (e.hasMoreElements()) {
entry = (ZipEntry)e.nextElement();
is = new BufferedInputStream(zipFile.getInputStream(entry));
dstFile = newFile(dir+"/"+entry.getName());
fos = newFileOutputStream(dstFile);
byte[] buffer = newbyte[8192];
while( (count =is.read(buffer, 0, buffer.length)) != -1){
fos.write(buffer,0,count);
} }
同样对上面的两个压缩文件进行解压，测试数据如下：
|
低压缩率（ms） |
高压缩率(ms) |
|
|
ZipInputStream |
930.2 |
1347.2 |
|
ZipFile |
794.5 |
1056.8 |
|
ZipFile耗时减少 |
15% |
22% |
结论：1，ZipFile较ZipInputStream相比，耗时仍有15%-22%的减少
2，与不使用Buffer相比，ZipInputStream的耗时减少14%-62%，ZipFile解压低压缩率文件耗时有6%的减少，但是对于高压缩率，耗时将有9%的增加（虽然减少了写磁盘的次数，但是为了凑足buffer，增加了read的调用次数，导致整体耗时增加）
Q4：那么问题来了，既然ZipFile效率这么好，那ZipInputStream还有存在的价值吗？
千万别被数据迷惑了双眼，上面的测试仅仅是覆盖了一种场景，即：文件已经在磁盘中存在，且需全部解压出ZIP中的文件，如果你的场景符合以上两点，使用ZipFile无疑是正确无比。同时，也可以利用ZipFile的随机访问能力，实现解压ZIP中间的某几个文件。
但是在以下场景，ZipFile则会略显无力，这是ZipInputStream价值就体现出来了：
1，当文件不在磁盘上，比如从网络接收的数据，想边接收边解压，因ZipInputStream是顺序按流的方式读取文件，这种场景实现起来毫无压力。
2，如果顺序解压ZIP前面的一小部分文件， ZipFile也不是最佳选择，因为ZipFile读CentralDirectory会带来额外的耗时。
3，如果ZIP中CentralDirectory遭到损坏，只能通过ZipInputStream来按顺序解压。
4，结论
1，如果ZIP文件已保存在磁盘，且解压ZIP中的所有文件，建议用ZipFile，效率较ZipInputStream有15%~27%的提升。
2，仅解压ZIP中间的某些文件，建议用ZipFile
3，如果ZIP没有在磁盘上或者顺序解压一小部分文件，又或ZIP文件目录遭到损坏，建议用ZipInputStream
从以上分析和验证可以看出，同一种解压方法使用的方式不同，效率也会相差甚远，最后再回顾一下ZipInputStream和ZipFile最高效的用法（红色为关键部分）。
ZipInputStream：
ZipInputStream zis = new ZipInputStream(newBufferedInputStream(fis));
FileOutputStream fos = new FileOutputStream(dstFile);
BufferedOutputStream bos = new BufferedOutputStream(fos);
byte[] buffer = new byte[8192];
while((ze=zis.getNextEntry())!=null){
while((count = zis.read(buffer))!= -1){
fos.write(buffer,0,count);
} }
ZipFile：
Enumeration e = ZipFile.entries();
while (e.hasMoreElements()) {
entry = (ZipEntry)e.nextElement();
if 低压缩率文件，如文本
is = new BufferedInputStream(zipFile.getInputStream(entry));
else if高压缩率文件，如图片
is =zipFile.getInputStream(entry);
byte[]buffer = new byte[8192];
while( (count =is.read(buffer, 0, buffer.length)) != -1){
fos.write(buffer,0,count);｝ ｝