Отладочные инструменты часто вызываются из
src/main: логирование экрана, свой интерцептор OkHttp. По умолчанию такой код попадает в релиз, а пользователю он не нужен. Чтобы оставить его только в отладочных сборках, обычно прячут каждый вызов под if (DEBUG), разносят сами вызовы по разным src или заводят плагинную архитектуру.NoOp проще. Две реализации одного публичного API: одна рабочая, вторая с теми же методами, но без работы. Вызов в общем коде не меняется, в релизе он ничего не делает. По исходникам разделяется только место, где создаётся реализация.
interface ScreenTracer {
fun trace(screen: String)
object NoOp : ScreenTracer {
override fun trace(screen: String) = Unit
}
}// src/release
fun createScreenTracer(): ScreenTracer = ScreenTracer.NoOp
// src/debug. Этот класс в release не попадает.
fun createScreenTracer(): ScreenTracer = DebugScreenTracer()
class DebugScreenTracer : ScreenTracer {
override fun trace(screen: String) {
Log.d("Screen", screen)
}
}
class AppContainer(
val screenTracer: ScreenTracer = createScreenTracer(),
)
// Одна и та же строка в debug и в release
screenTracer.trace("Checkout")
Пример маленький, но так же собираются целые модули. Правила те же:
1. Публичное API совпадает целиком: те же типы, методы и сигнатуры.
2. Если метод что-то возвращает, NoOp отдаёт нейтральное значение, от которого дальше ничего не запускается:
null, пустую коллекцию, константу DISABLED, -1.3. Методы NoOp не делают работу: не пишут логи, не ходят в сеть, не держат состояние.
// Подключение зависимостей с разной реализацией
debugImplementation(project(":lib:debug"))
releaseImplementation(project(":lib:noop"))
Оба модуля отдают одни и те же публичные типы. В сборку попадает один из них.
NoOp можно сочетать с вырезанием кода на этапе R8, чтобы в релизе не осталось даже заглушки. Если пост наберёт 200 огоньков 🔥 , разберу, как совместить оба подхода.
#Android #AndroidDev #Архитектура