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

Debug模式下使用JIT編譯模式，即Just in time(即時編譯)，Release下使用AOT模式，即Ahead of time(提前編譯)。JIT模式因為需要邊運行邊編譯，所以會占用運行時內存，導致卡頓現(xiàn)象，但是有動態(tài)編譯效果對于開發(fā)者來說非常方便調試。AOT模式提前編譯不會占用運行時內存，相對來說運行流暢，但是會導致編譯時間增加。

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

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

按照給定尺寸進行圖片的解碼，而不是解碼整個圖片的尺寸，用來減少內存的占用。

官方文檔：

官方說明：

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.

使用：

三方庫： cached_network_image 限2.5.0之后版本才可用

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

使用：

從相冊選取圖片，展示時使用指定尺寸寬高進行處理。

使用三方庫：

使用自定義 provider 來指定所需圖片的寬高：

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

provider 中 key.entity.thumbDataWithSize 方法：

進入 entity 中 thumbDataWithSize 方法：

進入 _getThumbDataWithId 方法中，

進入getThumb：

調用iOS原生的獲取圖片方法，

進入 getThumbWithId 方法，

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

使用 iOS 原生類 PHImageManager 的

來獲取縮略圖。

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

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

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

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

我們希望通過本文幫助大家進一步了解 Compose 的跨平臺能力，以及 JetBrains 將 Compose 從 Android 擴展到這些其他平臺背后的主要驅動力是什么。

基于 Jetpack Compose 1.0

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

盡管才剛迎來 1.0，但谷歌表示“目前 Play Store 中已經(jīng)有超過 2000 款應用程序在使用 Compose——更重要的是，就連 Play Store 這款應用本身也在使用 Compose。”谷歌方面還表示，“我們一直在與一些頂級應用的開發(fā)人員進行合作，他們的反饋和支持幫助我們使 1.0 版本更加強大。”

Jetpack Compose for Android 迎來 1.0 版本

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

Compose for Desktop: 這只是開始

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

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

JetBrains IDE 中的 Compose for Desktop 項目

Compose 與 Swing 有一個比較大的共同點：與其他使用本機控件的跨平臺框架，比如例如 Java 的 SWT（Standard Widget Toolkit）以及微軟的 Xamarin 有所不同，它們選擇自主繪制控件。Compose 使用的 Skia 開源圖形庫，也在谷歌 Chrome、Flutter 及其他眾多框架當中得到廣泛應用。那這是否意味著 Compose 應用程序將沒有自己的原生外觀？對此，Igotti 的回應是，“這取決于開發(fā)人員的選擇，取決于他們如何為應用程序設置主題。在這方面，Compose 的情況與 Flutter 等其他框架沒什么區(qū)別。”

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

也就是說，開發(fā)成果將會是一款被精心包裹起來的 JVM 應用程序。JetBrains 還有一款用于解決這個問題的 Kotlin/Native 編譯器，“預計將在未來發(fā)布，或者專門用于桌面開發(fā)?！?/p>

對應用程序的另一種思考方式

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

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

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

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

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

寫在最后

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

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

想要進一步了解 Compose，國內 Android 開發(fā)者可訪問以下鏈接查看中文手冊：

延伸閱讀：

Flutter 與 iOS 原生 webView 對比

本文對比的是 UIWebView、WKWebView、flutter_webview_plugin（在iOS中使用的是WKWebView）的加載速度，內存使用情況。

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

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

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

結果讓我有點驚訝，一直以為 WKWebView 會是個王者。結果看，速度上 WKWebView 略慢一點，不過總體差異不大（該結果僅僅是測試新浪的結果，僅供參考啦）

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

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

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 主站的時間；UIWebViewA 的數(shù)據(jù)是因為在加載完 sina 主站之后，新浪又加載了一個 ，所以導致總時間延長，不過即使按照 UIWebViewB 的數(shù)據(jù)來比較，也是 wkWebView 略勝一籌。

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

結論：

速度（didStart - didFinish） UIWebView flutter_webview WKWebView

速度（viewDidLoad - didFinish）WKWebView UIWebView flutter_webview

這里查看內存使用的是 xcode 的 debug session 中的 memory。

首先看之前測試時，連續(xù)打開十次新浪的內存情況

接著我們在看一下打開淘寶首頁的內存情況

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

他相比較原生 WKWebView 的內存開銷稍大一點，從測試表現(xiàn)來看，一般大個 30 MB 左右。

結論：內存 WKWebView flutter_webview UIWebView

可以在 html5test 中對瀏覽器的兼容性進行評分，通過測試發(fā)現(xiàn)得分分別如下

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

結論：兼容性 WKWebView = flutter_webview UIWebView

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

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

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

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

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倉庫地址

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

在前面的文章中，我們對 Dio 的基本使用、請求庫對比、源碼分析，我們知道 Dio 的使用非常的簡單，那為什么還需要進行封裝呢？有兩點如下：

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

當不需要 Dio 庫的時候，我們可以隨時方便切換到別的網(wǎng)絡請求庫，當然 Dio 目前內置支持使用第三方庫的適配器。

因為一個應用程序基本都是統(tǒng)一的配置方式，所以我們可以針對 攔截器 、 轉換器 、 緩存 、 統(tǒng)一處理錯誤 、 代理配置 、 證書校驗 等多個配置進行統(tǒng)一管理。

因為我們的應用程序在每個頁面中都會用到網(wǎng)絡請求，那么如果我們每次請求的時候都去實例化一個 Dio ，無非是增加了系統(tǒng)不必要的開銷，而使用單例模式對象一旦創(chuàng)建每次訪問都是同一個對象，不需要再次實例化該類的對象。

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

我們對 超時時間 、 響應時間 、 BaseUrl 進行統(tǒng)一設置

因為不管是 get() 還是 post() 請求， Dio 內部最終都會調用 request 方法，只是傳入的 method 不一樣，所以我們這里定義一個枚舉類型在一個方法中進行處理

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

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

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

在我們請求接口前可以對響應數(shù)據(jù)進行一些基礎的處理，比如對響應的結果進行自定義封裝，還可以針對單獨的 url 做特殊處理等。

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

執(zhí)行流程： 請求攔截器 請求轉換器 發(fā)起請求 響應轉換器 響應攔截器 最終結果 。

只會被用于 'PUT'、 'POST'、 'PATCH'方法，因為只有這些方法才可以攜帶請求體(request body)

會被用于所有請求方法的返回數(shù)據(jù)。

在開發(fā)過程中，客戶端和服務器打交道的時候，往往會用一個 token 來做校驗，因為每個公司處理刷新token的邏輯都不一樣，我這里舉一個簡單的例子

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

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

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

因為在我們平時的開發(fā)過程中，會碰到一種情況，在進行網(wǎng)絡請求時，我們希望能正常訪問到上次的數(shù)據(jù)，對于用戶的體驗比較好，而不是展示一個空白的頁面，該緩存主要是 《Flutter實戰(zhàn)》網(wǎng)絡接口緩存 提供參考。

我們在程序退出后內存緩存將會消失，所以我們用 shared_preferences 進行磁盤緩存數(shù)據(jù)。

在我們用flutter進行抓包的時候需要配置 Dio 代理。由 DefaultHttpClientAdapter 提供了一個 onHttpClientCreate 回調來設置底層 HttpClient 的代理。

用于驗證正在訪問的網(wǎng)站是否真實。提供安全性，因為證書和域名綁定，并且由根證書機構簽名確認。

日志打印主要是幫助我們開發(fā)時進行輔助排錯

Flutter 之 文件操作（二十九）

Dart的 IO 庫包含了文件讀寫的相關類，它屬于 Dart 語法標準的一部分，所以通過 Dart IO 庫，無論是 Dart VM 下的腳本還是 Flutter，都是通過 Dart IO 庫來操作文件的，不過和 Dart VM 相比，F(xiàn)lutter 有一個重要差異是文件系統(tǒng)路徑不同，這是因為Dart VM 是運行在 PC 或服務器操作系統(tǒng)下，而 Flutter 是運行在移動操作系統(tǒng)中，他們的文件系統(tǒng)會有一些差異。

Android 和 iOS 的應用存儲目錄不同， PathProvider 插件提供了一種平臺透明的方式來訪問設備文件系統(tǒng)上的常用位置。該類當前支持訪問兩個文件系統(tǒng)位置：

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

文件讀取本身有兩種形式，一種是文本，一種是二進制。

2.2.1 讀取文本內容

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

readAsString 一次性讀取所有文本

readAsLines 一行行的讀取文本

結果返回的是一個List，list中表示文件每行的內容

readAsStringSync、readAsLinesSync同步讀取文本

2.2.2 讀取二進制內容

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

dart中表示二進制有一個專門的類型叫做Uint8List,他實際上表示的是一個int的List。

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

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

示例

dart提供了open和openSync兩個方法來進行隨機文件讀寫：

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

一次性寫入的方法有四種，分別對應字符串和二進制

句柄形式可以調用openWrite方法，返回一個IOSink對象，然后通過這個對象進行寫入：

默認情況下寫入是會覆蓋整個文件的，但是可以通過下面的方式來更改寫入模式：

雖然dart中所有的異常都是運行時異常，但是和java一樣，要想手動處理文件讀寫中的異常，則可以使用try,catch:

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

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

執(zhí)行 flutter pub get

2.實現(xiàn)如下

參考：

新聞標題：flutter內存消耗,flutter包體積優(yōu)化
文章出自：http://chinadenli.net/article32/hohdsc.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供動態(tài)網(wǎng)站、網(wǎng)站收錄、標簽優(yōu)化、電子商務、網(wǎng)站制作、網(wǎng)站內鏈

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)