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

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

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

问题简述

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

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

1
2
3
4
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,

然后,他向壳工程提供的class文件SearchResultListAdapter.class就是106,

这样子上线,估计又要P1故障警告⚠️了!到此我们可以先得出结论,

谨慎修改常量值,一旦修改了一个常量,依赖了当前aar的所有项目,都要把当前aar升到最新版本,确保向壳工程提供的class文件是正确的。

哈迪在壳工程看了下,依赖了基础工程1并且用到了常量TYPE_RECOMMEND_TAB的上层工程,还有四五个,涉及了六七个类,这要是忘了改,就真的是大型翻车现场了…

解决

sorry,哈迪也还没想到很好的工程化的方式去避免,只能先小记一下加深印象,恳请大佬们一起出谋划策!

ps:最近入秋了,大伙注意温差!身边好多同事感冒了😷


欢迎关注原创技术公众号:哈利迪ei