OkGO使用详解
1.支持的常用功能
- 一般的 get,post,put,delete,head,options請求
- 基于Post的大文本數據上傳，postString(),postJson()等
- 多文件和多參數統一的表單上傳（允許監聽上傳進度）
- 支持一個key上傳一個文件，也可以一個Key上傳多個文件
- 大文件下載和下載進度回調
- 大文件上傳和上傳進度回調
- 支持cookie的內存存儲和持久化存儲，支持傳遞自定義cookie
- 提供網絡緩存功能，默認支持304緩存協議，并額外擴展了三種本地緩存模式
- 支持301、302重定向
- 支持鏈式調用
- 支持可信證書和自簽名證書的https訪問
- 支持根據Tag取消網絡請求
- 支持自定義泛型Callback，自動根據泛型返回對象
2.支持的擴展功能
- 統一的文件下載管理（DownloadManager）
默認使用的是 get 請求，同時下載數量為3個，支持斷點下載，斷點信息使用ORMLite數據庫框架保存，默認下載路徑/storage/emulated/0/download，下載路徑和下載數量都可以在代碼中配置，下載管理使用了服務提高線程優先級，避免后臺下載時被系統回收。
當你的項目需要做大量的下載的時候，并且多個頁面需要監聽下載進度，使用該擴展讓你更方便。原生支持下載任務的開始、暫停、停止、出錯、完成五個狀態，當同時下載任務數量超過3個（可代碼動態設置）時，后續任務自動等待，當有任務下載完成時，等待任務按照優先級自動開始下載。 - 統一的文件上傳管理（UploadManager）
默認使用的是 post 上傳請求，該上傳管理為簡單管理，不支持斷點續傳和分片上傳，只是簡單的將所有上傳任務使用線程池進行了統一管理，默認同時上傳數量為1個。由于斷點分片上傳的技術需要大量的服務端代碼配合，同時也會極大的增加客戶端代碼量，所以綜合考慮，該框架不做實現。如果確實有特殊需要，可以自己做擴展。
2.2 統一的文件上傳管理(UploadManager)
- 結合OkHttpUtils 的request進行網絡請求,支持與OkHttpUtils 保持相同的全局公共參數,同時支持請求傳遞參數
- 上傳只能使用Post,?Put,?Delete,?Options?這四種請求,不支持Get,?Head
- 該上傳管理為簡單管理，不支持斷點續傳或分片上傳，只是簡單的將所有上傳任務使用線程池進行了統一管理
- 默認同時上傳數量為1個,該數列可以在代碼中配置修改
- 由于斷點分片上傳的技術需要大量的服務端代碼配合，同時也會極大的增加客戶端代碼量，所以綜合考慮，該框架不做實現。如果確實有特殊需要，可以自己做擴展。
項目的效果圖如下：
項目主頁
請求詳細信息
下載管理列表頁
下載管理詳情頁
上傳管理和圖片選擇
3.如何選擇網絡框架
說了這么多功能，我們來看看為什么要使用OkHttpUtils這個框架。
首先目前主流的幾個網絡框架
- android-async-http
- xUtils
- volley
- retrofit
- okhttp
在此引用知乎上Stay Zhang的回答：
我們來先說一個常識性的錯誤：volley, retrofit, android-async-http 幫你封裝了具體的請求，線程切換以及數據轉換。而OkHttp 是基于http協議封裝的一套請求客戶端，雖然它也可以開線程，但根本上它更偏向真正的請求，跟HttpClient, HttpUrlConnection的職責是一樣的。
所以不要混淆。
-----以下純個人主觀見解
首先，我想即使你單純使用OkHttp，還是會再包一層的，這樣就等價于Volley之流的框架，只是封裝的好與壞而已。
android-async-http內部實現是基于HttpClient, 想必你肯定知道6.0之后HttpClient是不是系統自帶的了，不過它在最近的更新中將HttpClient的所有代碼copy了一份進來，所以還能使用。
Volley是官方出的，volley在設計的時候是將具體的請求客戶端做了下封裝：HurlStack，也就是說可以支持HttpUrlConnection, HttpClient, OkHttp，相當于模版模式吧，這樣解耦還是非常方便的，可以隨意切換，如果你之前使用過Volley，并習慣使用，那直接寫個OkHttp擴展就行了。
Retrofit因為也是square出的，所以大家可能對它更崇拜些。Retrofit的跟Volley是一個套路，但解耦的更徹底:比方說通過注解來配置請求參數，通過工廠來生成CallAdapter，Converter，你可以使用不同的請求適配器(CallAdapter), 比方說RxJava，Java8, Guava。你可以使用不同的反序列化工具(Converter)，比方說json, protobuff, xml, moshi等等。關鍵是想要用好這個框架，最好是和RxJava聯用，否者和普通的網絡框架也沒什么區別，而對于RxJava，特別team人數多的情況下，總得有個完全精通的吧，萬一掉坑里了呢。。。
4.OkHttpUtils的優勢
- 優勢一：性能高，專注于簡單易用的網絡請求，使用主流的okhttp進行封裝，對于okhttp大家都知道，在Android4.4的源碼中可以看到HttpURLConnection已經替換成OkHttp實現了，并且支持HTTP2/SPDY黑科技，支持socket自動選擇最好路線，并支持自動重連，擁有自動維護的socket連接池，減少握手次數，擁有隊列線程池，輕松寫并發。
- 優勢二：特有的網絡緩存模式，是大多數網絡框架所不具備的，說一個應用場景，老板說我們的app不僅需要在有網的情況下展示最新的網絡數據，還要在沒網的情況下使用緩存數據，這時候是不是項目中出現了大量的代碼判斷當前網絡狀況，根據不同的狀態保存不同的數據，然后決定是否使用緩存。細想一下，這是個通用的寫法，于是OkHttpUtils提供了四種緩存模式，讓你不用關心緩存的實現，而專注于數據的處理。（具體緩存的使用方法請看最后第四章節）。
- 優勢三：方便易用的擴展接口，可以添加全局的公共參數，全局攔截器，全局超時時間，更可以對單個請求定制攔截器，超時時間，請求參數修改等等，在使用上更是方便，原生支持的鏈式調用讓你的請求更加清晰。
- 優勢四：強大的Cookie保持策略，我們知道在客戶端對cookie的獲取是個不太簡單的事情，特別是還要處理cookie的過期時間，持久化策略等等，OkHttpUtils幫你徹底解決Cookie的難題，默認擁有內存存儲和持久化存儲兩種實現，cookie全程自動管理，并且提供了額外的addCookie方式，允許介入到自動管理的過程中，添加你想創建的任何cookie。
所以就說這么多啦，選最適合項目的，選大多數人選擇的，選簡單易用的，就這么個標準，而OkHttpUtils正是在這種情況下誕生啦！！
5.使用方法
對于Android Studio的用戶，可以選擇添加:
compile 'com.lzy.net:okhttputils:1.8.1' //可以單獨使用，不需要依賴下方的擴展包compile 'com.lzy.net:okhttpserver:1.0.3' //擴展了下載管理和上傳管理，根據需要添加compile 'com.lzy.net:okhttputils:+' //版本號使用 + 可以自動引用最新版compile 'com.lzy.net:okhttpserver:+' //版本號使用 + 可以自動引用最新版
- 為了方便大家使用，更加通俗的理解http的網絡協議，建議做網絡請求的時候，對每個請求抓包后查看請求信息和響應信息。
- 如果是 Windows 操作系統，可以使用?Fiddler?對手機的請求進行抓包查看。
- 如果是 Mac OS 操作系統，可以使用?Charles?對手機的請求進行抓包查看。
- 具體的下載地址和抓包配置方法，我這就不提供了，請自行百度或谷歌。
6.使用注意事項
- okhttputils使用的okhttp的版本是最新的 3.4.1 版本，和以前的 2.x 的版本可能會存在沖突。
- okhttpserver是對okhttputils的擴展，統一了下載管理和上傳管理，對項目有需要做統一下載的可以考慮使用該擴展，不需要的可以直接使用okhttputils即可。
- 對于緩存模式使用，需要與返回對象相關的所有javaBean必須實現Serializable接口，否者會報NotSerializableException。
- 使用緩存時，如果不指定cacheKey，默認是用url帶參數的全路徑名為cacheKey。
- 使用該網絡框架時，必須要在 Application 中做初始化?OkHttpUtils.init(this);。
一、全局配置
一般在 Aplication，或者基類中，只需要調用一次即可，可以配置調試開關，全局的超時時間，公共的請求頭和請求參數等信息，所有的請求參數都支持中文，
@Overridepublic void onCreate() {super.onCreate();HttpHeaders headers = new HttpHeaders();headers.put("commonHeaderKey1", "commonHeaderValue1"); //所有的 header 都 不支持 中文headers.put("commonHeaderKey2", "commonHeaderValue2");HttpParams params = new HttpParams();params.put("commonParamsKey1", "commonParamsValue1"); //所有的 params 都 支持 中文params.put("commonParamsKey2", "這里支持中文參數");//必須調用初始化OkHttpUtils.init(this);//以下都不是必須的，根據需要自行選擇OkHttpUtils.getInstance()//.debug("OkHttpUtils") //是否打開調試.setConnectTimeout(OkHttpUtils.DEFAULT_MILLISECONDS) //全局的連接超時時間.setReadTimeOut(OkHttpUtils.DEFAULT_MILLISECONDS) //全局的讀取超時時間.setWriteTimeOut(OkHttpUtils.DEFAULT_MILLISECONDS) //全局的寫入超時時間//.setCookieStore(new MemoryCookieStore()) //cookie使用內存緩存（app退出后，cookie消失）//.setCookieStore(new PersistentCookieStore()) //cookie持久化存儲，如果cookie不過期，則一直有效.addCommonHeaders(headers) //設置全局公共頭.addCommonParams(params); //設置全局公共參數}二、普通請求
1.基本的網絡請求
OkHttpUtils.get(Urls.URL_METHOD) // 請求方式和請求url.tag(this) // 請求的 tag, 主要用于取消對應的請求.cacheKey("cacheKey") // 設置當前請求的緩存key,建議每個不同功能的請求設置一個.cacheMode(CacheMode.DEFAULT) // 緩存模式，詳細請看緩存介紹.execute(new JsonCallback<RequestInfo>(RequestInfo.class) {@Overridepublic void onResponse(boolean isFromCache, RequestInfo requestInfo, Request request, @Nullable Response response) {// requestInfo 對象即為所需要的結果對象}});2.請求 Bitmap 對象
OkHttpUtils.get(Urls.URL_IMAGE)//.tag(this)//.execute(new BitmapCallback() {@Overridepublic void onResponse(boolean isFromCache, Bitmap bitmap, Request request, @Nullable Response response) {// bitmap 即為返回的圖片數據}});3.請求 文件下載
OkHttpUtils.get(Urls.URL_DOWNLOAD)//.tag(this)//.execute(new FileCallback("/sdcard/temp/", "file.jpg") { //文件下載時，需要指定下載的文件目錄和文件名@Overridepublic void onResponse(boolean isFromCache, File file, Request request, @Nullable Response response) {// file 即為文件數據，文件保存在指定布幕}});4.普通Post，直接上傳String類型的文本
一般此種用法用于與服務器約定的數據格式，當使用該方法時，params中的參數設置是無效的，所有參數均需要通過需要上傳的文本中指定，此外，額外指定的header參數仍然保持有效。
OkHttpUtils.post(Urls.URL_TEXT_UPLOAD)//.tag(this)//.postString("這是要上傳的長文本數據！")//.execute(new StringCallback() {@Overridepublic void onResponse(boolean isFromCache, String s, Request request, @Nullable Response response) {//上傳成功}});5.普通Post，直接上傳Json類型的文本
該方法與postString沒有本質區別，只是數據格式是json,一般來說，需要自己創建一個實體bean或者一個map，把需要的參數設置進去，然后通過三方的Gson或者fastjson轉換成json字符串，最后直接使用該方法提交到服務器。
OkHttpUtils.post(Urls.URL_TEXT_UPLOAD)//.tag(this)//.postJson("{\"des\": \"這里面要寫標準的json格式數據\"}")//.execute(new StringCallback() {@Overridepublic void onResponse(boolean isFromCache, String s, Request request, @Nullable Response response) {//上傳成功}});6.請求功能的所有配置講解
以下代碼包含了以下內容：
- 一次普通請求所有能配置的參數，真實使用時不需要配置這么多，按自己的需要選擇性的使用即可
- 多文件和多參數的表單上傳，同時支持進度監聽
- 自簽名網站https的訪問，調用setCertificates方法即可
- 為單個請求設置超時，比如涉及到文件的需要設置讀寫等待時間多一點。
- Cookie一般情況下只需要在初始化的時候調用setCookieStore即可實現cookie的自動管理，如果特殊業務需要，需要手動額外向服務器傳遞自定義的cookie，可以在每次請求的時候調用addCookie方法，該方法提供了3個重載形式，可以根據自己的需要選擇使用。
7.取消請求
每個請求前都設置了一個參數tag，取消則通過OkHttpUtils.cancel(tag)執行。
例如：在Activity中，當Activity銷毀取消請求，可以在onDestory里面統一取消。
8.同步的請求
execute方法不傳入callback即為同步的請求，返回Response對象，需要自己解析
Response response = OkHttpUtils.get("http://www.baidu.com")//.tag(this)//.headers("aaa", "111")//.params("bbb", "222").execute();三、自定義CallBack使用
目前內部提供的包含AbsCallback,?StringCallBack?,BitmapCallback?,FileCallBack?,可以根據自己的需求去自定義Callback
- AbsCallback: 所有回調的父類，抽象類
- StringCallBack：如果返回值類型是純文本數據，即可使用該回調
- BitmapCallback：如果請求的是圖片數據，則可以使用該回調
- FileCallBack：如果要做文件下載，則必須使用該回調，內部封裝了關于文件下載進度回調的方法
該網絡框架的核心使用方法即為Callback的繼承使用，詳細請看 Demo 源碼中callback包下的代碼。
因為不同的項目需求，可能對數據格式進行了不同的封裝，于是在 Demo 中的進行了詳細的代碼示例，以下是詳細介紹：
- CommonCallback:繼承自AbsCallback,主要作用是做全局共同請求參數的添加，同樣也可以在第一步全局配置的時候設置，效果一樣。
- EncryptCallback：繼承自CommonCallback,主要功能是做 Url 參數加密，對每個請求的參數進行編碼，防止攔截數據包，篡改數據。
- JsonCallback：繼承自EncryptCallback,一般來說，服務器返回的響應碼都包含 code，msg，data 三部分，在此根據自己的業務需要完成相應的邏輯判斷，并對數據進行解析，可以使用?Gson?或者?fastjson，將解析的對象返回。
- DialogCallback：繼承自JsonCallback,對需要在網絡請求的時候顯示對話框，使用該回調。
- StringDialogCallback：繼承自EncryptCallback,如果網絡返回的數據只是純文本，使用該回調
- BitmapDialogCallback?：繼承自BitmapCallback,如果網絡返回的是Bitmap對象，使用該回調
- DownloadFileCallBack?：繼承自FileCallback,如果需要做文件下載，使用該回調
以上基本是包含了大部分的業務邏輯，具體情況請參照demo示例，根據業務需求修改！
四、緩存的使用
使用緩存前，必須讓緩存的數據javaBean對象實現Serializable接口，否者會報NotSerializableException。
因為緩存的原理是將對象序列化后直接寫入 數據庫中，如果不實現Serializable接口，會導致對象無法序列化，進而無法寫入到數據庫中，也就達不到緩存的效果。
目前提供了四種CacheMode緩存模式
- DEFAULT: 按照HTTP協議的默認緩存規則，例如有304響應頭時緩存
- REQUEST_FAILED_READ_CACHE：先請求網絡，如果請求網絡失敗，則讀取緩存，如果讀取緩存失敗，本次請求失敗。該緩存模式的使用，會根據實際情況，導致onResponse,onError,onAfter三個方法調用不只一次，具體請在三個方法返回的參數中進行判斷。
- IF_NONE_CACHE_REQUEST：如果緩存不存在才請求網絡，否則使用緩存。
- FIRST_CACHE_THEN_REQUEST：先使用緩存，不管是否存在，仍然請求網絡，如果網絡順利，會導致onResponse方法執行兩次，第一次isFromCache為true，第二次isFromCache為false。使用時根據實際情況，對onResponse,onError,onAfter三個方法進行具體判斷。
無論對于哪種緩存模式，都可以指定一個cacheKey，建議針對不同需要緩存的頁面設置不同的cacheKey，如果相同，會導致數據覆蓋。
文／廖子堯（簡書作者）
原文鏈接： http://www.jianshu.com/p/4c17956fe3b4
著作權歸作者所有，轉載請聯系作者獲得授權，并標注“簡書作者”。
文／廖子堯（簡書作者）
原文鏈接：http://www.jianshu.com/p/4c17956fe3b4
著作權歸作者所有，轉載請聯系作者獲得授權，并標注“簡書作者”。
總結
