作者：CCO体系 尚红泽

背景介绍

应用安装包的体积影响着用户下载量、安装时长、用户磁盘占用量等多个方面，据Google Play统计，应用体积每增加6MB，安装的转化率将下降1%。



安装包的体积受诸多方面影响，针对dex、资源文件、so文件都有不同的优化策略，在此不做一一展开，本文主要记录了在研发时针对动态链接库的文件体积裁剪优化方案。

我开发的链接库使用rust语言开发，通过安卓jni接口实现java层和native层之间的相互调用。为什么使用rust主要有以下几个方面的考虑：

1.稳。安卓的JNI接口调用复杂，又涉及到native层的内存管理，随着代码量的增加，代码的安全稳定性会受到很大的挑战。使用rust开发，开发者几乎不需要考虑GC的问题，只要开发的时候按照规范老老实实写代码并且通过了编译器的检查，基本上就很难把程序写崩，这一点在代码上线后也确实得到了验证。

2.安全。传统使用C、C++开发的代码编译完成以后，如果不加保护，很容易使用反汇编工具破解，市面上比较成熟的工具如IDA、ghidra等都可以将汇编代码还原到高级语言。使用rust编译的产物，内部函数间的调用规约和传统都不一样，目前市面上还没有相对完善的反编译工具，软件的防破解能力直接上升一个数量级。

但是使用rust有一个非常明显的缺点就是编译产物体积过大。在不修改默认的rust编译选项的情况下，仅开启strip的情况下，我的动态库体积达到了495k。

优化方案

参考网上前人的经验，依次进行了以下优化方式。

调整优化等级

默认的编译优化等级是O3，该优化的目的提高代码的运行速度，但是与此同时会对部分循环进行展开，体积造成膨胀。在此我们以缩减体积为目标，将优化选项改为z，表示生成最小二进制体积：

1[profile.release]
2opt-level = 'z'

优化后前后体积变化

开启LTO

LTO（Link Time Optimization）可以在链接时消除冗余代码，减小二进制体积——代价是更长的链接时间。

1Cargo.toml
2[profile.release]
3opt-level = 'z'
4lto = true

优化后前后体积变化

优化效果非常不明显，聊胜于无。

Panic立刻终止

rust默认的panic会在崩溃时进行栈回溯，方便定位问题。然而会带来额外的体积增加，将这一功能使用abort替代。

1[profile.release]
2opt-level = 'z'
3lto = true
4panic = 'abort'

优化后前后体积变化

到目前为止，常规的优化手段已经用完了，后续优化需要配合一些代码的额外变动。

使用rust分析工具bloat对产物进行分析，结果如下：

1File  .text     Size Crate
24.1%  69.0% 192.7KiB std
31.0%  16.8%  46.9KiB jdmp
40.5%   8.1%  22.7KiB [Unknown]
50.2%   3.8%  10.5KiB jni
60.0%   0.5%   1.5KiB cesu8
70.0%   0.4%   1.1KiB adler32
80.0%   0.3%     904B bytes
90.0%   0.2%     640B aho_corasick
100.0%   0.2%     588B regex_syntax
110.0%   0.2%     572B regex_automata
120.0%   0.2%     440B log
130.0%   0.1%     304B memchr
140.0%   0.0%      52B combine
150.0%   0.0%       8B jni_sys

让我感到惊讶的是我的核心代码jdmp模块只占了46.9k，为此要额外引入几百k的额外开销！

移除一些无用字符串

在引入的第三方依赖里，开发者自己添加了很多字符串信息，大部分是用来完善提供运行时报错信息。通过修改、精简这些依赖库，删除无用代码，又可以省出一部分空间来。

同时，上面的优化尽管使用abort替代了panic，rust编译器仍然会生出一些格式化的字符串，使用panic_immediate_abort这个编译选项禁用这个行为。

1.cargo/config.toml
2[unstable]
3build-std-features = ["panic_immediate_abort"]
4build-std = ["std","panic_abort"]

优化后前后体积变化

再次分析，整个文件的体积已经降到了135k，自己开发的核心代码占总代码量的52%，基本符合预期。

1 File  .text    Size Crate
214.2%  52.0% 41.3KiB jdmp
3 3.2%  11.7%  9.3KiB core
4 3.1%  11.4%  9.1KiB jni
5 3.0%  11.0%  8.8KiB [Unknown]
6 1.9%   6.8%  5.4KiB std
7 0.9%   3.3%  2.6KiB alloc
8 0.3%   1.1%    936B cesu8
9 0.3%   1.0%    792B adler32
10 0.1%   0.5%    372B aho_corasick
11 0.1%   0.4%    316B regex_automata
12 0.1%   0.3%    220B log
13 0.1%   0.3%    216B hashbrown
14 0.0%   0.1%    108B bytes
15 0.0%   0.1%     44B combine
16 0.0%   0.1%     44B rustc_demangle
17 0.0%   0.0%      8B compiler_builtins
18 0.0%   0.0%      8B jni_sys

优化linker script

尽管目前文件体积已经相比一开始优化了不少，但是还没有达到接入要求。通过readelf进一步分析ELF文件的各个section，我找到了一些额外的优化空间。

1$ aarch64-linux-gnu-readelf -S target/aarch64-linux-android/release/libjdmp.so
2There are 24 section headers, starting at offset 0x21738:
3
4Section Headers:
5  [Nr] Name              Type             Address           Offset
6       Size              EntSize          Flags  Link  Info  Align
7  [ 0]                   NULL             0000000000000000  00000000
8       0000000000000000  0000000000000000           0     0     0
9  [ 1] .note.android.ide NOTE             0000000000000270  00000270
10       0000000000000098  0000000000000000   A       0     0     4
11  [ 2] .dynsym           DYNSYM           0000000000000308  00000308
12       00000000000002e8  0000000000000018   A       7     1     8
13  [ 3] .gnu.version      VERSYM           00000000000005f0  000005f0
14       000000000000003e  0000000000000002   A       2     0     2
15  [ 4] .gnu.version_r    VERNEED          0000000000000630  00000630
16       0000000000000040  0000000000000000   A       7     2     4
17  [ 5] .gnu.hash         GNU_HASH         0000000000000670  00000670
18       0000000000000024  0000000000000000   A       2     0     8
19  [ 6] .hash             HASH             0000000000000694  00000694
20       0000000000000100  0000000000000004   A       2     0     4
21  [ 7] .dynstr           STRTAB           0000000000000794  00000794
22       000000000000014d  0000000000000000   A       0     0     1
23  [ 8] .rela.dyn         RELA             00000000000008e8  000008e8
24       00000000000007f8  0000000000000018   A       2     0     8
25  [ 9] .rela.plt         RELA             00000000000010e0  000010e0
26       00000000000002a0  0000000000000018  AI       2    19     8
27  [10] .rodata           PROGBITS         0000000000001380  00001380
28       0000000000001d83  0000000000000000  AM       0     0     8
29  [11] .eh_frame_hdr     PROGBITS         0000000000003104  00003104
30       0000000000002494  0000000000000000   A       0     0     4
31  [12] .eh_frame         PROGBITS         0000000000005598  00005598
32       00000000000078cc  0000000000000000   A       0     0     8
33  [13] .text             PROGBITS         000000000000de64  0000ce64
34       0000000000013e0c  0000000000000000  AX       0     0     4
35  [14] .plt              PROGBITS         0000000000021c70  00020c70
36       00000000000001e0  0000000000000000  AX       0     0     16
37  [15] .data.rel.ro      PROGBITS         0000000000022e50  00020e50
38       0000000000000430  0000000000000000  WA       0     0     8
39  [16] .fini_array       FINI_ARRAY       0000000000023280  00021280
40       0000000000000010  0000000000000008  WA       0     0     8
41  [17] .dynamic          DYNAMIC          0000000000023290  00021290
42       0000000000000180  0000000000000010  WA       7     0     8
43  [18] .got              PROGBITS         0000000000023410  00021410
44       0000000000000048  0000000000000000  WA       0     0     8
45  [19] .got.plt          PROGBITS         0000000000023458  00021458
46       00000000000000f8  0000000000000000  WA       0     0     8
47  [20] .data             PROGBITS         0000000000024550  00021550
48       0000000000000060  0000000000000000  WA       0     0     8
49  [21] .bss              NOBITS           00000000000245b0  000215b0
50       0000000000000101  0000000000000000  WA       0     0     8
51  [22] .comment          PROGBITS         0000000000000000  000215b0
52       00000000000000b2  0000000000000001  MS       0     0     1
53  [23] .shstrtab         STRTAB           0000000000000000  00021662
54       00000000000000d3  0000000000000000           0     0     1

在对这些section进行优化时，有必要搞清楚每个section在程序运行的作用。

程序在正常运行时，代码段、数据段必不可少，同时需要保留动态链接需要的section。剩余的section可以移除，可以进一步优化文件体积。值得注意到是，删除.eh_frame .eh_frame_hdr后，在程序崩溃时只能得到一个崩溃地址，无法进行栈回溯。

创建一个linker script，只保留程序运行最小依赖的section。

1PHDRS
2{
3  headers PT_PHDR PHDRS ;
4  text PT_LOAD FILEHDR PHDRS ;
5  data PT_LOAD ;
6  dynamic PT_DYNAMIC ;
7}
8ENTRY(Reset);
9EXTERN(RESET_VECTOR); 
10SECTIONS
11{
12  . = SIZEOF_HEADERS;
13  .text : { *(.text .text.*) } :text
14  .rodata : { *(.rodata .rodata.*) } :text
15
16  . = . + 0x1000;
17  .data : { *(.data .data.*) *(.fini_array .fini_array.*) *(.got .got.*) *(.got.plt .got.plt.*) } : data
18  .bss : {*(.bss .bss.*)} : data
19  .dynamic : { *(.dynamic .dynamic.*)  } :data :dynamic
20
21  /DISCARD/ :
22  {
23    *(.ARM.exidx .ARM.exidx.*);
24    *(.gnu.version .gnu.version.*);
25    *(.gnu.version_r .gnu.version_r.*);
26    *(.eh_frame_hdr .eh_frame .eh_frame_hdr.* .eh_frame.* );
27    *(.note.android.ident .note.android.ident.*);
28    *(.comment .comment.*);
29  }
30}

修改编译参数，替换默认的linker script

1.cargo/config.toml
2
3[build]
4target = ["aarch64-linux-android","armv7-linux-androideabi"]
5
6[unstable]
7build-std-features = ["panic_immediate_abort"]
8build-std = ["std","panic_abort"]
9
10[target.aarch64-linux-android]
11rustflags = ["-C", "link-arg=-Tlinker.lds"]
12
13[target.armv7-linux-androideabi]
14rustflags = ["-C", "link-arg=-Tlinker.lds"]

经过一番操作，程序的体积最终裁减到了95k！完美符合要求。

总结