『壹』 android網路實戰篇——OkHttp3（Retrofit2）五種緩存模式的實現
網上有許多寫OKhttp3緩存的文章，例如：
【Okhttp3結合Retrofit2 實現緩存】 https://www.jianshu.com/p/74d2c10c3eba?from=timeline
【使用Retrofit和Okhttp3實現網路緩存】 https://www.jianshu.com/p/34f73e571ecb
【okhttp3緩存實踐】 http://blog.csdn.net/wuhengde/article/details/54927096
這些文章都很不錯，但還是有一些小小的瑕疵，這里我參考他們的文章結合自己的實踐簡單封裝了Okhttp3的五種緩存方式供大家參考，如有錯誤還請不吝賜教。
主要知識點：
public class OkHttpUtil {
}
後記：如有不同見解或疑惑，歡迎留言，如果覺得不錯可以來個贊！點個贊！
『貳』 Android使用OkHttp請求自簽名的https網站
很多公司考慮到安全問題，項目中都採用https加密協議進行數據傳輸。但是一些公司又不想花一筆錢去CA申請證書，所以就採用自簽名的證書。
OkHttp默認是可以訪問通過CA認證的HTTPS鏈接，例如網路首頁也是https鏈接（ https://www..com/ ）。 但是如果是你們公司自簽名(即自己用keytool生成的證書，而不是採用通過CA認證的證書)的伺服器，OkHttp是無法訪問的，例如訪問12306網站（ https://kyfw.12306.cn/otn/ ） ，會報如下錯誤：
HTTPS在傳輸數據之前需要客戶端（瀏覽器）與服務端（網站）之間進行一次握手，在握手過程中將確立雙方加密傳輸數據的密碼信息。握手過程的簡單描述如下：
握手過程中如果有任何錯誤，都會使加密連接斷開，從而阻止了隱私信息的傳輸。
以下我們使用12306網站為例
注意：別忘了加許可權和依賴okhttp庫
Demo地址： https://github.com/wildma/okhttps
參考博客： http://blog.csdn.Net/lmj623565791/article/details/48129405
『叄』 android 怎麼信任https
因為最近公司的open api伺服器訪問協議換成了https，所以 android 在使用okhttp 走https 訪問的時候遇到了證書信任的問題，
在這里把我走過的彎路記下來，一如既往的話不多說，上碼：
OkHttpClient sClient = new OkHttpClient();
// 設置超時時間
sClient.setConnectTimeout(8000, TimeUnit.MILLISECONDS);
sClient.setReadTimeout(8000, TimeUnit.MILLISECONDS);
// 注冊攔截器
sClient.interceptors().add(new BaseInterceptor(context));
第一種方式：
sClient.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
運行結果：
javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
11-26 11:17:57.264 17106-17268/com.dooioo.addressbook W/System.err: at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:410)
11-26 11:17:57.264 17106-17268/com.dooioo.addressbook W/System.err: at com.squareup.okhttp.Connection.connectTls(Connection.java:235)
11-26 11:17:57.264 17106-17268/com.dooioo.addressbook W/System.err: at com.squareup.okhttp.Connection.connectSocket(Connection.java:199)
11-26 11:17:57.264 17106-1726
『肆』 Android通過OKhttp從伺服器端獲取數據
①簡單的異棚洞步Get請求
第一步，創建OKHttpClient對象
第二步，創建Request請求
第三步，創建一個Call對象
第四步，將請求添大和賀加到調度中
不多說，直接上代碼：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
//okHttp的基本使用 --- get方法
String url = "https://api.douban.com/v2/movie/top250?start=0&count=10";
//1,創建OKHttpClient對象
OkHttpClient mOkHttpClient = new OkHttpClient();
//2,創建一個Request
Request request = new Request.Builder().url(url).build();
//3,創建一個call對象
Call call = mOkHttpClient.newCall(request);
//4,將請求添加到調滾派度中
call.enqueue(new Callback() {
@Override
public void onFailure(Request request, IOException e) {
}
@Override
public void onResponse(Response response) throws IOException {
if (response.isSuccessful()) {
final String message = response.body().string();
handler.post(new Runnable() {
@Override
public void run() {
tv_message.setText(message);
progressBar.setVisibility(View.GONE);
}
});
}
}
});
『伍』 安卓http和https的區別
HTTPS（）安全超文本傳輸協議它是一個安全通信通道，它基於HTTP開發，用於在客戶計算機和伺服器之間交換信息。它使用安全套接字層(SSL)進行信息交換，簡單來說它是HTTP的安全版。它是由Netscape開發並內置於其瀏覽器中，用於對數據進行壓縮和解壓操作，並返回網路上傳送回的結果。HTTPS實際上應用了Netscape的安全全套接字層（SSL）作為HTTP應用層的子層。（HTTPS使用埠443，而不是象HTTP那樣使用埠80來和TCP/IP進行通信。）SSL使用40位關鍵字作為RC4流加密演算法，這對於商業信息的加密是合適的。HTTPS和SSL支持使用X.509數字認證，如果需要的話用戶可以確認發送者是誰。HTTPS和HTTP的區別：https協議需要到ca申請證書，一般免費證書很少，需要交費。http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協議http和https使用的是完全不同的連接方式用的埠也不一樣,前者是80,後者是443。http的連接很簡單,是無狀態的HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議要比http協議安全HTTPS解決的問題：1.信任主機的問題.採用https的server必須從CA申請一個用於證明伺服器用途類型的證書.改證書只有用於對應的server的時候,客戶度才信任次主機.所以目前所有的銀行系統網站,關鍵部分應用都是https的.客戶通過信任該證書,從而信任了該主機.其實這樣做效率很低,但是銀行更側重安全.這一點對我們沒有任何意義,我們的server,採用的證書不管自己issue還是從公眾的地方issue,客戶端都是自己人,所以我們也就肯定信任該server.2.通訊過程中的數據的泄密和被竄改1.一般意義上的https,就是server有一個證書.a)主要目的是保證server就是他聲稱的server.這個跟第一點一樣.b)服務端和客戶端之間的所有通訊,都是加密的.i.具體講,是客戶端產生一個對稱的密鑰,通過server的證書來交換密鑰.一般意義上的握手過程.ii.加下來所有的信息往來就都是加密的.第三方即使截獲,也沒有任何意義.因為他沒有密鑰.當然竄改也就沒有什麼意義了.2.少許對客戶端有要求的情況下,會要求客戶端也必須有一個證書.a)這里客戶端證書,其實就類似表示個人信息的時候,除了用戶名/密碼,還有一個CA認證過的身份.應為個人證書一般來說上別人無法模擬的,所有這樣能夠更深的確認自己的身份.b)目前少數個人銀行的專業版是這種做法,具體證書可能是拿U盤作為一個備份的載體.HTTPS一定是繁瑣的.a)本來簡單的http協議,一個get一個response.由於https要還密鑰和確認加密演算法的需要.單握手就需要6/7個往返.i.任何應用中,過多的roundtrip肯定影響性能.b)接下來才是具體的http協議,每一次響應或者請求,都要求客戶端和服務端對會話的內容做加密/解密.i.盡管對稱加密/解密效率比較高,可是仍然要消耗過多的CPU,為此有專門的SSL晶元.如果CPU信能比較低的話,肯定會降低性能,從而不能serve的請求.ii.加密後數據量的影響.所以，才會出現那麼多的安全認證提示