向工程腐化开炮：Java代码治理

作者：刘天宇(谦风)

系列文章回顾《向工程腐化开炮 | proguard治理》《向工程腐化开炮 | manifest治理》。本文为系列文章第三篇，虽然标题是java代码，但准确来讲，本文主要聚焦的是jvm字节码，因此相关工具和治理，对于kotlin也同样适用，如无特殊情况，不再单独说明。此外，还会涉及到java资源。

java代码腐化和失控，主要体现在不合理代码使用不断累积。这里“不合理”的定义，由上层场景决定，例如在当前隐私合规监管态势下，我们不允许非预期的，代码直接调用系统敏感API，那么“对系统敏感API的直接调用”就是不合理。java代码治理，正是围绕这种“不合理“代码使用，逐步展开。

基础知识

本章不会介绍java语言本身，相信大家对此已有足够熟悉。相对的，会从工程应用角度，讲解几个有意思的技术点。

1.1 由源码到apk

源代码是如何经历多重处理，最终呈现在apk中，了解这个过程，有助于我们认清java代码腐化的一些原因。从apk构建视角来看，java（kotlin）代码完整处理过程如下：

上述流程中，无论是java还是kotlin代码，都会首先编译为jvm字节码。这里需要注意，app/子工程中的local jar、flat aar，以及通过外部依赖方式引入的jar、aar，都是直接包含编译好的jvm字节码，这会带来如下优劣势：

• 【优势】无需再进行由源码到字节码的编译，在代码完全相同情况下，工程的模块化（jar/aar）程度越高，越能够缩短整体apk构建耗时；
• 【劣势】提前编译好的jvm字节码，不会再进行源码编译期各项检查，容易出现代码间引用关系不匹配情况，具体后文「不兼容引用」部分会详述。

此外，关于jvm和Dalvik字节码，一个最核心的区别是：前者的指令，基于栈，后者基于寄存器。基于寄存器的优势，主要是运行时指令执行性能的提升。此外，jvm字节码，每个类位于独立.class文件，而dalvik字节码，所有类均位于同一（几）个dex文件，能够更好的复用代码数据，因此存储占用更低。

1.2 使用java8

java8是一个比较有代表性的java语言版本，在Android中使用java8，这个话题本身会比较复杂。首先，从java8新内容来看，主要分为新语言特性和新API；其次，从编码到运行的整个链路来看，涉及编译工具链、设备预装jdk、设备vm（Dalvik/Art）三个部分的支持；此外，Android本身使用的jdk并不是标准的oracle jdk或openjdk，而是进行了一些定制后的子集。

java8新语言特性，有一些涉及到新的jvm指令集，这些需要运行时vm能够支持。否则，就需要在编译工具链中，能够使用兼容的指令集来替换这些新指令集的功能，这个过程就是大家熟悉的“脱糖”，AndroidGradlePlugin3.0及以上版本，已经对此实现了较好的支持。由于Android系统中Art虚拟机，直到8.0版本，才完全实现对java8新指令集的支持，因此当apk构建的minSdkVersion设置为26（8.0）以下时，会触发脱糖处理。java8的主要新语言特性如下：

对于java8新API，两组具有代表性的是「流式编程streams」和「函数式编程functional」，直到os7.0才提供了较完整的支持。具体如何在更低minSdkVersion时使用这些java8新API，可以参考文末官方文档。

本节对在Android中使用java8的一些基础知识，进行了讲解，关于在工程中如何具体配置，官方文档已经给出了清晰的说明，在此不赘述。

1.3 DX vs D8

由jvm字节码“转换到”Dalvik字节码，需要编译工具来完成，这一任务由DX或D8承担。DX是第一代工具，D8是第二代工具，相对于DX，D8在编译速度、产物大小、代码性能方面，全面超越DX，官方blog中，给出的编译速度收益约25%，产物大小收益约5%：

在优酷这边，由DX升级到D8后，apk包大小降低约9%（额外对dex合并进行了优化，dex数量降低，对包大小收益较大），由此冷启动阶段dex加载耗时也降低了50ms。编译耗时无法做拆解性统计，但是肯定有正向收益。

此外，对于上一小节讲到的脱糖处理，DX并不包含，因此需要单独的前置脱糖处理，而D8则可以在转换过程中，直接进行脱糖，在速度和脱糖支持的全面性上，均有提升。

1.4 java资源

ja