Есть и другие способы. Зависит от архитектуры проекта. Api/impl подходит для нашего проекта.
Но есть еще вариант когда каждая фича внутри себя объявляет Dependencies (например интерфейс навигации, который нужен только этой фиче, провайдер данных и т.д.), которые должны предоставить этой фиче из других фич, как правило это происходит где-нибудь в app модуле (так он знает обо всех модулях). Этот подход также позволяет создавать модули изолировано. Тогда в демоприложении не будет подключаться ничего лишнего, так как связей между модулями нет.
Имеется ввиду подключать не исходники, а уже скомпилированные .aar? Если да, то мы это исследуем сейчас. Пока ничего не могу сказать. Это может помочь, если приходится менять код в главном модуле :app, куда подключены все остальные модули. Все модули к можно подключить как .aar к :app модулю, тогда синк и сборка. :app должна быть быстрее. Но пока это лишь предположения)
Проблем было много и еще много осталось. Например одна из проблем это общий модуль с бд.
Чтобы избегать болерпрейт всю базовую настройку вынесли во фреймворк для демок. Разработчики только указывают то, что им нужно для конкретной демки, к примеру подключают фичи свои или выключают автризацию и используют мок ответы для бэка.
По некорректному подключению gradle завичимостей у нас есть gradle plugin. Он регает таску, которая ругается если что то подключили не туда или выводит список модулей, которые стоит почистить от неправильных зависимостей прежде всего, чтоб уменьшить модули в демке. Кстати плагин хотим заоупенсорсить.
По di зависит от проекта, но можно подумать над тем, чтобы описать как это реализовано у нас.
Про стейт приложения не совсем понял. Могли бы детальнее расписать?
Мы также подключаем api модули с минимальным количеством зависимостей. Fake это видимо что то по типу заглушек без реальной реализации. У нас такие вещи в test fixtures, отдельный модуль не создаем для этого. Но это вопрос реализации, кому как удобнее. Отдельный модуль с фейками тоже ок, главное его не подключать к модулю app и убирать из settings.gradle чтоб не синкать, а подключать только в settings.gradle для демки.
По инструментам отвечю. Android Studio и gradle имеют свои проблемы влияющие на скорость сборки или количество потребляемой памяти. И есть множество оптимизаций, оптимизаций, которые позволяют ускорить сборку. Спасибо разработчиком этих инструментов за это.
Но есть также и другая сторона - это проекты с неправильными зависимостями между модулями. Когда все переплетено в связях и нет четких границ у модулей, это приводит к тому, что при каждом чихе пересобирается пол проекта.
Однозначно нужно следить за архитектурой проекта и развязывать зависимости. За нас эту работу Android Studio или gradle не сделают.
Есть и другие способы. Зависит от архитектуры проекта. Api/impl подходит для нашего проекта.
Но есть еще вариант когда каждая фича внутри себя объявляет Dependencies (например интерфейс навигации, который нужен только этой фиче, провайдер данных и т.д.), которые должны предоставить этой фиче из других фич, как правило это происходит где-нибудь в app модуле (так он знает обо всех модулях). Этот подход также позволяет создавать модули изолировано. Тогда в демоприложении не будет подключаться ничего лишнего, так как связей между модулями нет.
Имеется ввиду подключать не исходники, а уже скомпилированные .aar? Если да, то мы это исследуем сейчас. Пока ничего не могу сказать. Это может помочь, если приходится менять код в главном модуле :app, куда подключены все остальные модули. Все модули к можно подключить как .aar к :app модулю, тогда синк и сборка. :app должна быть быстрее. Но пока это лишь предположения)
Спасибо за такой развернутый комментарий!
Спасибо за подробный уоммент и полезные ссылки)
Проблем было много и еще много осталось. Например одна из проблем это общий модуль с бд.
Чтобы избегать болерпрейт всю базовую настройку вынесли во фреймворк для демок. Разработчики только указывают то, что им нужно для конкретной демки, к примеру подключают фичи свои или выключают автризацию и используют мок ответы для бэка.
По некорректному подключению gradle завичимостей у нас есть gradle plugin. Он регает таску, которая ругается если что то подключили не туда или выводит список модулей, которые стоит почистить от неправильных зависимостей прежде всего, чтоб уменьшить модули в демке. Кстати плагин хотим заоупенсорсить.
По di зависит от проекта, но можно подумать над тем, чтобы описать как это реализовано у нас.
Про стейт приложения не совсем понял. Могли бы детальнее расписать?
Спасибо за детальный коммент)
Мы также подключаем api модули с минимальным количеством зависимостей. Fake это видимо что то по типу заглушек без реальной реализации. У нас такие вещи в test fixtures, отдельный модуль не создаем для этого. Но это вопрос реализации, кому как удобнее. Отдельный модуль с фейками тоже ок, главное его не подключать к модулю app и убирать из settings.gradle чтоб не синкать, а подключать только в settings.gradle для демки.
Движемся как раз в сторону api/impl. Пока есть горстка модулей без api.
Для уже существующих модулей api так и делаем, мокаем/стабаем все лишнее.
Размер артефактов не измерял.
По инструментам отвечю. Android Studio и gradle имеют свои проблемы влияющие на скорость сборки или количество потребляемой памяти. И есть множество оптимизаций, оптимизаций, которые позволяют ускорить сборку. Спасибо разработчиком этих инструментов за это.
Но есть также и другая сторона - это проекты с неправильными зависимостями между модулями. Когда все переплетено в связях и нет четких границ у модулей, это приводит к тому, что при каждом чихе пересобирается пол проекта.
Однозначно нужно следить за архитектурой проекта и развязывать зависимости. За нас эту работу Android Studio или gradle не сделают.