Dagger2流行已经有一段时间了,是一个很强大的依赖注入框架。以前接触过Spring的IOC,了解过它的实现原理是用反射实现的。而移动端是对资源很敏感的,Dagger2作为移动端的一个主流框架,肯定不会用一样的套路去玩。所以抽空研究了一下它的实现方式。
从一个最简单的例子入手
public class ActivityLogin extends Activity implements ILoginView {
private static final String TAG = "ActivityLogin_";
@Inject
LoginPresenter loginPresenter;
Button loginBtn;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main2);
DaggerMyComponent.create().inject(this);
loginPresenter.attachView(this);
loginBtn = findViewById(R.id.btn_login);
loginBtn.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
loginPresenter.login();
}
});
}
@Override
public void onLoginSuccess() {
Log.i("MyModule", TAG + "LoginSuccess_");
Toast.makeText(this, "ActivityLogin onLoginSuccess", Toast.LENGTH_LONG).show();
}
@Override
public void onLoginError(String errorMsg) {
}
}
上面的例子是一个MVP的例子:要在一个Activity中注入一个LoginPresenter(在上面加了@Inject 注解)。来看LoginPresenter:
public class LoginPresenter extends BasePresenter<ILoginView> {
private static final String TAG = "LoginPresenter";
@Inject
public LoginPresenter() {
}
@Override
public void onDetach() {
Log.i("MyModule", TAG+" "+hashCode()+" detach_" + getActivityNameBelongTo());
}
@Override
public void onAttach() {
Log.i("MyModule", TAG+" "+hashCode()+" attach_" + getActivityNameBelongTo());
}
public void login() {
Log.i("MyModule",TAG+" http request ...");
getView().onLoginSuccess();
}
}
需要注入的类,LoginPresenter的构造函数上也加了@Inject注解。
然后看Component:
@Component()
public interface MyComponent {
void inject(ActivityLogin activityLogin);
}
可以看到MyComponent是个接口,@Component注解是可以带参数的(Class
看看生成的文件
工程的目录结构:
build/generate/source/apt/debug/xxx(包名)下的结构:
可以看到,Dagger2帮我们生成了几个文件:
- 被注入依赖类,也就是ActivityLogin 对应一个ActivityLogin_MembersInjector类,以“XXX_MembersInjector”命名(XXX是被注入依赖类的类名),这个类会放在和ActivityLogin同一个包目录下。
- 依赖的类,也就是LoginPresenter ,对应一个LoginPresenter_Factory类,以“XXX_Factory”命名(XXX是依赖的类的类名,放在了LoginPresenter同一个包目录下。
- Component注解接口对应的一个类,以“DaggerXXX”命名(XXX师Component注解对应的接口类名),同样放在了对应的目录下。
我们使用的时候是DaggerXXXX.creat().inject(this),看下这个生成的DaggerXXXX:
public final class DaggerMyComponent implements MyComponent {
private Provider<LoginPresenter> loginPresenterProvider;
private MembersInjector<ActivityLogin> activityLoginMembersInjector;
private DaggerMyComponent(Builder builder) {
assert builder != null;
initialize(builder);
}
public static Builder builder() {
return new Builder();
}
public static MyComponent create() {
return builder().build();
}
@SuppressWarnings("unchecked")
private void initialize(final Builder builder) {
this.loginPresenterProvider =
LoginPresenter_Factory.create(MembersInjectors.<LoginPresenter>noOp());
this.activityLoginMembersInjector =
ActivityLogin_MembersInjector.create(loginPresenterProvider);
}
@Override
public void inject(ActivityLogin activityLogin) {
activityLoginMembersInjector.injectMembers(activityLogin);
}
public static final class Builder {
private Builder() {}
public MyComponent build() {
return new DaggerMyComponent(this);
}
/**
* @deprecated This module is declared, but an instance is not used in the component. This method is a no-op. For more, see https://google.github.io/dagger/unused-modules.
*/
@Deprecated
public Builder myModule(MyModule myModule) {
Preconditions.checkNotNull(myModule);
return this;
}
}
}
这种情况是最简单的(依赖的类LoginPresenter没有其他依赖),所以这时候分析文件结构最清晰:
- DaggerMyComponent 实现了 MyComponent,也就说有了要Inject的宿主类,因为MyComponent这个接口;
- 有个用来装配Module的Builder,也就是说Module可以自己手动指定;
- 每个依赖的类如LoginPresenter都会有个Provider如Provider来包装它;每个被依赖的类如ActivityLogin都会有个MembersInjector来包装它;
- 如果依赖的类如LoginPresenter没有再继续有别的依赖,那么这个Provider由依赖的类的Factory生成;
- MembersInjector 由对应生成的ActivityLogin_MembersInjector来生成;
- 最后的inject其实是MembersInjector代理的。
贴出来LoginPresenter_Factory:
public final class LoginPresenter_Factory implements Factory<LoginPresenter> {
private final MembersInjector<LoginPresenter> loginPresenterMembersInjector;
public LoginPresenter_Factory(MembersInjector<LoginPresenter> loginPresenterMembersInjector) {
assert loginPresenterMembersInjector != null;
this.loginPresenterMembersInjector = loginPresenterMembersInjector;
}
@Override
public LoginPresenter get() {
return MembersInjectors.injectMembers(loginPresenterMembersInjector, new LoginPresenter());
}
public static Factory<LoginPresenter> create(
MembersInjector<LoginPresenter> loginPresenterMembersInjector) {
return new LoginPresenter_Factory(loginPresenterMembersInjector);
}
}
可以看到LoginPresenter_Factory 会有一个MembersInjector 成员,这个成员是构造函数依赖进来的;并且get方法里,有new的动作,也就是说,如果依赖的类是无参构造,最后依赖对象的实例化是在依赖对应的Factory中生成的。
看ActivityLogin_MembersInjector:
public final class ActivityLogin_MembersInjector implements MembersInjector<ActivityLogin> {
private final Provider<LoginPresenter> loginPresenterProvider;
public ActivityLogin_MembersInjector(Provider<LoginPresenter> loginPresenterProvider) {
assert loginPresenterProvider != null;
this.loginPresenterProvider = loginPresenterProvider;
}
public static MembersInjector<ActivityLogin> create(
Provider<LoginPresenter> loginPresenterProvider) {
return new ActivityLogin_MembersInjector(loginPresenterProvider);
}
@Override
public void injectMembers(ActivityLogin instance) {
if (instance == null) {
throw new NullPointerException("Cannot inject members into a null reference");
}
instance.loginPresenter = loginPresenterProvider.get();
}
public static void injectLoginPresenter(
ActivityLogin instance, Provider<LoginPresenter> loginPresenterProvider) {
instance.loginPresenter = loginPresenterProvider.get();
}
}
ActivityLogin_MembersInjector 会有一个Provider 的成员,这个成员是构造的参数,并且injectMembers方法持有被注入依赖类(ActivityLogin)的实例引用,instance.loginPresenter = loginPresenterProvider.get()真正做了“桥梁”,为ActivityLogin中的loginPresenter赋值。
梳理一下几个类的关系
简单的总结就是,DaggerMyComponent通过Factory获取了Provider包装的依赖的对象(Provider的实例)然后用它生成了ActivityLogin_MembersInjector的实例,最后这个实例包含了被依赖和依赖对象的引用,就可以完成搭桥了。
给LoginPresenter加依赖
@Inject
public LoginPresenter(Dependence1 dependence1) {
}
如果这时候什么都不做,编译的时候会报错:
这是因为Dagger2并不知道Dependence1 的实例要从哪里来。对Dependence1做处理:
public class Dependence1 {
@Inject
public Dependence1(){}
}
给构造函数加Inject注解。
描述下变化:
- 对应目录下多了一个Dependence1_Factory的类:
public enum Dependence1_Factory implements Factory<Dependence1> {
INSTANCE;
@Override
public Dependence1 get() {
return new Dependence1();
}
public static Factory<Dependence1> create() {
return INSTANCE;
}
}
这是个枚举单例,实现了Factory。可以看到,这里对Dependence1做了实例化(new 动作)
- DaggerMyComponent中的initalize方法:
this.loginPresenterProvider =
LoginPresenter_Factory.create(
MembersInjectors.<LoginPresenter>noOp(), Dependence1_Factory.create());
对比之前,就是create方法多加了一个参数,这个参数由Dependence1_Factory提供。
其他都没有动。
对应的示意图:
所以基本可以看出:
- 生成的DaggerXXX类中会持有所有的注入依赖类对象的Provider和被注入对象的MemberInjector;
- 所有的提供依赖的类都会被包装成Provider,所有需要注入依赖的类都被包装成MemberInjector;
- 需要注入依赖的MemberInjector会通过create方法把所有依赖的Provider传进去,有几个依赖,create就有几个参数;
- 所有Provider的实例都是通过对应的Factory提供的。
小结
这只是一个最简单的使用Dagger2的例子,这样可以很清晰的搞清楚Dagger2为我们生成这么多文件它们之间的关系。后面会把其他的注解也分析,整体的分析思路是一样的。这一趟分析个人感觉有几个很nice的设计思路:
@Inject 修饰的成员不能是private的,因为生成的桥梁类MemberInjector和被注入类在一个包目录下面,private是不能访问的。放在含有注解的类所在包目录下面,可以最大程度保护成员的访问权限,不然只能是public;
DaggerXXX用了外观模式,拿到了本来只能在包目录下才能访问的依赖实例;
- DaggerXXX实现了标注了@Component 的接口,这个接口指定了哪些类是需要注入依赖的类,所以我们在要注入依赖的类里使用DaggerXXX.create().inject(this)才这么方便。
使用的设计模式: 外观模式、 工厂模式、 单例模式