Warum Paging?
Die Kosten des gleichzeitigen Ladens aller Daten
Warum Paging? 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.
Alles zu laden ist teuer
Stellen Sie sich einen Feed mit 50.000 Einträgen vor. Wenn Sie alle auf einmal abrufen und im Speicher halten, verschwenden Sie Speicherplatz, verlangsamen das Netzwerk und blockieren die Benutzeroberfläche, während die Antwort verarbeitet wird.
Die meisten Benutzer scrollen ohnehin nur durch die ersten Bildschirme. Paging bedeutet, Daten beim Scrollen in kleinen Abschnitten (Seiten) zu laden, statt alles im Voraus abzurufen.
Das Problem im Code
Ein naiver Ansatz lädt die gesamte Liste in den Speicher. Selbst wenn der Server dies unterstützt, kann die Antwort sehr groß sein, und die geparste Liste nimmt den größten Teil des Heaps ein.
Dieses Muster skaliert nicht und birgt bei großen Datensätzen das Risiko eines OutOfMemoryError.
// Anti-pattern: load the whole table at once
suspend fun loadAllArticles(): List<Article> {
// Could be tens of thousands of rows / megabytes of JSON
return api.getArticles(limit = 50_000)
}
// UI holds ALL of them in memory at once
val articles = loadAllArticles()
LazyColumn {
items(articles) { article -> ArticleRow(article) }
}So sieht eine Seite aus
Eine Seite ist ein kleiner Ausschnitt des Datensatzes, häufig mit 20–50 Elementen. Der Server gibt eine Seite zusammen mit einem Verweis auf die nächste Seite zurück – beispielsweise eine Zahl, einen Offset oder ein Token.
Die App behält nur wenige Seiten im Speicher und verwirft ältere Seiten, sobald der Benutzer sie durch Scrollen verlässt.
data class ArticlePage(
val items: List<Article>,
val nextKey: Int? // null means no more pages
)
// Example REST call returning one page
suspend fun getArticlePage(page: Int, size: Int = 20): ArticlePagePaging 3 kennenlernen
Paging 3 ist die Jetpack-Bibliothek, die alle schwierigen Aufgaben der Seitennavigation für Sie übernimmt:
- Anfordern der nächsten Seite, wenn der Benutzer sich dem Ende der Liste nähert
- Begrenzen der im Speicher gehaltenen Elemente auf ein bestimmtes Fenster
- Bereitstellen von Lade- und Fehlerzuständen
- Integrierte Unterstützung für Coroutines, Flow und Jetpack Compose
Die Abhängigkeit hinzufügen
Paging 3 wird als separate Artefakte bereitgestellt: eine Laufzeitbibliothek und eine Compose-Integration. Fügen Sie diese in der build.gradle.kts Ihres Moduls hinzu.
Das Artefakt paging-compose stellt Hilfsfunktionen für LazyColumn bereit.
// build.gradle.kts (module)
dependencies {
val pagingVersion = "3.3.6"
implementation("androidx.paging:paging-runtime:$pagingVersion")
implementation("androidx.paging:paging-compose:$pagingVersion")
}Die drei zentralen Bausteine
Paging 3 basiert auf drei Typen, die Sie immer wieder verwenden werden:
- PagingSource – weiß, wie eine Seite aus einer Quelle geladen wird
- Pager – konfiguriert einen Datenstrom mit Seitennavigation und stellt ihn bereit
- PagingData – der Container für die Elemente, ausgegeben als
Flow
In den nächsten Lektionen erstellen wir jeden dieser Bausteine.
PagingData und der Flow
Ihr Repository stellt einen Flow<PagingData<T>> bereit. Die Benutzeroberfläche sammelt ihn und rendert die aktuell geladenen Elemente.
Sie setzen die vollständige Liste nie selbst zusammen – Paging überträgt die Elemente bei Bedarf an die Benutzeroberfläche.
import androidx.paging.Pager
import androidx.paging.PagingConfig
import androidx.paging.PagingData
import kotlinx.coroutines.flow.Flow
class ArticleRepository(private val api: ArticleApi) {
fun articles(): Flow<PagingData<Article>> = Pager(
config = PagingConfig(pageSize = 20)
) {
ArticlePagingSource(api)
}.flow
}PagingConfig steuert das Fenster
Mit PagingConfig stimmen Sie ab, wie Paging Daten lädt und im Speicher hält:
pageSize– Anzahl der Elemente pro SeitenanforderungprefetchDistance– Abstand zum Rand, bei dem das Laden der nächsten Seite ausgelöst wirdenablePlaceholders– Platzhalter für noch nicht geladene Elemente anzeigenmaxSize– maximale Anzahl der im Speicher gehaltenen Elemente
import androidx.paging.PagingConfig
val config = PagingConfig(
pageSize = 20,
prefetchDistance = 5,
enablePlaceholders = false,
maxSize = 100
)Netzwerk oder Datenbank – oder beides
Eine PagingSource kann Daten aus einer REST-API, einer Room-Datenbank oder einer beliebigen benutzerdefinierten Quelle beziehen.
Für ein echtes Offline-First-Erlebnis kombinieren Sie beide mit einem RemoteMediator (behandelt in der letzten Lektion): Das Netzwerk füllt eine lokale Datenbank, und die Benutzeroberfläche lädt die Seiten aus dieser Datenbank.
Flüssiges Scrollen, weniger Speicher
Mit Paging bleibt das Scrollen flüssig, weil jede Anforderung klein ist und das Speicherfenster durch maxSize begrenzt wird.
Lade- und Fehleranzeigen werden über LoadState direkt bereitgestellt. Dadurch können Sie ohne manuelle Verwaltung unten einen Ladekreisel oder eine Schaltfläche zum erneuten Versuch anzeigen.
// LoadState exposes loading/error per direction
when (val state = adapterLoadState.append) {
is LoadState.Loading -> showBottomSpinner()
is LoadState.Error -> showRetry(state.error)
is LoadState.NotLoading -> hideBottomSpinner()
}Wann Sie Paging benötigen
Verwenden Sie Paging 3, wenn:
- der Datensatz groß oder unbegrenzt ist (Feeds, Suchergebnisse, Chatverläufe)
- die Daten aus einer Netzwerk-API stammen, die Seiten oder Cursor zurückgibt
- Sie eine automatische Lade-/Fehleranzeige und eine Speicherverwaltung wünschen
Für eine kurze, feste Liste (etwa ein Einstellungsmenü) ist ein einfaches LazyColumn unkomplizierter und völlig ausreichend.
Kurze Überprüfung
Was ist der wichtigste Vorteil von Paging 3 bei einer großen Liste?
Zusammenfassung: Warum Paging
Sie haben gelernt, warum das gleichzeitige Laden aller Daten die Leistung und den Speicher beeinträchtigt und wie Paging 3 dieses Problem löst.
- Daten werden beim Scrollen in kleinen Seiten geladen
- Die drei zentralen Bausteine sind PagingSource, Pager und PagingData
PagingConfigsteuert Seitengröße, Vorabladen und das Speicherfenster- Paging lässt sich in Coroutines, Flow und Compose integrieren und stellt Lade-/Fehlerzustände automatisch bereit
Als Nächstes: Erstellen einer PagingSource und Einbinden in einen Pager.
Häufig gestellte Fragen
Ist die Lektion „Warum Paging?“ kostenlos?
Ja — der vollständige Text von „Warum Paging?“ 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 Paging?“?
Die Kosten des gleichzeitigen Ladens aller Daten 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 Paging?“?
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.