支付宝 App 构建优化解析：Android 包大小极致压缩

上图是一个比较常见的 crash 信息，红框中的行号便是通过查找这个 debugItem 来获取的。

• debugItem 有多大？

在支付宝的场景下，debug 包有 4-5M，release 包有 3.5M 左右，占 dex 文件大小的比例在 5.5% 左右，和 google 官方的数据是一致的。如果能把这部分直接去掉，是不是很诱人！

• debugItem 能直接去掉吗？

显然不能，如果去掉了，那所有上报的 crash 信息就会没有行号，所有的行号都会变成 -1，会被喷的找不到北。 其实在 proguard 的时候就是有配置可以去掉或保留这个行号信息，-keep SourceFile, LineNumberTable 就是这个作用，为了方便定位问题，基本所有的开发都保留了这个配置。 所以，方案的核心思路就是去掉 debugItem，同时又能让 crash 上报的时候能拿到正确的行号。至于 IDE 调试，这个比较好解决，我们只要处理 release 包就行了，debug 包不处理。

方案一

核心思路也比较简单，就是行号查找离线化，让本来存放在 App 中的行号对应关系提前抽离出来存放在服务端，crash 上报的时候通过提前抽离的行号表进行行号反解，解决 crash 信息上报无行号，无法定位的问题。 思路虽然简单，实现的时候还是有点复杂，推动上线也比较曲折，方案经过几次调整，大概的方案可以用下面一张图来抽象：

如上图，核心点有四个：

1. 修改 proguard，利用 proguard 来删除 debugItem （去掉 -keep lineNumberTable)，在删除行号表之前 dump 出一个临时的 dex。
2. 修改 dexdump，把临时的 dex 中的行号表关系 dump 成一个 dexpcmapping 文件(指令集行号和源文件行号映射关系)，并存至服务端。
3. hook app runtime 的 crash handler，把 crash 时的指令集行号上报到反解平台。
4. 反解平台通过上报指令集行号和提前准备好 dexpcmapping 文件反解出正确的行号。

上面这套方案大概花了两个多星期，撸出了整个 demo，其它几个改造点都不是很难，难点还是在指令集行号的上报。 我们知道所有的 crash 最终都是会有一个 throwable 对象，里面保存了整个堆栈信息，经过反复的阅读源码和尝试，发现我要的指令集行号其实也在这个对象里面。可以用下面一幅简单的图示意：

在打印 crash 堆栈信息前，每个 throwable 都会调用art虚拟机提供的一个 jni 方法，返回一个内部的对象叫 stackTrace 保存在 Throwable 对象中，这个 stackTrace 对象里面保存的便是整个方法的调用栈，当然也包括指令集行号，后续获取实际的堆栈信息时会再调用一个 art 的 jni 方法，把这个 stackTrace 方法丢过去，底层通过这个 stackTrace 对象中的指令集行号反解出正式的源文件行号。 好了，其实很简单，反射获取下这个 Throwable 中的 stackTrace 对象，拿到指令集行号，然后，上报。 这里要注意的一个点，比较恶心，每个虚拟机的实现都不一样，首先内部对象的名字，有些叫 stackTrace，有些叫 backstrace，然后这个内部对象的类型也非常有，有些是 int 数组，有些是 long 数组，有些是对象数组，但是都会有这个指令集行号，需要针对不同的虚拟机版本使用不同的方法去解析这个对象，大概要兼容4种虚拟机，4.x, 5.x, 6.x, 7.x，7.x 虚拟机之后的就统一了。

方案二

上面这套方案其实挺完美的，没有什么兼容性问题，删除是直接利用 proguard，获取指令集行号直接在 java 层获取，不需要各种 hook，如果只需要处理 crash 的上报，方案一足够了，但是在支付宝有很多场景是远远不够的。 比如：

• 性能，CPU，内存异常时调用栈。
• native crash 时的 Java 调用栈。

上面这些 case 都会涉及到堆栈信息，方案一中通过反射调用 throwable 中的 stackTrace 内部对象根本搞不定，需要换种方法。 最开始的思路是尝试 hook art 虚拟机，每天翻源码，看看可以 hook 的点，最后还是放弃了，一个是担心兼容性问题，另一个是 hook 的点太多，比较慌。 最后换了一种思路，尝试直接修改 dex 文件，保留一小块 debugItem，让系统查找行号的时候指令集行号和源文件行号保持一致，这样就什么都不用做，任何监控上报的行号都直接变成了指令集行号，只需修改 dex 文件。可以用下面的示意图表示：

如上图：本来每一个方法都会有一个 debugInfoItem，每一个 debuginfoItem 里面都有一个指令集行号和源文件行号的映射关系，我做的修改其实非常简单，就是把多余的 debugInfoItem 全部删掉了，只留了一个 debugInfoItem，所有的方法都指向同一个 debugInfoItem，并且这个 debugInfoItem 中的指令集行号和源文件行号保持一致，这样不管用什么方式来查行号，拿到的都是指令集行号。

其中也踩过很多坑，其实光留一个 debugInfoItem 是不够的，要兼容所有虚拟机的查找方式，需要对 debugInfoItem 进行分区，并且 debugInfoItem 表不能太大，遇到过一个坑就是 androidO 上进行 dex2oat 优化的时候，会频繁的遍历这个 debugInfoItem，导致 AOT 编译比较慢，最后都通过 debugInfoItem 分区解决了。

这个方案比较彻底，不用改 proguard，也不用 hook native。不过如果只需要处理 crash 的行号问题，那还是首推方案一，这个方案改动有点大，前期也是每天研究 dex 的文件结构，抠每一个细节，有比较大的把握时才敢改。

小结

目前该方案已经在支付宝正式上线，前面经过好几轮的外灰验证，还是比较稳定的。支付宝整体包大小减少了 2.1M 左右，真实的 dex 大小减少 3.5M 左右。

通过本节内容，我们初步了解了支付宝在 Android 客户端如何通过包大小压缩以提升 App 运行效率和质量。由于篇幅限制，很多技术要点我们无法一一展开。而相应的技术内核，我们同样应用在了 mPaaS 并对外输出，欢迎大家上手体验：

tech.antfin.com/docs/2/4954…

关于 Android 端包大小压缩的设计思路和具体实践，同样期待你们的反馈，欢迎一起探讨交流。

往期阅读

《开篇 | 模块化与解耦式开发在蚂蚁金服 mPaaS 深度实践探讨》

《支付宝移动端动态化方案实践》

《支付宝客户端架构解析：iOS 容器化框架初探》

《支付宝客户端架构解析：Android 容器化框架初探》

《支付宝客户端架构解析：Android 客户端启动速度优化之「垃圾回收」》

《支付宝 App 构建优化解析：通过安装包重排布优化 Android 端启动性能》

关注我们公众号，获得第一手 mPaaS 技术实践干货

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

总结

开发是面向对象。我们找工作应该更多是面向面试。哪怕进大厂真的只是去宁螺丝，但你要进去得先学会面试的时候造飞机不是么？

作者13年java转Android开发，在小厂待过，也去过华为，OPPO等，去年四月份进了阿里一直到现在。等大厂待过也面试过很多人。深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。

这里附上上述的技术体系图相关的几十套腾讯、头条、阿里、美团等公司的面试题，把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分。

相信它会给大家带来很多收获：

资料太多，全部展示会影响篇幅，暂时就先列举这些部分截图

当程序员容易，当一个优秀的程序员是需要不断学习的，从初级程序员到高级程序员，从初级架构师到资深架构师，或者走向管理，从技术经理到技术总监，每个阶段都需要掌握不同的能力。早早确定自己的职业方向，才能在工作和能力提升中甩开同龄人。

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！

方向，才能在工作和能力提升中甩开同龄人。

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！