使用方式类似于 ButterKnife ，在 Activity 中我们使用 Inject 来注解一个全局变量：
@Inject User user;
然后 onCreate 方法中需要调用 inject(Activity activity) 方法实现注入：
RouterInjector.inject(this);
这样我们就可以获取到前面通过 Router 跳转的传参了。
由于篇幅限制，加上为了便于理解，这里只贴出了极少部分 Router https://github.com/BaronZ88/Router 框架的源码。希望进一步了解 Router 实现原理的可以到 GiuHub 去翻阅源码，Router 的实现还比较简陋，后面会进一步完善功能和文档，之后也会有单独的文章详细介绍。源码地址：https://github.com/BaronZ88/Router
资源名冲突
对于多个 Bussines Module 中资源名冲突的问题，可以通过在 build.gradle 定义前缀的方式解决：
defaultConfig {
...
resourcePrefix "new_house_"
...
}
而对于 Module 中有些资源不想被外部访问的，我们可以创建 res/values/public.xml，添加到 public.xml 中的 resource 则可被外部访问，未添加的则视为私有：
重复依赖
模块化的过程中我们常常会遇到重复依赖的问题，如果是通过 aar 依赖， gradle 会自动帮我们找出新版本，而抛弃老版本的重复依赖。如果是以 project 的方式依赖，则在打包的时候会出现重复类。对于这种情况我们可以在 build.gradle 中将 compile 改为 provided，只在最终的项目中 compile 对应的 library ；
其实从前面的安居客模块化设计图上能看出来，我们的设计方案能一定程度上规避重复依赖的问题。比如我们所有的第三方库的依赖都会放到 OpenSoureLibraries 中，其他需要用到相关类库的项目，只需要依赖 OpenSoureLibraries 就好了。
模块化过程中的建议
对于大型的商业项目，在重构过程中可能会遇到业务耦合严重，难以拆分的问题。我们需要先理清业务，再动手拆分业务模块。比如可以先在原先的项目中根据业务分包，在一定程度上将各业务解耦后拆分到不同的 package 中。比如之前新房和二手房由于同属于 app module，因此他们之前是通过隐式的 intent 跳转的，现在可以先将他们改为通过 Router 来实现跳转。又比如新房和二手房中公用的模块可以先下放到 Business Component Layer 或者 Basic Component Layer 中。在这一系列工作完成后再将各个业务拆分成多个 module 。
模块化重构需要渐进式的展开，不可一触而就，不要想着将整个项目推翻重写。线上成熟稳定的业务代码，是经过了时间和大量用户考验的；全部推翻重写往往费时费力，实际的效果通常也很不理想，各种问题层出不穷得不偿失。对于这种项目的模块化重构，我们需要一点点的改进重构，可以分散到每次的业务迭代中去，逐步淘汰掉陈旧的代码。
各业务模块间肯定会有公用的部分，按照我前面的设计图，公用的部分我们会根据业务相关性下放到业务组件层（Business Component Layer）或者基础组件层（Common Component Layer）。对于太小的公有模块不足以构成单独组件或者模块的，我们先放到类似于 CommonBusiness 的组件中，在后期不断的重构迭代中视情况进行进一步的拆分。过程中完美主义可以有，切记不可过度。
以上就是我在模块化探索实践方面的一些经验，不住之处还望大家指出。
