另辟蹊径的 Android 包体积优化之 Jar 包压缩
1、背景
最近因为需要做文本的字符串编码解析，所以引用了 IBM 的一个开源库。不过这个库体积实在太大，9M！讲道理，对于文本编码方式解析这种功能，如果需要使用 9M 的代码才能完成确实有些夸张。所以，我猜想这个库中应该包含了一些我并不需要的类文件。因此，我考虑从这个 jar 包当中移除这些我并不需要的类文件。使用手动删除的方式并不容易，因为文件太多，而且引用关系不容易确定。所以，我决定使用 Python 脚本来做 jar 包瘦身的工作。
2、常量池解析
了解过 JVM 的都清楚 class 文件的结构。如果，我们可以解析出这个类引用了哪些类，然后将被引用的类添加到队列中依次进行遍历，直到找到所有的引用的类，然后将这些被引用到类重新打包。这样我们就只提取了我们需要用到的类，从而实现了 jar 包的压缩。这本质上是 class 解析和广度优先搜索的过程。
这里，我们先看下几个解析 class 常量池的方案。
2.1 方案一：使用 javap 反编译类文件
为了解决这个问题，我首先想到的是使用 javap 反编译获取 class 文件中引用的类。一开始的时候，我使用的是如下指令，
private static java.util.ArrayList<com.ibm.icu.text.CharsetRecognizer> createRecognizers();
Code:
0: new #14 // class java/util/ArrayList
3: dup
4: invokespecial #15 // Method java/util/ArrayList."<init>":()V
7: astore_0
8: aload_0
9: new #39 // class com/ibm/icu/text/CharsetRecog_UTF8
12: dup
13: invokespecial #40 // Method com/ibm/icu/text/CharsetRecog_UTF8."<init>":()V
16: invokevirtual #23 // Method java/util/ArrayList.add:(Ljava/lang/Object;)Z
19: pop
20: aload_0
21: new #41 // class com/ibm/icu/text/CharsetRecog_Unicode$CharsetRecog_UTF_16_BE
24: dup
25: invokespecial #42 // Method com/ibm/icu/text/CharsetRecog_Unicode$CharsetRecog_UTF_16_BE."<init>":()V所以，我们可以通过匹配 // Method 这个关键字来获取这个类文件引用的类。不过这种方式存在一个问题，即，如果一个类不是在方法中引用而是通过 extends 的方式继承引用的则获取不到。不过，对于继承的方式也有一个解决办法，即对于继承，编译器会默认为子类生成构造方法并且在构造方法中调用父类的构造方法，所以我们可以在构造方法中获取到被引用的类。但是，如果是接口的话就无能为力了。所以，这种方案还是存在这样一个问题。
2.2 方案二：使用 javap -verbose 指令输出常量池
这种方式解析出的常量池如下，
Constant pool:
#1 = Methodref #102.#196 // java/lang/Object."<init>":()V
#2 = Fieldref #101.#197 // com/ibm/icu/text/CharsetDetector.fInputBytes:[B
#3 = Fieldref #101.#198 // com/ibm/icu/text/CharsetDetector.fByteStats:[S
#4 = Fieldref #101.#199 // com/ibm/icu/text/CharsetDetector.fC1Bytes:Z
#5 = Fieldref #101.#200 // com/ibm/icu/text/CharsetDetector.fStripTags:Z
#6 = Fieldref #101.#201 // com/ibm/icu/text/CharsetDetector.fDeclaredEncoding:Ljava/lang/String;
#7 = Fieldref #101.#202 // com/ibm/icu/text/CharsetDetector.fRawInput:[B
#8 = Fieldref #101.#203 // com/ibm/icu/text/CharsetDetector.fRawLength:I
#9 = Fieldref #101.#204 // com/ibm/icu/text/CharsetDetector.fInputStream:Ljava/io/InputStream;
#10 = Methodref #205.#206 // java/io/InputStream.mark:(I)V
#11 = Methodref #205.#207 // java/io/InputStream.read:([BII)I
#12 = Methodref #205.#208 // java/io/InputStream.reset:()V
#13 = Methodref #101.#209 // com/ibm/icu/text/CharsetDetector.detectAll:()[Lcom/ibm/icu/text/CharsetMatch;
#14 = Class #210 // java/util/ArrayList
#15 = Methodref #14.#196 // java/util/ArrayList."<init>":()V
#16 = Methodref #101.#211 // com/ibm/icu/text/CharsetDetector.MungeInput:()V
#17 = Fieldref #101.#212 // com/ibm/icu/text/CharsetDetector.fCSRecognizers:Ljava/util/ArrayList;
#18 = Methodref #14.#213 // java/util/ArrayList.iterator:()Ljava/util/Iterator;
#19 = InterfaceMethodref #214.#215 // java/util/Iterator.hasNext:()Z
#20 = InterfaceMethodref #214.#216 // java/util/Iterator.next:()Ljava/lang/Object;所以，我们可以在解析出常量池之后通过字符串匹配的方式获取引用的类。
这种方式是可行的，不过相比于下面的一种方案，这种方案的执行效率相对较低，因为反编译过程中生成了许多我们用不到的信息，此外字符串匹配的过程效率也不高。
所以，最终我采用了下面的方案。
2.3 方案三：手动解析常量池
这里复习一下 class 文件的结构。下面是一个比较简单的 class 通过 hex 打开之后的图，
根据 class 类结构的定义：前面四个字节（CA FE BA BE）是魔数；接下来的两个字节（00 00）是 class 支持的最低的 JDK 的版本，通常数值在 40~60 之间，即 JDK 的版本；再接下来的两个字节（00 31）是支持的最高的 JDK 的版本；紧接着的两个个字节（00 1F）是常量池的大小，这里的值是 31. 需要注意的是常量池的编号是从 1 开始的（可以看上面通过 javap -verbose 输出的结果）。这很重要，因为常量池中常量会通过这个编号引用其他常量。
对于常量池中的常量，其部分定义如下
常量池定义
这里的 u1, u2, u4 和 u8 分别表示一个、两个、四个和八个字节的意思。对于每个常量，都是以一个字节的 tag 作为起始的标志。每个常量的长度除了 tag 为 1 的常量之外都是固定的。比如 tag 为 3 的除了 tag 之外还占用 4 个字节；tag 为 5 的除了 tag 之外还占用 8 个字节。对于 tag 为 1 的常量，它表示字符串类型，通常用来定义类和方法的名称等。紧跟着 tag 1 的两个字节表示这个常量的字节的长度，比如如果它的值是 5 的话，那么接下来的 5 个字节就是这个字符串的具体内容。
了解了常量池的规则之后，我们就可以通过 Python 脚本来实现常量池的解析，
class PoolParser:
def __init__(self):
self.constants = {
3: 4, 4: 4, 5: 8, 6: 8, 7: 2, 8: 2, 9: 4, 10: 4,
11: 4, 12: 4, 15: 3, 16: 2, 17: 4, 18: 4, 19: 2, 20: 2
}
def parse(self, path: str) -> List[str]:
'''Parse constant pool of class file with path.'''
try:
with open(path, 'rb') as fp:
data = fp.read()
constant_count = data[8] * 16 * 16 + data[9]
cur_constant_index = 1
index = 10
sequences = {}
classes_nums = []
while cur_constant_index < constant_count:
constant_code = data[index]
if constant_code == 1:
char_length = data[index+1]*16*16+data[index+2]
char_start = index+3
char_end = char_start+char_length
# print(str(cur_constant_index) + '/' + str(constant_count) + ': ' + str(data[char_start:char_end], 'utf-8'))
sequences[cur_constant_index] = str(data[char_start:char_end], 'utf-8')
index = index + 2 + char_length + 1
cur_constant_index = cur_constant_index + 1
elif constant_code == 5 or constant_code == 6:
# Special guideline for double and long type, see https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.4.5
index = index + self.constants[constant_code] + 1
cur_constant_index = cur_constant_index + 2
else:
# Get number of class in the constant pool.
if constant_code == 7:
classes_nums.append(data[index+1]*16*16+data[index+2])
index = index + self.constants[constant_code] + 1
cur_constant_index = cur_constant_index + 1
return [sequences[num] for num in classes_nums]
except BaseException as e:
logging.error("Error while parsing constant pool:\n%s" % traceback.format_exc())
print("Error while parsing constant pool for [%s]" % path)
return []这里的逻辑是解析出常量池的长度之后进行遍历，每次递增一，直到将所有的常量全部解析出来。这里有几个细节需要注意：
- 对于 tag 为 5 和 6 的常量（实际就是 long 和 double 类型定义的常量）他们占用两个编号。这个定义感觉有些奇葩。如果不是看了 Oracle 的官方文档，一般的书还真查不到这个。就是说，如果一个 class 文件的常量池的大小部分的值是 30 并且常量池中包含了一个 double 类型，那么它实际只有 29 个常量而不是 30 个，因为 double 占了两个编号，尽管 class 文件上的布局是连续的。
- 确定常量池中的 class 的时候用到了 tag 为 7 的常量。这个常量 tag 之后的两个字节就是 class 的内容。所以，这是一种准确的找到常量池中的 class 的方法。（class 被放到 tag 为 1 的常量中，实际是作为 uft8 类型的字符串处理的）
- 最后，Oracle 对于 JVM 定义详细的文档：https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.4.5，感兴趣的可以自己查找，比任何书籍都更加全面。
3、整体的脚本实现
3.1 jar 包解析
jar 使用的是 zip 文件格式。对于 Android 的应用场景，因为我们本身不将 jar 作为可执行文件使用，所以对于 jar 的格式要求就低得多。基本使用 Python 的 zip 库解压，然后使用 jar 指令打包即可。这里 Zip 解包的逻辑是，
def _unzip_jar(self):
'''Unzip the jar.'''
print("Unzip jar ...")
logging.info("Unzip jar ...")
self.unzip_to = str(int(time.time()))
try:
with open(self.jar_path, 'rb') as fp:
data = fp.read()
self.unzip_to = hashlib.md5(data).hexdigest()
except BaseException as e:
logging.error("Error while reading the jar md5:\n%s" % traceback.format_exc())
print("Error while reading the jar md5 [%s]" % self.jar_path)
self.unzip_to = 'space/%s/unzip' % self.unzip_to
if not os.path.exists(self.unzip_to):
try:
zipFile = zipfile.ZipFile(self.jar_path)
zipFile.extractall(self.unzip_to)
zipFile.close()
except BaseException as e:
logging.error("Error while unzip the jar:\n%s" % traceback.format_exc())
print("Error while unzip the jar [%s]" % self.jar_path)
else:
logging.info("Unziped resources exists, ignore!")
print("Unziped resources exists, ignore!")逻辑比较简单，即先读取 jar 文件的 md5 来判断指定的 jar 的解压文件是否存在，如果存在就直接使用，否则再做一遍解压操作。
3.2 广度优先搜索
这里我用到的是基于队列的广度优先算法。
def _search_by_read_constants(self):
'''Search by parsing constants.'''
print("Searching classes by parsing constant pool ...")
logging.info("Searching classes by parsing constant pool ...")
start = int(time.time())
self.classes = [os.path.join(self.unzip_to, cls.replace('.', '/')) + '.class' for cls in self.classes]
visits = []
visits.extend(self.classes)
count = 0
parser = PoolParser()
while len(visits) > 0:
count = count + 1
cur_path = visits.pop()
exists = os.path.exists(cur_path)
logging.info("Searching under [%d][%s][%s]" % (count, str(exists), self._simplify_class_path(cur_path)))
print("Searching under [%d][%s][%s]" % (count, str(exists), self._simplify_class_path(cur_path)), end='\r')
# Ignore if the class file not exists.
if not exists:
self.classes.remove(cur_path)
continue
# Parse classes from class constant pool.
classes = parser.parse(cur_path)
for cls in classes:
self._handle_classes(cls, cur_path, visits)
logging.info("Searching classes by parsing constant pool done in [%d]" % (int(time.time())-start))
print("Searching classes by parsing constant pool done in [%d]" % (int(time.time())-start))
def _handle_classes(self, cls: str, cur_path: str, visits: List[str]):
'''Handle classes.'''
pathes = [cls]
# Handle if the class is an inner class.
if cls.rfind('$') > 0:
pos = cls.rfind('$')
while pos > 0:
cls = cls[0:pos]
pathes.append(cls)
pos = cls.rfind('$')
for path in pathes:
cls_path = os.path.join(self.unzip_to, path) + '.class'
# Only search one class a time.
if cls_path not in self.classes:
self.classes.append(cls_path)
visits.append(cls_path)
logging.info("Found [%s] under [%s]" % (path, self._simplify_class_path(cur_path)))这里以启动脚本的时候传入的执行类作为起点进行遍历，判断这个文件是否存在于本地。因为有一些标准库中引用到的类并不在我们的 jar 包当中，所以这一操作是为了将这类的文件排除掉。然后，这里使用了我们前面介绍的 class 常量池解析逻辑从 class 中解析这个引用到的其他的类并将其他们加入到队列中继续进行遍历。直到整个队列为空，则表明程序执行结束。
这里有个细节需要注意，即内部类的处理。对于形如 AAA$BBB$CCC 有一个要求，我们在打包的时候必须将外部类同时打入到包中，否则内部类不会被打进最终的 jar 文件中。这里我写了一段程序来解析上述类型的内部类及其父类，即 _handle_classes() 方法中的前几行代码。
3.3 jar 打包
对于 jar 打包，我们最好还是使用官方的 jar 指令来完成。打包的时候，一种方式是将我们的所有的类通过拼接的方式组成一个指令。不过因为有时候包含的类太多，这种方式会造成打包的指令非常长。所以，后来我换了另外一种方案。即将所有用到的类文件复制到一个目录下面，然后再针对这个目录进行打包。即，
def _pack_classes(self):
'''Packing casses.'''
print("Packing classes ...")
logging.info("Packing classes ...")
if not os.path.exists(self.output):
os.mkdir(self.output
# Copy all filted classes to a directory.
for cls in self.classes:
dst = cls.replace(self.unzip_to, self.copy_to)
par = os.path.dirname(dst)
if not os.path.exists(par):
os.makedirs(par)
shutil.copyfile(cls, dst)
# Get into the copied directory and use jar to package the directory.
pack_command = 'cd %s && jar cvf %s/final.jar %s' % (self.copy_to, self.output, '.')
logging.info("PACK COMMAND: %s" % pack_command)
ret = os.popen(pack_command).read().strip()4、效果
因为本身是针对 jar 包的瘦身，所以实际执行的效果要取决于 jar 包的具体情况。比如，上述我引用的 IBM 的 jar 包经过瘦身之后，从 9M 精简到了 1M 大小。
5、限制
- 现在的方案还不是最极致的优化：因为现在的方案只要在一个类文件中出现就会被加入到最终的 jar 包当中，而我们需要用到的方法可能并不会用到这些类。所以，如果做方法级别的扫描就能够排除更多的没必要的类文件。不过，如果做方法级别的扫描，还需要面对崩溃堆栈可能和实际的代码对不上的问题。
- 此外，对于在 so 中引用到的方法现在还无能为力。
总结
上面是 Android 包体积优化的技巧之一吧。我之前看到过有的团队做 dex 级别的优化，如果按照上面这种思路，从整个 Android 包体积中做优化，排除用不到的 class 文件，效果会比 dex 级别优化效果要好一些。不过，对于 Android 而言，遇到的情况可能会更加复杂，比如 so 中进行调用以及加密和反射等情况。