Confronto tra le librerie di rete Android: OkHTTP, Retrofit e Volley [chiuso]

Domanda in due parti di uno sviluppatore iOS che impara Android, lavorando su un progetto Android che presenterà una varietà di richieste da JSON a immagini per il download in streaming di audio e video:

1. Su iOS ho usato ampiamente il progetto AFNetworking . Esiste una libreria equivalente per Android?

2. Ho letto su OkHTTP e Retrofit di Square, oltre a Volley, ma non ho ancora esperienza di sviluppo con loro. Spero che qualcuno possa fornire alcuni esempi concreti dei migliori casi d'uso per ciascuno. Da quello che ho letto, sembra che OkHTTP sia il più robusto dei tre e possa gestire i requisiti di questo progetto (menzionato sopra).

Spero che qualcuno possa fornire alcuni esempi concreti dei migliori casi d'uso per ciascuno.

Utilizzare Retrofit se si sta comunicando con un servizio Web. Utilizzare la libreria peer Picasso se si stanno scaricando immagini. Utilizzare OkHTTP se è necessario eseguire operazioni HTTP esterne a Retrofit / Picasso.

Volley compete approssimativamente con Retrofit + Picasso. Tra i lati positivi, è una libreria. Sul lato negativo, è una libreria priva di documenti, non supportata, "getta il codice sul muro e fai una presentazione I | O su di esso".

EDIT - Volley è ora ufficialmente supportato da Google. Si prega di fare riferimento alla Guida per gli sviluppatori di Google

Da quello che ho letto, sembra che OkHTTP sia il più robusto dei 3

Retrofit utilizza automaticamente OkHTTP se disponibile. C'è un Gist di Jake Wharton che collega Volley a OkHTTP.

e potrebbe gestire i requisiti di questo progetto (menzionato sopra).

Probabilmente non ne userete nessuno per "download in streaming di audio e video", secondo la definizione convenzionale di "streaming". Al contrario, il framework multimediale di Android gestirà quelle richieste HTTP per te.

Detto questo, se hai intenzione di provare a fare il tuo streaming basato su HTTP, OkHTTP dovrebbe gestire quello scenario; Non ricordo quanto Volley avrebbe gestito questo scenario. Né Retrofit né Picasso sono progettati per questo.

Guardando la prospettiva Volley qui ci sono alcuni vantaggi per le tue esigenze:

Volley, da un lato, è totalmente concentrato sulla gestione di singole richieste HTTP di piccole dimensioni. Quindi, se la gestione delle richieste HTTP presenta alcune stranezze, Volley probabilmente ha un gancio per te. Se, d'altra parte, hai una stranezza nella gestione delle immagini, l'unico vero gancio che hai è ImageCache . "Non è niente, ma non è molto!". ma presenta altri vantaggi come Una volta definite le richieste, utilizzarle da un frammento o un'attività è indolore a differenza di AsyncTask parallele

Pro e contro di Volley:

Cosa c'è di bello in Volley?

• La parte di rete non è solo per le immagini. Volley è pensato per essere parte integrante del tuo back-end. Per un nuovo progetto basato su un semplice servizio REST, questa potrebbe essere una grande vittoria.

• NetworkImageView è più aggressivo nella pulizia delle richieste rispetto a Picasso e più conservativo nei suoi schemi di utilizzo dei GC. NetworkImageView si basa esclusivamente su forti riferimenti di memoria e pulisce tutti i dati delle richieste non appena viene effettuata una nuova richiesta per ImageView o non appena ImageView si sposta dallo schermo.

• Prestazione. Questo post non valuterà questa affermazione, ma hanno chiaramente preso cura di essere giudiziosi nei loro schemi di utilizzo della memoria. Volley si impegna inoltre a richiamare in batch il thread principale per ridurre il cambio di contesto.

• Apparentemente anche Volley ha dei futuri. Dai un'occhiata a RequestFuture se sei interessato.

• Se hai a che fare con immagini compresse ad alta risoluzione, Volley è l'unica soluzione che funziona bene.

• Volley può essere utilizzato con Okhttp (la nuova versione di Okhttp supporta NIO per prestazioni migliori)

• Volley gioca bene con il ciclo di vita delle attività.

Problemi con Volley:
dato che Volley è nuovo, poche cose non sono ancora supportate, ma è stato risolto.

1. Richieste in più parti (soluzione: https://github.com/vinaysshenoy/enhanced-volley )

2. il codice di stato 201 viene considerato come errore, i codici di stato da 200 a 207 ora hanno una risposta corretta. (Risolto: https://github.com/Vinayrraj/CustomVolley )

   Aggiornamento: nell'ultima versione di Google volley, il bug dei codici di stato 2XX è stato corretto ora! Grazie a Ficus Kirkpatrick!

3. è meno documentato ma molte persone supportano la pallavolo in github, qui è possibile trovare documentazione simile a Java . Sul sito Web degli sviluppatori Android, è possibile trovare una guida per la trasmissione dei dati di rete tramite Volley . E il codice sorgente di volley è disponibile su Google Git

4. Per risolvere / modificare la politica di reindirizzamento di Volley Framework utilizzare Volley con OkHTTP (CommonsWare sopra menzionato)

Puoi anche leggere questo Confronto del caricamento dell'immagine di Volley con Picasso

Ammodernamento:

È rilasciato da Square , offre API REST molto facili da usare (Aggiornamento: Voila! Con supporto NIO)

Pro di retrofit:

• Rispetto a Volley, il codice API REST di Retrofit è breve e fornisce un'eccellente documentazione API e ha un buon supporto nelle comunità! È molto facile da aggiungere ai progetti.

• Possiamo usarlo con qualsiasi libreria di serializzazione, con gestione degli errori.

Aggiornamento: - Ci sono molte modifiche molto buone in Retrofit 2.0.0-beta2

• la versione 1.6 di Retrofit con OkHttp 2.0 ora dipende da Okio per supportare java.io e java.nio, il che rende molto più semplice l'accesso, l'archiviazione e l'elaborazione dei dati utilizzando ByteString e Buffer per fare alcune cose intelligenti per risparmiare CPU e memoria. (FYI: Questo mi ricorda la libreria OIN di Koush con supporto NIO!) Possiamo usare Retrofit insieme a RxJava per combinare e concatenare le chiamate REST usando rxObservables per evitare brutte catene di callback (per evitare l'inferno di callback !!) .

Contro di Retrofit per la versione 1.6:

• La funzionalità di gestione degli errori relativi alla memoria non è buona (nelle versioni precedenti di Retrofit / OkHttp) non sono sicuro che sia migliorato con Okio con supporto Java NIO.

• L'assistenza minima di threading può comportare il richiamo dell'inferno se lo utilizziamo in modo improprio.

(Tutti i contro sopra sono stati risolti nella nuova versione di Retrofit 2.0 beta)

================================================== ======================

Aggiornare:

Benchmark delle prestazioni di Android Async vs Volley vs Retrofit (millisecondi, valore inferiore è migliore):

(I FYI sopra le informazioni sui benchmark di retrofit miglioreranno con il supporto java NIO perché la nuova versione di OKhttp dipende dalla libreria NIO Okio)

In tutti e tre i test con ripetute variabili (da 1 a 25 volte), Volley è stata ovunque dal 50% al 75% più veloce. Il retrofit ha registrato un impressionante aumento del 50% -90% rispetto agli AsyncTask, colpendo lo stesso endpoint lo stesso numero di volte. Nella suite di test Dashboard, questo si è tradotto nel caricamento / analisi dei dati più rapidamente di alcuni secondi. Questa è una grande differenza nel mondo reale. Al fine di rendere i test equi, i tempi per AsyncTasks / Volley includevano l'analisi JSON mentre Retrofit lo fa automaticamente.

RetroFit vince nel test benchmark!

Alla fine, abbiamo deciso di utilizzare Retrofit per la nostra applicazione. Non solo è incredibilmente veloce, ma si adatta abbastanza bene alla nostra architettura esistente. Siamo stati in grado di creare un'interfaccia di callback padre che esegue automaticamente la gestione degli errori, la memorizzazione nella cache e l'impaginazione con uno sforzo minimo o nullo per le nostre API. Per unirci in Retrofit, abbiamo dovuto rinominare le nostre variabili per rendere i nostri modelli conformi GSON, scrivere alcune semplici interfacce, eliminare le funzioni dalla vecchia API e modificare i nostri frammenti per non usare AsyncTasks. Ora che abbiamo alcuni frammenti completamente convertiti, è abbastanza indolore. Ci sono stati alcuni problemi e problemi in crescita che abbiamo dovuto superare, ma nel complesso è andato tutto liscio. All'inizio, abbiamo riscontrato alcuni problemi / bug tecnici, ma Square ha una fantastica community Google+ che è stata in grado di aiutarci.

Quando usare Volley ?!

Possiamo usare Volley quando dobbiamo caricare immagini e consumare API REST !, per molte richieste n / n è necessario il sistema di accodamento delle chiamate di rete! anche Volley ha una migliore gestione degli errori relativi alla memoria rispetto a Retrofit!

OkHttp può essere utilizzato con Volley, Retrofit utilizza OkHttp per impostazione predefinita! Ha il supporto SPDY , pool di connessioni, cache del disco, compressione trasparente! Di recente, ha ottenuto il supporto di Java NIO con la libreria Okio .

Fonte, credito: volley-vs-retrofit di Mr. Josh Ruesch

Nota: lo streaming dipende dal tipo di streaming desiderato come RTSP / RTCP.

RoboSpice vs. raffica

Da https://groups.google.com/forum/#!topic/robospice/QwVCfY_glOQ

• RoboSpice (RS) è basato sui servizi e più rispettoso della filosofia Android rispetto a Volley. Volley è basato su thread e questo non è il modo in cui l'elaborazione in background dovrebbe avvenire su Android. Alla fine, puoi scavare entrambe le librerie e scoprire che sono abbastanza simili, ma il nostro modo di eseguire l'elaborazione in background è più orientato verso Android, ci consente, ad esempio, di dire agli utenti che RS sta effettivamente facendo qualcosa in background, che sarebbe difficile per la pallavolo (in realtà non lo fa affatto).
• RoboSpice e volley offrono entrambe funzionalità interessanti come la definizione delle priorità, le politiche di riprova, la richiesta di cancellazione. Ma RS offre di più: una cache più avanzata e che è una grande, con la gestione della cache, l'aggregazione delle richieste, più funzionalità come la sostituzione di una richiesta in sospeso, la gestione della scadenza della cache senza fare affidamento sulle intestazioni del server, ecc.
• RoboSpice fa di più al di fuori del thread dell'interfaccia utente: volley diserializzerà i tuoi POJO sul thread principale, il che è orribile per la mia mente. Con RS la tua app sarà più reattiva.
• In termini di velocità, abbiamo sicuramente bisogno di metriche. RS è diventato super veloce ora, ma non abbiamo ancora cifre da mettere qui. Volley dovrebbe teoricamente essere un po 'più veloce, ma RS ora è enormemente parallelo ... chi lo sa?
• RoboSpice offre un'ampia gamma di compatibilità con estensioni. Puoi usarlo con okhttp, retrofit, ormlite (beta), jackson, jackson2, gson, serializzatore xml, client http di google, spring android ... Abbastanza. Volley può essere usato con ok http e usa gson. questo è tutto.
• Volley offre più zucchero UI che RS. Volley fornisce NetworkImageView, RS fornisce un adattatore per l'elenco di spic. In termini di funzionalità non è così lontano, ma credo che Volley sia più avanzato su questo argomento.
• Più di 200 bug sono stati risolti in RoboSpice dalla sua prima versione. È abbastanza robusto e utilizzato pesantemente in produzione. Volley è meno maturo ma la sua base di utenti dovrebbe crescere rapidamente (effetto Google).
• RoboSpice è disponibile su Maven Central. Volley è difficile da trovare;)

AFNetworking per Android:

La rete Android veloce è qui

La libreria di rete Android veloce supporta tutti i tipi di richiesta HTTP / HTTPS come GET, POST, DELETE, HEAD, PUT, PATCH

Fast Android Networking Library supporta il download di qualsiasi tipo di file

La libreria di rete Android veloce supporta il caricamento di qualsiasi tipo di file (supporta il caricamento multipart)

La libreria di rete Android veloce supporta l'annullamento di una richiesta

La libreria di rete Android veloce supporta l'impostazione della priorità per qualsiasi richiesta (LOW, MEDIUM, HIGH, IMMEDIATE)

La libreria di rete Android veloce supporta RxJava

Poiché utilizza OkHttp come livello di rete, supporta:

Fast Android Networking Library supporta il supporto HTTP / 2 che consente a tutte le richieste allo stesso host di condividere un socket

La libreria di rete Android veloce utilizza il pool di connessioni che riduce la latenza delle richieste (se HTTP / 2 non è disponibile)

GZIP trasparente riduce le dimensioni del download

La libreria di rete Android veloce supporta la memorizzazione nella cache delle risposte che evita completamente la rete per richieste ripetute

Grazie: la biblioteca è stata creata da me

Async HTTP client loopj vs. Volley

Le specifiche del mio progetto sono piccole richieste REST HTTP, ogni 1-5 minuti.

Uso a lungo un client HTTP asincrono (1.4.1). Le prestazioni sono migliori rispetto all'utilizzo di httpClient Vanilla Apache o di una connessione URL HTTP. Comunque, la nuova versione della libreria non funziona per me: libreria tra eccezioni taglia catena di callback.

Leggere tutte le risposte mi ha motivato a provare qualcosa di nuovo. Ho scelto la libreria HTTP Volley.

Dopo averlo usato per qualche tempo, anche senza test, vedo chiaramente che il tempo di risposta è sceso a 1,5x, 2x Volley.

Forse Retrofit è meglio di un client HTTP asincrono? Ho bisogno di provarlo. Ma sono sicuro che Volley non fa per me.

Solo per aggiungere un po 'alla discussione dalla mia esperienza di lavoro con Volley:

1. Volley non gestisce upload o download in streaming in alcun senso. Cioè, l'intero corpo della richiesta deve essere in memoria e non è possibile utilizzare un OutputStreamper scrivere il corpo della richiesta nel socket sottostante, né è possibile utilizzare un InputStreamper leggere il corpo della risposta, come di base HttpURLConnection. Quindi, Volley è una cattiva scelta per caricare o scaricare file di grandi dimensioni. Le tue richieste e risposte dovrebbero essere piccole. Questa è una delle maggiori limitazioni di Volley che ho incontrato personalmente. Per quello che vale, OkHttp ha interfacce per lavorare con i flussi.

2. La mancanza di documentazione ufficiale è fastidiosa, anche se sono stato in grado di aggirare il problema leggendo il codice sorgente, che è abbastanza facile da seguire. La cosa più fastidiosa è che, per quanto posso dire, Volley non ha versioni ufficiali di rilascio e nessun artefatto Maven o Gradle, e quindi gestirlo come dipendenza diventa più un mal di testa di, per esempio, una delle librerie Square ha rilasciato . Basta clonare un repository, costruire un barattolo e sei da solo. Alla ricerca di una correzione di bug? Prendi e spero che sia lì. Potresti avere anche altre cose; non sarà documentato. A mio avviso, ciò significa che Volley è una libreria di terze parti non supportata, anche se la base di codice è ragionevolmente attiva. Caveat emptor.

3. Come nit, avere il Content-Type legato al tipo di classe / richiesta (JsonObjectRequest, ImageRequest, ecc.) È un po 'imbarazzante e riduce un po' la flessibilità del codice chiamante, poiché sei legato alla gerarchia del tipo di richiesta esistente di Volley. Mi piace la semplicità di impostare Content-Type come un'intestazione come qualsiasi altra (non farlo con Volley, comunque; finirai con due intestazioni di Content-Type!). Questa è solo la mia opinione personale, e può essere risolta.

Questo non vuol dire che Volley non abbia alcune funzioni utili. Certamente. Criteri di riprova facilmente personalizzabili, memorizzazione nella cache trasparente, API di annullamento e supporto per la pianificazione delle richieste e connessioni simultanee sono ottime funzionalità. Sappi solo che non è destinato a tutti i casi di utilizzo HTTP (vedi l'articolo 1 sopra) e che ci sono alcuni mal di testa coinvolti nel mettere Volley in uso di produzione nella tua app (elemento 2).

Recentemente ho trovato una lib chiamata ion che porta un piccolo extra sul tavolo.

ion ha il supporto integrato per il download di immagini integrato con ImageView, JSON (con l'aiuto di GSON), i file e un supporto di threading UI molto utile.

Lo sto usando su un nuovo progetto e finora i risultati sono stati buoni. Il suo utilizzo è molto più semplice di Volley o Retrofit.

Aggiungendo alla risposta accettata e cosa ha detto LOG_TAG .... affinché Volley analizzi i dati in un thread in background, è necessario eseguire la sottoclasse Request<YourClassName>poiché il onResponsemetodo viene chiamato sul thread principale e l'analisi sul thread principale potrebbe causare un ritardo dell'interfaccia utente se la risposta è grande. Leggi qui su come farlo.

Retrofit 1.9.0 vs. RoboSpice

Sto usando entrambi nella mia app.

Robospice funziona più velocemente di Retrofit ogni volta che analizzo la classe JSON nidificata. Perché Spice Manger farà tutto per te. In Retrofit è necessario creare GsonConverter e deserializzarlo.

Ho creato due frammenti nella stessa attività e chiamato allo stesso tempo con due stessi tipi di URL.

09-23 20:12:32.830  16002-16002/com.urbanpro.seeker E/RETROFIT﹕   RestAdapter Init
09-23 20:12:32.833  16002-16002/com.urbanpro.seeker E/RETROFIT﹕ calling the method
09-23 20:12:32.837  16002-16002/com.urbanpro.seeker E/ROBOSPICE﹕ initialzig spice manager
09-23 20:12:32.860  16002-16002/com.urbanpro.seeker E/ROBOSPICE﹕ Executing the method
09-23 20:12:33.537  16002-16002/com.urbanpro.seeker E/ROBOSPICE﹕ on SUcceess
09-23 20:12:33.553  16002-16002/com.urbanpro.seeker E/ROBOSPICE﹕ gettting the all contents
09-23 20:12:33.601  16002-21819/com.urbanpro.seeker E/RETROFIT﹕ deseriazation starts
09-23 20:12:33.603  16002-21819/com.urbanpro.seeker E/RETROFIT﹕ deseriazation ends

E ancora un'altra opzione: https://github.com/apptik/jus

• È modulare come Volley, ma è più esteso e la documentazione sta migliorando, supportando immediatamente stack e convertitori HTTP diversi
• Ha un modulo per generare mappature dell'interfaccia API del server come Retrofit
• Ha anche il supporto JavaRx

E molte altre utili funzioni come marker, trasformatori, ecc.