Dagger自动注入框架PopStar

PopStar 1.0已经完成，本文主要阐述PopStar开发的构想和实现方案。
注：新项目建议使用dagger.android包下内容。

---

DI

DI (Dependency injection)，即依赖注入。是我们在开发中经常使用的一种设计模式。简单的描述就是，依赖不在宿主中初始化，而是使用外部传入或工厂生成的方式。这样的设计模式带来如下几点好处：

• 依赖的注入和配置独立于组件之外。
• 因为对象是在一个独立、不耦合的地方初始化，所以当注入抽象方法的时候，我们只需要修改对象的实现方法，而不用大改代码库。
• 依赖可以注入到一个组件中：我们可以注入这些依赖的模拟实现，这样使得测试更加简单。应用在Android开发中，开发者不再需要关注依赖的的生命周期和作用域，这些工作都交由框架管理。这种方式是非常棒的。

Java中有名的框架有JBoss Seam、Spring Framework、Google Guice和Google Dagger2 。PopStar基于Dagger2。

Dagger2

Dagger由Square开发，符合JSR-330规范。后由Google fork，开发了Dagger2 。Dagger2受Google AutoValue项目启发，采用生成+手写结合的方式实现了0反射，可跟踪，可混淆的框架。但这种方式同样带来缺乏动态性的问题，当使用范围扩大，会出现疲于重复手写component， module数量过多和scope无法管理等问题。

PopStar采用了apt+少量反射的模式，生成component和module的全部代码，scope限制在Application，Activity，Fragment三个层面（view的scope和容器相同）。同时对custom annotation做支持。让双手从重复劳动中解放出来。

PopStar

• Component和Module

component的声明事实上是重复的相同操作，可以用模板解决一部分问题，但在使用时还是需要我们手动调用如下类似代码：

DaggerInjectActivity_DaggerComponent.builder().injectActivity_DaggerModule(new InjectActivity_DaggerModule()).build().inject(this);

这完全是没有必要的，在Android中，我们都会抽取BaseActivity作为一切Activity的父类，他承载了一部分初始化操作。由于Dagger2的限制我们无法直接在BaseActivity中简单声明。PopStar采用apt生成的方式解决了这个问题。当然生成是在编译时，所以不用担心性能和调试问题。具体步骤：

• 构造Dagger2标准Component。构造DaggerInjector，用于真正的注入生成。
• 记录class -> DaggerInjector 的Mapping。
• 调用时查找，进行注入。

module的构造与component不同，他更复杂，是生命周期管理和域管理的载体。先来看一下构想的module结构:

@Module
public class InjectActivity_DaggerModule {
    protected final Provider provider;

    public InjectActivity_DaggerModule(Activity activity) {
        this.provider = Provider.get(activity);
    }

    @Provides
    public Activity provideActivity() {
        return provider.activityScope().getScope();
    }

    @Provides
    public Application provideApplication() {
        return provider.applicationScope().getScope();
    }

    @Provides
    public A provideA() {
        A a = provider.applicationScope().getInstance(A.class);
        AProxy.proxy(a, provideActivity());
        return a;
    }

    @Provides
    public TestInterface provideTestInterface() {
        return provider
                .activityScope()
                .getSingleton(TestInterface.class);
    }
}

module类中的provide方法都交给了provider去处理，provider则是通过自身及此例中的InjectActivity得到的。

• Scope和Provider

上面说到，Scope在PopStar中只有三个。他们三者的可见性如下图：

dagger.png

其中Application的Scope最小，他只能看到自己范围内的实例，而Fragment最大，他能看到对应Activity Scope和Application中的全部内容。这样做的好处在于，每个域中的内容不需要关心外部是谁在操作，他只需要根据自己的生命周期来管理对应域下的实例。

具体实现，我们就是通过上面module中provider。整个程序维护一个静态mapping，他是scope->provider的映射。provider中维护着自己域下的实例的生命周期，包括：调用者的引用，单例，子域和普通对象的创建。

如果父类携带了域，那么子类直接继承了父类域中的元素。如果采用多态，你需要显式的声明implement和interface的关系。

• Proxy和Custom Annotation

在开发中会遇到这样一种情况，某些类需要在声明后执行特定操作。PopStar希望提供几个方式解决。一种就是直接继承生命周期接口，在对应函数中执行操作。或者声明一个Proxy。Proxy会在编译时扫描module中的对应类和他的子类的provide方法，调用Invoked函数。

@PSProxy(IPresenter.class)
public class PresenterProxy {
    @Invoked(injector = Activity.class)
    public static void proxy(IPresenter presenter, Activity activity) {
        presenter.attach(activity);
    }
}

custom annotation提供一种初始化的方式，例如retrofit的动态代理。我可以这么声明：

@Provide(typeAnnotations = {Api.class})
public static  T provideApi(InjectedField field) {
    return retrofit.create(field.getType());
}

结语

PopStar解决了动态性的问题，并且使用起来非常简单，只需要简单声明。

@Inject
protected Provider testInterface;
@Inject 
protected Application application;
@Inject 
protected A a;

---

声明

此篇文章是16年12月在红星内部发表的，发到这里给大家提供下思路。

Basic Knowledge:

stackoverflow what is di
Dagger2
Tasting Dagger2 on Android