Как поделиться зависимостями в модульном Android-приложении

Question

У меня есть проект Android, который построен по модульному принципу. Я модулировал проекты, разделив их исходный код между несколькими модулями Gradle, следуя чистой архитектуре .

Вот структура приложения.

Главный модуль в этой иерархии, App - это тот, от которого не зависит ни один другой модуль, это основной модуль вашего приложения. Модули нижнего уровня domain и data не зависят от модуля App, где модуль App включает в себя модули data и domain. Я добавил следующий код в build.gradle модуля app

    implementation project(':domain')
    api project(':data')

Теперь у меня есть некоторые проблемы с поддержанием зависимостей для каждого модуля. Поскольку каждый из них представляет собой отдельный модуль Android, каждый из них имеет свой собственный build.gradle. Модуль App может использовать классы в модулях data и domain. Но у меня есть несколько классов общего назначения (например, некоторые аннотации, утилиты, классы Broadcast, области Dagger и т. Д.), Которые я хочу использовать во всех модулях. Но вот проблемы, с которыми я сталкиваюсь

• Поскольку эти классы содержатся в основном модуле app, я не могу доступ к ним в моих data и domain, потому что эти модули не зависит от верхнего слоя app
• Любые библиотеки, которые я использую во всех слоях (например, RxJava), должны быть входит в build.gradle каждого модуля

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

Все мои другие модули app, domain и data будут иметь этот модуль в качестве зависимости.

implementation project(':common')

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

Это хороший подход? Или есть способ решить эту проблему эффективно?

Answer 1

Мы недавно столкнулись с этой проблемой, когда мы перешли к многомодульному проекту для повторного использования, оптимизации времени сборки (неизмененные модули не перекомпилируются) и т. Д. Ваша основная цель - сделать ваш модуль app как можно меньше. , так как он будет перекомпилироваться каждый раз.

Мы использовали несколько общих принципов, которые могут вам помочь:

• Общий base-ui модуль содержит основной strings.xml, styles.xml и т. Д.
• Другие интерфейсные модули (profile, dashboard и т. Д.) Реализуют этот модуль base-ui.
• Библиотеки, которые будут использоваться в всех пользовательских модулях, включены в base-ui, как api вместо implementation.
• Библиотеки, которые используются только в некоторых модулях, добавляются как зависимости только в эти модули.
• В проекте также широко используются синхронизация данных и т. Д., Поэтому существуют также модули base-data, dashboard-data и т. Д., Следуя той же логике.
• Функциональный модуль dashboard зависит от dashboard-data.
• Модуль app зависит только от функциональных модулей, dashboard, profile и т. Д.

Я настоятельно рекомендую сделать набросок потока зависимостей вашего модуля заранее, мы получили около 15 или около того модулей, все строго организованы. В вашем случае, вы упомянули, что это уже довольно большое приложение, поэтому я думаю, что app нужны извлеченные из него функциональные модули, как и domain. Помните, что маленькие модули = меньше кода для перекомпиляции!

Мы столкнулись с некоторыми проблемами при проверке того, что одна и та же версия (buildType, flavors) приложения была использована во всех подмодулях. По сути, все подмодули должны иметь одинаковые flavor с и buildType с, определенные как модуль app.

С другой стороны, мультимодульная разработка действительно заставляет задуматься о зависимостях и обеспечивает строгое разделение функций. Скорее всего, вы столкнетесь с несколькими неожиданными проблемами, которые никогда не рассматривали раньше. Например, простое отображение версии приложения внезапно усложняет (заявление об отказе: моя статья).

Эта статья также помогла нам определиться с нашим подходом. Статья, на которую вы ссылаетесь, также кажется отличным ресурсом, я хотел бы, чтобы она существовала, когда мы перешли!

После обсуждения комментариев, вот примерная диаграмма (с прискорбной неопрятностью, но достаточной для иллюстрации концепции. Обратите внимание, что следующим шагом будет различие между api и implementation):