项目组件化之遇到的坑

在MDCC中冯森林老师的《回归初心,从容器化到组件化》,为我们这些没有那么多精力折腾黑科技开发者们打开了另一扇门。

需要做的事情很简单,就是将业务解耦模块化,让这个模块在debug下作为application单独运行,而在release下就作为library。

这篇其实只是写一下我碰到的问题,记录一下。

组件化套壳思路

在这要感谢一下低调的二帅 ( https://github.com/zzz40500 ),提供了合并manifest的思路。

以及小梁提供的demo示例( https://github.com/liangzhitao/ComponentizationApp )

项目组件化之遇到的坑_第1张图片

main同级下有一个debugrelease目录,在用命令行gradle assembleDebug 就会把main中的manifest和debug中的manifest合并。

当debug的时候就会使用debug的manifest中的activity作为入口启动,这样在开发的时候只需要在当前模块编译开发即可。

release的时候module就是library了,而入口就是app。

组件化遇到的坑

因为我们项目重度依赖apt以及一些编译中生成的库,像databindingdaggerretrolambda

我们把dagger一些公用的component以及module都随着业务module一起抽离了出来。

填坑之databinding

之后抽离databinding的时候遇到了蛋疼的问题,我们使用databinding直接get之前set进去的variable,结果这样会导致在databidning在library中编译出错,其中缘由可以另外移驾至 → http://blog.zhaiyifan.cn/2016/10/11/data-binding-in-library-module/

查错

databinding生成出错后,会连带dagger报错,这个时候报错又毫无头绪。
需要使用命令行,将编译的log输出到文件中,因为console输出log有行数限制的。
gradle assembleDebug --debug --info > log.txt 2>&1

xml

在抽离module的时候用的AndroidStudio(大坑)的refactor,但是不支持对xml的修改,所以databinding涉及的xml中的依赖都要手动修改过来。

生成的BR

有多个module都是使用了databinding,那么这个时候会有对于BR依赖的问题,你要自己区分你使用的是依赖module的BR还是当前module的BR

databinding组件化总结:只要一处没修改好,所有编译都是红的,反正都是泪~

retrolambda

db填完后,发现retrolambda提示生成class出错,但是它又不是apt的,根据错误提示找了许久,提示升级版本,之前是3.2.5,升级到3.3.0之后编译OK,然后在阿翟那边编译失败,又降了回来,现在又可以编译了,没有复现问题,推测是dagger依赖出现编译失败,导致了retrolambda生成失败。

升级到3.3.0后提示的错反而是NoSuchMethodError,真是扯犊子。

dagger

这位大哥,只要有一个地方错,满屏幕都是它报错,所有该生成的都没生成。而且错误提示还不友好,看错误日志的最上面,有没有提示什么。如果没有,那么就恭喜了,是不是什么地方写漏了回去慢慢看吧。

AndroidStudio

升级到2.2后,在module中开发,经常会智能提示失败,然后莫名其妙标红,命令行编译又是通过的,反正我就是关闭再重启,其他东西点了都没什么用,都是大爷MD!。


再次感谢冯森林老师提供的思路,让我也可以高大上的尝试一次组件化,虽然重构挺痛苦的,但是学习到的还是很多。

欢迎大家加入QQ实践群(568863373)一起讨论,也可以关注我们的公众号:魔都三帅
项目组件化之遇到的坑_第2张图片

你可能感兴趣的:(项目组件化之遇到的坑)