安卓软件后缀名是什么（安卓软件后缀名是多少）

大家好，我是讯享网，很高兴认识大家。

讯享网

/   今日科技快讯   /

近日，香港联交所网站信息显示，菜鸟已正式向港交所提交上市申请，成为阿里巴巴“1+6+N”之后首个正式进入IPO进程的业务集团。花旗、中信证券、摩根大通为联席保荐人。至此，菜鸟有望成为阿里集团旗下六大业务集团中首家独立上市的公司。

/   作者简介   /

明天就是中秋+国庆双假同至啦，祝大家双节快乐！我们节后再见。

本篇文章转自d袋鼠b的博客，文章深入分析了APK格式，相信会对大家有所帮助！

原文地址：

https://juejin.cn/post/

/   前言   /

最近在升级项目的 Gradle 及 AGP 版本，在进行APK编辑再压缩时遇到了前后压缩比不一致的问题，所以抽空又一总结了下 APK (ZIP) 文件格式。

无论是使用 7z 进行包体积优化，或是快速构建多渠道包，又或是V2、V3签名等都是基于 APK (ZIP) 文件格式进行的，因此对 APK (ZIP) 格式的了解也颇为必要。

/   ZIP文件格式   /

未进行（V2、V3）签名的 APK 就是一个标准的 ZIP 文件，所以本文会先介绍 ZIP 文件格式，后续再介绍签名后的 APK 与标准 ZIP 文件有何差异。

首先看看 ZIP 文件格式预览：

 
  
    
   
   
     
   &nbsp;&nbsp;&nbsp;&nbsp;[local&nbsp;file&nbsp;header&nbsp;1]
&nbsp;&nbsp;&nbsp;&nbsp;[file&nbsp;data&nbsp;1]
&nbsp;&nbsp;&nbsp;&nbsp;[data&nbsp;descriptor&nbsp;1]
&nbsp;&nbsp;&nbsp;&nbsp;.&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;.
&nbsp;&nbsp;&nbsp;&nbsp;.
&nbsp;&nbsp;&nbsp;&nbsp;[local&nbsp;file&nbsp;header&nbsp;n]
&nbsp;&nbsp;&nbsp;&nbsp;[file&nbsp;data&nbsp;n]
&nbsp;&nbsp;&nbsp;&nbsp;[data&nbsp;descriptor&nbsp;n]
&nbsp;&nbsp;&nbsp;&nbsp;[central&nbsp;directory]
&nbsp;&nbsp;&nbsp;&nbsp;[end&nbsp;of&nbsp;central&nbsp;directory&nbsp;record]

讯享网

对结构描述并划分一下，看起来清晰很多：

ZIP 文件由两大区块组成：数据区、中心目录区

下面分别介绍一下两大区块：

数据区

先看数据区，数据区可以理解为一个数组，数组的每一项由 [local file header][file data][data descriptor] 这三项组成。

Local file header

首先看看 local file header （文件头）的结构定义：

这里需要注意的是每个 Entry 的文件头都有自己的 Compression method —— 压缩方式，也就是说 ZIP 文件内的不同 Entry 可以选择不同的压缩方式，并不要求里面的文件都采用同一种压缩方式。

不同的压缩方式对应不同的值，具体如下：

讯享网 
  
    
   
   
     
   compression&nbsp;method:&nbsp;(2&nbsp;bytes)
&nbsp;&nbsp;&nbsp;&nbsp;(see&nbsp;accompanying&nbsp;documentation&nbsp;for&nbsp;algorithm
&nbsp;&nbsp;&nbsp;&nbsp;descriptions)
&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;-&nbsp;The&nbsp;file&nbsp;is&nbsp;stored&nbsp;(no&nbsp;compression)
&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;-&nbsp;The&nbsp;file&nbsp;is&nbsp;Shrunk
&nbsp;&nbsp;&nbsp;&nbsp;2&nbsp;-&nbsp;The&nbsp;file&nbsp;is&nbsp;Reduced&nbsp;with&nbsp;compression&nbsp;factor&nbsp;1
&nbsp;&nbsp;&nbsp;&nbsp;3&nbsp;-&nbsp;The&nbsp;file&nbsp;is&nbsp;Reduced&nbsp;with&nbsp;compression&nbsp;factor&nbsp;2
&nbsp;&nbsp;&nbsp;&nbsp;4&nbsp;-&nbsp;The&nbsp;file&nbsp;is&nbsp;Reduced&nbsp;with&nbsp;compression&nbsp;factor&nbsp;3
&nbsp;&nbsp;&nbsp;&nbsp;5&nbsp;-&nbsp;The&nbsp;file&nbsp;is&nbsp;Reduced&nbsp;with&nbsp;compression&nbsp;factor&nbsp;4
&nbsp;&nbsp;&nbsp;&nbsp;6&nbsp;-&nbsp;The&nbsp;file&nbsp;is&nbsp;Imploded
&nbsp;&nbsp;&nbsp;&nbsp;7&nbsp;-&nbsp;Reserved&nbsp;for&nbsp;Tokenizing&nbsp;compression&nbsp;algorithm
&nbsp;&nbsp;&nbsp;&nbsp;8&nbsp;-&nbsp;The&nbsp;file&nbsp;is&nbsp;Deflated
&nbsp;&nbsp;&nbsp;&nbsp;9&nbsp;-&nbsp;Enhanced&nbsp;Deflating&nbsp;using&nbsp;Deflate64(tm)
&nbsp;&nbsp;&nbsp;10&nbsp;-&nbsp;PKWARE&nbsp;Data&nbsp;Compression&nbsp;Library&nbsp;Imploding
&nbsp;&nbsp;&nbsp;11&nbsp;-&nbsp;Reserved&nbsp;by&nbsp;PKWARE
&nbsp;&nbsp;&nbsp;12&nbsp;-&nbsp;File&nbsp;is&nbsp;compressed&nbsp;using&nbsp;BZIP2&nbsp;algorithm

APK中，使用的是 0-Stored （不压缩）和 8-Deflated （Deflated 压缩算法压缩）。

File data

Flie data 则是文件压缩或直接存储后的二进制数据。

Data descriptor

Data descriptor 区块，只有通用比特标志位的第三位bit为1时才会出现此区块。

 
  
    
   
   
     
   Data&nbsp;descriptor:

&nbsp;&nbsp;crc-32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4&nbsp;bytes
&nbsp;&nbsp;compressed&nbsp;size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4&nbsp;bytes
&nbsp;&nbsp;uncompressed&nbsp;size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4&nbsp;bytes

This&nbsp;descriptor&nbsp;exists&nbsp;only&nbsp;if&nbsp;bit&nbsp;3&nbsp;of&nbsp;the&nbsp;general
purpose&nbsp;bit&nbsp;flag&nbsp;is&nbsp;set&nbsp;(see&nbsp;below).&nbsp;&nbsp;It&nbsp;is&nbsp;byte&nbsp;aligned
and&nbsp;immediately&nbsp;follows&nbsp;the&nbsp;last&nbsp;byte&nbsp;of&nbsp;compressed&nbsp;data.
This&nbsp;descriptor&nbsp;is&nbsp;used&nbsp;only&nbsp;when&nbsp;it&nbsp;was&nbsp;not&nbsp;possible&nbsp;to
seek&nbsp;in&nbsp;the&nbsp;output&nbsp;.ZIP&nbsp;file,&nbsp;e.g.,&nbsp;when&nbsp;the&nbsp;output&nbsp;.ZIP&nbsp;file
was&nbsp;standard&nbsp;output&nbsp;or&nbsp;a&nbsp;non&nbsp;seekable&nbsp;device.&nbsp;&nbsp;For&nbsp;Zip64&nbsp;format
archives,&nbsp;the&nbsp;compressed&nbsp;and&nbsp;uncompressed&nbsp;sizes&nbsp;are&nbsp;8&nbsp;bytes&nbsp;each.

案例展示

进过上面的理论学习，接下来可以找个APK瞅瞅；

可以看出：在该APK文件中，classes2.dex 文件的压缩方式为 0x0008 (Deflated)。

中心目录区

在 ZIP 文件中，数据区后面紧接着的就是中心目录区，ZIP 里的每个文件 (Entry) 在数据区和中心目录区都分别有一条对应的数据记录 (File Record) 和目录记录 (Dir Record)。（完成V2、V3签名的 APK 中，签名区块则位于数据区与中心目录区之间，签名区块这一点单独讲，先看看中心目录区。）

中心目录区由多条目录文件头 (Fille header) 和一条目录尾部 (End of central directory record) 组成，

File header

Fille header 格式定义如下：

从 File header 的格式定义中不难看出：目录区文件头比数据区文件头多了几个字段，例如：数据文件头的偏移地址。其他字段基本是重复的。

目录记录 (Dir Record) 只有文件头，因此比起数据记录 (File Record) 要小很多，解析起来也比较快，所以通过中心目录区可以快速获取压缩文件部分信息而不用解析整个 ZIP ，例如：ZIP 中是否含有某个文件。

同时目录记录里包含了对应的文件记录的偏移量，这样能通过目录快速定位并解压 ZIP 内的单个文件，避免从数据区从头遍历解析。

案例展示

End of central directory record

上面提到，通过中心目录区可以优化数据的查找和解析过程，那如何快速知道中心目录区的起始位置呢？

目录尾部对中心目录进行了简要描述，中心目录区的起始位置就在目录尾 (End of central directory record) 当中，其格式如下：

通过目录尾部的中心目录起始位置偏移，能快速获取目录位置。

案例展示

所以很有意思的一点：在某些场景下，ZIP 也可以从后往前解析的，而且能提效。常用的 ZipFile 正是使用了从后往前解析的方式。首先找到尾部，通过尾部，获取中心目录区的偏移量和长度，然后通过中心目录区域信息定位实际的数据区获取最终的数据。

/   ZipFile   /

这一步分析可能比较复杂，若阅读困难可以先略过~ 详细过程如下：

1）创建ZipFile文件

这一步主要是从目录尾部获取中心目录起始偏移等信息，并建立目录数据Hash与其起始偏移地址映射关系；在 ZipFile 的构造函数中会调用 ZipFile#open 函数：

[java.util.zip.ZipFile#open] -> [xref/libcore/ojluni/src/main/native/zip_util.c#ZIP_Open]-> [xref/libcore/ojluni/src/main/native/zip_util.c#ZIP_Open_Generic] -> [xref/libcore/ojluni/src/main/native/zip_util.c#ZIP_Put_In_Cache0] -> [xref/libcore/ojluni/src/main/native/zip_util.c#readCEN]

通过进一步阅读可以了解到 [readCEN]函数中只是对中心目录做了粗略的解析。只有在 getEntry 时才会仔细解析单条目录记录，其解析逻辑如下：

再看看尾部数据获取，从文件末尾查找能与尾部数据标志 0x06064B50 匹配的4个字节。

2）通过Hash查找并解析Entry

首先看下 ZipFile#getEntry(String ) 是如何查找并解析出 Entry 的：

今天周末，再深究一下，看看newEntry的解析。

这里就和我们看到头文件（File Header）的字段对应上了，头文件内容基本解析出来并放入ze 对象，ze 对象的指针做为函数的返回值。

看到这里，能体会到 ZipFile 做的优化还是挺细致的，ZipFile 创建的时候只做目录的粗解析，在获取具体文件（Entry）信息时只解析需要的头文件，到目前为止只获取了 Entry 基本信息，并没有去解析数据区。

3）二进制数据流读取

再看看 ZipFile 如何获取文件的二进制数据流的？

通过上面的 getEntry，我们已经能拿到 Entry 在中心目录区的头文件对象了，因此java.util.zip.ZipFile#getInputStream(ZipEntry entry)获取数据流时，通过 Entry 对应的指针获取数据记录 (File Record) 的起始地址直接读取数据即可。

[java.util.zip.ZipFile#getInputStream(ZipEntry entry)] -> [java.util.zip.ZipFile.ZipFileInputStream#read(byte[], int, int)] -> [xref/libcore/ojluni/src/main/native/java_util_zip_ZipFile.c#ZipFile_read>] -> [xref/libcore/ojluni/src/main/native/zip_util.c#ZIP_Read]

/   APK文件   /

前文提到：未进行（V2、V3）签名的 APK 就是一个标准的 ZIP 文件，完成V2、V3签名的 APK 中，签名区块则位于数据区与中心目录区之间。

APK Signing Block

APK 签名区块的结构如下：

A1: 签名区块起始偏移
B2: 中心目录区起始位置

案例展示

1）首先获取目录区域偏移量；

目录尾部标识：06 05 4B 50，中央目录区起始位置偏移量：00 04 4E 7D

2）通过中央目录区偏移量，找到常量标识”APK Sig Block42”及签名区块长度：

同时也能知道签名区块长度为：0F F8；

3）查找 ID-Valuce 的起始位置，以魔术最后一位，前移动 0F F8 ：

所以图中的偏移量为 0X043E86 就是ID-Value的起始位。

4）查看 ID-Value 结构：

V2 的签名信息存放在 ID = 0xa 的数据块中

V3 的签名信息存放在 ID = 0xf05368c0 的数据块中

第一项 ID-Value偏移量：

0X043E8D
长度：05 6E
ID：71 09 87 1A

第二项 ID-Value

偏移量：0x0443FB
长度：0A 62
ID: 72 42 65 77

第二项最后一位刚好与第二位的区块长度衔接

不难发现这里的Value字节全为0，这些 0 本身毫无含义，本以为能删除掉缩减一点包体，但是经查询，这里为了使签名区块为4096 的整数倍与内存页对齐（同时高版本 Android 会检测这个对齐规则，不可删除）。

部分团队的多渠道APK方案，则是在签名区块中加入额外的 ID-Value ，通常是固定一个 ID，Value设置为渠道信息即可。

/   小结   /

至此完成部分了 ZIP 及 APK 文件的格式分析，另外 ZIP 相关的其他知识点也比较繁多，很难说一篇文章能盖全，或全面了解，例如各类压缩算法、ZIP 版本差异以及 7z （后续计划讲下 7z ）等等，但是能掌握到文中介绍的这些，也足以解决日常遇到的绝大多 ZIP 相关问题了。

参考

https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.2.0.txt
http://androidxref.com/9.0.0_r3/
https://www.youtube.com/watch?v=_a_keel8JFI
https://source.android.com/docs/security/features/apksigning/v2?hl=zh-cn#apk-signing-block

安卓软件后缀名是什么（安卓软件后缀名是多少）

相关推荐