在上一篇文章中Android 模块化探索和实践（1）：基本思路讲到模块化中使用Dagger2会有些特殊的坑，这篇文章我就争取把这个坑填上。
问题
在采用普通（非模块化）架构的项目中使用Dagger2，一般会通过ApplicationComponent、ActivityComponent、FragmentComponent等方式来控制所注入对象的生命周期，其生命周期分别是Application全局单例、Activity局部单例和Fragment局部单例，很自然的，只需要处理好Component之间的依赖关系，并在Application和Activity、Fragment中处理好Component的创建逻辑即可。
在模块化项目中，Dagger2却有不一样的使用，我还是以上一篇文章的架构设计为例，其问题主要表现在两点：
- 如何保证BaseCore中的某些类全局单例，比如那些存储管理、网络组件等；
- 同一个业务模块，其在Debug时是独立的Application，在Release时又是Library，如何让业务模块中的Dagger2管理不受Application变化的影响；
- 如何保证业务模块中的某些类模块内单例
解决方案
先来看一下模块化中的Dagger2注入需求图
无论BaseCore还是各个业务模块，都存在这样的单例类和非单例类，需要注入到上层应用层，其中BaseCore是全局注入，而业务模块中只注入该模块内，其他模块无法注入。
为满足这样的需求，我采用的解决方式是：
- 对Component进行分层设计，明确Component之间的依赖关系，控制不同层次Component的生命周期，以达到Component生命周期和Application、Activity、Fragment等一致；
- 不同层次的Component设计不同的scope进行标注，通过scope可以保证在本层次Component注入的实例是单例的
这个方案总结下来就是：合理控制Component的创建，使得Component和需要注入的对象（Application、Activity等）生命周期一致；不同层次Component采用scope标注，以实现Component内局部单例。
方案的架构图如下：
BaseCore中对单例类的处理如下：
@Module
public class SingletonModule {
@Provides
@Singleton
RxBus provideRxBus() {
return RxBus.getInstance();
}
...
}
@Module(includes = SingletonModule.class)
public class AppModule {
private final Application application;
public AppModule(Application app) {
application = app;
}
@Provides
@Singleton
Application provideApplication() {
return application;
}
@Provides
@Singleton
Context provideContext() {
return application;
}
}
@Singleton
@Component(modules = {AppModule.class, SingletonModule.class})
public interface BaseAppComponent {
RxBus rxBus();
...
}
对非单例类的处理如下：
@Module
public class BaseViewModule {
private final Activity activity;
public BaseViewModule(Activity activity) {
this.activity = activity;
}
@Provides
@PerView
Activity provideActivity() {
return this.activity;
}
@Provides @PerView
JsInterface jsInterface() {
return new JsInterface(activity);
}
}
@PerView
@Component(modules = BaseViewModule.class)
public interface BaseViewComponent {
Activity activity();
...
}
业务模块中对单例类的处理：
@Module
public class BusinessAModule {
@Provides
@AppScope
BusinessAManager provideBusinessAManager(Applition app) {
return BusinessAManager.getInstance(app);
}
...
}
@AppScope
@Component(dependencies = BaseAppComponent.class, modules = {BusinessAModule.class})
public interface BusinessAAppComponent extends AppComponent {
/* Note: 必须显式的提供BaseAppComponent所能提供的对象
* 理由：BaseAppComponent中的对象对于BusinessAAppComponent是可见的，
* 但是对于依赖于BusinessAAppComponent的上层ActivityComponent 是不可见的，所以需要再次显式的声明
*/
RxBus rxBus();
...
}
业务模块中的非单例类可以在 BusinessAActivityModule 中提供。
经过以上的处理，问题来了，如何在业务层中的Activity等目标类中inject上述对象呢？我们来看业务模块中的 ActivityComponent：
@PerView
@Component(dependencies = {BusinessAAppComponent.class}, modules = BaseViewModule.class)
public interface ActivityComponent extends android.databinding.DataBindingComponent {
void inject(MainActivity activity);
...
}
这样，你就可以在MainActivity中通过ActivityComponent 注入BaseAppComponent、BusinessAAppComponent、BaseViewModule暴露出来的对象了。这里有个细节，ActivityComponent继承自DataBindingComponent，之所以要这么做是为了满足在Databinding中使用Dagger2依赖注入。
最后，还有个关键问题：如何处理Debug和Release模式下AppComponent初始化问题？只有保证了AppComponent的单例，才能保证通过其注入对象的单例。
我在BaseCore上定义一个接口：
public interface AppComponent {}
不同模块中的BusinessAAppComponent、BusinessBAppComponent继承它
public interface BusinessAAppComponent extends AppComponent {}
public interface BusinessBAppComponent extends AppComponent {}
再定义一个接口：
public interface AppModuleComponentDelegate { AppComponent initAppComponent();}
在BaseCore中定义一个BaseModuleKit，目的在于获取BaseAppComponent：
public class BaseModuleKit {
private static BaseModuleKit instance;
private BaseAppComponent component;
public static BaseModuleKit getInstance() {
if (instance == null) {
synchronized (BaseModuleKit.class) {
if (instance == null) {
instance = new BaseModuleKit();
Application application = BaseApplication.getInstance();
instance.component = DaggerBaseAppComponent.builder().appModule(new AppModule(application)).build();
}
}
}
return instance;
}
public BaseAppComponent getComponent() {
return component;
}
}
再定义一个BusinessModuleKit, 目的在于获取到BusinessAAppComponent：
public class BusinessAModuleKit {
private static BusinessAModuleKit instance;
private Application application;
private AppComponent component;
public static BusinessAModuleKit getInstance() {
if (instance == null) {
synchronized (BusinessAModuleKit.class) {
if (instance == null) {
instance = new BusinessAModuleKit();
}
}
}
return instance;
}
public BusinessAModuleKit init(Application application, AppModuleComponentDelegate appModuleComponentDelegate) {
this.application = application;
this.component = appModuleComponentDelegate.initAppComponent();
return this;
}
public Application getApplication() {
return application;
}
public AppComponent getComponent() {
return component;
}
}
以上的思路就是：通过BaseModuleKit保证BaseAppComponent单例；通过BusinessAModuleKit保证BusinessAAppComponent单例；ActivityComponent的创建需要依赖于这两个，必须保证这两个是单例。
下面再讲述一下BusinessAAppComponent 和 ActivityComponent的创建。
在业务模块中的BusinessAApplication 中：
private AppModuleComponentDelegate aAppComponentDelegate = new AppModuleComponentDelegate() {
@Override
public AppComponent initAppComponent() {
BusinessAAppComponent appComponent = DaggerBusinessAAppComponent.builder()
.baseAppComponent(BaseModuleKit.getInstance().getComponent())
.build();
return appComponent;
}
};
BusinessAModuleKit.getInstance().init(this, aAppComponentDelegate);
在MainActivity中：
private ActivityComponent activityComponent;
public ActivityComponent activityComponent() {
if (activityComponent == null) {
activityComponent = DaggerActivityComponent.builder()
.businessAAppComponent((BusinessAAppComponent) BusinessAModuleKit.getInstance().getComponent())
.baseViewModule(new BaseViewModule(this))
.build();
}
return activityComponent;
}
// 注入
activityComponent().inject(this);
至此，Dagger2在模块化中的处理就介绍完了，讲的有点乱，希望没有把大家绕晕。
此外还有几个有意思的问题有待进一步的探究：
- 如果要进一步细化业务模块的生命周期，比如增加业务模块的注册、卸载，在这种情况下，业务模块中的Dagger2如何处理？
- 做成一个开源库，方便在模块化中直接引入
先挖个坑，后面有时间争取补上！
。
。
。
。
终于把Demo给大家补上了，Github: DaggerModules，Demo目前还比较简单，只具备基本功能，欢迎大家Star or Fork