- 本文章所使用的 OkHttp 源碼版本：3.12.10
上一篇：OkHttp 精講：RetryAndFollowUpInterceptor
源碼解析
- 一眼望去册着，給人第一感覺(jué)就是這個(gè)攔截器的作用就是在添加請(qǐng)求頭筋夏，接下來(lái)讓我們分析一下這個(gè)攔截器到底在做什么
- 這個(gè) Content-Type 是什么呢芍秆？讓我們回顧一下之前看過(guò)的請(qǐng)求頭和響應(yīng)頭信息對(duì)照表
| 名稱 | 說(shuō)明 | 示例 |
|---|---|---|
| Content-Type | 返回內(nèi)容的MIME類型 | Content-Type: text/html; charset=utf-8 |
- 這個(gè) Content-Type 其實(shí)就是 RequestBody 的類型纺座，目的也很簡(jiǎn)單樟结，就是為了告訴后臺(tái)，我這邊發(fā)送了什么類型的數(shù)據(jù)過(guò)去任洞，后臺(tái)才能去解析衰倦，如果你不告訴后臺(tái)，那么后臺(tái)不知道該把你傳過(guò)去的數(shù)據(jù)流解析成什么疙赠。
| 名稱 | 說(shuō)明 |
|---|---|
| application/x-www-form-urlencoded | 代表 RequestBody 的類型是一個(gè)提交表單參數(shù)的內(nèi)容 |
| multipart/form-data | 代表 RequestBody 的類型是一個(gè)帶文件的表單參數(shù)的內(nèi)容 |
| application/json; charset=utf-8 | 代表 RequestBody 的類型是一個(gè)提交 Json 參數(shù)的內(nèi)容 |
這里給大家舉個(gè)栗子付材，例如我們平時(shí)說(shuō)的表單請(qǐng)求、表單+文件請(qǐng)求圃阳、Json 請(qǐng)求厌衔，這三種方式是目前最常用的參數(shù)提交方式，后臺(tái)是怎么區(qū)分請(qǐng)求是這三種方式哪一種呢捍岳？就是要靠 Content-Type 這個(gè)請(qǐng)求頭來(lái)辨別富寿。
不過(guò)值得一提的是，OkHttp 目前只支持了表單請(qǐng)求和表單+文件請(qǐng)求锣夹，不支持 Json 請(qǐng)求页徐，但是 Json 請(qǐng)求又是目前比較主流的參數(shù)提交方式，如果要使用這一方式晕城，只有兩個(gè)方法：一是自己重新定義一個(gè) RequestBody 類泞坦，二是使用第三方基于 OkHttp 封裝的網(wǎng)絡(luò)請(qǐng)求框架。
剛看完 Content-Type砖顷，再來(lái)看看 Content-Length
- 這段代碼的意思是贰锁，如果我傳過(guò)去的內(nèi)容長(zhǎng)度是固定的，那么我就直接通過(guò) Content-Length 告訴后臺(tái)滤蝠，如果不是那么我就通過(guò) Transfer-Encoding =“chunked” 這個(gè)請(qǐng)求頭告訴后臺(tái)豌熄，我傳過(guò)去的內(nèi)容長(zhǎng)度是不固定的，需要進(jìn)行分段傳輸物咳。
- 可能大家對(duì) Accept-Encoding 這個(gè)請(qǐng)求頭比較陌生锣险，讓我們回顧一下之前看過(guò)的請(qǐng)求頭和響應(yīng)頭信息對(duì)照表
| 名稱 | 說(shuō)明 | 示例 |
|---|---|---|
| Accept-Encoding | 指定瀏覽器可以支持的web服務(wù)器返回內(nèi)容壓縮編碼類型 | Accept-Encoding: compress, gzip |
- 我們可以看到，這兩種文件壓縮格式芯肤，各有特點(diǎn)巷折，compress 是重復(fù)的字眼越多壓縮率越高，而 gzip 則是能對(duì)純文本內(nèi)容壓縮到原大小的 40%崖咨，基于這一特點(diǎn)锻拘，gzip 成為目前 Http 傳輸主流的壓縮方式，因?yàn)?gzip 在壓縮包大小上的優(yōu)勢(shì)比 compress 好太多击蹲。
Token 是什么我相信大家都懂署拟，但是 Cookie 是什么，大部分人可能有學(xué)過(guò)歌豺，但是因?yàn)樘脹](méi)用已經(jīng)如數(shù)還給老師了推穷，今天我們剛好講到，順道學(xué)習(xí)或者復(fù)習(xí)一下
Cookie 和 Token 的作用其實(shí)都差不多类咧，都是后臺(tái)返回給客戶端的用戶登錄信息馒铃，但是仍然有一些不同，目前的現(xiàn)象是：前端開(kāi)發(fā)基本都用 Cookie轮听，而 App 開(kāi)發(fā)基本都用 Token骗露，那么問(wèn)題來(lái)了，為什么不統(tǒng)一采用某一種呢血巍？
在 Http 協(xié)議中萧锉，是沒(méi)有 Token 這一概念，只有 Cookie述寡，而 App 開(kāi)發(fā)都是用手機(jī)進(jìn)行開(kāi)發(fā)和調(diào)試柿隙，而手機(jī)對(duì)這塊沒(méi)有強(qiáng)制要求，用戶登錄信息想怎么保存就怎么保存鲫凶，而前端開(kāi)發(fā)不一樣了禀崖，他們需要用瀏覽器進(jìn)行開(kāi)發(fā)和調(diào)試，而這塊需要嚴(yán)格遵循 Http 協(xié)議螟炫，登錄信息不可能你想存哪里就存哪里波附，必須都要保存到 Cookie 中，因?yàn)?Cookie 的管理者是瀏覽器
至于 Cookie 為什么是有多個(gè)的昼钻？我先帶大家看一下 Github 的 Cookie 信息
我們可以看到掸屡，Cookie 包含了很多信息，每個(gè)的信息都用分號(hào)隔開(kāi)然评，不僅包含登錄信息仅财，還有設(shè)備 id 等其他信息
所以可以得出一個(gè)結(jié)論，Cookie 的功能還是比較強(qiáng)大的碗淌，相比之下 Token 顯得太不專業(yè)了
- 最后一步盏求，攔截器會(huì)獲取請(qǐng)求之后的結(jié)果抖锥，并判斷服務(wù)器有沒(méi)有對(duì)這個(gè)流進(jìn)行 gzip 進(jìn)行壓縮，因?yàn)橹坝懈嬖V服務(wù)器我們支持 gzip 壓縮碎罚，所以我們需要對(duì)服務(wù)器返回的數(shù)據(jù)進(jìn)行解壓磅废，如果不對(duì)數(shù)據(jù)流進(jìn)行解壓的話，直接讀取的話將會(huì)導(dǎo)致無(wú)法使用荆烈，所以必須要對(duì)其進(jìn)行解壓还蹲，這樣才能正常讀取到數(shù)據(jù)流中的內(nèi)容
源碼總結(jié)
- 這個(gè)攔截器主要的作用就是添加一些通用的請(qǐng)求頭，例如 Content-Type耙考、Content-Length，還有將我們?cè)?OkHttp 中配置的 Cookie 信息都處理成請(qǐng)求頭潭兽，再通過(guò) Accept-Encoding 這個(gè)請(qǐng)求頭告訴服務(wù)器我們支持接收 gzip 編碼的數(shù)據(jù)流倦始，如果服務(wù)器返回的數(shù)據(jù)流是經(jīng)過(guò) gzip 壓縮的，在這個(gè)攔截器中還會(huì)對(duì)數(shù)據(jù)流進(jìn)行解壓山卦，最后將這個(gè)數(shù)據(jù)流重新設(shè)置給 Response 的 body 中鞋邑，以便我們能夠正常解析這個(gè)數(shù)據(jù)流。
