Perbandingan perpustakaan jaringan Android: OkHTTP, Retrofit, dan Volley [ditutup]

Pertanyaan dua bagian dari pengembang iOS yang mempelajari Android, mengerjakan proyek Android yang akan membuat berbagai permintaan dari JSON ke gambar hingga streaming unduhan audio dan video:

1. Di iOS saya telah menggunakan proyek AFNetworking secara luas. Apakah ada perpustakaan yang setara untuk Android?

2. Saya sudah membaca tentang OkHTTP dan Retrofit oleh Square, serta Volley tetapi belum memiliki pengalaman mengembangkannya. Saya berharap seseorang dapat memberikan beberapa contoh nyata kasus penggunaan terbaik untuk masing-masing. Dari apa yang saya baca, sepertinya OkHTTP adalah yang paling kuat dari ketiganya, dan bisa menangani persyaratan proyek ini (disebutkan di atas).

Saya berharap seseorang dapat memberikan beberapa contoh nyata kasus penggunaan terbaik untuk masing-masing.

Gunakan Retrofit jika Anda berkomunikasi dengan layanan Web. Gunakan perpustakaan rekan Picasso jika Anda mengunduh gambar. Gunakan OkHTTP jika Anda perlu melakukan operasi HTTP yang terletak di luar Retrofit / Picasso.

Volley secara kasar bersaing dengan Retrofit + Picasso. Di sisi positifnya, ini adalah satu perpustakaan. Di sisi minus, itu adalah salah satu perpustakaan tidak berdokumen, tidak didukung, "melemparkan kode di dinding dan melakukan presentasi I | O di atasnya".

EDIT - Volley sekarang secara resmi didukung oleh Google. Silakan merujuk Panduan Pengembang Google

Dari apa yang saya baca, sepertinya OkHTTP adalah yang paling kuat dari 3

Retrofit menggunakan OkHTTP secara otomatis jika tersedia. Ada inti dari Jake Wharton yang menghubungkan Volley ke OkHTTP.

dan dapat menangani persyaratan proyek ini (disebutkan di atas).

Mungkin Anda tidak akan menggunakannya untuk "streaming unduhan audio dan video", dengan definisi "streaming" konvensional. Sebagai gantinya, kerangka kerja media Android akan menangani permintaan HTTP tersebut untuk Anda.

Yang sedang berkata, jika Anda akan mencoba melakukan streaming berbasis HTTP Anda sendiri, OkHTTP harus menangani skenario itu; Saya tidak ingat seberapa baik Volley menangani skenario itu. Retrofit maupun Picasso tidak dirancang untuk itu.

Melihat perspektif Volley di sini adalah beberapa keuntungan untuk kebutuhan Anda:

Volley, di satu sisi, benar-benar fokus pada penanganan permintaan HTTP kecil dan individu. Jadi jika penanganan permintaan HTTP Anda memiliki beberapa keanehan, Volley mungkin memiliki pengait untuk Anda. Jika, di sisi lain, Anda memiliki kekhasan dalam penanganan gambar Anda, satu-satunya pengait yang Anda miliki adalah ImageCache . "Bukan apa-apa, tapi juga tidak banyak!" tetapi memiliki lebih banyak keuntungan lain seperti Setelah Anda mendefinisikan permintaan Anda, menggunakannya dari dalam fragmen atau aktivitas tidak menimbulkan rasa sakit tidak seperti AsyncTasks paralel

Pro dan kontra Volley:

Jadi apa yang baik tentang Volley?

• Bagian jaringan bukan hanya untuk gambar. Voli dimaksudkan untuk menjadi bagian integral dari ujung belakang Anda. Untuk proyek baru yang didasarkan pada layanan REST sederhana, ini bisa menjadi kemenangan besar.

• NetworkImageView lebih agresif tentang pembersihan permintaan daripada Picasso, dan lebih konservatif dalam pola penggunaan GC. NetworkImageView mengandalkan secara eksklusif pada referensi memori yang kuat, dan membersihkan semua data permintaan segera setelah permintaan baru dibuat untuk ImageView, atau segera setelah itu ImageView bergerak dari layar.

• Performa. Posting ini tidak akan mengevaluasi klaim ini, tetapi mereka jelas berhati-hati untuk bijaksana dalam pola penggunaan memori mereka. Volley juga berupaya untuk melakukan batch panggilan balik ke utas utama untuk mengurangi pengalihan konteks.

• Volley rupanya memiliki masa depan juga. Periksa RequestFuture jika Anda tertarik.

• Jika Anda berurusan dengan gambar terkompresi resolusi tinggi, Volley adalah satu-satunya solusi di sini yang bekerja dengan baik.

• Volley dapat digunakan dengan Okhttp (Okhttp versi baru mendukung NIO untuk kinerja yang lebih baik)

• Volley bermain bagus dengan siklus hidup Aktivitas.

Masalah dengan Volley:
Karena Volley baru, beberapa hal belum didukung, tetapi sudah diperbaiki.

1. Permintaan Multi Bagian (Solusi: https://github.com/vinaysshenoy/enhanced-volley )

2. kode status 201 dianggap sebagai kesalahan, Kode status dari 200 hingga 207 adalah respons yang berhasil sekarang. (Tetap: https://github.com/Vinayrraj/CustomVolley )

   Pembaruan: dalam rilis terbaru Google volley, bug kode Status 2XX diperbaiki sekarang! Terima kasih kepada Ficus Kirkpatrick!

3. itu kurang didokumentasikan tetapi banyak orang yang mendukung voli di github, dokumentasi seperti java dapat ditemukan di sini . Di situs web pengembang android, Anda dapat menemukan panduan untuk Mengirimkan Data Jaringan Menggunakan Volley . Dan kode sumber voli dapat ditemukan di Google Git

4. Untuk memecahkan / mengubah Kebijakan Pengalihan Volley Framework gunakan Volley dengan OkHTTP (CommonsWare disebutkan di atas)

Anda juga dapat membaca gambar Membandingkan Volley ini dengan Picasso

Retrofit:

Ini dirilis oleh Square , Ini menawarkan sangat mudah untuk menggunakan REST API (Perbarui: Voila! Dengan dukungan NIO)

Pro Retrofit:

• Dibandingkan dengan Volley, kode REST API Retrofit singkat dan memberikan dokumentasi API yang sangat baik dan memiliki dukungan yang baik di masyarakat! Sangat mudah untuk ditambahkan ke dalam proyek.

• Kita dapat menggunakannya dengan pustaka serialisasi apa pun, dengan penanganan kesalahan.

Pembaruan: - Ada banyak perubahan yang sangat bagus di Retrofit 2.0.0-beta2

• versi 1.6 dari Retrofit dengan OkHttp 2.0 sekarang tergantung pada Okio untuk mendukung java.io dan java.nio yang membuatnya lebih mudah untuk mengakses, menyimpan dan memproses data Anda menggunakan ByteString dan Buffer untuk melakukan beberapa hal pintar untuk menghemat CPU dan memori. (FYI: Ini mengingatkan saya pada perpustakaan OIN Koush dengan dukungan NIO!) Kita dapat menggunakan Retrofit bersama dengan RxJava untuk menggabungkan dan membuat panggilan REST menggunakan rxObservables untuk menghindari rantai panggilan balik yang jelek (untuk menghindari panggilan balik neraka !!) .

Kontra Retrofit untuk versi 1.6:

• Fungsionalitas penanganan kesalahan terkait memori tidak baik (dalam Retrofit / OkHttp versi lama) tidak yakin apakah itu ditingkatkan dengan Okio dengan dukungan Java NIO.

• Bantuan threading minimum dapat mengakibatkan panggilan balik neraka jika kita menggunakan ini dengan cara yang tidak benar.

(Semua Kontra di atas telah dipecahkan dalam versi baru Retrofit 2.0 beta)

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

Memperbarui:

Android Async vs Volley vs Retrofit tolok ukur kinerja (milidetik, nilai lebih rendah lebih baik):

(FYI di atas Retrofit Benchmarks info akan membaik dengan dukungan java NIO karena versi baru OKhttp bergantung pada perpustakaan NIO Okio)

Dalam ketiga tes dengan berbagai pengulangan (1 - 25 kali), Volley berkisar antara 50% hingga 75% lebih cepat. Retrofit bekerja dengan kecepatan 50% hingga 90% lebih cepat daripada AsyncTasks, mencapai titik akhir yang sama beberapa kali. Pada Dashboard test suite, ini diterjemahkan menjadi memuat / mem-parsing data beberapa detik lebih cepat. Itu adalah perbedaan dunia nyata yang sangat besar. Untuk membuat tes adil, waktu untuk AsyncTasks / Volley termasuk JSON parsing sebagai Retrofit melakukannya untuk Anda secara otomatis.

RetroFit Menangkan tes benchmark!

Pada akhirnya, kami memutuskan untuk menggunakan Retrofit untuk aplikasi kami. Tidak hanya sangat cepat, tetapi juga sangat cocok dengan arsitektur yang ada. Kami dapat membuat antarmuka Panggilan Balik induk yang secara otomatis melakukan penanganan kesalahan, caching, dan pagination dengan sedikit atau tanpa upaya untuk API kami. Untuk menggabungkan Retrofit, kami harus mengganti nama variabel kami agar model kami sesuai dengan GSON, menulis beberapa antarmuka sederhana, menghapus fungsi dari API lama, dan memodifikasi fragmen kami untuk tidak menggunakan AsyncTasks. Sekarang kami memiliki beberapa fragmen yang sepenuhnya dikonversi, itu cukup tidak menyakitkan. Ada beberapa rasa sakit dan masalah yang terus meningkat yang harus kami atasi, tetapi secara keseluruhan semuanya berjalan lancar. Pada awalnya, kami mengalami beberapa masalah teknis / bug, tetapi Square memiliki komunitas Google+ yang fantastis yang dapat membantu kami melewatinya.

Kapan menggunakan Volley ?!

Kita dapat menggunakan Volley ketika kita perlu memuat gambar dan juga mengkonsumsi REST API !, sistem antrian panggilan jaringan diperlukan untuk banyak permintaan n / w pada saat yang sama! juga Volley memiliki penanganan kesalahan terkait memori yang lebih baik daripada Retrofit!

OkHttp dapat digunakan dengan Volley, Retrofit menggunakan OkHttp secara default! Memiliki dukungan SPDY , koneksi pooling, caching disk, kompresi transparan! Baru-baru ini, telah mendapat beberapa dukungan java NIO dengan perpustakaan Okio .

Sumber, kredit: volley-vs-retrofit oleh Mr. Josh Ruesch

Catatan: Tentang streaming tergantung pada jenis streaming yang Anda inginkan seperti RTSP / RTCP.

RoboSpice Vs. Tembakan

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

• RoboSpice (RS) berbasis layanan dan lebih menghargai filosofi Android daripada Volley. Volley berbasiskan benang dan ini bukan cara pemrosesan latar belakang yang harus dilakukan di Android. Pada akhirnya, Anda dapat menggali kedua lib dan menemukan bahwa keduanya sangat mirip, tetapi cara kami untuk melakukan pemrosesan latar belakang lebih berorientasi pada Android, memungkinkan kami, misalnya, untuk memberi tahu pengguna bahwa RS sebenarnya melakukan sesuatu di latar belakang, yang akan menjadi sulit untuk voli (sebenarnya tidak sama sekali).
• RoboSpice dan volley keduanya menawarkan fitur-fitur bagus seperti penentuan prioritas, coba lagi kebijakan, permintaan pembatalan. Tetapi RS menawarkan lebih banyak: caching yang lebih canggih dan itu yang besar, dengan manajemen cache, agregasi permintaan, lebih banyak fitur seperti mengganti permintaan yang tertunda, berurusan dengan cache yang kedaluwarsa tanpa mengandalkan header server, dll.
• RoboSpice melakukan lebih banyak di luar UI Thread: volley akan membatalkan deserialisasi POJO Anda di utas utama, yang menurut saya mengerikan. Dengan RS aplikasi Anda akan lebih responsif.
• Dalam hal kecepatan, kita pasti membutuhkan metrik. RS sudah sangat cepat sekarang, tapi kami masih belum memiliki angka untuk ditempatkan di sini. Secara teoritis, volley seharusnya sedikit lebih cepat, tetapi RS sekarang paralel secara masif ... siapa tahu?
• RoboSpice menawarkan rentang kompatibilitas yang luas dengan ekstensi. Anda dapat menggunakannya dengan okhttp, retrofit, ormlite (beta), jackson, jackson2, gson, serializer xml, google http client, spring android ... Cukup banyak. Volley dapat digunakan dengan http ok dan menggunakan gson. itu dia.
• Volley menawarkan lebih banyak gula UI daripada RS. Volley menyediakan NetworkImageView, RS memang menyediakan adaptor spicelist. Dalam hal fitur tidak sejauh ini, tapi saya percaya Volley lebih maju dalam topik ini.
• Lebih dari 200 bug telah dipecahkan di RoboSpice sejak rilis awal. Ini cukup kuat dan banyak digunakan dalam produksi. Volley kurang matang tetapi basis penggunanya harus tumbuh cepat (efek Google).
• RoboSpice tersedia di pakar pusat. Volley sulit ditemukan;)

AFNetworking untuk Android:

Jaringan Android Cepat ada di sini

Perpustakaan Jaringan Android yang cepat mendukung semua jenis permintaan HTTP / HTTPS seperti GET, POST, DELETE, HEAD, PUT, PATCH

Perpustakaan Jaringan Android yang Cepat mendukung pengunduhan jenis file apa pun

Perpustakaan Jaringan Android yang Cepat mendukung pengunggahan semua jenis file (mendukung pengunggahan multi-bagian)

Perpustakaan Jaringan Android yang Cepat mendukung membatalkan permintaan

Perpustakaan Jaringan Android yang Cepat mendukung pengaturan prioritas untuk setiap permintaan (RENDAH, SEDANG, TINGGI, SEGERA)

Pustaka Jaringan Android yang cepat mendukung RxJava

Karena menggunakan OkHttp sebagai lapisan jaringan, ia mendukung:

Pustaka Jaringan Android Cepat mendukung dukungan HTTP / 2 memungkinkan semua permintaan ke host yang sama untuk berbagi soket

Pustaka Jaringan Android Cepat menggunakan penyatuan koneksi yang mengurangi latensi permintaan (jika HTTP / 2 tidak tersedia)

GZIP transparan menyusut ukuran unduhan

Fast Android Networking Library mendukung caching respons yang menghindari jaringan sepenuhnya untuk permintaan yang berulang

Terima kasih: Perpustakaan dibuat oleh saya

Looping klien HTTP async vs. Volley

Spesifikasi proyek saya adalah permintaan HTTP REST kecil, setiap 1-5 menit.

Saya menggunakan klien HTTP async (1.4.1) untuk waktu yang lama. Kinerja lebih baik daripada menggunakan vanilla Apache httpClient atau koneksi URL HTTP. Bagaimanapun, versi baru perpustakaan tidak berfungsi untuk saya: perpustakaan antar pengecualian memotong rantai panggilan balik.

Membaca semua jawaban memotivasi saya untuk mencoba sesuatu yang baru. Saya telah memilih perpustakaan HTTP Volley.

Setelah menggunakannya untuk beberapa waktu, bahkan tanpa tes, saya melihat dengan jelas bahwa waktu respons turun ke 1,5x, 2x Volley.

Mungkin Retrofit lebih baik daripada klien HTTP async? Saya perlu mencobanya. Tapi saya yakin Volley bukan untuk saya.

Hanya untuk menambahkan sedikit ke diskusi dari pengalaman saya bekerja dengan Volley:

1. Volley tidak menangani upload atau unduhan streaming dalam arti apa pun. Artinya, seluruh badan permintaan harus ada dalam memori dan Anda tidak dapat menggunakan a OutputStreamuntuk menulis badan permintaan ke soket yang mendasarinya, Anda juga tidak dapat menggunakan a InputStreamuntuk membaca badan tanggapan, seperti yang HttpURLConnectiondilakukan dasar . Jadi, Volley adalah pilihan yang buruk untuk mengunggah atau mengunduh file besar. Permintaan dan tanggapan Anda harus kecil. Ini adalah salah satu batasan Volley terbesar yang saya temui secara pribadi. Untuk apa nilainya, OkHttp memang memiliki antarmuka untuk bekerja dengan stream.

2. Kurangnya dokumentasi resmi sangat menyebalkan, walaupun saya sudah bisa mengatasinya dengan membaca kode sumber, yang cukup mudah diikuti. Yang lebih menyusahkan adalah, sejauh yang saya tahu, Volley tidak memiliki versi rilis resmi dan tidak ada artifak Maven atau Gradle, dan karenanya mengelolanya sebagai ketergantungan menjadi lebih memusingkan daripada, katakanlah, salah satu perpustakaan yang dirilis Square . Anda hanya mengkloning repo, membuat toples, dan Anda sendiri. Mencari perbaikan bug? Ambil dan harap ada di sana. Anda mungkin mendapatkan beberapa barang lainnya juga; itu tidak akan didokumentasikan. Menurut pendapat saya, ini secara efektif berarti bahwa Volley adalah perpustakaan pihak ke-3 yang tidak didukung, meskipun basis kode cukup aktif. Kaisar peringatan.

3. Sebagai sebuah nit, memiliki Tipe-Konten yang diikat ke kelas / tipe permintaan (JsonObjectRequest, ImageRequest, dll.) Agak canggung dan sedikit mengurangi fleksibilitas kode panggilan, karena Anda terikat dengan hierarki Jenis Permintaan Volley yang ada. Saya suka keterusterangan dengan hanya menetapkan Content-Type sebagai header seperti yang lain (omong-omong, jangan lakukan ini dengan Volley; Anda akan berakhir dengan dua header Tipe-Konten!). Itu hanya pendapat pribadi saya, dan itu bisa diselesaikan.

Itu tidak berarti bahwa Volley tidak memiliki beberapa fitur yang bermanfaat. Tentu saja. Kebijakan coba ulang yang mudah disesuaikan, caching transparan, API pembatalan, dan dukungan untuk penjadwalan permintaan dan koneksi bersamaan adalah fitur hebat. Ketahuilah bahwa itu tidak dimaksudkan untuk semua kasus penggunaan HTTP (lihat item 1 di atas), dan bahwa ada beberapa sakit kepala yang terlibat dalam menempatkan Volley ke dalam penggunaan produksi di aplikasi Anda (item 2).

Saya baru-baru ini menemukan ion yang disebut lib yang membawa sedikit tambahan ke meja.

ion memiliki dukungan bawaan untuk pengunduhan gambar yang terintegrasi dengan ImageView, JSON (dengan bantuan GSON), file dan dukungan threading UI yang sangat praktis.

Saya menggunakannya pada proyek baru dan sejauh ini hasilnya bagus. Penggunaannya jauh lebih sederhana daripada Volley atau Retrofit.

Menambahkan ke jawaban yang diterima dan apa yang LOG_TAG katakan .... agar Volley mem-parsing data Anda di utas latar Anda harus subkelas Request<YourClassName>karena onResponsemetode ini dipanggil pada utas utama dan mengurai pada utas utama dapat menyebabkan UI tertinggal jika respons Anda besar. Baca di sini tentang cara melakukannya.

Retrofit 1.9.0 vs. RoboSpice

Saya menggunakan keduanya di aplikasi saya.

Robospice bekerja lebih cepat daripada Retrofit setiap kali saya mem-parsing kelas JSON bersarang. Karena Spice Manger akan melakukan segalanya untuk Anda. Di Retrofit Anda perlu membuat GsonConverter dan membatalkan deserialisasi.

Saya membuat dua fragmen dalam aktivitas yang sama dan menelepon waktu yang sama dengan dua jenis URL yang sama.

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

Dan satu lagi pilihan: https://github.com/apptik/jus

• Ini modular seperti Volley, tetapi lebih luas dan dokumentasi membaik, mendukung tumpukan HTTP dan konverter yang berbeda
• Ini memiliki modul untuk menghasilkan pemetaan antarmuka server API seperti Retrofit
• Ini juga memiliki dukungan JavaRx

Dan banyak fitur berguna lainnya seperti marker, transformer, dll.