项目组件化之遇到的坑

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

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

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

组件化套壳思路

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

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

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

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

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

组件化遇到的坑

因为我们项目重度依赖apt以及一些编译中生成的库，像databinding、dagger、retrolambda。

我们把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）一起讨论，也可以关注我们的公众号：魔都三帅