【从零开始撸一个App】Dagger2

Dagger2是一个IOC框架,一般用于Android平台,第一次接触的朋友,一定会被搞得晕头转向。它延续了Java平台Spring框架代码碎片化,注解满天飞的传统。尝试将各处代码片段串联起来,理清思绪,真不是件容易的事。更不用说还有各版本细微的差别。
与Spring不同的是,Spring是通过反射创建对象的,而Dagger2是[通过apt插件]在编译期间生成代码,这些生成的代码负责依赖对象创建。

本文旨在以简单通俗易懂的方式说明如何使用Dagger2,对其背后设计不做深入探讨。人生苦短,码农更甚,先知其然等有空时再知其所以然,不失为撸App的较好实践。

正式开始前,先给像笔者这样的小白定义几个概念,方便下文理解:

  • 依赖对象:比如bean,被其它类所需(依赖)的对象,需要以某种方式注入到目标对象中。
  • 目标对象:依赖对象的需求方,注入者将依赖对象注入其中。
  • 注入者/[依赖对象的]容器:维护依赖对象,将依赖对象注入到目标对象的工具类。

入门

首先,添加依赖库。

    implementation "com.google.dagger:dagger:2.27"
    // kapt是服务于Kotlin的Annotation Processing Tool,用于编译时处理注解
    kapt "com.google.dagger:dagger-compiler:2.27"

一般来说,IOC会根据规则在运行时自动帮我们生成依赖对象实例。Dagger2提供了两种声明依赖对象的方式:

  • 构造函数有@Inject修饰。
  • @Module修饰的类中所定义的有@Provides修饰的方法提供(可用于依赖对象是第三方库中的对象)。
// 方式一(注意此处hen也要是依赖对象,否则将为null或者直接报错)
class Egg @Inject constructor(private val hen: Hen)

// 方式二
@Module
class HenModule {
    @Singleton
    @Provides
    fun provideHen() = Hen()
}

大家注意@Singleton注解(javax.inject中定义),它表示该依赖对象的作用域或者说生命周期,Dagger2中可通过@Scope定义。@Singleton是Dagger2默认支持的scope,表示依赖对象是单例。需要注意的是,通常我们将单例保存在一个静态域中,这样的单例往往要等到虚拟机关闭时候,所占用的资源才释放,但是,Dagger通过Singleton创建出来的单例并不保持在静态域上,而是保留在同样标注了@Singleton的Component实例中(依赖对象容器,接下来会讲到)。其实对于任意scope,只要依赖对象和Component标注的是相同scope,那么该依赖对象在相应的Component中就是一个局部单例,仅会调用一次工厂类生成对象实例。一般来说我们只要使用默认的@Singleton即可,没必要自定义,自定义Scope常用于业务或逻辑的划分。
如果不想依赖对象与Component绑定,则可以使用@Reusable作用域。

上面说的Component是@Component注解修饰的接口,Dagger2会先寻找它,以此为入口得到所有依赖对象。该接口中可定义类似void inject(Target target)的方法。显然,@Component注解的接口就是注入者,它将依赖对象和目标对象串联了起来。

@Singleton
@Component(modules = [HenModule::class]) //依赖对象
interface MyAppComponent {
    fun inject(activity: MainActivity); //目标对象
}

最后我们就可以在目标对象中愉快地使用依赖对象了。

class MainActivity : AppCompatActivity() {
    @Inject
    lateinit var hen: Hen

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        DaggerMyAppComponent.builder().build().inject(this); // 关键
    }
}

改进

如上,对于Activity/Fragment来说,它们的实例化是系统完成的,因此若要将它们纳入IOC容器管理,只能在它们使用之前的某个环节比如onCreate回调方法内手动加入。这产生了至少一个问题:这种方式破坏了依赖注入的核心准则——一个类不应该知道它是如何被注入的。为了解决这个问题,Dagger 2.10版本引入的dagger-android,它是一个专为Android设计的除了Dagger主模块之外的全新模块。

首先,新增两个依赖库。

    implementation "com.google.dagger:dagger-android:2.27"
    kapt "com.google.dagger:dagger-android-processor:2.27"

针对每个目标类编写对应的子容器代码:

@Subcomponent(modules = [HenModule::class])
interface MainActivitySubcomponent : AndroidInjector<MainActivity?> {
    @Subcomponent.Builder
    abstract class Builder : AndroidInjector.Factory<MainActivity?>
}

再针对每个目标类编写对应的依赖对象代码:

@Module(subcomponents = MainActivitySubcomponent::class)
abstract class MainActivityModule {
    @Binds
    @IntoMap
    @ActivityKey(MainActivity::class)
    abstract fun bindMainActivityInjectorFactory(builder: MainActivitySubcomponent.Builder?): AndroidInjector.Factory<out Activity?>?
}

修改之前的MyAppComponent代码:

@Singleton
@Component(modules = [AndroidInjectionModule::class,MainActivityModule::class]) // 关键,引入AndroidInjectionModule
interface MyAppComponent {
    fun inject(app: MyApplication); //注入到Application
}

Application需要继承HasActivityInjector,实现inject方法,返回DispatchingAndroidInjector对象。

class MyApplication : Application(), HasActivityInjector {
    // 由dagger.android自动注入
    @Inject
    lateinit var dispatchingAndroidInjector: DispatchingAndroidInjector<Activity>

    override fun androidInjector() = dispatchingAndroidInjector

    override fun onCreate() {
        super.onCreate()
        DaggerMyAppComponent.builder().build().inject(this)
    }
}

创建一个BaseActivity,在super.onCreate之前调用AndroidInjection.inject(this),这样之后的Activity就只需要继承它,就可以使用各自的依赖对象了。

open class BaseActivity: AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        AndroidInjection.inject(this)
        super.onCreate(savedInstanceState)
    }
}
class MainActivity : BaseActivity() {
    @Inject
    lateinit var hen: Hen

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        //DaggerMyAppComponent.builder().build().inject(this); // 不需要了
    }
}

可见,为了解决前述问题,引入了更多的代码,复杂度也提高了,这是否有必要,值得商榷。好在Dagger2提供了@ContributesAndroidInjector注解解决了这个问题。


再改进

  1. 删除前述的MainActivitySubcomponent和MainActivityModule;
  2. 创建基于BaseActivity类型的容器(非必须):
@Subcomponent
interface ActivityComponet: AndroidInjector<BaseActivity>{
    @Subcomponent.Builder
    abstract class Builder: AndroidInjector.Builder<BaseActivity>()
}
  1. 创建ActivityModule,管理所有Activity。注意@ContributesAndroidInjector注解的使用。
@Module(subcomponents = [ActivityComponet::class])
abstract class ActivityModule{
    @ContributesAndroidInjector
    abstract fun mainActivityInjector(): MainActivity
}
  1. 修改之前的MyAppComponent代码:
@Singleton
@Component(modules = [AndroidInjectionModule::class,ActivityModule::class]) // MainActivityModule改为ActivityModule
interface MyAppComponent {
    fun inject(app: MyApplication);
}

大功告成!我们再也不需要重复地创建XXXActivityModule和XXXActivitySubcomponent类了。
参看Dagger & Android


后记拾遗

@BindsInstance:编译后会在Component的Builder类中生成修饰的方法里面的参数对应的成员变量,so该变量对应的对象可在与该Component相关的Module中通过@Inject注入,可看作是该Component范围内的全局单例,类似于上述的@Scope的作用。

Dagger 2.22 起引入了 @Component.Factory, 可以取代@Component.Builder的使用,Factory在许多场景的上的使用相对于Builder会更简单。

Dagger 2.23新增了一个HasAndroidInjector接口,用于替代HasActivityInjector, HasServiceInjector, HasBroadcastReceiverInjector, HasSupportFragmentInjector四个接口,让Application中的代码更简洁,目前还是beta版。一般如果我们只需要HasActivityInjector的话那也无所谓了。参看Reducing Boilerplate with the new HasAndroidInjector in Dagger 2.23

了解一下javax.inject,这个是 Java EE 6 规范 JSR 330 -- Dependency Injection for Java 中的东西, Spring、Guice兼容该规范。

Assisted Injection:似乎是Guice引入的一个概念?——
Sometimes a class gets some of its constructor parameters from the Injector and others from the caller. 对于这种情况,我们常封装一个工厂类,该类内部提供了注入类型的实例化,对外暴露一个生产方法,该方法只接收需要外部传入的参数。如果觉得手写这种工厂类太过麻烦或工作量太大,那么可以使用AssistedInject自动生成。参看AssistedInjectAssisted Injection for JSR 330

抛弃dagger-android:虽然最终改进之后,代码变得清晰很多,但内在逻辑反而更加复杂了。这种[理解门槛较高的]复杂度就像一颗定时炸弹,让人夜不能寐。当我使用到ViewModel之后发现,也可以不引入dagger-android,而是将所有依赖注入到ViewModel中,再由ViewModel暴露给系统组件。然而由于框架所限,其实不然——ViewModel是由Android框架本身维护的,当然框架也给我们留了一个自定义provider viewmodel的口子,就是ViewModelProvider.Factory——这又是一项颇费脑力的工程,参看How to Inject ViewModel using Dagger 2。这步完成以后,我们再将ViewModelProvider.Factory实例注入到Application中,变为一个全局工厂对象,Activity/Fragment直接拿来用即可,再也不需要与依赖注入有任何瓜葛,自然也不需要dagger-android了。也有大神跟我想到一块,参看当Dagger2撞上ViewModel


参考资料

Dagger2从入门到放弃再到恍然大悟
Dagger2 @Component 和@SubComponent 区别解惑
学习Dagger2笔记
dagger.android(Dagger2中的AndroidInjector)使用解析
Dagger2 中的 Binds、IntoSet、IntoMap
dagger android 学习(一):dagger基础使用
Dagger2在Android平台上的新魔法(作者了解了dagger-android背后的原理后弃用)

posted @ 2020-08-04 10:42  莱布尼茨  阅读(3333)  评论(0编辑  收藏  举报