Комментарии 11
Жаль перевод. Есть несколько вопросов и дополнений. Часто вижу как делить, но ни где не видел зачем делить. Хоть бы один какделитель написал бы, что это нужно, когда у вас instant или вы шарите между несколькими разными приложениями какой-либо функционал, в остальных случаях деление почти всегда избыточно, а пакетов хватает с лихвой. Так же что есть и цена этого деления, поддержка клея между модулями тоже требует и время и увеличивает сложность проекта. Чем больше модулей, тем больше клея, тем дороже эта модульность обходится.Без явной практической необходимости не стоит этого делать.
Современные android-приложения уже давно переваливают за несколько сотен экранов. Таким образом деление на модули - способ организации кода для дальнейшего переиспользования и уменьшения связанности даже в пределах одного приложения. В статье есть примеры data-модулей, утилитных модулей - они могут пригодиться даже в небольшом проекте. А если у вас команда в проекте больше 20 android-разработчиков, то выделение в отдельные фича -модули позволяют ускорить разработку, уменьшить кол-во merge-конфликтов, снизить кол-во ошибок во всем приложении. Не зря большие команды типа Uber имеют несколько десятков, а то и сотен модулей. Если у вас небольшое приложение с небольшой командой - то скорее всего разбиение на модули и не нужно.
модули позволяют ускорить разработку, уменьшить кол-во merge-конфликтов, снизить кол-во ошибок во всем приложении.
В последнее время многомодульность преподносится в виде решения вообще всех насущных проблем.
Мердж конфликты появляются когда несколько человек трогают одно и то же место, нет никакой разницы, будет это место в одном из сотен модулей или в одном единственном. Если экраны раскидать по пакетам как по модулям, а не городить package by type, то и конфликтов будет ровно столько же.
Как именно многомодульность уменьшает количество ошибок в приложении мне тоже не очень ясно.
И все это идет с огромной пачкой проблем по поддержанию корректности структуры модулей и поддержки Gradle конфигураций.
в остальных случаях деление почти всегда избыточно, а пакетов хватает с лихвой.
Пока ваше приложение умещается в десяток-другой экранов - да. А потом наступает момент, когда вы начинаете тратить по 5-10-15 минут на сборку, потому что у вас мономодуль и фишки типа параллельной сборки и кеширования вам недоступны.
А есть цифры во сколько раз ускоряется сборка? После какого числа пакетов модульная сборка начинает обгонять обычную сборку? Почему параллельная сборка не работает в проекте "на пакетах"?
А есть цифры во сколько раз ускоряется сборка?
От проекта к проекту отличается, надо мерять. На моем прошлом жирном проекте вроде около половины смогли срезать.
После какого числа пакетов модульная сборка начинает обгонять обычную сборку?
Та же история. В теории - с любого, хотя бы за счёт более агрессивного кеширования.
Почему параллельная сборка не работает в проекте "на пакетах"?
Работает, но сильно ограниченно. Шаги сборки нельзя выполнять параллельно: сначала препроцессинг, потом компиляция, потом дексинг, потом упаковка. Какие-то шаги типа дексинга плохо параллелятся внутри, если у вас есть такой шаг - он становится бутылочным горлышком. Компилятор может параллелить работу, но ему всё равно сначала нужно переварить весь код модуля чтобы понять, что поменялось, что нужно пересобрать, и что из этого можно распараллелить.
Если же у вас есть модули, то у системы сборки есть простые и четкие критерии того, что можно гарантированно параллелить и кешировать, а что нужно пересобрать. Если два модуля не зависят друг от друга - их можно параллелить. Если в модуле нет изменений и ни одна из его зависимостей не поменялась - модуль не нужно пересобирать, даже смотреть на него не нужно.
Можете сами прикинуть, что проще обработать: граф модулей из 30 нод или граф зависимостей классов из нескольких тысяч нод.
вот точно так же думаю. Я пришел к тому, что многомодульный проект будет оправдан если на проекте несколько команд или если какие-то фичи динамические и не во все билды нужны.
Странно, что модулями здесь называется либо общий код, либо разные реализации нужного интерфейса. Во всем мире это обычные библиотеки. Модуль же - нечто, что можно воткнуть-вынуть на лету без пересборки.
В основном, когда говорим о модулях в контексте android-разработки, то имеются ввиду Android-модули. Но иногда, если не нужны классы из Android SDK, то достаточно java или kotlin - библиотеки, но в оригинальной статье их тоже называют модулями.
Потому что в терминах Gradle и Maven, которые де-факто стандарты для Java/Kotlin разработки, подпроекты называются модулями. Библиотека - внешняя зависимость, модуль - обособленная часть проекта.
Во всем мире это обычные библиотеки
В сборочных тулзах Java подмодулями называются именно подпроекты этих тулзов, но каждый из них собирается в библиотеку, в случае ванильной Java — в shared, в случае ведра — в AAR. В ведре действительно есть «модули», отвечающие просто за кусок расшаренного кода — это как раз то, что я и назвал странным. Впрочем, это терминология самого гугла.
Принципы построения многомодульных Android-приложений