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中只有三个。他们三者的可见性如下图：
其中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> T provideApi(InjectedField field) {
return retrofit.create(field.getType());
}
结语
PopStar解决了动态性的问题，并且使用起来非常简单，只需要简单声明。
@Inject
protected Provider<TestInterface> testInterface;
@Inject
protected Application application;
@Inject
protected A a;
声明
此篇文章是16年12月在红星内部发表的，发到这里给大家提供下思路。
Basic Knowledge:
