標簽（空格分隔）： Android
我們來先說一個常識性的錯誤：
volley, retrofit, android-async-http 幫你封裝了具體的請求，線程切換以及數(shù)據(jù)轉(zhuǎn)換。他們是網(wǎng)絡底層實現(xiàn)庫的封裝庫
而OkHttp 是基于http協(xié)議封裝的一套請求客戶端，雖然它也可以開線程，但根本上它更偏向真正的請求，跟HttpClient,HttpUrlConnection的職責是一樣的。所以不要混淆
網(wǎng)絡底層的實現(xiàn)庫：
HttpURLConnection：是Java中的標準類，是對Java中socket的封裝。
Httpclient：是Apache的開源框架，是對HttpURLConnection的封裝。
Okhttp：是Square公司開發(fā)的開源網(wǎng)絡訪問框架，是對socket的封裝。
以下是Stay的見解：
作者：Stay Zhang
鏈接：https://www.zhihu.com/question/35189851/answer/93973482
來源：知乎
著作權歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權，非商業(yè)轉(zhuǎn)載請注明出處。
首先，我想即使你單純使用OkHttp，還是會再包一層的，這樣就等價于Volley之流的框架，只是封裝的好與壞而已。
android-async-http內(nèi)部實現(xiàn)是基于HttpClient, 想必你肯定知道6.0之后HttpClient是不是系統(tǒng)自帶的了，不過它在最近的更新中將HttpClient的所有代碼copy了一份進來，所以還能使用。
Volley是官方出的，volley在設計的時候是將具體的請求客戶端做了下封裝：HurlStack，也就是說可以支持HttpUrlConnection, HttpClient, OkHttp，相當于模版模式吧，這樣解耦還是非常方便的，可以隨意切換，如果你之前使用過Volley，并習慣使用，那直接寫個OkHttp擴展就行了。
Retrofit因為也是square出的，所以大家可能對它更崇拜些。Retrofit的跟Volley是一個套路，但解耦的更徹底:比方說通過注解來配置請求參數(shù)，通過工廠來生成CallAdapter，Converter，你可以使用不同的請求適配器(CallAdapter), 比方說RxJava，Java8, Guava。你可以使用不同的反序列化工具(Converter)，比方說json, protobuff, xml, moshi等等。
炒雞解耦，里面涉及到超多設計模式，個人覺得是很經(jīng)典的學習案例。雖然支持Java8， Guava你可能也不需要用到。xml，protobuff等數(shù)據(jù)格式你也可能不需要解析。but，萬一遇到鬼了呢。
至于性能上，個人覺得這完全取決于請求client，也就是okhttp的性能，跟這些封裝工具沒太大關系。
至于RxJava，最好充分理解其原理之后再使用，別人云亦云，特別team人數(shù)多的情況下，總得有個完全精通的吧，萬一掉坑里了呢。。。
就說這么多啦，選最適合項目的，選大多數(shù)人選擇的，選簡單易用的，就這么個標準。
一片綜合性很強的文章，包括Http原理，各個網(wǎng)絡庫比較，圖片庫比較，圖床
總結
終于到了總結的時候了，一般來說，這都是干貨的時候，哈哈～
Volley對比優(yōu)勢
1.緩存處理；Volley自己就提供了一套完整的緩存處理方案，默認使用文件存儲到磁盤中，并且提供了TTL SOFTTTL這么體貼入微的機制；一個Request可能存在兩個Response,對于需要顯示緩存，再顯示網(wǎng)絡數(shù)據(jù)的場景真是爽的不要不要的。而Retrofit中并沒有提供任何和緩存相關的方案。
2.代碼簡單，可讀性高。Volley的代碼是寫的如此的直接了當，讓你看起代碼來都不需要喝口茶，這樣的好處是我們我們需要修改代碼時不太容易引入bug....囧
3.同一個請求如果同時都在發(fā)送，那么實際上只會有一個請求真正發(fā)出去， 其它的請求會等待這個結果回來，算小小優(yōu)化吧。實際上這種場景不是很多哈，如果有，可能是你代碼有問題...
4.請求發(fā)送的時候提供了優(yōu)先級的概念，但是是只保證順序出去，不保證順序回來，然并卵。
5.支持不同的Http客戶端實現(xiàn)，默認提供了HttpClient和HttpUrlConnection的實現(xiàn)，而Retrofit在2.0版本之后，鎖死在OkHttp上了。
6.支持請求取消
Retrofit對比優(yōu)勢
1.發(fā)送請求真簡單，定義一個方法就可以了，這么簡單的請求框架還有誰？Volley?
2.較好的可擴展性，Volley中每一個新建一個Request時都需要指定一個父類，告知序列化數(shù)據(jù)的方式，而Retrofit中只需要在配置時，指定各種轉(zhuǎn)換器即可。CallAdapter的存在，可以使你隨意代理調(diào)用的Call，不錯不錯。。。
3.OkHttpClient自帶并發(fā)光環(huán)，而Volley中的工作線程是自己維護的，那么就有可能存在線程由于異常退出之后，沒有下一個工作線程補充的風險(線程池可以彌補這個缺陷)，這在Retrofit中不存在，因為即使有問題，這個鍋也會甩給OkHttp，嘿嘿
4.支持請求取消
再次說明的是，Retrofit沒有對緩存提供任何額外支持，也就是說它只能通過HTTP的Cache control做文件存儲，這樣就會有一些問題：
1.需要Server通過Cache control頭部來控制緩存，需要修改后臺代碼
2.有些地方比較適合使用數(shù)據(jù)庫來存儲，比如關系存儲，此時，Retrofit就無能為力了
3.緩存不在我們的控制范圍之內(nèi)，而是完全通過OkHttp來管理，多少有些不便，比如我們要刪除某一個指定的緩存，或者更新某一個指定緩存，代碼寫起來很別扭(自己hack請求頭里面的cache contrl)
而在我們項目的實際使用過程中，緩存是一個比較重要的角色，Retrofit對緩存的支持度不是很好，真是讓人傷心。。。
但是，我們還是覺得在使用中Retrofit真心比較方便，容易上手，通過注解代碼可讀性和可維護性提升了N個檔次，幾乎沒有樣板代碼(好吧，如果你覺得每個請求都需要定義一個方法，那這也算。。)，所以最后的決定是選擇Retrofit。
有人說了，Volley中的兩次響應和緩存用起來很happy怎么辦？嗯，我們會修改Retrofit，使它支持文件存儲和ORM存儲，并將Volley的緩存 網(wǎng)絡兩次響應回調(diào)移接過來，這個項目正在測試階段，待我們項目做完小白鼠，上線穩(wěn)定之后，我會把代碼開源，大家敬請關注。
文／楚云之南（簡書作者）
原文鏈接：http://www.itdecent.cn/p/07dac989272c
著作權歸作者所有，轉(zhuǎn)載請聯(lián)系作者獲得授權，并標注“簡書作者”。
