Android Academy · Lektion

Warum modularisieren?

Build-Geschwindigkeit, Zuständigkeiten und Wiederverwendung

Lektion 1 von 413 Schritte

Warum modularisieren? ist eine kostenlose Android Academy-Lektion auf CoddyKit. Dies ist Lektion 1 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Android Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Android Academy-Kurs umfasst insgesamt 4 Lektionen.

Das Monolith-Problem

Wenn eine Android-App wächst, befindet sich ihr gesamter Code oft in einem einzigen app-Modul. Das ist ein Monolith. Anfangs ist das praktisch, aber mit der Zeit wird es mühsam: Jede Änderung betrifft dasselbe Modul, Builds werden langsam, und Teammitglieder kommen sich ständig in die Quere.

Modularisierung bedeutet, dieses eine große Modul in viele kleinere, fokussierte Gradle-Module aufzuteilen. In dieser Lektion lernen Sie, warum Teams das tun und welche konkreten Vorteile sich daraus ergeben.

Was ein Modul eigentlich ist

In Gradle ist ein Modul eine unabhängig baubare Codeeinheit mit einer eigenen Datei build.gradle.kts. Ihre App besitzt bereits mindestens eines: das :app-Modul. Sie deklarieren jedes Modul in settings.gradle.kts.

Ein Modul hinzuzufügen ist so einfach wie es einzubinden. Jedes Modul erzeugt ein eigenes Build-Ergebnis und kann von anderen Modulen abhängen.

// settings.gradle.kts
include(":app")
include(":core:designsystem")
include(":core:data")
include(":feature:home")
include(":feature:profile")

Vorteil 1: Schnellere Builds

Der größte praktische Vorteil ist die Build-Geschwindigkeit. Gradle kann Module parallel bauen und – was besonders wichtig ist – Module, deren Eingaben unverändert sind, zwischenspeichern und überspringen.

Wenn Sie nur :feature:profile bearbeiten, verwendet Gradle die bereits erstellten Ergebnisse aller anderen Module wieder. In einem Monolithen kann jede Änderung eine erneute Kompilierung der gesamten App erzwingen.

Parallele Ausführung über mehrere Module hinweg
Inkrementelle Builds: Nur geänderte Inhalte werden neu gebaut
Bessere Trefferquoten bei Remote- und Build-Caches

// gradle.properties
org.gradle.parallel=true
org.gradle.caching=true
org.gradle.configuration-cache=true

Vorteil 2: Klare Grenzen

Module erzwingen Grenzen. Code in einem Modul kann nur auf das zugreifen, was ein anderes Modul ausdrücklich bereitstellt. Dadurch wird ein unübersichtliches Spaghetti-Geflecht verhindert, in dem jede Klasse auf jede andere Klasse zugreift.

Mit den Gradle-Konfigurationen api und implementation steuern Sie die Sichtbarkeit. implementation hält eine Abhängigkeit innerhalb des Moduls privat; Nutzer können sie nicht versehentlich verwenden.

// feature/profile/build.gradle.kts
dependencies {
    // Exposed to whoever depends on :feature:profile
    api(project(":core:model"))

    // Private: hidden from consumers of this module
    implementation(project(":core:network"))
}

Vorteil 3: Wiederverwendung

Sobald sich Logik in einem fokussierten Modul befindet, können Sie sie überall wiederverwenden. Ein :core:designsystem-Modul, das Ihr Theme, Farben und wiederverwendbare Composables enthält, kann von jedem Feature verwendet werden.

Dasselbe Prinzip lässt sich auf mehrere Apps übertragen: Ein Unternehmen kann ein :core:network-Modul für mehrere Produkte gemeinsam nutzen, statt Code zu kopieren.

// Any feature can pull in shared building blocks
// feature/home/build.gradle.kts
dependencies {
    implementation(project(":core:designsystem"))
    implementation(project(":core:data"))
}

Vorteil 4: Zuständigkeit des Teams

Module lassen sich klar der Zuständigkeit eines Teams zuordnen. Das Zahlungsteam ist für :feature:payments zuständig, das Profilteam für :feature:profile. Beide Teams können mit weniger Merge-Konflikten parallel arbeiten, weil ihr Code in getrennten Ordnern und Build-Dateien liegt.

Tools wie eine CODEOWNERS-Datei können anhand des Modulpfads automatisch Reviews beim zuständigen Team anfordern.

# .github/CODEOWNERS
/feature/payments/   @org/payments-team
/feature/profile/    @org/profile-team
/core/designsystem/  @org/platform-team

Vorteil 5: Kapselung durch Sichtbarkeit

Innerhalb eines Moduls wird Kotlin's Modifizierer internal besonders leistungsfähig. Eine internal-Klasse oder -Funktion ist nur innerhalb ihres eigenen Moduls sichtbar. Andere Module können nicht auf sie verweisen.

So können Sie eine kleine öffentliche Schnittstelle bereitstellen und Implementierungsdetails verbergen – etwas, das sich in einem einzigen riesigen Modul nicht erzwingen lässt.

// In :core:data
// Public API other modules may use
fun interface UserRepository {
    suspend fun loadUser(id: String): User
}

// Hidden from other modules
internal class DefaultUserRepository(
    private val api: UserApi
) : UserRepository {
    override suspend fun loadUser(id: String) = api.fetch(id).toUser()
}

Der Preis: zusätzlicher Aufwand

Modularisierung ist nicht kostenlos. Jedes Modul bringt eine zu pflegende Datei build.gradle.kts mit, und Sie müssen entscheiden, welchem Modul die einzelnen Codebestandteile gehören. Eine zu starke Modularisierung einer kleinen App erzeugt zusätzlichen Aufwand ohne entsprechenden Nutzen.

Als Faustregel gilt: Modularisieren Sie, wenn lange Build-Zeiten zum Problem werden, Teams sich gegenseitig behindern oder Sie klar wiederverwendbare Schichten haben. Eine Hobby-App, die Sie am Wochenende erstellen, benötigt nur selten 30 Module.

Ein typischer Modulaufbau

Eine verbreitete, skalierbare Struktur teilt Module in die Schichten app, feature und core auf. Das :app-Modul verbindet alle Bestandteile; Features enthalten die benutzerorientierten Bildschirme; Core-Module enthalten gemeinsam genutzte Infrastruktur.

// Conceptual project tree
// app/                  <- single entry point, wires features
// feature/
//   home/
//   profile/
//   settings/
// core/
//   designsystem/       <- theme + reusable composables
//   data/               <- repositories
//   network/            <- Retrofit/Ktor
//   model/              <- shared data classes

Convention Plugins sorgen für Ordnung

Bei vielen Modulen ist es eine Falle, dieselbe Gradle-Konfiguration überall zu kopieren. Teams lagern die gemeinsame Konfiguration in Convention Plugins (in einem build-logic-Modul) aus. Jedes eigentliche Modul wendet dann ein Plugin an, statt Dutzende Zeilen zu wiederholen.

Dieses Muster finden Sie in großen Open-Source-Apps wie Now in Android. Für den Moment genügt es, das Ziel zu kennen: Build-Dateien sollen klein und konsistent bleiben.

// feature/home/build.gradle.kts
plugins {
    // One convention plugin sets up Android + Compose + Kotlin
    id("myapp.android.feature")
}

android { namespace = "com.myapp.feature.home" }

Denkweise: In Schichten denken

Das wichtigste Denkmodell lautet: Abhängigkeiten sollten nach unten fließen. Features hängen von Core ab; Core hängt nicht von Features ab. Das :app-Modul steht ganz oben und hängt von allem ab, was es zum Zusammensetzen der App benötigt.

Wenn Sie diese Richtung konsequent beibehalten, bleibt Ihr Modulgraph übersichtlich und Sie vermeiden Zyklen, die Sie in einer späteren Lektion untersuchen werden.

// Allowed:  app -> feature -> core
// Forbidden: core -> feature (upward) or feature -> feature (sideways)
// app/build.gradle.kts
dependencies {
    implementation(project(":feature:home"))
    implementation(project(":feature:profile"))
}

Kurze Überprüfung

Welcher der folgenden Punkte ist der konkreteste alltägliche Vorteil, den Teams durch die Modularisierung einer wachsenden Android-App erhalten?

Beantworte es in der interaktiven Lektion

Zusammenfassung: Warum modularisieren?

Sie haben gelernt, warum Teams einen Monolithen in Module aufteilen:

Schnellere Builds durch parallele Ausführung und inkrementelles Caching
Klare Grenzen mithilfe von api/implementation und internal
Wiederverwendung von Core-Schichten wie Designsystem und Netzwerk
Zuständigkeiten im Team mit weniger Merge-Konflikten

Sie haben außerdem den Preis (zusätzliche Build-Dateien) und die wichtigste Regel kennengelernt: Abhängigkeiten fließen nach unten, app -> feature -> core. Als Nächstes legen Sie die tatsächlichen Grenzen zwischen Feature- und Core-Modulen fest.

Kostenlos starten

Lerne Kotlin mit einem KI-Tutor — kostenlos

Schreibe und führe echten Code in deinem Browser aus, bekomme sofortige Hilfe von einem 24/7 KI-Tutor und setze dein Lernen im Web oder in der App fort.

Kurse: 36
Lektionen: 152

Kostenlos lernen Den vollständigen Kurs ansehen

Häufig gestellte Fragen

Ist die Lektion „Warum modularisieren?“ kostenlos?

Ja — der vollständige Text von „Warum modularisieren?“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Android Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Android Academy-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Warum modularisieren?“?

Build-Geschwindigkeit, Zuständigkeiten und Wiederverwendung Du übst Android Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Android Academy zu starten?

Keine Vorkenntnisse erforderlich. Android Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 1 von 4.

Wie lange dauert die Lektion „Warum modularisieren?“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Android Academy-Lektion Code schreiben und ausführen?

Ja. Jede Android Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

← Zurück zu Android Academy