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

嗨，我是哈利迪~好久不见，最近大促比较忙，人也变懒了没啥时间写文章肝源码...本文做个小记，记录一个多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键点击TYPERECOMMENDTAB可见他的值是新的306，然而把他赋值给type后，type的值居然是106，这是什么鬼！





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





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



揭开真相



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





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





这时在壳工程不管搜DATA_TYPE.java还是DATA_TYPE.class，毋庸置疑常量TYPERECOMMENDTAB的值都是新的306，那问题出在哪呢？出在依赖了基础工程1的业务工程1，即306只对壳工程可见，对于业务工程1来说，TYPERECOMMENDTAB仍然是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