準(zhǔn)備寫這一系列的文章自己是下了很大的決心的，自知會遇到很大的困難。因能力有限，如有疏漏之處，還請大家斧正。
我們提供的服務(wù)有：成都網(wǎng)站制作、做網(wǎng)站、外貿(mào)營銷網(wǎng)站建設(shè)、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、龍亭ssl等。為上1000+企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的龍亭網(wǎng)站制作公司
相信大家都看過很多遍下面那張圖，這個系列的文章就是要分析紅框內(nèi)的源碼：
我們看源碼的結(jié)構(gòu)其實是這樣的：
總共十二個模塊，對應(yīng)的模塊我一旦寫完就會在下面更新鏈接：
官方文檔
將 Flutter module 集成到 iOS 項目
（1）這時候還沒有App.framework ， podspec文件是有了
（2）有engine，F(xiàn)lutter.framework。
（3）有插件列表 podspec FlutterPluginRegistrant.podspec，這時沒有symlinks/plugins目錄軟鏈接
（4）導(dǎo)出當(dāng)前的環(huán)境變量 flutter_export_environment.sh
flutter-plugins-dependencies
執(zhí)行 podHelper.rb 腳本
做2件事情：
/Volumes/huc/opt/fvm/versions/2.2.0/packages/flutter_tools/bin/xcode_backend.sh build
多了.symlinks 和App.framework，重新拷貝了Flutter.xcframework
Pods-HouseCommercialCube-frameworks.sh
執(zhí)行 xcode_backend.sh
做3件事情：
AppFrameworkInfo.plist
assets_path 這個后面也沒有人用??！
放到.ios下面
.ios/Flutter/engine/Flutter.xcframework
編譯前， 把這個下面添加一個空文件， engine被覆蓋了，那么那個空文件就沒了？
對比了一下大小。 release
debug 版本的Flutter.xcframework 255M
ios-release 1.03 GB
一開始是1.03G， run之后， 變成了255M
說明確實拷貝到這里了
.ios下面App.framework 沒有變
App.framework 61Mb
Flutter.framework 35Mb
"${PODS_ROOT}/Target Support Files/Pods-HouseCommercialCube/Pods-HouseCommercialCube-frameworks.sh"
Flutter Dio源碼分析(一)--Dio介紹
Flutter Dio源碼分析(二)--HttpClient、Http、Dio對比
Flutter Dio源碼分析(三)--深度剖析
Flutter Dio源碼分析(四)--封裝
Flutter Dio源碼分析(一)--Dio介紹視頻教程
Flutter Dio源碼分析(二)--HttpClient、Http、Dio對比視頻教程
Flutter Dio源碼分析(三)--深度剖析視頻教程
Flutter Dio源碼分析(四)--封裝視頻教程
github倉庫地址
本文會手把手教你該怎么去封裝一個類庫，平時在我們的工作中都是拿著別人的造好的輪子在使用，這篇文章將帶你怎么去自己造輪子，以后再碰到別的類庫需要對其進(jìn)行封裝的時候提供一個的思路和方法。
在前面的文章中，我們對 Dio 的基本使用、請求庫對比、源碼分析，我們知道 Dio 的使用非常的簡單，那為什么還需要進(jìn)行封裝呢？有兩點如下：
當(dāng)組件庫方法發(fā)生重要改變需要遷移的時候如果有多處地方用到，那么需要對使用到的每個文件都進(jìn)行修改，非常的繁瑣而且很容易出問題。
當(dāng)不需要 Dio 庫的時候，我們可以隨時方便切換到別的網(wǎng)絡(luò)請求庫，當(dāng)然 Dio 目前內(nèi)置支持使用第三方庫的適配器。
因為一個應(yīng)用程序基本都是統(tǒng)一的配置方式，所以我們可以針對 攔截器 、 轉(zhuǎn)換器 、 緩存 、 統(tǒng)一處理錯誤 、 代理配置 、 證書校驗 等多個配置進(jìn)行統(tǒng)一管理。
因為我們的應(yīng)用程序在每個頁面中都會用到網(wǎng)絡(luò)請求，那么如果我們每次請求的時候都去實例化一個 Dio ，無非是增加了系統(tǒng)不必要的開銷，而使用單例模式對象一旦創(chuàng)建每次訪問都是同一個對象，不需要再次實例化該類的對象。
這是通過靜態(tài)變量的私有構(gòu)造器來創(chuàng)建的單例模式
我們對 超時時間 、 響應(yīng)時間 、 BaseUrl 進(jìn)行統(tǒng)一設(shè)置
因為不管是 get() 還是 post() 請求， Dio 內(nèi)部最終都會調(diào)用 request 方法，只是傳入的 method 不一樣，所以我們這里定義一個枚舉類型在一個方法中進(jìn)行處理
我們已經(jīng)把 Restful API 風(fēng)格簡化成了一個方法，通過 DioMethod 來標(biāo)明不同的請求方式。在我們平時開發(fā)的過程中，需要在請求前、響應(yīng)前、錯誤時對某一些接口做特殊的處理，那我們就需要用到攔截器。 Dio 為我們提供了自定義攔截器功能，很容易輕松的實現(xiàn)對請求、響應(yīng)、錯誤時進(jìn)行攔截
我們發(fā)現(xiàn)雖然 Dio 框架已經(jīng)封裝了一個 DioError 類庫，但如果需要對返回的錯誤進(jìn)行統(tǒng)一彈窗處理或者路由跳轉(zhuǎn)等就只能自定義了
在我們發(fā)送請求的時候會碰到幾種情況，比如需要對非open開頭的接口自動加上一些特定的參數(shù)，獲取需要在請求頭增加統(tǒng)一的 token
在我們請求接口前可以對響應(yīng)數(shù)據(jù)進(jìn)行一些基礎(chǔ)的處理，比如對響應(yīng)的結(jié)果進(jìn)行自定義封裝，還可以針對單獨的 url 做特殊處理等。
我們看了轉(zhuǎn)換器的介紹，發(fā)現(xiàn)和攔截器的功能差不多，那為什么還要存在轉(zhuǎn)換器，有兩點：
執(zhí)行流程： 請求攔截器 請求轉(zhuǎn)換器 發(fā)起請求 響應(yīng)轉(zhuǎn)換器 響應(yīng)攔截器 最終結(jié)果 。
只會被用于 'PUT'、 'POST'、 'PATCH'方法，因為只有這些方法才可以攜帶請求體(request body)
會被用于所有請求方法的返回數(shù)據(jù)。
在開發(fā)過程中，客戶端和服務(wù)器打交道的時候，往往會用一個 token 來做校驗，因為每個公司處理刷新token的邏輯都不一樣，我這里舉一個簡單的例子
為什么我們需要有取消請求的功能，如果當(dāng)我們的頁面在發(fā)送請求時，用戶主動退出當(dāng)前界面或者app應(yīng)用程序退出的時候數(shù)據(jù)還沒有響應(yīng)，那我們就需要取消該網(wǎng)絡(luò)請求，防止不必要的錯誤。
由 服務(wù)器生成 的 一小段文本信息 ，發(fā)送給瀏覽器，瀏覽器把 cookie 以kv形式保存到本地 某個目錄下的文本文件內(nèi)，下一次請求同一網(wǎng)站時會把該 cookie 發(fā)送給服務(wù)器。
cookie 的使用需要用到兩個第三方組件 dio_cookie_manager 和 cookie_jar
因為在我們平時的開發(fā)過程中，會碰到一種情況，在進(jìn)行網(wǎng)絡(luò)請求時，我們希望能正常訪問到上次的數(shù)據(jù)，對于用戶的體驗比較好，而不是展示一個空白的頁面，該緩存主要是 《Flutter實戰(zhàn)》網(wǎng)絡(luò)接口緩存 提供參考。
我們在程序退出后內(nèi)存緩存將會消失，所以我們用 shared_preferences 進(jìn)行磁盤緩存數(shù)據(jù)。
在我們用flutter進(jìn)行抓包的時候需要配置 Dio 代理。由 DefaultHttpClientAdapter 提供了一個 onHttpClientCreate 回調(diào)來設(shè)置底層 HttpClient 的代理。
用于驗證正在訪問的網(wǎng)站是否真實。提供安全性，因為證書和域名綁定，并且由根證書機構(gòu)簽名確認(rèn)。
日志打印主要是幫助我們開發(fā)時進(jìn)行輔助排錯
重慶分公司
重慶分公司
