更加强大的Dagger2

1996次阅读  |  发布于5年以前

更加强大的Dagger2

著名的依赖注入库Dagger的2.0版本变为生产版本只是一个时间问题，这似乎给了我一个写一篇关于它的文章的好理由。

Dagger 1

在这里，先做一个小小的历史回顾，Dagger是由Square公司的几个十分优秀的开发人员在2012年创建的，他们觉得将依赖注入应用到Java中是一个非常棒的点子，但是却觉得当时使用的Guice库（当时的标准）的速度稍微有点慢。所以，他们开发了一个依赖于基于注解的代码生成（JSR-330），拥有着和Guice相似的API，但是性能更强、更加灵活的库。

Dagger的工作原理就是通过声明一些module，这些module里包括了所有你想要注入的依赖的提供者方法（provider method）， 把这些module加载到一个对象图谱（object graph）里，最终将图谱中的内容根据需要注入到对象（target）中。 足够简单的结构（当然实现起来还是不那么简单的）有利于开发者解耦他们的代码,并且通过把初始化代码移动到由库自动生成的injector中,从而删掉每个类开始的地方那些丑陋的工厂类初始化代码。

然而，伴随着明显的优点（这些优点足以让大部分的Android开发者选择Dagger作为他们开发新项目中选择使用的第一个库），也存在着一些明显的问题，都是一些不可以简单地被一个或者两个的pull request就解决掉的问题，因为这些问题都是与整个底层架构相关的。

因而，在Github的问题跟踪系统中，由于上述问题导致的一些issues，都被标记为“它就是这样的，这个问题会在Dagger2中解决”

Dagger 2

时间快进到现在，Google的core libraries团队（Guava的创造者）与原来的Square的创建者一起推出了新一代的Dagger，并在一个月内就发布了生产版本

新的release版本，像之前所承诺的一样，解决了老版本的许多问题：

Usage 用法

虽然Dagger也可以用在任何的Java工程中，但是在示例代码中，我们将专注于它在Android平台上的应用。不过，这些代码都可以很容易的就被改写，以用于其它地方，比如说，改写为服务器后端相关的代码。

Module

Dagger2中基本保持不变的部分是module。你仍然需要在这里定义可被注入的依赖的提供者方法（provider methods）。比如说，我们需要注入的是SharedPreferences对象。

@Module
public class ApplicationModule {  
private Application mApp;

public ApplicationModule(Application app) {
mApp = app;
}

@Provides 
@Singleton
SharedPreferences provideSharedPrefs() {
return PreferenceManager.getDefaultSharedPreferences(mApp);
}
}

类似的，你可以提供（provide）其他的东西（并不是所有的，只是提供一些想法）

Component

眼尖的读者可能发现了在@Module注解中，injects = {}参数不见了，那是因为Dagger2不再需要用到这个参数了。取而代之的是，"component"的概念，component是用来连接module和要注入依赖的对象（target）之间的桥梁。

@Singleton
@Component(modules = {ApplicationModule.class})
public interface ApplicationComponent {  
void inject(DemoApplication app);
void inject(MainActivity activity);
}

所以，你仍然需要注明（define）你要注入依赖的对象（target），但是，与之前不同的是，如果你现在不注明的话，在编译时就会提示"cannot find method"错误，而这个错误在以前，则是一个隐秘的运行时错误，只有在运行时才会报错。

Application 应用

下一步，我们要了解的是你的component的容器。具体的方式由你的应用来决定，你可以选择用更复杂的方式保存你的components，但是对于这个例子来说，一个简单的保存在application中的component就足以说明情况了。

public class DemoApplication extends Application {  
private ApplicationComponent mComponent;

@Override 
public void onCreate() {
super.onCreate();
mComponent = DaggerApplicationComponent.builder()
.applicationModule(new ApplicationModule(this))
.build();
}

public ApplicationComponent getComponent() { 
return mComponent;
}
}

这里没有什么新的东西：只是之前我们创建并初始化的的是对象图谱（ObjectGraph），而现在，我们则会创建并初始化对应的component。

注意：你很有可能会在某个时候想到这个问题，我在这先提前解释一下。上面例子中的DaggerApplicationComponent是一个编译时生成的类（命名方式是 Dagger%COMPONENT_NAME%），只要你对你的component做了改动，就需要重新编译工程，通过了，这个类才会被生成。所以，如果你找不到这个类，点击你的IDE的"Rebuild Project"，如果编译不出错的话，它就会出现了。类似的，applicationModule()方法对应于你的module的名字。

Injection 注入

终于，经过前面几个部分为注入进行的准备后，我们来到了用到它们的地方了，我们要在activity中注入一个SharedPreferences对象。

public class MainActivity extends Activity {  
@Inject SharedPreferences mSharedPrefs;

@Override 
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
((DemoApplication) getApplication()).getComponent().inject(this);

mSharedPrefs.edit().putString(“status”, “success!”).apply();
}
}

和期待的一样，@Inject注解的使用没有任何改变，只是注入本身发生了一点变化。

这里有一点小小的不便，是由于inject()方法是强类型关联的，这个我们在后面会讨论到。

Named injections 命名注入 如果你有几个对象是同一类型的，比如说两个不同的SharedPreferences实例（可能是指向了不同的文件），这时候，我们可以怎么做？ 这时候，我们就需要用到命名注入了。只要在module的提供者（provider）里像下面一样使用@Named注解

@Provides 
@Named(“default”) 
SharedPreferences provideDefaultSharedPrefs() { … }

@Provides 
@Named(“secret”)
SharedPreferences provideSecretSharedPrefs() { … }

在要注入的对象中，注入的方法是一样的

@Inject @Named(“default”) SharedPreferences mDefaultSharedPrefs;
@Inject @Named(“secret”) SharedPreferences mSecretSharedPrefs;

很简单，没有什么好解释的，但是这是一个非常有用的用法，值得一提。

Lazy injections 延迟注入

说到性能，如果在一个要注入依赖的对象中，有很多不同的依赖需要被注入，有些依赖只会在某些特定的场景才会被用到（比如说 用户输入的时候）。在这种情况下，如果我们没有用到这个依赖，也要去注入的话，会导致资源的浪费，所以，我们可以选择用延迟注入（lazy injection）替代。

@Inject Lazy<SharedPreferences> mLazySharedPrefs;

void onSaveBtnClicked() {  
mLazySharedPrefs.get()
.edit().putString(“status”, “lazy…”)
.apply();
}

这里的意思是说，mLazySharedPrefs只有在第一次调用get()方法的时候才会被注入。之后所有的get()调用都会是同一个mLazySharedPrefs实例。

Provider injections 注入提供者

最后一个诀窍，如果你是在一个全新的你可以完全掌控住的工程中，你想要实现这样的注入的话，你可能会考虑用其它方法来替代，比如说工厂方法。 但是，对于历史遗留代码来说，这个诀窍将会很有用。

想象这样一个场景，你需要创建一个对象的多个实例，而不是仅仅注入单个实例。在这时候，你需要注入一个提供者（Provider<T>）

@Inject Provider<Entry> mEntryProvider;

Entry entry1 = mEntryProvider.get();  
Entry entry2 = mEntryProvider.get();

在这个例子中，你的提供者（provider）会创建两个Entry对象的实例。有一点要注意的是，module中的实例如何创建完全是由你决定的

Annoyances 烦人的地方

还好，我真的不能把这个部分叫做问题，因为都是一些不足以称为问题的东西。

烦人的地方#1： 像是之前提到的，inject()方法与要注入的target，是强类型关联的。这对于debug来说很好，但是这对于我们希望在基类中实现注入的普遍做法变得复杂（如在 base activity，fragment等中）。

直觉上，你觉得应该在基类中创建一个inject()方法，但是，这样做的话，它就仅仅会注入那些在基类中声明的依赖，在他的子类中声明的依赖并不会被注入。

解决方法1：这也是我所使用的解决方案，就是在基类中声明一个抽象的注入方法来进行实际上的注入

@Override
public void onCreate(Bundle savedInstanceState) {  
super.onCreate(savedInstanceState);
injectComponent(((DemoApplication) getApplication()).getComponent());
}

protected void injectComponent(ApplicationComponent component);

然后在你的子类中实现这个方法


@Override
protected void injectComponent(ApplicationComponent component) {  
component.inject(this);
}

与Dagger1相比，需要多写一个额外的方法，来实现同样的事情。但是为了可以在编译时查错，这个代价是完全值得的。

解决方法2：另一个选择就是利用反射。如果你看到反射就不想看下去的话，并不怪你：因为这也是Dagger2所提到的点，不利用反射。但是，如果你坚持要在基类中实现注入，而不想在子类中增加额外方法的话，请继续往下看。

这个解决方法简而言之就是要找到你要注入的类型所对应的inject()方法。

首先，你要将在component类中声明的所有方法对应上方法的参数类型来保存在缓存中（因为inject()方法只能有一个参数，所以只需保存第一个有一个参数的方法就行）

// Keep the returned cache in some helper.
Map<Class, Method> buildCache() {  
Map<Class, Method> cache = new HashMap<>();
for (Method m : ApplicationComponent.class.getDeclaredMethods()) {
Class[] types = m.getParameterTypes();
if (types.length == 1) {
cache.put(types[0], m);
}
}
return cache;
}

最后，你只要在需要注入依赖的对象（target）中调用getClass()，找到缓存中对应的方法，然后使用invoke()来调用这个方法就行了。

// Use for injecting targets of any type.
void inject(ApplicationComponent component, Object target) {  
Method m = cache.get(target.getClass());
if (m != null) {
m.invoke(component, target);
}
}

在这里，我想重申一下,这个解决方法只是为了省几行代码，却对整个流程进行了过度的设计，我个人来说是不会这样做的，但是对于那些想把注入的过程隐藏在基类中，或者是在旧的代码中已经是这样做的人来说，或许会觉得这个方法是有用的。

Annoyance #2:烦人的地方2：

Component的实现类（比如说：DaggerApplicationComponent）只有在重新编译工程之后才能出现，同时如果在编译时出现任何与注入相关的错误的话，都会提示找不到这个类（换句话说，这个类没有被生成）。

我承认这虽然不是什么大问题，但是你会觉得这有点烦，至少在你刚开始使用Dagger2的那几个小时里会这样觉得，尤其是这几个小时还是你对component改动比较频繁的时候。因而，这个问题还是值得提一下的。

解决方法：据我所知，没有。

Conclusion 结论

我不想在这里长篇大论的总结，所以我会尽可能说的简洁精练

Dagger2是否比原来的版本有明显的进步？是的，提升非常大。

是否还存在问题呢？是的，但是这些问题并没有严重到让你连试都不想试，甚至不会影响到你在生产环境的工程中使用它

Updates 更新

2015-05-11: 根据Jake Wharton的评论，更正了对Dagger 1中反射使用的陈述。

Source 源码

Dagger 2 Demo (GitHub)

Resources 资源

Documentation Video introduction - by Gregory Kick (Google)

Copyright© 2013-2020

All Rights Reserved 京ICP备2023019179号-8