Модульность и DI в современном Android-приложении. Большой туториал от Яндекса

[IlnurStybayev]

Очень полезная статья ! Спасибо за труд !

[mishkarodionov]

Вопрос автору - использование разбиения на api и internal в рамках одного модуля не приведет ли к долгому процессу сборки приложения грэдлом в ситуации, когда в internal какой-то фичи мы что-то поменяли, и из-за этого будут пересобираться все остальные фичи и модули, которые ссылаются на api (не изменившееся!) этой фичи? Не будет ли более правильным подоходом создавать отдельные модули для api фичи и его реализации, типа feature1_api, feature1_impl? Или сборщик понимает, что изменения коснулись только модулей фичи помеченных internal и значит не надо пересобирать те модули, которые зависят от api этой фичи?

[zagayevskiy]

Добрый день. Насколько мне известно, gradle не знает про Kotlin internal, поэтому пересборка тех модулей, которые зависят от фичи, действительно будет происходить, но это не точно, надо проверять. Кроме того, есть ещё инкрементальность на уровне компилятора Kotlin.
Но, как упоминалось в статье, фичам не рекомендуется зависеть друг от друга, поэтому их пересборка происходить не будет.
Развитие идеи, подобное тому, что вы предлагаете, известно, и есть команды, которые им пользуются. Уточню, что, по классике, один фиче-модуль превращается в три, а не в два:

• feature-api — только публичный интерфейс
• feature-impl — реализация
• feature-factory — то, от чего будут зависеть клиенты, предоставляет имплементацию, закрытую интерфейсом.

Зависимости между ними будут такие:
feature-api не зависит ни от -impl, ни от -factory.
feature-impl зависит от feature-api по api или implementation, не важно:

// :feature-impl/build.gradle
api/implementation project(':feature-api')

feature-factory зависит от feature-api по api, а от feature-impl по implementation:

// :feature-factory/build.gradle
api project(':feature-api')
implementation project(':feature-impl')

Клиенты зависят только от feature-factory.
Смысл всего этого как раз в том, чтобы при изменениях в реализации feature-impl пересобирались только два модуля — feature-impl и feature-factory. Gradle знает, что сам модуль feature-factory, и его публичный api не изменились, поэтому может не пересобирать зависящие от него модули.

Конкретно мы не используем такой подход повсеместно, потому что он троекратно увеличивает количество модулей, а от этого начинает страдать туллинг. Android studio тормозит, замедляется sync, индексация.
Мы начали использовать ещё большее развитие этого подхода в мультиплатформенных фичах, где используется Kotlin multiplatform. Но не для избежания пересборки, а для того, чтобы api модулей был более чистым. Но об этом как-нибудь в другой раз:)