По какому принципу выбирать DI библиотеку на проекте

Что проверяют

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

Как отвечать

Перечислить критерии и сразу показать, чем варианты по ним различаются:

• когда падает ошибка. Dagger и Hilt собирают граф на компиляции, незакрытая зависимость это ошибка сборки. Koin резолвит в рантайме, и промах вылезает при открытии экрана, частично это закрывается тестом на проверку модулей;
• цена сборки. Кодогенерация через kapt или KSP добавляет время, и в многомодульном проекте это заметно. У Koin кодогенерации нет;
• интеграция с платформой. Hilt из коробки знает про Activity, Fragment, ViewModel, WorkManager и задаёт стандартные скоупы, поверх чистого Dagger это пишется руками;
• порог входа и состав команды. Dagger требует, чтобы граф понимал не один человек;
• тестируемость: насколько просто подменить зависимость в тесте и в отладочной сборке;
• стоимость выхода: миграция живого проекта дороже первоначального выбора.

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

Где спотыкаются

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

Не различают внедрение зависимостей и сервис-локатор. Koin ближе ко второму: объект сам тянет зависимость из контейнера, и это меняет и тестируемость, и момент обнаружения ошибки.

Утверждают, что DI замедляет запуск приложения. У Dagger и Hilt основная цена в сборке, в рантайме это обычные вызовы конструкторов; у Koin наоборот, работа переносится на старт и на первое обращение.