从 Dagger 到 Hilt，谷歌为何执着于让我们用依赖注入？

来源 | 扔物线

责编 | Carol

文章开始之前，首先来看个视频：

开始

说到依赖注入，做 Android 的人都会想到一个库：Dagger；说到 Dagger，大家的反应普遍是一套三连：牛逼、高端、我才不用。

又牛逼又高端，为什么不用？因为太难了。是吧？又难学又难用。大多数的人在学习 Dagger 的路上就被直接劝退了，剩下的这一小撮人最终排除万难，学会并且用上了 Dagger，但多半都是用着用着就掉进了自己亲手用 Dagger 搭建的迷宫里，怎么也绕不清楚，而且越陷越深，就这么成年累月地被它折磨。

有人可能会说：难用就别用呗？拆出来啊。

拆？哼哼。你对 Dagger 一无所知。

而就在上个月，Android 团队又在 Jetpack 里面又增加了一个新的依赖注入库：Hilt。这个 Hilt 是专门针对于 Android 平台的依赖注入库，它是基于 Dagger 的。

啊？基于……Dagger？这次到底是真正的神器到来，还是又一个大坑？

依赖注入是什么？

Dagger 的名字取自有向无环图 DAG (directed acyclic graph)：

因为程序里的依赖关系拼接起来就是一个或者多个有向无环图：

DAG-er，Dagger，取了个谐音，Dagger 是匕首的意思。而这次的 Hilt 是刀柄的意思，匕首很难用是吧？来，给你个柄。

说得很好听，到底有没有那么好用啊？这是个复杂的问题，且听我慢慢道来~

依赖注入有什么用

Hilt 好不好用，我们先来看看它是个什么。它是个用注解来进行配置的依赖注入库。注解是它的写法，首先它是个依赖注入库，对吧？什么是依赖注入？一个类里有两个变量，这两个变量就是它的依赖：

要初始化一个依赖，有两种方法：第一，你这个类自己初始化：

第二，让外部帮你初始化。

其中这第二种，让外部帮你初始化你的依赖，就叫依赖注入。关键在于初始化是谁做的，至于最后一步是你把结果拿过来，还是说你连拿都不用拿，最后一步的赋值工作也让外部来帮你做了，这都不重要，只要初始化工作是外部做的，就都叫依赖注入。

所以 Factory 的使用是依赖注入吗？

是的。

Builder？

也是。

带参数的构造函数？

也是！

这些都属于由外部来提供依赖的初始化，所以都是依赖注入，并不是非要像 Dagger 那样使用注解的像魔法一样的才叫依赖注入。也就是说，其实我们每个人都已经在使用依赖注入了。虽然很多人在面对 Dagger 的时候会问「依赖注入到底有什么用」，但其实 Dagger 并不是提供了依赖注入的能力，而是为依赖注入提供了一种更简单的方式。依赖注入本来就是有用的，这个问题不想明白，不管是 Dagger 还是现在的 Hilt，你都用不好。

Dagger 让我们可以用注解的方式来配置依赖关系，让依赖注入变得更方便。不过由于功能复杂，导致它的上手非常困难；再加上刚才我说的，很多人对于依赖注入的作用以及 Dagger 的定位都没搞清楚，这两个原因加起来，就导致很多人还没学会 Dagger 就把它弃了，让 Dagger 成为 Android 史上最受冷落的优质库。这样的结果不论是对 Dagger 还是对我们，都是很可惜的。

而 Hilt 的出现，就直接解决了 Dagger 太复杂的这个问题。

Hilt 怎么帮助我们进行依赖注入

Hilt 是 Google 专门针对 Android 平台做的一个依赖注入库。它不是从里到外全新开发的，而是基于 Dagger 做的，它的下层还是 Dagger。

为什么不直接去优化改进 Dagger，而要基于它做一个新库呢？因为 Hilt 做的事其实也并不是对 Dagger 进行优化，而是场景化：针对 Android 开发制定了一系列的规则，通过这些规则大大简化了这套工具的使用。例如在 Dagger 里，你要对某个类的依赖进行注入，你需要手动获取依赖图和执行注入依赖操作：

而在 Hilt 里，注入会自动完成：

因为 Hilt 会自动找到 Android 的系统组件里面那些最佳的初始化位置——比如 Activity 的 onCreate() ——然后在这些位置注入依赖。所以，为什么不是去优化 Dagger，而是做了个新库？因为 Hilt 本身并不是一种优化，而是场景化，或者说，它是一种针对场景的优化。总之，它是不通用的，只能给 Android 用，所以不能放在 Dagger 里。

有点明白了吧？

那它具体怎么用呢？大概是这样的：

我们程序里有些对象是全局共享的，比如线程池，或者 Retrofit 对象，这种东西我们通常会把它放在 Application 对象里，或者做成单例的：

而如果用 Hilt，你也可以把它做成自动注入的依赖：

还有些对象是局部共享的，比如某个 Activity 会把一些显示用的数据共享给它内部的一些 View 和 Fragment。这一类情况我们的做法通常是获取外部 Activity 对象然后强转，再去拿它内部的对象：

而如果用 Hilt，你可以把这个对象直接声明出来，让它自动注入：

这不只是一个「美观」的差别，依赖注入可以让你的程序更加灵活，比如如果你的 View 可以在多个不同的 Activity 里显示，那你在 View 里面要怎么强转？你要转成谁？

很麻烦，是吧？而如果用依赖注入，这些就都是自动的。

除了共享的对象，不共享的也可以用依赖注入的方式来进行初始化，因为依赖注入的作用除了对共享对象提供一致性支持，也可以让我们在创建任何对象的时候省一些思考和力气：

@Inject newUser: User

总之，如果一个组件可能会被被共享，或者不会被共享但可能会在多处使用，你都可以使用 Hilt 来把它配置成依赖注入的加载方式。

加载的方式可以选择直接调用构造函数：

或者指定子类或实现类：

或者干脆给出具体的代码：

加载的作用域可以选择默认的每次都初始化，也可以设置成全局单例的：

也可以设置成针对任何 Activity、Fragment、View 或者 ViewModel 的局部共享：

简单又强大，好用又灵活。具体的写法你可以去看文档，或者过段时间我会有一次公开课，到时候也会提前通知大家。

到这里有的人可能会分个叉可能会想：诶 ButterKnife 或者现在 Jetpack 推出的 ViewBinding 它们提供的功能，Hilt 提供了吗？因为如果提供了，我在用了 Hilt 之后，不就可以把 ButterKnife 和 ViewBinding 扔掉了？

不好意思，Hilt 不提供它们的功能。Hilt 和 Dagger 虽然用法和 ButterKnife 很像，都是给变量加注解，然后变量会自动赋值，但它们的功能定位是不一样的：Hilt 和 Dagger 是做依赖注入的，而 ButterKnife 和 ViewBinding 是做视图绑定的。

这可不是个文字游戏，依赖注入和视图绑定是有本质区别的：依赖注入是由外部对对象进行初始化，也就是所谓的控制翻转；而视图绑定是让变量去指向一个已经有了的 View，它的依赖依然是由依赖持有者自己决定的，这是一个本质的区别。

Dagger 为什么难用

这么看来，Hilt 还是很好用的，是吧？那有些人就又有问题了：哎，Hilt 这么好用，那Dagger 真的难用吗？到底难用在哪了？

其实说白了，Dagger 的难用主要在于这个框架太强大和灵活了，导致你要遵守很多约定才能正确使用它。比如在 Hilt 里，一个注解就能让 Activity 内部的依赖自动被注入，而 Dagger 需要手动注入；再比如在 Hilt 里如果你想让一个对象只在 Activity 内部被共享而不是全局共享，也就是一个注解能解决的问题，而在 Dagger 里面你需要先去创建一个自定义的注解。这些难吗？每个都不难的，对吧？但把它们放在一起，让你灵活搭配使用，就有点难了。

另外，Dagger 被大家普遍认为难的另一个原因刚才我也说过了：很多人连依赖注入都不太懂的。所以我再说一遍：如果一个组件可能被共享，或者可能在多处被使用，你可以使用依赖注入来初始化它。然后，在需要依赖注入的场景里，使用 Dagger 能让你的依赖注入写起来更简单。最后，Hilt 进一步简化了这个事情。先知道它是什么，再去用它。

总结

所以今天表面上是在介绍 Hilt，其实是对于 Hilt 以及它背后的依赖注入机制进行一个整体的讲解，希望对你可以有帮助。大家学知识和技术的时候，一定不要只关注表面，要透过表面看到里面的本质，掌握最核心的东西。

那么回到这期的标题——《从 Dagger 到 Hilt，谷歌为何执着于让我们用依赖注入》，为什么？其实谷歌并没有非要让我们使用依赖注入，而是我们本来就需要使用依赖注入，谷歌只是想提供一种更方便的方式让我们去使用依赖注入而已。Dagger 很强大，但太难学从而导致太难用；而 Hilt 彻底扫除了这个障碍，那……

要不咱给它个机会？

更多阅读推荐