Volley — vad är det, funktioner i Googles nätverksbibliotek

Vad är Volley?

Volley — är ett bibliotek för nätverkskommunikation i Android-applikationer, presenterat av Google på konferensen I/O 2013. Namnet Volley betyder “salva” — biblioteket är utformat för att utföra flera parallella snabba förfrågningar, karakteristiska för UI-orienterade applikationer där gränssnittets svarstid är viktig.

Volley skapades som en lösning på problemen med HttpURLConnection och AsyncTask: manuell trådhantering, brist på cachning, svårighet att prioritera förfrågningar och omfattande kod. Google positionerade Volley som ett bibliotek för operationer av typen fire-and-forget — små förfrågningar vars resultat omedelbart visas i gränssnittet.

Arkitekturen i Volley omfattar tre huvudkomponenter: RequestQueue (köhanterare), CacheDispatcher (tråd för cachade svar) och NetworkDispatcher (nätverkstrådar). Denna arkitektur distribuerar automatiskt förfrågningar: först kontrolleras cachen och endast om den saknas utförs en nätverksförfrågan. Detta minskar fördröjningen för återkommande data med 50–80%.

Hur fungerar Volley

RequestQueue — den centrala klassen i Volley. Request<T>-objekt läggs till i den och kön distribuerar automatiskt dem till två typer av trådar: CacheDispatcher (en tråd, bearbetar förfrågningar med möjlig cache) och NetworkDispatcher (flera trådar, utför verkliga HTTP-förfrågningar). Som standard skapar Volley 4 nätverkstrådar.

När en förfrågan läggs till kontrollerar RequestQueue om den kan betjänas från cachen. Om cachen innehåller ett aktuellt svar returnerar CacheDispatcher det omedelbart, utan nätverksförfrågan. Om cachen är föråldrad eller saknas skickas förfrågan vidare till NetworkDispatcher. Prioriteten på förfrågan (low, normal, high, immediate) bestämmer bearbetningsordningen i kön — förfrågningar med hög prioritet bearbetas före normala.

Efter att förfrågan har utförts levereras resultatet till huvudtråden (UI-tråden) via Handler. Volley växlar automatiskt callback-funktionerna onResponse() och onErrorResponse() till huvudtråden, så du kan direkt uppdatera gränssnittet i callbacken utan ytterligare växlingar. Detta förenklar koden och eliminerar en hel klass av trådrelaterade fel.

En annan funktion i Volley är automatisk deduplicering av förfrågningar. Om två identiska GET-förfrågningar till samma URL med samma parametrar läggs till i kön, utför Volley endast en av dem och returnerar samma svar till båda callbackarna. Detta är särskilt användbart för skärmar där flera komponenter oberoende begär samma data — till exempel användarprofilen som samtidigt behövs av både rubriken och fragmentet med inställningar.

Livscykel för en förfrågan i Volley

Varje förfrågan går igenom en sekvens av steg: skapa Request, lägga till i RequestQueue, kontrollera cache (CacheDispatcher), utföra HTTP-förfrågan (NetworkDispatcher), tolka svaret via Response.Listener, leverera resultatet till UI-tråden. Vid annullering av förfrågan (cancel) tar RequestQueue bort den från kön och förhindrar anrop av callbackar.

Volley stöder också RetryPolicy, som bestämmer antalet återförsök vid fel. DefaultRetryPolicy gör som standard ett återförsök med en timeout på 2,5 sekunder. För instabila anslutningar kan antalet återförsök ökas till 3 och timeouten till 10 sekunder. En anpassad RetryPolicy implementeras via gränssnittet RetryPolicy med metoderna getCurrentTimeout, getCurrentRetryCount och retry.

Typer av Volley-förfrågningar

Volley tillhandahåller färdiga typer av förfrågningar för vanliga dataformat. Varje typ implementerar den abstrakta klassen Request<T> och definierar hur svaret ska tolkas. För anpassade format kan du skapa din egen typ genom att åsidosätta metoden parseNetworkResponse.

Anpassade förfrågningar

För arbete med Gson eller Kotlinx Serialization kan du skapa en anpassad Request<T> som använder den valda tolkaren i parseNetworkResponse. Detta gör det möjligt att få typade objekt direkt, utan manuell tolkning av JSONObject. Detta tillvägagångssätt är särskilt användbart för projekt som redan använder serialisering via Gson eller Moshi.

För att skicka data stöder Volley tre typer av brödtext: JSONObject (via JsonObjectRequest med POST-metod), Form-encoded (via HashMap<String, String> i konstruktorn) och Multipart (via anpassad MultipartRequest). Multipart-förfrågningar är användbara för att ladda upp bilder och filer, men kräver manuell implementering eftersom Volley inte har inbyggt stöd för multipart/form-data till skillnad från OkHttp eller Dio.

Begränsningarna med Volley blir märkbara vid arbete med stora svar. Volley laddar hela svaret i minnet innan det skickas till callbacken, vilket kan orsaka OutOfMemoryError för JSON-filer större än 10–20 MB. För att ladda stora filer är Volley inte lämplig — använd DownloadManager eller OkHttp med strömmande ResponseBody. Volley stöder inte heller återupptagning av avbrutna nedladdningar (Range header) och fungerar inte med strömningsprotokoll som Server-Sent Events eller WebSocket i realtid.

Kodexempel för Volley i Java och Kotlin

Låt oss titta på ett grundläggande exempel — StringRequest för att hämta data från servern. Först skapas RequestQueue via Volley.newRequestQueue(context). Sedan sammanställs förfrågan med URL och callbackar för framgång och fel.

val queue = Volley.newRequestQueue(context)

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

queue.add(request)

För en JSON-förfrågan används JsonObjectRequest, som automatiskt tolkar svaret till JSONObject. Volley stöder GET- och POST-förfrågningar. För POST skickas ett JSONObject i förfrågans brödtext.

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("Skapad: ${response.getString("id")}")
    },
    { println("Fel: $it") }
)

queue.add(request)

Annullera förfrågningar

För att annullera en förfrågan används metoden cancel() eller gruppannullering per tagg. Vid annullering anropar Volley varken onResponse eller onErrorResponse, vilket förhindrar uppdatering av gränssnittet efter att skärmen lämnats. Detta är viktigt för att förhindra minnesläckor i Activity och Fragment.

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

// Avbryt vid lämnande av skärmen
queue.cancelAll("profile_request")

ImageLoader och NetworkImageView

ImageLoader — är en wrapper-klass över RequestQueue, optimerad för att ladda bilder. Den stöder minnescache (LruCache) och annullerar automatiskt förfrågningar vid återanvändning av ImageView i RecyclerView-listor. ImageLoader skalar också bilder till storleken på View, vilket sparar minne.

NetworkImageView — är en anpassad View som integreras med ImageLoader och automatiskt hanterar laddning: sätter en placeholder under laddning, ersätter med fel vid misslyckande och annullerar förfrågan när View lämnar skärmen. DefaultImageUrlLoader laddar bilden via URL och sparar den i LruCache för snabb visning igen.

För att använda ImageLoader räcker det att skapa en instans via ImageLoader(queue, ImageCache), där ImageCache är implementeringen av gränssnittet ImageCache med LruCache inuti. NetworkImageView i XML kopplas till ImageLoader via metoden setImageUrl(), och hela laddningen sker helt automatiskt utan extra kod för att hantera placeholders och fel.

Vanliga misstag vid arbete med Volley

Skapa RequestQueue i varje Activity — ett vanligt misstag som leder till dubblering av trådar och förvirring i cachen. RequestQueue rekommenderas att skapas en gång i Application eller via en singleton-klass. Annars kommer varje skärm att ha sin egen trådpool, och cachen kommer att lagras separat för varje kö.

Ignorera annullering av förfrågningar vid skärmrotation. Vid konfigurationsändring återskapas Activity och callbackarna för den gamla Activityn finns kvar i minnet. Detta leder till läckor och försök att uppdatera en förstörd View. Annullera alltid förfrågningar i onStop() via cancelAll() med en tagg som är specifik för Activityn.

Volley stöder inte HTTP/2 och korutiner — detta är inte ett användarfel, utan en arkitektonisk begränsning. Volley skapades 2013 och stöder inte moderna protokoll och Kotlin-korutiner. För nya projekt rekommenderar Google Retrofit + OkHttp. Volley är endast lämplig för att stödja äldre projekt eller enkla applikationer med minimala nätverkskrav.