扩展砧板的乐趣和利润

Note: This article assumes some familiarity with Dagger, Anvil, and Kotlin.

注意：本文假定对《小刀》有一定的熟悉程度。 匕首, 砧板和 Kotlin.

We use Dagger heavily in the Slack Android app for compile-time dependency injection. It’s powerful, flexible, supports basic Kotlin idioms, and allows for advanced dependency injection patterns with less boilerplate. It’s not without its sharp edges though. It slows down our builds with kapt, has a steep learning curve, and can often be tedious to write out its module+component plumbing.

我们在Slack的Android应用中大量使用Dagger来进行编译时的依赖注入。它强大、灵活，支持基本的Kotlin习语，并允许以较少的模板实现高级依赖注入模式。不过，它也不是没有缺点。它降低了我们使用kapt构建的速度，有一个陡峭的学习曲线，而且写出模块+组件的管道往往很乏味。

Anvil augments Dagger’s own boilerplate. Factory generation enables us to remove kapt from much of our project, @ContributesTo and @ContributesBinding allow us to automatically wire dependencies without modules, and @MergeComponent allows us to automatically wire together component interfaces. Factory generation alone recently helped us reduce our incremental build times by as much as 25%!

Anvil增强了Dagger自己的模板。工厂生成使我们能够从项目的大部分内容中移除kapt，@ContributesTo 和@ContributesBinding使我们能够在没有模块的情况下自动连接依赖关系，以及 @MergeComponent允许我们自动连接组件的接口。最近，仅工厂生成就帮助我们减少了25%的增量构建时间。

Anvil’s core features are fantastic, but they are not (nor pretend to be!) turnkey solutions for every use case, though they cover the common ones. Every codebase has its own patterns and nuances, so Anvil 2.3.0 introduced a new compiler-api artifact that allows us to extend Anvil’s own code generation to suit those remaining needs. In this post we’ll detail a little of how it works with our own Activity injection pattern as an example.

Anvil的核心功能非常棒，但它们不是（也没有假装是！）每个用例的交钥匙解决方案，尽管它们涵盖了常见的用例。每个代码库都有自己的模式和细微差别，因此Anvil 2.3.0引入了一个新的compiler-api artifact，允许我们扩展Anvil自己的代码生成，以适应这些剩余需求。在这篇文章中，我们将以我们自己的Activity注入模式为例，详细介绍一下它是如何工作的。

The problem

问题所在

We historically used dagger-android, which is now deprecated. As such, most of our activities were wired via @ContributesAndroidInjector. While Hilt is the canonical successor to this, we’ve opted n...