Flutter Dio源碼分析(一)--Dio介紹
成都創(chuàng)新互聯(lián)公司是一家專業(yè)提供海東企業(yè)網(wǎng)站建設(shè),專注與成都網(wǎng)站制作、成都做網(wǎng)站、外貿(mào)營銷網(wǎng)站建設(shè)、H5場景定制、小程序制作等業(yè)務(wù)。10年已為海東眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)絡(luò)公司優(yōu)惠進(jìn)行中。
Flutter Dio源碼分析(二)--HttpClient、Http、Dio對比
Flutter Dio源碼分析(三)--深度剖析
Flutter Dio源碼分析(四)--封裝
Flutter Dio源碼分析(一)--Dio介紹視頻教程
Flutter Dio源碼分析(二)--HttpClient、Http、Dio對比視頻教程
Flutter Dio源碼分析(三)--深度剖析視頻教程
Flutter Dio源碼分析(四)--封裝視頻教程
github倉庫地址
本文會(huì)手把手教你該怎么去封裝一個(gè)類庫，平時(shí)在我們的工作中都是拿著別人的造好的輪子在使用，這篇文章將帶你怎么去自己造輪子，以后再碰到別的類庫需要對其進(jìn)行封裝的時(shí)候提供一個(gè)的思路和方法。
在前面的文章中，我們對 Dio 的基本使用、請求庫對比、源碼分析，我們知道 Dio 的使用非常的簡單，那為什么還需要進(jìn)行封裝呢？有兩點(diǎn)如下：
當(dāng)組件庫方法發(fā)生重要改變需要遷移的時(shí)候如果有多處地方用到，那么需要對使用到的每個(gè)文件都進(jìn)行修改，非常的繁瑣而且很容易出問題。
當(dāng)不需要 Dio 庫的時(shí)候，我們可以隨時(shí)方便切換到別的網(wǎng)絡(luò)請求庫，當(dāng)然 Dio 目前內(nèi)置支持使用第三方庫的適配器。
因?yàn)橐粋€(gè)應(yīng)用程序基本都是統(tǒng)一的配置方式，所以我們可以針對 攔截器 、 轉(zhuǎn)換器 、 緩存 、 統(tǒng)一處理錯(cuò)誤 、 代理配置 、 證書校驗(yàn) 等多個(gè)配置進(jìn)行統(tǒng)一管理。
因?yàn)槲覀兊膽?yīng)用程序在每個(gè)頁面中都會(huì)用到網(wǎng)絡(luò)請求，那么如果我們每次請求的時(shí)候都去實(shí)例化一個(gè) Dio ，無非是增加了系統(tǒng)不必要的開銷，而使用單例模式對象一旦創(chuàng)建每次訪問都是同一個(gè)對象，不需要再次實(shí)例化該類的對象。
這是通過靜態(tài)變量的私有構(gòu)造器來創(chuàng)建的單例模式
我們對 超時(shí)時(shí)間 、 響應(yīng)時(shí)間 、 BaseUrl 進(jìn)行統(tǒng)一設(shè)置
因?yàn)椴还苁?get() 還是 post() 請求， Dio 內(nèi)部最終都會(huì)調(diào)用 request 方法，只是傳入的 method 不一樣，所以我們這里定義一個(gè)枚舉類型在一個(gè)方法中進(jìn)行處理
我們已經(jīng)把 Restful API 風(fēng)格簡化成了一個(gè)方法，通過 DioMethod 來標(biāo)明不同的請求方式。在我們平時(shí)開發(fā)的過程中，需要在請求前、響應(yīng)前、錯(cuò)誤時(shí)對某一些接口做特殊的處理，那我們就需要用到攔截器。 Dio 為我們提供了自定義攔截器功能，很容易輕松的實(shí)現(xiàn)對請求、響應(yīng)、錯(cuò)誤時(shí)進(jìn)行攔截
我們發(fā)現(xiàn)雖然 Dio 框架已經(jīng)封裝了一個(gè) DioError 類庫，但如果需要對返回的錯(cuò)誤進(jìn)行統(tǒng)一彈窗處理或者路由跳轉(zhuǎn)等就只能自定義了
在我們發(fā)送請求的時(shí)候會(huì)碰到幾種情況，比如需要對非open開頭的接口自動(dòng)加上一些特定的參數(shù)，獲取需要在請求頭增加統(tǒng)一的 token
在我們請求接口前可以對響應(yīng)數(shù)據(jù)進(jìn)行一些基礎(chǔ)的處理，比如對響應(yīng)的結(jié)果進(jìn)行自定義封裝，還可以針對單獨(dú)的 url 做特殊處理等。
我們看了轉(zhuǎn)換器的介紹，發(fā)現(xiàn)和攔截器的功能差不多，那為什么還要存在轉(zhuǎn)換器，有兩點(diǎn)：
執(zhí)行流程： 請求攔截器 請求轉(zhuǎn)換器 發(fā)起請求 響應(yīng)轉(zhuǎn)換器 響應(yīng)攔截器 最終結(jié)果 。
只會(huì)被用于 'PUT'、 'POST'、 'PATCH'方法，因?yàn)橹挥羞@些方法才可以攜帶請求體(request body)
會(huì)被用于所有請求方法的返回?cái)?shù)據(jù)。
在開發(fā)過程中，客戶端和服務(wù)器打交道的時(shí)候，往往會(huì)用一個(gè) token 來做校驗(yàn)，因?yàn)槊總€(gè)公司處理刷新token的邏輯都不一樣，我這里舉一個(gè)簡單的例子
為什么我們需要有取消請求的功能，如果當(dāng)我們的頁面在發(fā)送請求時(shí)，用戶主動(dòng)退出當(dāng)前界面或者app應(yīng)用程序退出的時(shí)候數(shù)據(jù)還沒有響應(yīng)，那我們就需要取消該網(wǎng)絡(luò)請求，防止不必要的錯(cuò)誤。
由 服務(wù)器生成 的 一小段文本信息 ，發(fā)送給瀏覽器，瀏覽器把 cookie 以kv形式保存到本地 某個(gè)目錄下的文本文件內(nèi)，下一次請求同一網(wǎng)站時(shí)會(huì)把該 cookie 發(fā)送給服務(wù)器。
cookie 的使用需要用到兩個(gè)第三方組件 dio_cookie_manager 和 cookie_jar
因?yàn)樵谖覀兤綍r(shí)的開發(fā)過程中，會(huì)碰到一種情況，在進(jìn)行網(wǎng)絡(luò)請求時(shí)，我們希望能正常訪問到上次的數(shù)據(jù)，對于用戶的體驗(yàn)比較好，而不是展示一個(gè)空白的頁面，該緩存主要是 《Flutter實(shí)戰(zhàn)》網(wǎng)絡(luò)接口緩存 提供參考。
我們在程序退出后內(nèi)存緩存將會(huì)消失，所以我們用 shared_preferences 進(jìn)行磁盤緩存數(shù)據(jù)。
在我們用flutter進(jìn)行抓包的時(shí)候需要配置 Dio 代理。由 DefaultHttpClientAdapter 提供了一個(gè) onHttpClientCreate 回調(diào)來設(shè)置底層 HttpClient 的代理。
用于驗(yàn)證正在訪問的網(wǎng)站是否真實(shí)。提供安全性，因?yàn)樽C書和域名綁定，并且由根證書機(jī)構(gòu)簽名確認(rèn)。
日志打印主要是幫助我們開發(fā)時(shí)進(jìn)行輔助排錯(cuò)
網(wǎng)絡(luò)請求, 先想到的是dart官方維護(hù)的 http 庫. 由于我們項(xiàng)目組網(wǎng)絡(luò)請求都采用的表單結(jié)構(gòu), http 貌似不支持表單格式的網(wǎng)絡(luò)請求; 后來查看 dio 庫, 發(fā)現(xiàn)支持 FormData , 完美解決!
官方表單網(wǎng)絡(luò)請求示例:
比葫蘆畫瓢, 嘗試下
國外地址：
國內(nèi)鏡像：
以 flutter_screenutil 為例
路由框架 annotation_route
狀態(tài)管理 provider
UI適配 flutter_screenutil
刷新控件 flutter_easyrefresh
網(wǎng)絡(luò)請求 dio
toast控件 fluttertoast
圖表庫 charts_flutter
網(wǎng)絡(luò)監(jiān)聽 connectivity
事件總線 event_bus
日歷組件 table_calendar
官方webview webview_flutter
第三方webview flutter_webview_plugin
該篇文章為常用依賴包總結(jié)，用來記錄所需要的常用依賴包，后續(xù)會(huì)不斷擴(kuò)充內(nèi)容~
dio的使用方式有很多，我就只選出我認(rèn)為最好用的api方式做下記錄,把get成post就是post請求了,網(wǎng)絡(luò)請求都用的百度的api，實(shí)際上的response沒有任何意義，所以只要打印出response有值即可。
1.最簡單的請求例子,網(wǎng)絡(luò)請求是異步的所以用async await
2.帶有參數(shù)的get請求
3.自定義請求頭,可定義的請求頭dart已經(jīng)為我們提供了專門的類存了對應(yīng)的字符,引入以下庫，就能使用 HttpHeaders
一般我們請求接收到的數(shù)據(jù)是json格式，如'accept: application/json',我們就可以這樣自定義請求頭
4.使用Baseoptions
其他詳細(xì)參數(shù)設(shè)置參考如下:
下面這種情況下，為 InkWell 設(shè)置的 splashColor 不會(huì)生效：
需要用 Material 去除背景色，然后將顏色設(shè)置在 InkWell 外部：
在 Dialog builder 中使用 WillPopScope 禁用返回鍵返回：
注意：使用此方法同時(shí)也會(huì)禁用 iOS 上的手勢滑動(dòng)返回功能，推薦判斷平臺(tái)后再使用。
修改對話框中的復(fù)選框狀態(tài)，最簡便的方法是通過 Element 中的 markNeedsBuild 方法：
當(dāng)然，更推薦的做法是通過 StatefulBuilder ，然后就可以在 Dialog 中調(diào)用 setState 方法了，不過在調(diào)用 setState 時(shí)需要判斷 Dialog 是否已經(jīng)關(guān)閉，否則會(huì)造成 setState() called after dispose() 的錯(cuò)誤，可以通過添加一個(gè)標(biāo)志位來解決，如下：
在 Web 中加載網(wǎng)絡(luò)圖片有時(shí)會(huì)失敗，遇到這樣的報(bào)錯(cuò)： Exception caught by image resource service... ，造成該錯(cuò)誤的原因通常是，圖片跨域了（見 跨域資源共享 ）。最簡單的解決辦法是， 使用 HTML 渲染加載 ，而不是默認(rèn)的 CanvasKit。
Flutter 中所有的 list 默認(rèn)都是沒有 ScrollBar 的，必須使用 ScrollBar 組件。ScrollBar 組件通過監(jiān)聽 ScrollView 的 ScrollNotification 來刷新位置，所以 List 的長度必須是固定的。
當(dāng)使用 WebView 等高度不定的組件時(shí)會(huì)出現(xiàn)內(nèi)容被截?cái)嗟那闆r，通?？梢允褂?NestedScrollView 來解決該問題，需要在 WebView 外部嵌套 SingleChildScrollView。
雖然使用了緩存，而且也是用 builder 加載圖片的，但是發(fā)現(xiàn)一個(gè)現(xiàn)象：滑動(dòng)屏幕后圖片短暫消失并重新加載了。圖片高度很高時(shí)這種現(xiàn)象更加明顯，其原因是超出屏幕范圍一定距離的組件被重新渲染了。解決方法是在 ListView 上設(shè)置 cacheExtent 參數(shù):
該參數(shù)的作用是改變超出屏幕高度后繼續(xù)渲染的范圍（以像素為單位），比如設(shè)置成 9999 后意味著超出屏幕 10000 像素以內(nèi)的內(nèi)容都會(huì)被保留下來。
借助 IntrinsicHeight 組件：
另外，IntrinsicHeight 還可以用于 Dialog 或者 BottomSheet 中，使得其中的元素 顯示內(nèi)在元素的高度 ，從而避免元素因?yàn)榧s束的存在而不顯示或者高度太高（比如在使用了 Column 或者 Row 的時(shí)候）。
在通過 Uri 的 queryParameters 獲取 query 參數(shù)時(shí)，發(fā)現(xiàn)有些鏈接會(huì)拋出下面異常：
造成該異常的原因是 Uri 默認(rèn)使用 utf-8 解碼超鏈接字符串，如果鏈接中包含非 utf-8 字符，就會(huì)造成上面的錯(cuò)誤，相關(guān) issue 見： issue #31621 。目前該 issue 處于 open 的狀態(tài)，暫時(shí)的解決辦法是，在所有使用到 queryParameter 的地方用 try..catch 捕捉可能拋出的異常。
Flutter 開發(fā)非常依賴各種官方或第三方的插件，而在使用這些插件時(shí)多少都會(huì)遇到一些問題，大部分問題都可以通過搜索和查找 issue 來解決。這里記錄下一些我在使用部分插件時(shí)遇到的問題及其解決方法。
目前該庫沒有圖片加載完成的回調(diào)（見 issue #545 ），不過我們可以通過在 imageBuilder 中來添加回調(diào)：
這是一個(gè)應(yīng)用內(nèi)更新插件，安卓 10 以上安裝時(shí)需要在 manifest 中添加以下內(nèi)容：
目前功能最強(qiáng)大的 WebView 插件，基本能滿足絕大部分移動(dòng)端網(wǎng)頁加載的需求，而且可定制化程度高。
一般通過 CookieManager 修改 Cookie，攔截請求并修改請求對象的 Header 不會(huì)生效。
InAppWebViewOptions 的 userAgent 只在 iOS 上生效，而 applicationNameForUserAgent 只在 Android 上生效，所以最好的做法是分平臺(tái)設(shè)置 InAppWebViewOptions ，而且需要注意，由于設(shè)置 userAgent 后會(huì)覆蓋默認(rèn)的 UserAgent，所以如果需要在默認(rèn)的 UserAgent 上添加其它參數(shù)，iOS 上需要通過 InAppWebViewController.getDefaultUserAgent() 獲取默認(rèn) UserAgent 參數(shù)，而 Android 不需要添加。
如果圖片源或者請求是 http 的，為了在 Android 上正常加載請求，必須在 AndroidInAppWebViewOptions 中將 mixedContentMode 設(shè)置為 AndroidMixedContentMode.MIXED_CONTENT_ALWAYS_ALLOW 。
當(dāng)我們想要設(shè)置全屏圖片的時(shí)候，由于默認(rèn)的 Constraint 會(huì)將圖片居中顯示，所以圖片四周會(huì)留有空隙。為了去除這個(gè)限制，我們需要 Xcode 中打開 LaunchScreen.storyboard，然后在 View Controller 的 View 和 LaunchImage 上的 Safe Area 去掉。
具體設(shè)置方法：右側(cè) Inspector 面板 Show the Size inspector 解選 Layout Margins 中的 Safe Area Relative Margins，拖動(dòng)圖片占滿全屏，然后根據(jù) View Controller Scene 的 Warning，更新 Constraint 就可以了。
在集成某些三方庫之后，在使用命令行運(yùn)行 iOS 模擬器的時(shí)候可能會(huì)遇到下面這個(gè)報(bào)錯(cuò)：
這是因?yàn)?iOS 模擬器未來將會(huì)兼容 arm64 架構(gòu)，但是目前還不支持，所以我們需要修改 Build Setting 使得能夠在 x86_64 的模擬器上運(yùn)行，操作步驟見 這里 。
在yaml文件里邊添加如下依賴
新建一個(gè)network_config.dart文件存放網(wǎng)絡(luò)配置
ApiResponse是之前定義的公共接口返回實(shí)體 Flutter的Json數(shù)據(jù)解析之FlutterJsonBeanFactory插件
主要是對http異常和業(yè)務(wù)異常進(jìn)行處理。
上述封裝后，如果業(yè)務(wù)存在多個(gè)請求依賴調(diào)用，就需要統(tǒng)一的處理錯(cuò)誤。
Dio支持自定義攔截器，繼承 Interceptor ，重寫 onRequest 和 onResponse 方法就行。
在初始化dio的地方，把攔截器加入dio對象的攔截器集合 dio.interceptors 中就行。
可以通過自定義的攔截器實(shí)現(xiàn)，也可以引入 pretty_dio_logger 庫。
fastmock 上新建自己的項(xiàng)目，接口配置如下：
發(fā)起請求：
效果展示：
參考文章：
重慶分公司
重慶分公司
