Volley — was ist das, Funktionen der Google-Netzwerkbibliothek

Was ist Volley?

Volley ist eine Bibliothek für die Netzwerkkommunikation in Android-Anwendungen, die von Google auf der I/O 2013 Konferenz vorgestellt wurde. Der Name Volley bedeutet „Salve“ — die Bibliothek wurde für die Ausführung mehrerer paralleler schneller Anfragen entwickelt, die für UI-orientierte Anwendungen charakteristisch sind, bei denen die Antwortgeschwindigkeit der Benutzeroberfläche wichtig ist.

Volley wurde als Lösung für die Probleme von HttpURLConnection und AsyncTask entwickelt: manuelle Thread-Verwaltung, fehlendes Caching, Komplexität der Anfragepriorisierung und umständlicher Code. Google positionierte Volley als Bibliothek für „Fire-and-Forget“-Operationen — kleine Anfragen, deren Ergebnis sofort in der Benutzeroberfläche angezeigt wird.

Die Volley-Architektur umfasst drei Hauptkomponenten: RequestQueue (Warteschlangen-Manager), CacheDispatcher (Thread für gecachte Antworten) und NetworkDispatcher (Netzwerk-Threads). Diese Architektur verteilt Anfragen automatisch: Zuerst wird der Cache überprüft, und nur wenn dieser nicht vorhanden ist, wird eine Netzwerkanfrage ausgeführt. Dies reduziert die Latenz für wiederholte Daten um 50–80%.

Wie Volley funktioniert

RequestQueue ist die zentrale Klasse von Volley. Ihr werden Request<T>-Objekte hinzugefügt, und die Warteschlange verteilt sie automatisch auf zwei Arten von Threads: CacheDispatcher (ein Thread, bearbeitet Anfragen mit möglichem Cache) und NetworkDispatcher (mehrere Threads, führen tatsächliche HTTP-Anfragen aus). Standardmäßig erstellt Volley 4 Netzwerk-Threads.

Beim Hinzufügen einer Anfrage prüft RequestQueue, ob sie aus dem Cache bedient werden kann. Wenn der Cache eine aktuelle Antwort enthält, gibt CacheDispatcher sie sofort ohne Netzwerkanfrage zurück. Wenn der Cache veraltet oder nicht vorhanden ist, wird die Anfrage an NetworkDispatcher weitergeleitet. Die Priorität der Anfrage (low, normal, high, immediate) bestimmt die Reihenfolge der Verarbeitung in der Warteschlange — Anfragen mit hoher Priorität werden vor normalen verarbeitet.

Nach der Ausführung der Anfrage wird das Ergebnis über Handler an den Haupt-Thread (UI-Thread) geliefert. Volley wechselt die Callbacks onResponse() und onErrorResponse() automatisch zum Haupt-Thread, sodass die Benutzeroberfläche direkt im Callback ohne zusätzliche Thread-Wechsel aktualisiert werden kann. Dies vereinfacht den Code und eliminiert eine ganze Klasse von Threading-Fehlern.

Eine weitere Funktion von Volley ist die automatische Anfrage-Deduplizierung. Wenn zwei identische GET-Anfragen an dieselbe URL mit denselben Parametern zur Warteschlange hinzugefügt werden, führt Volley nur eine davon aus und gibt dieselbe Antwort an beide Callbacks zurück. Dies ist besonders nützlich für Bildschirme, auf denen mehrere Komponenten unabhängig voneinander dieselben Daten anfordern — zum Beispiel ein Benutzerprofil, das gleichzeitig von der Kopfzeile und einem Einstellungsfragment benötigt wird.

Lebenszyklus einer Anfrage in Volley

Jede Anfrage durchläuft eine Abfolge von Schritten: Erstellen eines Request, Hinzufügen zur RequestQueue, Überprüfen des Caches (CacheDispatcher), Ausführen der HTTP-Anfrage (NetworkDispatcher), Parsen der Antwort durch Response.Listener, Zustellung des Ergebnisses an den UI-Thread. Beim Abbrechen einer Anfrage (cancel) entfernt RequestQueue sie aus der Warteschlange und verhindert das Aufrufen von Callbacks.

Volley unterstützt auch RetryPolicy, das die Anzahl der Wiederholungsversuche bei Fehlern bestimmt. DefaultRetryPolicy führt standardmäßig einen Wiederholungsversuch mit einem Timeout von 2,5 Sekunden durch. Für instabile Verbindungen kann die Anzahl der Wiederholungen auf 3 und das Timeout auf 10 Sekunden erhöht werden. Eine benutzerdefinierte RetryPolicy wird über das RetryPolicy-Interface mit den Methoden getCurrentTimeout, getCurrentRetryCount und retry implementiert.

Volley-Anfragearten

Volley bietet vorgefertigte Anfragearten für gängige Datenformate. Jeder Typ implementiert die abstrakte Klasse Request<T> und definiert eine Methode zum Parsen der Antwort. Für benutzerdefinierte Formate können Sie durch Überschreiben der Methode parseNetworkResponse Ihren eigenen Typ erstellen.

Benutzerdefinierte Anfragen

Für die Arbeit mit Gson oder Kotlinx Serialization können Sie eine benutzerdefinierte Request<T> erstellen, die den gewählten Parser in parseNetworkResponse verwendet. Dadurch können Sie typisierte Objekte direkt empfangen und manuelles JSONObject-Parsing vermeiden. Dieser Ansatz ist besonders nützlich für Projekte, die bereits Serialisierung über Gson oder Moshi verwenden.

Zum Senden von Daten unterstützt Volley drei Body-Typen: JSONObject (über JsonObjectRequest mit POST-Methode), Form-encoded (über HashMap<String, String> im Konstruktor) und Multipart (über einen benutzerdefinierten MultipartRequest). Multipart-Anfragen sind nützlich zum Hochladen von Bildern und Dateien, erfordern jedoch eine manuelle Implementierung, da Volley im Gegensatz zu OkHttp oder Dio keine integrierte Unterstützung für multipart/form-data hat.

Die Einschränkungen von Volley werden bei der Arbeit mit großen Antworten deutlich. Volley lädt die gesamte Antwort in den Arbeitsspeicher, bevor sie an den Callback übergeben wird, was bei JSON-Dateien über 10–20 MB zu OutOfMemoryError führen kann. Zum Herunterladen großer Dateien ist Volley nicht geeignet — verwenden Sie DownloadManager oder OkHttp mit streaming ResponseBody. Volley unterstützt auch kein Fortsetzen unterbrochener Downloads (Range-Header) und funktioniert nicht mit Streaming-Protokollen wie Server-Sent Events oder WebSocket in Echtzeit.

Volley-Codebeispiele in Java und Kotlin

Betrachten wir ein grundlegendes Beispiel — einen StringRequest zum Abrufen von Daten von einem Server. Zuerst wird eine RequestQueue über Volley.newRequestQueue(context) erstellt. Dann wird eine Anfrage mit einer URL und Erfolgs- und Fehler-Callbacks gebildet.

val queue = Volley.newRequestQueue(context)

val request = StringRequest(
    Request.Method.GET,
    "https://api.github.com/users/octocat",
    { response ->
        println("Antwort: $response")
    },
    { error ->
        println("Fehler: ${error.message}")
    }
)

queue.add(request)

Für eine JSON-Anfrage wird JsonObjectRequest verwendet, der die Antwort automatisch in ein JSONObject parst. Volley unterstützt GET- und POST-Anfragen. Für POST wird ein JSONObject im Anforderungstext übergeben.

val jsonBody = JSONObject()
jsonBody.put("name", "New Repo")
jsonBody.put("description", "Created via Volley")

val request = JsonObjectRequest(
    Request.Method.POST,
    "https://api.github.com/user/repos",
    jsonBody,
    { response ->
        println("Erstellt: ${response.getString("id")}")
    },
    { println("Fehler: $it") }
)

queue.add(request)

Anfragen abbrechen

Zum Abbrechen einer Anfrage wird die cancel()-Methode oder das gruppenweise Abbrechen nach Tag verwendet. Beim Abbrechen ruft Volley weder onResponse noch onErrorResponse auf, was Aktualisierungen der Benutzeroberfläche nach dem Verlassen des Bildschirms verhindert. Dies ist wichtig, um Speicherlecks in Activity und Fragment zu verhindern.

request.tag = "profile_request"
queue.add(request)

// Abbruch beim Verlassen des Bildschirms
queue.cancelAll("profile_request")

ImageLoader und NetworkImageView

ImageLoader ist eine Wrapper-Klasse über RequestQueue, optimiert zum Laden von Bildern. Er unterstützt Arbeitsspeicher-Cache (LruCache) und bricht Anfragen automatisch ab, wenn ImageView in RecyclerView-Listen wiederverwendet wird. ImageLoader skaliert Bilder auch auf die Größe der View, um Speicher zu sparen.

NetworkImageView ist eine benutzerdefinierte View, die mit ImageLoader integriert ist und das Laden automatisch verwaltet: Sie zeigt einen Platzhalter während des Ladens an, ersetzt ihn bei Fehler durch eine Fehlermeldung und bricht die Anfrage ab, wenn die View den Bildschirm verlässt. DefaultImageUrlLoader lädt ein Bild per URL und speichert es in LruCache für eine schnelle erneute Anzeige.

Um ImageLoader zu verwenden, erstellen Sie einfach eine Instanz über ImageLoader(queue, ImageCache), wobei ImageCache eine Implementierung des ImageCache-Interface mit LruCache im Inneren ist. NetworkImageView im XML-Layout wird über die setImageUrl()-Methode mit ImageLoader verbunden, und das gesamte Laden erfolgt vollständig automatisch ohne zusätzlichen Code für die Behandlung von Platzhaltern und Fehlern.

Häufige Fehler bei der Arbeit mit Volley

Erstellen einer RequestQueue in jeder Activity ist ein häufiger Fehler, der zu Thread-Duplizierung und Cache-Verwirrung führt. Es wird empfohlen, RequestQueue einmal in Application oder über eine Singleton-Klasse zu erstellen. Andernfalls hat jeder Bildschirm seinen eigenen Thread-Pool und der Cache wird für jede Warteschlange separat gespeichert.

Ignorieren des Anfrageabbruchs bei Bildschirmdrehung. Bei Konfigurationsänderung wird die Activity neu erstellt und die Callbacks der alten Activity bleiben im Speicher. Dies führt zu Lecks und Versuchen, eine zerstörte View zu aktualisieren. Brechen Sie Anfragen immer in onStop() über cancelAll() mit einem Activity-spezifischen Tag ab.

Volley unterstützt kein HTTP/2 und keine Coroutinen — dies ist kein Anwendungsfehler, sondern eine architektonische Einschränkung. Volley wurde 2013 erstellt und unterstützt keine modernen Protokolle und Kotlin-Coroutinen. Für neue Projekte empfiehlt Google die Verwendung von Retrofit + OkHttp. Volley eignet sich nur für die Unterstützung von Legacy-Projekten oder einfachen Anwendungen mit minimalen Netzwerkanforderungen.