flutter內(nèi)存消耗,flutter包體積優(yōu)化

Flutter在Debug和Release下分別使用什么編譯模式，有什么區(qū)別？

Debug模式下使用JIT編譯模式，即Just in time(即時(shí)編譯)，Release下使用AOT模式，即Ahead of time(提前編譯)。JIT模式因?yàn)樾枰呥\(yùn)行邊編譯，所以會(huì)占用運(yùn)行時(shí)內(nèi)存，導(dǎo)致卡頓現(xiàn)象，但是有動(dòng)態(tài)編譯效果對(duì)于開(kāi)發(fā)者來(lái)說(shuō)非常方便調(diào)試。AOT模式提前編譯不會(huì)占用運(yùn)行時(shí)內(nèi)存，相對(duì)來(lái)說(shuō)運(yùn)行流暢，但是會(huì)導(dǎo)致編譯時(shí)間增加。

創(chuàng)新互聯(lián)建站是一家專注于網(wǎng)站設(shè)計(jì)、網(wǎng)站制作和遂寧服務(wù)器托管的網(wǎng)絡(luò)公司，有著豐富的建站經(jīng)驗(yàn)和案例。

flutter圖片內(nèi)存優(yōu)化

按照給定尺寸進(jìn)行圖片的解碼，而不是解碼整個(gè)圖片的尺寸，用來(lái)減少內(nèi)存的占用。

官方文檔：

官方說(shuō)明：

Instructs Flutter to decode the image at the specified dimensions instead of at its native size.

This allows finer control of the size of the image in ImageCache and is generally used to reduce the memory footprint of ImageCache .

The decoded image may still be displayed at sizes other than the cached size provided here.

使用：

三方庫(kù)： cached_network_image 限2.5.0之后版本才可用

設(shè)定最大的緩存寬度和高度 this.maxWidthDiskCache 、 this.maxHeightDiskCache

使用：

從相冊(cè)選取圖片，展示時(shí)使用指定尺寸寬高進(jìn)行處理。

使用三方庫(kù)：

使用自定義 provider 來(lái)指定所需圖片的寬高：

AssetEntityImageProvider 傳入寬高和圖片原圖 AssetEntity 數(shù)據(jù)。

provider 中 key.entity.thumbDataWithSize 方法：

進(jìn)入 entity 中 thumbDataWithSize 方法：

進(jìn)入 _getThumbDataWithId 方法中，

進(jìn)入getThumb：

調(diào)用iOS原生的獲取圖片方法，

進(jìn)入 getThumbWithId 方法，

原生實(shí)現(xiàn)獲取置頂寬高縮略圖方法實(shí)現(xiàn)：

使用 iOS 原生類 PHImageManager 的

來(lái)獲取縮略圖。

為什么除了Flutter之外，我們還需要另一個(gè)跨平臺(tái)開(kāi)發(fā)框架？

不久前，谷歌正式推出 Jetpack Compose 1.0 版本。近日，JetBrains 在此基礎(chǔ)上發(fā)布了 Compose Multiplatform Alpha 版本，旨在將 Compose 擴(kuò)展到桌面和 Web 端。

Compose Multiplatform 由 Compose for Desktop 和 Compose for Web 組成，通過(guò) Kotlin Multiplatform 支持許多不同的平臺(tái)。其中，Compose Desktop 采用 Google 的 Skia 圖形庫(kù)，來(lái)實(shí)現(xiàn)在 Windows、macOS 和 Linux 上的 UI 繪制，借此在所有支持的操作系統(tǒng)中提供統(tǒng)一的體驗(yàn)，類似于 Flutter 的做法。

根據(jù) Kotlin 團(tuán)隊(duì)的說(shuō)法，相比起 Electron 框架，Compose Multiplatform 在內(nèi)存消耗、安裝大小和 UI 渲染性能等方面將有更明顯的優(yōu)勢(shì)。隨著 Alpha 版本的發(fā)布，Compose Multiplatform 還收獲了新的 Android Studio 插件，包括對(duì)在 IDE 中顯示組件預(yù)覽的支持以及許多附加功能。

我們希望通過(guò)本文幫助大家進(jìn)一步了解 Compose 的跨平臺(tái)能力，以及 JetBrains 將 Compose 從 Android 擴(kuò)展到這些其他平臺(tái)背后的主要驅(qū)動(dòng)力是什么。

基于 Jetpack Compose 1.0

由谷歌打造的 Jetpack Compose 是一款用于在 Android 應(yīng)用程序之內(nèi)構(gòu)建用戶界面的官方框架，上周剛剛發(fā)布 1.0 版本。與此同時(shí)，Android Studio 代號(hào)“極狐”的首個(gè)穩(wěn)定版 2020.3.1 也正式亮相。

盡管才剛迎來(lái) 1.0，但谷歌表示“目前 Play Store 中已經(jīng)有超過(guò) 2000 款應(yīng)用程序在使用 Compose——更重要的是，就連 Play Store 這款應(yīng)用本身也在使用 Compose?！惫雀璺矫孢€表示，“我們一直在與一些頂級(jí)應(yīng)用的開(kāi)發(fā)人員進(jìn)行合作，他們的反饋和支持幫助我們使 1.0 版本更加強(qiáng)大?！?/p>

Jetpack Compose for Android 迎來(lái) 1.0 版本

Compose 基于 Kotlin 開(kāi)發(fā)，而 Kotlin 與 Android Studio（即官方指定的 Android IDE）均來(lái)自開(kāi)發(fā)工具廠商 JetBrains。雖然 Jetpack Compose 專為 Android 打造（與谷歌的 Flutter 框架不同）， 但 JetBrains 公司堅(jiān)信 Compose 完全能夠獲得跨平臺(tái)能力 。

Compose for Desktop: 這只是開(kāi)始

Compose Multiplatform 可以說(shuō)是該框架面向 MacOS、Linux、Windows 以及 Web 開(kāi)設(shè)的一個(gè)端口，目前剛剛發(fā)布 1.0 Alpha 版本。雖然尚處于早期開(kāi)發(fā)階段，但 JetBrains 表示，其已經(jīng)“為開(kāi)發(fā)人員帶來(lái)能夠基本安全使用的穩(wěn)定 API”。

TheRegister 就此事詢問(wèn)了 JetBrains 公司 Compose 項(xiàng)目負(fù)責(zé)人 Nikolay Igotti，希望了解為什么該公司在擁有了已經(jīng)廣泛應(yīng)用于 IntelliJ IDEA IDE 及多種豐富變體的桌面應(yīng)用程序跨平臺(tái) Java 框架之外，還要費(fèi)力開(kāi)發(fā) Compose for Desktop。Igotti 的回答是，“舊有 Java 框架基本上就是修改版的 Swing。Swing 屬于默認(rèn) JDK UI 框架，Swing 和 AWT（Abstract Windows Toolkit，抽象窗口工具包）。Compose 則完全是另一碼事，當(dāng)然我們也在設(shè)計(jì)中考慮到了互操作性需求……Swing 這套框架太陳舊了，最早出現(xiàn)在上世紀(jì)九十年代末。多年來(lái)人們對(duì)于 UI 的設(shè)計(jì)思路已經(jīng)天翻地覆，Swing 顯然滿足不了要求了。”

JetBrains IDE 中的 Compose for Desktop 項(xiàng)目

Compose 與 Swing 有一個(gè)比較大的共同點(diǎn)：與其他使用本機(jī)控件的跨平臺(tái)框架，比如例如 Java 的 SWT（Standard Widget Toolkit）以及微軟的 Xamarin 有所不同，它們選擇自主繪制控件。Compose 使用的 Skia 開(kāi)源圖形庫(kù)，也在谷歌 Chrome、Flutter 及其他眾多框架當(dāng)中得到廣泛應(yīng)用。那這是否意味著 Compose 應(yīng)用程序?qū)](méi)有自己的原生外觀？對(duì)此，Igotti 的回應(yīng)是，“這取決于開(kāi)發(fā)人員的選擇，取決于他們?nèi)绾螢閼?yīng)用程序設(shè)置主題。在這方面，Compose 的情況與 Flutter 等其他框架沒(méi)什么區(qū)別?！?/p>

那 Compose for Desktop 應(yīng)用程序是否依賴于 JVM（Java Virtual Machine）運(yùn)行？Igotti 表示，“我們也知道，JVM 應(yīng)用程序的發(fā)布情況可能比較棘手。因此我們提供自己的 Gradle 插件，其使用 jpackage 與 Jlink 以 JVM 應(yīng)用程序?yàn)榛A(chǔ)制作原生應(yīng)用程序。Mac 的.dmg、Windows 的 MSI、Linux 的 deb 包等均可實(shí)現(xiàn)，大家用不著擔(dān)心 JVM?！?/p>

也就是說(shuō)，開(kāi)發(fā)成果將會(huì)是一款被精心包裹起來(lái)的 JVM 應(yīng)用程序。JetBrains 還有一款用于解決這個(gè)問(wèn)題的 Kotlin/Native 編譯器，“預(yù)計(jì)將在未來(lái)發(fā)布，或者專門用于桌面開(kāi)發(fā)?！?/p>

對(duì)應(yīng)用程序的另一種思考方式

那 Web 應(yīng)用程序方面呢？Igotti 回應(yīng)稱，“我們使用 Kotlin/JS 編譯器?！盋ompose 的 Web 版本不如桌面版先進(jìn)，說(shuō)明文檔中也警告稱“API 尚未最終確定，預(yù)計(jì)會(huì)發(fā)生重大變化?！贝送猓m然 Web 版本確實(shí)使用 Compose 模型，但 API 卻完全不同，而且會(huì)使用 HTML 與 CSS。所以，Web 版與 Compose for Desktop 之間能夠共享的代碼應(yīng)該比較少。

據(jù) Igotti 介紹，“Compose 代表著一種不同的應(yīng)用程序思考方式。狀態(tài)即 UI 的真實(shí)來(lái)源，而 UI 本身是無(wú)狀態(tài)的，其表達(dá)永遠(yuǎn)由狀態(tài)計(jì)算得出。在這方面，Compose for Web 采用一組相同的原語(yǔ)，完全相同的狀態(tài)管理思路。但是對(duì)于具體的小部件集合與排列方式，Web 版與桌面版之間確實(shí)無(wú)法互通。”

說(shuō)到這里，為什么要把 Compose for Android 擴(kuò)展到多種其他平臺(tái)之上？“Compose 的目標(biāo)受眾主要分為三類。首先是使用 Kotlin 與 Compose 的 Android 開(kāi)發(fā)人員，他們希望把自己的開(kāi)發(fā)成果交付至其他平臺(tái)；其二是純 Kotlin 開(kāi)發(fā)人員，他們希望以‘一次編寫(xiě)、隨處運(yùn)行’的方式開(kāi)發(fā)新的應(yīng)用程序；第三則是那些不太熟悉 Kotlin 或者 Compose，但又希望開(kāi)發(fā)出精美 UI 的用戶，我們希望能為他們提供實(shí)現(xiàn)目標(biāo)的工具?！?/p>

Igotti 并沒(méi)有給出具體的發(fā)布日期，但表示自己希望 Beta 版能在今年秋天發(fā)布，“我們也希望能在今年之內(nèi)推出 1.0 版本。”項(xiàng)目本身是完全開(kāi)源的，“二十一世紀(jì)了，框架在大多數(shù)人們心目中就不應(yīng)該收費(fèi)。我們只是想開(kāi)發(fā)一款長(zhǎng)期缺失的軟件”，補(bǔ)足 JetBrains 當(dāng)前商業(yè)模式中的工具鏈。

那么，JetBrains 會(huì)在自己的其他工具中使用 Compose 嗎？事實(shí)上，他們的 JetBrains Toolbox（用于管理已安裝的 IDE）已經(jīng)在使用 Compose，但 Igotti 表示短時(shí)間內(nèi) Compose 還無(wú)法取代 IntelliJ IDEA 等現(xiàn)有框架?！熬庉嬈魇瞧渲凶顝?fù)雜也最重要的組件，經(jīng)歷了 20 年的發(fā)展演進(jìn)，我們幾乎不可能在中途進(jìn)行重寫(xiě)了。無(wú)論是 JetBrains 還是我個(gè)人，都不打算強(qiáng)迫每個(gè)人都轉(zhuǎn)而使用 Compose。我們的目標(biāo)是為原有框架選項(xiàng)滿足不了的用戶提供新的解決方案?！?/p>

寫(xiě)在最后

那么，為什么除了 Flutter 之外，我們還需要另一個(gè)跨平臺(tái)框架？雖然谷歌的 Flutter 最開(kāi)始主要面向移動(dòng)設(shè)備，但現(xiàn)在也開(kāi)始向桌面及 iOS 進(jìn)軍，甚至比 Compose 還搶先了一步。不過(guò)，根據(jù) StackOverflow 的最新調(diào)查， Flutter 使用的語(yǔ)言為 Dart；盡管 Dart 語(yǔ)言的人氣正在增長(zhǎng)（正是受到 Flutter 的推動(dòng)），但仍然無(wú)法與 Kotlin 相提并論。

Compose 代表著一種獨(dú)特的 UI 構(gòu)建方法，也許最期待 Compose 跨平臺(tái)功能的受眾，正是那些曾在 Android 上使用過(guò)它、又特別喜歡這種 UI 構(gòu)建體驗(yàn)的開(kāi)發(fā)者。

想要進(jìn)一步了解 Compose，國(guó)內(nèi) Android 開(kāi)發(fā)者可訪問(wèn)以下鏈接查看中文手冊(cè)：

延伸閱讀：

Flutter 與 iOS 原生 webView 對(duì)比

本文對(duì)比的是 UIWebView、WKWebView、flutter_webview_plugin（在iOS中使用的是WKWebView）的加載速度，內(nèi)存使用情況。

測(cè)試網(wǎng)頁(yè)打開(kāi)的速度，只需要獲取 WebView 在開(kāi)始加載網(wǎng)頁(yè)和網(wǎng)頁(yè)加載完成時(shí)的時(shí)間戳，時(shí)間戳的差即為打開(kāi)網(wǎng)頁(yè)的時(shí)間

為了使差異更明顯，我們選擇較為復(fù)雜的 新浪首頁(yè) 進(jìn)行加載的對(duì)比，為了減小網(wǎng)絡(luò)對(duì)加載速度的影響，我們讓手機(jī)連接同一個(gè)網(wǎng)絡(luò)，分別進(jìn)行 10 次測(cè)試然后取平均值，另外，我們需要關(guān)閉 WebView 的緩存，防止緩存對(duì)加載速度產(chǎn)生影響

下面使筆者進(jìn)行 10 次測(cè)試所得到的數(shù)據(jù)

結(jié)果讓我有點(diǎn)驚訝，一直以為 WKWebView 會(huì)是個(gè)王者。結(jié)果看，速度上 WKWebView 略慢一點(diǎn)，不過(guò)總體差異不大（該結(jié)果僅僅是測(cè)試新浪的結(jié)果，僅供參考啦）

在這里，筆者又加了一個(gè)測(cè)試，嘗試記錄從 viewController 的 viewDidLoad 到 webview 的 didFinish 時(shí)間，測(cè)試了新浪的數(shù)據(jù)，如下：

UIWebViewA ： 4970、3808、3815、4250、3556 avg(4079.8) （加載完所有頁(yè)面）

UIWebViewB ： 4103、3124、3070、3256、2835 avg(3277.6)（加載sina完畢）

WKWebView ： 3672、3032、2892、2912、2739 avg(3049.4)

flutter_webView ： 4532、3901、4310、3496、3378 avg(3923.4)

其中可以看到，webView 有兩行，UIWebViewB 的數(shù)據(jù)就是加載 sina 主站的時(shí)間；UIWebViewA 的數(shù)據(jù)是因?yàn)樵诩虞d完 sina 主站之后，新浪又加載了一個(gè) ，所以導(dǎo)致總時(shí)間延長(zhǎng)，不過(guò)即使按照 UIWebViewB 的數(shù)據(jù)來(lái)比較，也是 wkWebView 略勝一籌。

此處可以看出 flutter_webView 使用的是 wkwebView，所以它吃虧的主要原因是 flutter 包了一層。

結(jié)論：

速度（didStart - didFinish） UIWebView flutter_webview WKWebView

速度（viewDidLoad - didFinish）WKWebView UIWebView flutter_webview

這里查看內(nèi)存使用的是 xcode 的 debug session 中的 memory。

首先看之前測(cè)試時(shí)，連續(xù)打開(kāi)十次新浪的內(nèi)存情況

接著我們?cè)诳匆幌麓蜷_(kāi)淘寶首頁(yè)的內(nèi)存情況

從圖上可以看出，WKWebView 在內(nèi)存方面有很大的優(yōu)勢(shì)啊，UIWebView 的內(nèi)存是真的傷啊，然后 debug 看了一下 flutter_webView，他使用的就是原生的 webView 。

他相比較原生 WKWebView 的內(nèi)存開(kāi)銷稍大一點(diǎn)，從測(cè)試表現(xiàn)來(lái)看，一般大個(gè) 30 MB 左右。

結(jié)論：內(nèi)存 WKWebView flutter_webview UIWebView

可以在 html5test 中對(duì)瀏覽器的兼容性進(jìn)行評(píng)分，通過(guò)測(cè)試發(fā)現(xiàn)得分分別如下

因?yàn)?flutter 里使用的就是 WK，所以和原生的 WKWebView 一樣都是 444 分，比 UIWebView 的 437 略勝一籌

結(jié)論：兼容性 WKWebView = flutter_webview UIWebView

UIWebView : 速度相比較 WKWebView 稍快一點(diǎn)，但是內(nèi)存是一大硬傷，所以只要條件允許，就不推薦使用了

WKWebView : 速度略慢一點(diǎn)，不過(guò)差別不大，總體可以接受。是比UIWebView更好的選擇，推薦使用。

flutter_webView_plugin ：在iOS中使用的就是原生的WKWebView，所以總體和 native WKWebView 表現(xiàn)差不多。如果是混編項(xiàng)目中，因?yàn)樗话艘粚?，所以?yè)面加載上存在一定的劣勢(shì)，所以混編項(xiàng)目中仍然推薦使用 WKWebView。不過(guò)如果從多端考慮、以及項(xiàng)目可遷移等，那么使用也未嘗不可，就是維護(hù)成本要增加一些，需要維護(hù)兩套 webView。這個(gè)就需要根據(jù)自己的情況自己取舍了。

Flutter Dio源碼分析(四)--封裝

Flutter Dio源碼分析(一)--Dio介紹

Flutter Dio源碼分析(二)--HttpClient、Http、Dio對(duì)比

Flutter Dio源碼分析(三)--深度剖析

Flutter Dio源碼分析(四)--封裝

Flutter Dio源碼分析(一)--Dio介紹視頻教程

Flutter Dio源碼分析(二)--HttpClient、Http、Dio對(duì)比視頻教程

Flutter Dio源碼分析(三)--深度剖析視頻教程

Flutter Dio源碼分析(四)--封裝視頻教程

github倉(cāng)庫(kù)地址

本文會(huì)手把手教你該怎么去封裝一個(gè)類庫(kù)，平時(shí)在我們的工作中都是拿著別人的造好的輪子在使用，這篇文章將帶你怎么去自己造輪子，以后再碰到別的類庫(kù)需要對(duì)其進(jìn)行封裝的時(shí)候提供一個(gè)的思路和方法。

在前面的文章中，我們對(duì) Dio 的基本使用、請(qǐng)求庫(kù)對(duì)比、源碼分析，我們知道 Dio 的使用非常的簡(jiǎn)單，那為什么還需要進(jìn)行封裝呢？有兩點(diǎn)如下：

當(dāng)組件庫(kù)方法發(fā)生重要改變需要遷移的時(shí)候如果有多處地方用到，那么需要對(duì)使用到的每個(gè)文件都進(jìn)行修改，非常的繁瑣而且很容易出問(wèn)題。

當(dāng)不需要 Dio 庫(kù)的時(shí)候，我們可以隨時(shí)方便切換到別的網(wǎng)絡(luò)請(qǐng)求庫(kù)，當(dāng)然 Dio 目前內(nèi)置支持使用第三方庫(kù)的適配器。

因?yàn)橐粋€(gè)應(yīng)用程序基本都是統(tǒng)一的配置方式，所以我們可以針對(duì) 攔截器 、 轉(zhuǎn)換器 、 緩存 、 統(tǒng)一處理錯(cuò)誤 、 代理配置 、 證書(shū)校驗(yàn) 等多個(gè)配置進(jìn)行統(tǒng)一管理。

因?yàn)槲覀兊膽?yīng)用程序在每個(gè)頁(yè)面中都會(huì)用到網(wǎng)絡(luò)請(qǐng)求，那么如果我們每次請(qǐng)求的時(shí)候都去實(shí)例化一個(gè) Dio ，無(wú)非是增加了系統(tǒng)不必要的開(kāi)銷，而使用單例模式對(duì)象一旦創(chuàng)建每次訪問(wèn)都是同一個(gè)對(duì)象，不需要再次實(shí)例化該類的對(duì)象。

這是通過(guò)靜態(tài)變量的私有構(gòu)造器來(lái)創(chuàng)建的單例模式

我們對(duì) 超時(shí)時(shí)間 、 響應(yīng)時(shí)間 、 BaseUrl 進(jìn)行統(tǒng)一設(shè)置

因?yàn)椴还苁?get() 還是 post() 請(qǐng)求， Dio 內(nèi)部最終都會(huì)調(diào)用 request 方法，只是傳入的 method 不一樣，所以我們這里定義一個(gè)枚舉類型在一個(gè)方法中進(jìn)行處理

我們已經(jīng)把 Restful API 風(fēng)格簡(jiǎn)化成了一個(gè)方法，通過(guò) DioMethod 來(lái)標(biāo)明不同的請(qǐng)求方式。在我們平時(shí)開(kāi)發(fā)的過(guò)程中，需要在請(qǐng)求前、響應(yīng)前、錯(cuò)誤時(shí)對(duì)某一些接口做特殊的處理，那我們就需要用到攔截器。 Dio 為我們提供了自定義攔截器功能，很容易輕松的實(shí)現(xiàn)對(duì)請(qǐng)求、響應(yīng)、錯(cuò)誤時(shí)進(jìn)行攔截

我們發(fā)現(xiàn)雖然 Dio 框架已經(jīng)封裝了一個(gè) DioError 類庫(kù)，但如果需要對(duì)返回的錯(cuò)誤進(jìn)行統(tǒng)一彈窗處理或者路由跳轉(zhuǎn)等就只能自定義了

在我們發(fā)送請(qǐng)求的時(shí)候會(huì)碰到幾種情況，比如需要對(duì)非open開(kāi)頭的接口自動(dòng)加上一些特定的參數(shù)，獲取需要在請(qǐng)求頭增加統(tǒng)一的 token

在我們請(qǐng)求接口前可以對(duì)響應(yīng)數(shù)據(jù)進(jìn)行一些基礎(chǔ)的處理，比如對(duì)響應(yīng)的結(jié)果進(jìn)行自定義封裝，還可以針對(duì)單獨(dú)的 url 做特殊處理等。

我們看了轉(zhuǎn)換器的介紹，發(fā)現(xiàn)和攔截器的功能差不多，那為什么還要存在轉(zhuǎn)換器，有兩點(diǎn)：

執(zhí)行流程： 請(qǐng)求攔截器 請(qǐng)求轉(zhuǎn)換器 發(fā)起請(qǐng)求 響應(yīng)轉(zhuǎn)換器 響應(yīng)攔截器 最終結(jié)果 。

只會(huì)被用于 'PUT'、 'POST'、 'PATCH'方法，因?yàn)橹挥羞@些方法才可以攜帶請(qǐng)求體(request body)

會(huì)被用于所有請(qǐng)求方法的返回?cái)?shù)據(jù)。

在開(kāi)發(fā)過(guò)程中，客戶端和服務(wù)器打交道的時(shí)候，往往會(huì)用一個(gè) token 來(lái)做校驗(yàn)，因?yàn)槊總€(gè)公司處理刷新token的邏輯都不一樣，我這里舉一個(gè)簡(jiǎn)單的例子

為什么我們需要有取消請(qǐng)求的功能，如果當(dāng)我們的頁(yè)面在發(fā)送請(qǐng)求時(shí)，用戶主動(dòng)退出當(dāng)前界面或者app應(yīng)用程序退出的時(shí)候數(shù)據(jù)還沒(méi)有響應(yīng)，那我們就需要取消該網(wǎng)絡(luò)請(qǐng)求，防止不必要的錯(cuò)誤。

由 服務(wù)器生成 的 一小段文本信息 ，發(fā)送給瀏覽器，瀏覽器把 cookie 以kv形式保存到本地 某個(gè)目錄下的文本文件內(nèi)，下一次請(qǐng)求同一網(wǎng)站時(shí)會(huì)把該 cookie 發(fā)送給服務(wù)器。

cookie 的使用需要用到兩個(gè)第三方組件 dio_cookie_manager 和 cookie_jar

因?yàn)樵谖覀兤綍r(shí)的開(kāi)發(fā)過(guò)程中，會(huì)碰到一種情況，在進(jìn)行網(wǎng)絡(luò)請(qǐng)求時(shí)，我們希望能正常訪問(wèn)到上次的數(shù)據(jù)，對(duì)于用戶的體驗(yàn)比較好，而不是展示一個(gè)空白的頁(yè)面，該緩存主要是 《Flutter實(shí)戰(zhàn)》網(wǎng)絡(luò)接口緩存 提供參考。

我們?cè)诔绦蛲顺龊髢?nèi)存緩存將會(huì)消失，所以我們用 shared_preferences 進(jìn)行磁盤緩存數(shù)據(jù)。

在我們用flutter進(jìn)行抓包的時(shí)候需要配置 Dio 代理。由 DefaultHttpClientAdapter 提供了一個(gè) onHttpClientCreate 回調(diào)來(lái)設(shè)置底層 HttpClient 的代理。

用于驗(yàn)證正在訪問(wèn)的網(wǎng)站是否真實(shí)。提供安全性，因?yàn)樽C書(shū)和域名綁定，并且由根證書(shū)機(jī)構(gòu)簽名確認(rèn)。

日志打印主要是幫助我們開(kāi)發(fā)時(shí)進(jìn)行輔助排錯(cuò)

Flutter 之 文件操作（二十九）

Dart的 IO 庫(kù)包含了文件讀寫(xiě)的相關(guān)類，它屬于 Dart 語(yǔ)法標(biāo)準(zhǔn)的一部分，所以通過(guò) Dart IO 庫(kù)，無(wú)論是 Dart VM 下的腳本還是 Flutter，都是通過(guò) Dart IO 庫(kù)來(lái)操作文件的，不過(guò)和 Dart VM 相比，F(xiàn)lutter 有一個(gè)重要差異是文件系統(tǒng)路徑不同，這是因?yàn)镈art VM 是運(yùn)行在 PC 或服務(wù)器操作系統(tǒng)下，而 Flutter 是運(yùn)行在移動(dòng)操作系統(tǒng)中，他們的文件系統(tǒng)會(huì)有一些差異。

Android 和 iOS 的應(yīng)用存儲(chǔ)目錄不同， PathProvider 插件提供了一種平臺(tái)透明的方式來(lái)訪問(wèn)設(shè)備文件系統(tǒng)上的常用位置。該類當(dāng)前支持訪問(wèn)兩個(gè)文件系統(tǒng)位置：

File代表一個(gè)整體的文件,他有三個(gè)構(gòu)造函數(shù)，分別是：

文件讀取本身有兩種形式，一種是文本，一種是二進(jìn)制。

2.2.1 讀取文本內(nèi)容

如果是文本文件，F(xiàn)ile提供了readAsString、readAsLines、readAsStringSync、readAsLinesSync方法，讀取文本內(nèi)容

readAsString 一次性讀取所有文本

readAsLines 一行行的讀取文本

結(jié)果返回的是一個(gè)List，list中表示文件每行的內(nèi)容

readAsStringSync、readAsLinesSync同步讀取文本

2.2.2 讀取二進(jìn)制內(nèi)容

如果文件是二進(jìn)制，那么可以使用readAsBytes或者同步的方法readAsBytesSync:

dart中表示二進(jìn)制有一個(gè)專門的類型叫做Uint8List,他實(shí)際上表示的是一個(gè)int的List。

上面提到的讀取方式，都是一次性讀取整個(gè)文件，缺點(diǎn)就是如果文件太大的話，可能造成內(nèi)存空間的壓力。

所以File為我們提供了另外一種讀取文件的方法，流的形式來(lái)讀取文件.

示例

dart提供了open和openSync兩個(gè)方法來(lái)進(jìn)行隨機(jī)文件讀寫(xiě)：

寫(xiě)入和文件讀取一樣，可以一次性寫(xiě)入或者獲得一個(gè)寫(xiě)入句柄，然后再寫(xiě)入。

一次性寫(xiě)入的方法有四種，分別對(duì)應(yīng)字符串和二進(jìn)制

句柄形式可以調(diào)用openWrite方法，返回一個(gè)IOSink對(duì)象，然后通過(guò)這個(gè)對(duì)象進(jìn)行寫(xiě)入：

默認(rèn)情況下寫(xiě)入是會(huì)覆蓋整個(gè)文件的，但是可以通過(guò)下面的方式來(lái)更改寫(xiě)入模式：

雖然dart中所有的異常都是運(yùn)行時(shí)異常，但是和java一樣，要想手動(dòng)處理文件讀寫(xiě)中的異常，則可以使用try,catch:

我們還是以計(jì)數(shù)器為例，實(shí)現(xiàn)在應(yīng)用退出重啟后可以恢復(fù)點(diǎn)擊次數(shù)。 這里，我們使用文件來(lái)保存數(shù)據(jù)：

1.引入PathProvider插件；在pubspec.yaml文件中添加如下聲明：

執(zhí)行 flutter pub get

2.實(shí)現(xiàn)如下

參考：

分享文章：flutter內(nèi)存消耗,flutter包體積優(yōu)化
鏈接URL：http://m.jiaotiyi.com/article/hohdsc.html