在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！。
再次感谢冯森林老师提供的思路，让我也可以高大上的尝试一次组件化，虽然重构挺痛苦的，但是学习到的还是很多。
