分析的很全面，推薦給大家
OKHTTP攔截器緩存策略CacheInterceptor的簡(jiǎn)單分析
OKHTTP攔截器ConnectInterceptor的簡(jiǎn)單分析
OKHTTP攔截器CallServerInterceptor的簡(jiǎn)單分析
OKHTTP攔截器BridgeInterceptor的簡(jiǎn)單分析
OKHTTP攔截器RetryAndFollowUpInterceptor的簡(jiǎn)單分析
OKHTTP結(jié)合官網(wǎng)示例分析兩種自定義攔截器的區(qū)別
1、LoggingInterceptor示例代碼
通過(guò)下面的代碼可以看出尚氛，它就是用于在請(qǐng)求發(fā)送前和網(wǎng)絡(luò)響應(yīng)后的打印日志信息的攔截器。具體打印的內(nèi)容很簡(jiǎn)單，就不解釋了懒熙，重點(diǎn)是 Application Intercetor 和 NetworkInterceptor 的區(qū)別，繼續(xù)往下看普办。
class LoggingInterceptor implements Interceptor{
@Override?
public Responseintercept(Interceptor.Chain chain)
throws IOException{? ??
Request request = chain.request();
//請(qǐng)求前--打印請(qǐng)求信息
longt1 = System.nanoTime();? ??
logger.info(String.format("Sending request %s on %s%n%s",? ? ? ? request.url(), chain.connection(), request.headers()));
//網(wǎng)絡(luò)請(qǐng)求Response response = chain.proceed(request);
//網(wǎng)絡(luò)響應(yīng)后--打印響應(yīng)信息longt2 = System.nanoTime();? ?
?logger.info(String.format("Received response for %s in %.1fms%n%s",? ? ? ? response.request().url(), (t2 - t1) /1e6d, response.headers()));returnresponse;? }}
2工扎、Application Intercetor和NetworkInterceptor的區(qū)別
在官方文檔中用 LoggingInterceptor 作為示例，解釋了 Application Intercetor 和 NetworkInterceptor 的區(qū)別衔蹲。
OKHTTP官網(wǎng)示例在看兩種攔截器的區(qū)別之前定庵，還是要點(diǎn)擊這個(gè)鏈接去看看，之后再看這個(gè)博客的總結(jié)會(huì)好點(diǎn)踪危。
到這里，默認(rèn)就是已經(jīng)看過(guò)了官網(wǎng)的示例了猪落，那我們就使用一個(gè)圖來(lái)看看攔截器的調(diào)用過(guò)程：
攔截器的執(zhí)行過(guò)程.png
從上面的調(diào)用關(guān)系可以看出除了紅色圈出的攔截器之外都是系統(tǒng)提供的攔截器贞远，這整個(gè)過(guò)程是遞歸的執(zhí)行過(guò)程，在 CallServerInterceptor 中得到最終的 Response 之后笨忌，將 response 按遞歸逐級(jí)進(jìn)行返回蓝仲，期間會(huì)經(jīng)過(guò) NetworkInterceptor 最后到達(dá)自定義的 Interceptor 。
在官網(wǎng)給出的 NetworkInterceptor 和 Application Interceptor 的區(qū)別在上面的圖中就可以看出：
1.自定義 Interceptor 是第一個(gè) Interceptor 因此它會(huì)被第一個(gè)執(zhí)行，因此這里的 request 還是最原始的袱结，并沒(méi)有經(jīng)過(guò) BridgeInterceptor 進(jìn)行加工過(guò)亮隙，因此他只有一個(gè)自定義的 User-Agent 請(qǐng)求頭。而對(duì)于 response 而言呢垢夹，因?yàn)檎麄€(gè)過(guò)程是遞歸的調(diào)用過(guò)程溢吻，因此它會(huì)在 CallServerInterceptor 執(zhí)行完畢之后才會(huì)將 Response 進(jìn)行返回，因此這里得到的 response 就是最終的響應(yīng)果元，雖然中間有重定向促王，但是這里只關(guān)心最終的 response 。
2.NetwrokInterceptor 處于第 6 個(gè)攔截器中而晒，它會(huì)經(jīng)過(guò) RetryAndFollowIntercptor 進(jìn)行重定向并且也會(huì)通過(guò) BridgeInterceptor 進(jìn)行 request 請(qǐng)求頭和 響應(yīng) resposne 的處理蝇狼，因此這里可以得到的是更多的信息。在打印結(jié)果可以看到它內(nèi)部是發(fā)生了一次重定向操作倡怎，在上圖可以看出迅耘，為什么 NetworkInterceptor 可以比 Application Interceptor 得到更多的信息了。
3监署、兩種攔截器的區(qū)別
下面是官網(wǎng)給出的區(qū)別颤专，根據(jù)我自己的理解，使用中文標(biāo)出了自己的解釋焦匈。
Application interceptors
Don't need to worry about intermediate responses like redirects and retries.不需要去關(guān)心中發(fā)生的重定向和重試操作血公。
Are always invoked once, even if the HTTP response is served from the cache.只會(huì)被調(diào)用一次，即使這個(gè)響應(yīng)是從緩存中獲取的缓熟。
Observe the application's original intent. Unconcerned with -OkHttp-injected headers like If-None-Match.只關(guān)注最原始的請(qǐng)求累魔，不去關(guān)系請(qǐng)求的資源是否發(fā)生了改變，我只關(guān)注最后的 response 結(jié)果而已够滑。
Permitted to short-circuit and not call Chain.proceed().因?yàn)槭堑谝粋€(gè)被執(zhí)行的攔截器垦写，因此它有權(quán)決定了是否要調(diào)用其他攔截犁珠，也就是 Chain.proceed() 方法是否要被執(zhí)行您单。
Permitted to retry and make multiple calls to Chain.proceed()
.因?yàn)槭堑谝粋€(gè)被執(zhí)行的攔截器，因此它有可以多次調(diào)用 Chain.proceed() 方法沟涨，其實(shí)也就是相當(dāng)與重新請(qǐng)求的作用了况毅。
Network Interceptors
Able to operate on intermediate responses like redirects and retries.因?yàn)?NetworkInterceptor 是排在第 6 個(gè)攔截器中分蓖，因此會(huì)經(jīng)過(guò) RetryAndFollowup 進(jìn)行失敗重試或者重定向，因此可以操作中間的 resposne尔许。
Not invoked for cached responses that short-circuit the network.這個(gè)我不知道是什么意思么鹤，望大神指點(diǎn)。TODO
Observe the data just as it will be transmitted over the network.觀察數(shù)據(jù)在網(wǎng)絡(luò)中的傳輸味廊，具體我也不太清除是干嘛的蒸甜。TODO
Access to the Connection that carries the request.因?yàn)樗旁?ConnectInterceptor 后執(zhí)行棠耕，因此返回執(zhí)行這個(gè) request 請(qǐng)求的 Connection 連接。
在上面還有幾個(gè) TODO 沒(méi)有解決柠新，希望懂的同學(xué)指點(diǎn)一下...
