轉載請注明出處 http://www.lxweimin.com/p/cccdf48ea8d4 (作者:韓棟)
本文為譯文,由于譯者水平有限,歡迎拍磚,讀者也可以閱讀原文
【OkHttp3-基本用法,OkHttp3-使用進階(Recipes),OkHttp3-請求器(Calls),OkHttp3-連接(Connections),OkHttp3-攔截器(Interceptor)】
OkHttp客戶端負責接收應用程序發出的請求,并且從服務器獲取響應返回給應用程序。理論聽起來十分簡單,但是在實踐中往往會出現很多意想不到的因素。
請求 (Request)
每一個Http請求都包含一個URL和一個請求方式(比如Get
或者Post
),以及一些請求頭信息。請求也有可能包含一個請求主體:當一個數據流存在指定的content type
類型的請求頭時。
響應 (Responses)
服務器根據請求向你的應用程序返回響應,此響應包含了一個狀態碼(比如200表示請求成功,404表示請求失?。?、響應頭、以及可能包含的響應主體。
重寫請求 (Rewriting Requests)
OkHttp所發出去的每個Http請求都是高等級的:`“fetch me this URL with these headers.”。為了請求的正確性和高效性,OkHttp在數據傳輸之前會自動重寫你的請求。
OkHttp可以自動為你的請求添加一些請求所沒有的請求頭,包括Content-Length
、Transfer-Encoding
、User-Agent
、Host
、Connection
,以及Content-Type
。 如果你的原生請求中沒有定義Accept-Encoding
類型,那么OkHtpp會自動為請求添加Accept-Encoding
類型為Gzip
,以此希望服務端能返回壓縮過的數據。如果應用程序中存在Cookies
,那么OkHttp將會自動將它們添加到你的請求的Cookie
頭部信息中。
OkHttp會將一些請求的響應緩存起來。當其中的一個緩存過期時,OkHttp將會發送一個帶有特定的請求頭信息(比如If-Modified-Since
或者If-None-Match
),并且以Get
方式請求去重新從服務器上獲取數據,并且如果所獲取的新數據與舊的緩存數據不一致,OkHttp將新的數據保存覆蓋掉舊的緩存。
重寫響應 (Rewriting Responses)
如果響應主體是經過壓縮處理,那么OkHttp會自動將響應頭部中的Content-Encoding
和Content-Length
去掉,因為它們并不適用于解壓縮響應主體的操作。
如果一個請求方法為Get
的網絡請求執行成功,那么正常情況下從服務器返回的響應將會和緩存進行合并。
跟蹤請求 (Follow-up Requests)
當你所請求的主機的URL發生改變時,服務器將會返回一個為302
的響應狀態碼以及新的URL信息。OkHttp將會根據這個URL進行重定向操作,并且再次向新的URL發送請求獲取數據。
當你發送請求時,服務器可能會返回一個響應告訴你需要進行身份基本認證,那么OkHttp此時會自動告訴Authenticator
去解決這個認證問題,當然,Authenticator
需要你自己進行配置。Authenticator
處理身份認證通過時會獲取到認證成功憑證,OkHttp會攜帶著它再次向服務器發送原來的請求。
重試請求 (Retrying Requests)
有的時候會發生連接失?。嚎赡苓B接池過期而導致連接斷開,或者請求的服務器無法找到。OkHttp將會不斷嘗試不同的可用線路去發送請求。
請求器 (Calls)
通過重寫、重定向、跟蹤以及重試,你發送的一個簡單的請求可能會變成需要發送多個請求以及接收多次響應之后才能獲得最后的想要的響應。OkHttp
會將這些全部請求以及響應(你的一個請求任務)塑造成一個Call
對象,然而請求過程中所發生的多次請求以及響應是必須的。但是通常情況下中間請求及響應工作不會很多!令人欣慰的是,無論發生URL重定向還是因為服務器出現問題而向一個備用IP地址再次發送請求的情況,你的代碼都會一直正常運行。
執行Call
有兩種方式:
- 同步:請求和處理響應發生在同一線程。并且此線程會在響應返回之前會一直被堵塞。
- 異步:請求和處理響應發生在不同線程。將發送請求操作發生在一個線程,并且通過回調的方式在其他線程進行處理響應。(一般在子線程發送請求,主線程處理響應)
Calls
可以在任何線程被取消。當這個Call
尚未執行結束時,執行取消操作將會直接導致此Call
失?。‘斠粋€Call
被取消時,無論是寫入請求主體或者讀取響應主體的代碼操作,都會拋出一個IOException
異常。
調度者 (Dispatch)
對于在同步線程中執行Call
而言,你最好創建子線程并且手動管理你所發出的并發請求。因為太多并發連接浪費資源,以及可能會導致發生一些不好的小問題。
對于異步線程執行Call
而言,Dispactcher
實現了一個限制最大并發的接口。你也可以自定義設置對于每臺主機的最大并發數(默認為5),以及總的并發數(默認為64)。