Привет, Хабр. Для будущих студентов курса "Android Developer. Professional" подготовили традиционный перевод материала.

Также приглашаем всех желающих на вебинар по теме «Профилируем и ускоряем Gradle сборки». На занятии участники вместе с экспертом:
— научатся искать узкие места в сборках с помощью gradle-profiler, scan и visualVM;
— научатся правильно конфигурировать Gradle;
— рассмотрят другие возможности для оптимизации и ускорения сборок на большом проекте.

Dagger и Koin, без сомнения, являются двумя самыми популярными фреймворками для внедрения зависимостей на Android. Обе эти библиотеки служат одной цели и кажутся очень похожими, но работают они по-разному.

А при чем здесь Hilt? Hilt — это библиотека, которая использует Dagger под капотом и просто упрощает работу с ним, поэтому все, что я говорю здесь о Dagger, применимо и к Hilt.

В этой статье я не буду подталкивать вас к решению, какую из этих библиотек выбрать. Вместо этого я хочу показать вам, чем они отличаются внутри, и каковы могут быть последствия от этих различий для вашего приложения.

Dagger

Если мы хотим, чтобы Dagger предоставил экземпляр какого-либо класса, все, что нам нужно сделать, это добавить аннотацию @Inject к конструктору.

Добавление этой аннотации приведет к тому, что Dagger сгенерирует фабрику (Factory) для этого класса во время компоновки. В данном случае, поскольку имя класса — CompositeAdapter, он сгенерирует класс с именем CompositeAdapter_Factory.

Этот класс содержит всю информацию, необходимую для создания экземпляра класса CompositeAdapter.

Как видите, фабрика реализует метод get(), который возвращает новый экземпляр класса CompositeAdapter. Фактически это метод, указанный в интерфейсе Provider, который реализует этот класс. Другие классы могут использовать интерфейс Provider для получения экземпляра класса.

Что, если мы будем использовать Hilt вместо Dagger?

В этом примере особой разницы вы бы не заметили. Hilt — это библиотека, которая использует Dagger внутри себя, а класс, который я вам показал, генерируется Dagger. Если вы используете Hilt, он создает для нас пару дополнительных классов, которые упрощают использование Dagger и сокращают количество шаблонного кода, который нам нужно написать. Но основная часть остается прежней.

Koin

У Koin совершенно другой подход к управлению зависимостями, чем у Dagger и, конечно, чем у Hilt. Чтобы зарегистрировать зависимость в Koin, мы не используем никаких аннотаций, поскольку Koin не генерирует никакого кода. Вместо этого мы должны предоставить модули с фабриками, которые будут использоваться для создания экземпляров каждого класса, который понадобится в нашем проекте.

Ссылка на эти фабрики добавляется Koin в класс InstancesRegistry, который содержит ссылки на все фабрики, которые мы написали.

Ключ в этой map — это полное имя класса или имя, которое мы предоставили, используя именованный параметр. Значение — это написанная нами фабрика, которая будет использоваться для создания экземпляра класса.

Чтобы получить зависимость, все, что нам нужно сделать, это вызвать get() (например, в фабрике) или вызвать делегированное свойство inject() в активити или фрагментах, которые под капотом лениво вызывают get(). Метод get() найдет фабрику, зарегистрированную для класса данного типа, и внедрит ее туда.

Какие последствия для приложения?

Есть некоторые последствия того факта, что Dagger генерирует код для предоставления зависимостей, а Koin — нет.

1. Обработка ошибок

Поскольку Dagger — это среда внедрения зависимостей во время компиляции, если мы забыли предоставить какую-либо зависимость, мы узнаем о нашей ошибке практически мгновенно, потому что наш проект не будет собран.

Например, если мы забыли добавить аннотацию @Inject к конструктору CompositeAdapter и попытаемся внедрить его во фрагмент, сборка завершится неудачно с соответствующей ошибкой, которая показывает нам, что именно пошло не так.

С Koin ситуация иная. Поскольку он не генерирует никакого кода, если мы забыли добавить фабрику для класса CompositeAdapter, приложение будет собрано, но закрашится с RuntimeException, как только мы запросим экземпляр этого класса. Это может произойти при запуске приложения, поэтому мы можем заметить это сразу, но это также может произойти позже, на каком-то второстепенном экране или когда пользователь выполняет какое-то конкретное действие.

2. Влияние на время сборки

В том, что Koin не генерирует никакого кода, есть некоторое преимущество: это оказывает гораздо меньшее влияние на время сборки. Dagger необходимо использовать процессор аннотаций для сканирования нашего кода и создания соответствующих классов. Это может занять некоторое время и замедлить нашу сборку.

3. Влияние на производительность во время выполнения

С другой стороны, поскольку Koin разрешает зависимости во время выполнения, это результирует в немного более худшей производительности во время выполнения.

На сколько? Чтобы оценить разницу в производительности, мы можем взглянуть на этот репозиторий, где Рафа Васкес измерил и сравнил производительность этих двух библиотек на разных устройствах. Тестовые данные были подготовлены таким образом, чтобы имитировать несколько уровней транзитивных зависимостей, т.е. это не просто приложение-болванка с 4 классами.

Как видите, Dagger практически не влияет на производительность при запуске. С другой стороны, в Koin мы видим, что настройка занимает значительное время. Внедрение зависимостей в Dagger также немного быстрее, чем в Koin.

Резюме

Как я сказала в начале этой статьи, моя цель не в том, чтобы указать вам, какую из этих библиотек использовать. Я использовала Koin и Dagger в двух разных, довольно больших проектах. Честно говоря, я думаю, что решение, какой из них выбрать, Dagger или Koin, гораздо менее важно, чем буквально что-угодно, что позволяет вам писать чистый, простой и легкий для модульного тестирования код. И я думаю, что все эти библиотеки: Koin, Dagger и Hilt действительно служат этой цели.

У всех этих библиотек есть свои сильные стороны, и я надеюсь, что знание того, как они работают, поможет вам принять решение, какая из них лучше всего подойдет именно для вашего приложения.

- Узнать подробнее о курсе "Android Developer. Professional".
- Узнать подробнее о курсе "Android Developer. Basic".

Смотреть вебинар по теме «Профилируем и ускоряем Gradle сборки».