踩坑记 | 多aar下修改常量的一个小坑

Holiday

发布于 2020-09-22 02:03:32

48700

代码可运行

文章被收录于专栏：哈利迪ei哈利迪ei

运行总次数：0

代码可运行

嗨，我是哈利迪~好久不见，最近大促比较忙，~~人也变懒了~~没啥时间写文章肝源码…本文做个小记，记录一个多aar下修改常量引起的问题，希望能给大家避避坑~

本文约0.9k字，阅读大约3分钟。

问题简述

App结构大致如下，各工程以aar形式进行依赖，壳工程以打平的形式依赖所有业务工程和基础工程的aar，避开依赖传递的问题，还可以加快开发过程的构建速度，

因业务需要，哈迪把基础工程1的1.0版本的一个常量TYPE_RECOMMEND_TAB从106改成了306，

public class DATA_TYPE {
    //public static final int TYPE_RECOMMEND_TAB = 106;
    public static final int TYPE_RECOMMEND_TAB = 306;
}

然后推代码，打出一个新的aar，版本为1.1，壳工程使用1.1版本，运行后debug如下，

在debug一个业务工程1的类SearchResultListAdapter时，发生了神奇的一幕，alt键点击TYPE_RECOMMEND_TAB可见他的值是新的306，然而把他赋值给type后，type的值居然是106，这是什么鬼！

马上联想到，是不是编译期常量自动替换的问题呢，在壳工程搜一下SearchResultListAdapter.class（注意是class文件），

果然，前面debug看到的只是表象，实际上我们就是给type赋值了106，那么问题来了，这个106是哪里来的，我明明已经改掉了啊？

揭开真相

其实问题并不难找，前边提到了壳工程会以打平的形式依赖业务工程和基础工程的aar，如下，

当我们修改了基础工程1的常量后，进行aar升级，壳工程更新依赖版本，从1.0变成1.1，

这时在壳工程不管搜DATA_TYPE.java还是DATA_TYPE.class，毋庸置疑常量TYPE_RECOMMEND_TAB的值都是新的306，那问题出在哪呢？出在依赖了基础工程1的业务工程1，即306只对壳工程可见，对于业务工程1来说，TYPE_RECOMMEND_TAB仍然是106，我去怎么越说越绕…上图！

壳工程把基础工程1升级到1.1，看见了306；但是在业务工程1里，他依赖的还是基础工程1的旧的1.0版本，所以对他来说，他看到的TYPE_RECOMMEND_TAB仍然是106，因此，他的类SearchResultListAdapter被编译成class后，由于编译期常量自动替换的设计，class文件里就会写死106，