Android-разработчик (Mobile Architecture)

Актуальные проблемы с текущим DI

Прежде всего я обратился к community, и на встрече мы обсудили основные проблемы и сложности с текущим DI, который у нас построен на Dagger 2. Я аккуратно записал все проблемы:

• Сложно заменять зависимости в тестовом коде и демо-аппах.
• Много бойлерплейта.
• Непонятен граф зависимостей.
• Сложно добавить component dependencies из-за того, что нужно трогать много классов, и IDE тормозит.
• Импакт на build-time: kapt-процессинг аннотаций даггера входит в критический путь и занимает большое время.

Ожидания от новой системы DI

На этой же встрече мы определили, чего ожидаем от новой системы DI:

• Строгие правила по организации зависимостей.
• Простое понимание того, как подключить ту или иную зависимость.
• Уменьшение количества бойлерплейта при написании DI.
• Простота в подмене зависимостей в тестах и в демо-приложениях.
• Улучшение скорости сборки.

Инструменты для решения проблемы

Из инструментов мы могли использовать только библиотеки на базе Dagger 2, из-за его compile time проверок графа зависимостей и большого количества даггеро-специфичной логики, написанной в проекте. К таким инструментам относятся Hilt и Anvil.

Для тестирования DI-фреймворка я придумал набор сценариев, с которыми чаще всего сталкиваются разработчики, когда пишут код и работают с зависимостями.

• Добавление новой зависимости в Application component.
• Добавление application-scope зависимости в компонент экрана.
• Добавление screen-scope зависимости в компонент экрана.
• Мультибиндинг: Добавление зависимости в однотипный список (Set, Map).
• Подмена зависимости в тестах.
• Подмена зависимости в DemoApp.
• Добавление зависимостей в ViewModel.

Тестирование системы DI

• Далее я провел тесты производительности. Тестирование производительности я производил с помощью Gradle Profiler. Все сценарии имели 2 стадии разогрева и 3 итерации прогона. Для чистоты эксперимента build cache отключен.
• В результате оказалось, что Anvil выигрывает (-5-10% времени) по времени чистого билда и на модулях, в которых не происходили изменения. Однако при инкрементальной сборке на модулях, в которых включен Kapt, Anvil занимает больше времени, иногда в 3 и более раз. Это происходит из-за того, что anvil не поддерживает инкрементальную генерацию kapt stubs. У этой проблемы есть WorkAround: можно выносить DI-код из большого модуля, это поможет kapt-процессору обрабатывать меньше кода, и в итоге модуль будет обработан значительно быстрее.
• Далее я написал тестовый модуль в нашем проекте на Anvil, подготовил отдельно примеры кода и подготовил презентацию для выступления… которая как раз сейчас началась! Еще увидимся!

Кого ищем

Мы ищем коллегу Android-разработчика в нашу команду. Приходи на собес, будем тебе рады.