What are the differences between the three major Android annotation frameworks Dagger, Hilt and Koin?

Dagger and Koin are undoubtedly the two most popular dependency injection frameworks for Android. Both libraries serve the same purpose and look very similar, but they work very differently under the hood.

So what is Hilt? Hilt is a library that uses Dagger internally, but simplifies its usage, so what I say here about Dagger also applies to Hilt. In this article, I won't tell you which library you should choose. Instead, I want to show you how they differ in essence and how those differences can affect your application.

Dagger

If we want Dagger to provide an instance of a class, all we have to do is add the @Inject annotation to the constructor.

After adding this annotation, Dagger will generate a Factory for this class at build time. In this case, since its class name is CompositeAdapter, it will generate a class named CompositeAdapter**_**Factory.

This class contains all the information required to create an instance of the CompositeAdapter class.

As you can see, the factory class implements get() and returns a new CompositeAdapter instance. This is actually the method specified in the Provider<T> interface implemented by this class. Other classes can use the Provider<T> interface to get an instance of a class.

What if we use Hilt instead of Dagger?

In this example, there is no difference. Hilt is a library that uses Dagger internally, and the classes I showed you were generated by Dagger. If you use Hilt, it does generate some additional classes for us that simplify the use of Dagger and reduce the amount of boilerplate code we need to write. But the core remains the same.

Koin

Koin has a completely different approach to managing dependencies compared to Dagger and Hilt. To register dependencies in Koin, we will not use any annotations, because Koin does not generate any code. Instead, we have to provide factories for modules that will be used to create instances of each class needed in the project.

Koin adds references to these factory classes to the InstancesRegistry class, which contains references to all the factories we write.

The key in this map is the full name of the class or the name provided when using named arguments. The corresponding value is the factory we write that will be used to create instances of the class.

To get dependencies, we need to call get() (such as in a factory class) or by calling the inject() delegate property in activities or fragments, which lazily loads get(). The get() method will look for a factory registered for a class of the given type and inject it into it.

What are the impacts?

Dagger generates code to provide dependencies, while Koin does not generate code, which actually brings some impact.

1. Error handling

Because Dagger is a compile-time dependency injection framework, if we forget to provide certain dependencies, we will almost immediately know our mistake because our project will fail to build.

For example, if we forget to add the @Inject annotation to the CompositeAdapter in the constructor and try to inject it into a fragment, the build will fail with an appropriate error telling us exactly what went wrong.

Things are different in Koin, because it doesn't generate any code. If we forget to add a factory for the CompositeAdapter class, the app will build successfully, but a RuntimeException will be thrown as soon as we request an instance of this class. It may happen at app launch, so we may notice it right away, but it may also happen later on other screens or when the user performs some specific actions.

2. Impact on build time

The advantage of Koin not generating any code is that it has a much smaller impact on our build time. Dagger needs to use an annotation processor to scan the code and generate the appropriate classes. This can take some time and may slow down our build.

3. Impact on runtime performance

On the other hand, because Koin resolves dependencies at runtime, its runtime performance is slightly worse.

How much difference? To estimate the performance difference we can use this library where Rafa Vázquez measured and compared both libraries on different devices. The test data is written in such a way that it simulates multiple levels of transitive dependencies, so it is not just a dummy application with 4 classes.

As you can see, Dagger has almost no impact on the startup performance. On the other hand, in Koin, we can see that it takes a lot of time. Injecting dependencies in Dagger is also a bit faster than in Koin.

Summarize

As I said at the beginning of this article, my goal here is not to tell you which library to use. I have used both Koin and Dagger in two different large projects. Honestly, I think it doesn’t matter whether you choose Dagger or Koin, what matters is the ability to write clean, simple and easily unit-testable code. I think all libraries: Koin, Dagger and Hilt achieve this goal.

All of these libraries have their own strengths, and I hope that understanding how they work under the hood will help you decide for yourself which library is best for your application.