android - retrofit volley




Android網絡庫比較:OkHTTP,Retrofit和Volley (7)

我希望有人能提供一些最佳用例的具體例子。

如果您正在與Web服務通信,請使用Retrofit。 如果您正在下載圖像,請使用對等庫Picasso。 如果您需要執行位於Retrofit / Picasso之外的HTTP操作,請使用OkHTTP。

Volley大致與Retrofit + Picasso競爭。 另一方面,它是一個圖書館。 在負面方面,它是一個沒有記錄的,不受支持的,“將代碼放在牆上並對其執行I | O演示”庫。

編輯 - Volley現在正式得到Google的支持。 請參閱Google開發人員指南

從我讀過的內容來看,好像OkHTTP是3中最強大的

如果可用,Retrofit會自動使用OkHTTP。 Jake Wharton有一個將Volley和OkHTTP連接起來的Gist

並可以處理該項目的要求(如上所述)。

按照傳統的“流媒體”的定義,你可能不會使用它們來“流式下載音頻和視頻”。 相反,Android的媒體框架將為您處理這些HTTP請求。

話雖如此,如果您打算嘗試自己的基於HTTP的流媒體,OkHTTP應該處理這種情況; 我不記得Volley會如何處理這種情況。 Retrofit和Picasso都不是為此設計的。

來自iOS開發人員學習Android的兩部分問題,涉及Android項目,該項目將提出從JSON到圖像到流式下載音頻和視頻的各種請求:

  1. 在iOS上,我廣泛使用了AFNetworking項目。 有沒有一個等效的Android庫?

  2. 我已經閱讀了Square上的OkHTTPRetrofit以及Volley但還沒有與他們一起開發經驗。 我希望有人能提供一些最佳用例的具體例子。 從我讀過的內容來看,似乎OkHTTP是三者中最強大的,並且可以處理這個項目的需求(如上所述)。


改裝1.9.0與RoboSpice

我在我的應用程序中使用了兩者。

每當我解析嵌套的JSON類時,Robospice的工作速度都比翻新速度快。 因為香料經理會為你做所有事情。 在Retrofit中,您需要創建GsonConverter並將其反序列化。

我在同一活動中創建了兩個片段,並使用兩種相同類型的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

異步HTTP客戶端loopj與Volley

我的項目的細節是小的HTTP REST請求,每隔1-5分鐘。

我長時間使用異步HTTP客戶端(1.4.1)。 性能比使用香草Apache httpClient或HTTP URL連接更好。 無論如何,這個庫的新版本並不適合我:庫間例外的回調鏈。

閱讀所有答案激勵我嘗試新事物。 我選擇了Volley HTTP庫。

使用一段時間後,即使沒有進行測試,我也清楚地看到響應時間縮短到1.5倍,2倍排氣。

也許Retrofit比異步HTTP客戶端更好? 我需要嘗試一下。 但我相信沃利不適合我。


只需要加入我在與Volley合作的經驗中的討論:

  1. Volley在任何意義上都不處理流式上傳或下載。 也就是說,整個請求體必須位於內存中,並且不能使用OutputStream將請求體寫入底層套接字,也不能像基本的HttpURLConnection那樣使用InputStream讀取響應體。 所以,Volley是上傳或下載大文件的不好選擇。 您的請求和回复應該很小。 這是我親自遇到的Volley最大的限制之一。 對於它的價值,OkHttp確實有用於處理流的接口。

  2. 官方文檔的缺乏令人討厭,儘管我可以通過閱讀源代碼來解決這個問題,這很容易遵循。 更令人煩惱的是,據我所知,Volley沒有官方發布版本,也沒有Maven或Gradle神器,因此將其作為依賴關係變得更加頭疼,比任何Square已發布的庫。 你只需克隆一個回購站,建立一個罐子,然後你就可以自己做。 尋找錯誤修復? 取,並希望它在那裡。 你也可能會得到一些其他的東西; 它不會被記錄。 在我看來,這實際上意味著Volley是一個不受支持的第三方庫,即使代碼庫相當活躍。 買者自負。

  3. 作為一個nit,將Content-Type綁定到類/請求類型(JsonObjectRequest,ImageRequest等)是有點笨拙的,並且會降低調用代碼的靈活性,因為您與Volley的現有的Request類型層次結構綁定在一起。 我喜歡將Content-Type設置為任何其他標題的簡單性(順便說一下,不要使用Volley來做這件事;最終會有兩個Content-Type標頭!)。 但這只是我個人的看法,而且可以解決。

這並不是說Volley沒有一些有用的功能。 它當然會。 輕鬆定制的重試策略,透明緩存,取消API以及對請求調度和並發連接的支持都是很好的功能。 只要知道它不適用於所有HTTP使用情況(請參閱上面的第1項),並且在您的應用程序中使用Volley進行生產使用(第2項)時會遇到一些麻煩。


我最近發現了一個名為ion的lib,它為表格帶來了一些額外的功能。

ion內置支持與ImageView集成的圖像下載,JSON(借助GSON),文件和非常方便的UI線程支持。

我在一個新項目中使用它,迄今為止結果一直不錯。 它的使用比Volley或Retrofit簡單得多。


添加到接受的答案和什麼LOG_TAG說...對於Volley在後台線程中解析數據,您必須onResponse Request<YourClassName>因為onResponse方法在主線程上調用,並且在主線程上解析可能會導致UI如果你的反應很大,就會滯後。 here閱讀如何做到這一點。


還有另一種選擇: https://github.com/apptik/jushttps://github.com/apptik/jus

  • 它像Volley這樣模塊化,但更多擴展和文檔正在改進,支持不同的HTTP堆棧和轉換器
  • 它有一個模塊來生成服務器API接口映射,如Retrofit
  • 它也有JavaRx支持

還有許多其他方便的功能,如標記,變壓器等







android-networking