Flutter設置APP版本與構建版本

當一個純Flutter APP開發(fā)完成，我們要打包發(fā)布到App Store和各大安卓市場，這時候我們需要設置APP的版本號。

創(chuàng)新互聯(lián)堅持“要么做到，要么別承諾”的工作理念，服務領域包括：成都網(wǎng)站制作、做網(wǎng)站、外貿(mào)營銷網(wǎng)站建設、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務，滿足客戶于互聯(lián)網(wǎng)時代的民豐網(wǎng)站設計、移動媒體設計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡建設合作伙伴！

如果我們在使用原生iOS或者Android開發(fā)的時,我們會在info.plist中設置 version 和 build 或是在build.gradle中設置 versionName 和 versionCode ,他們分別表示APP的版本和構建版本。

但是我們在使用Flutter管理APP版本時，打開 pubspec.yaml 只看到一個 version 字段。這時候我們應該怎么設置APP的 version 和 build 呢？

我們在pub上隨便找一個Flutter的組件，例如官方的 camera ,我們可以看到截止目前為止最新的版本為： camera: ^0.5.2+1 。看到這里，我想大家都明白了，Dart采用的是加號式的版本描述方式， + 前面是版本號， + 后面是當前版本的build號。所以我們設置APP的版本號和build次數(shù)，在這里設置即可，例如： version: 1.2.0+1 。

當我們新建一個Flutter工程的時候，我們分別使用Xcode和Android Studio打開iOS和Android的工程可以看到，iOS中的 version 和 build 的值分別為 FLUTTER_BUILD_NAME 和 FLUTTER_BUILD_NUMBER ：

同樣我們打開Android工程可以看到有如下定義：

事實上，F(xiàn)lutter在編譯的時候會生成 ios/Flutter/Generated.xcconfig 和 android/local.properties 文件。這兩個文件由Flutter編譯自動生成，不可更改。記錄了包含SDK路徑或者文件路徑，版本信息，環(huán)境配置（release/debug）等信息。原生工程獲取版本信息的變量就定義在這兩個文件里面。

Flutter 94: 初識 MediaQuery

當我們同時為手機和平板適配編寫 app 針對不同屏幕尺寸進行 UI 布局或當用戶偏好設置較大字號或是想要最大限度等減少動畫等；此時就需要 MediaQuery 來幫我們獲取所用設備的信息以及用戶設置的偏好信息；

MediaQuery 一直存在于 WidgetsApp 和 MaterialApp 中， MediaQuery 繼承自 InheritedWidget 是一個單獨的 Widget ，但一般通過 MediaQuery.of(context) 來獲取相關信息；

當相關信息發(fā)生變化，例如屏幕旋轉等時，屏幕中 Widget 會重新構建，以保持最新狀態(tài)；我們可以通過 MediaQuery 構造函數(shù)和提供的靜態(tài)方法手動設置對應的相關信息；

MediaQueryData 包含關于媒介的相關信息；一般通過 MediaQuery.of(context) 獲取；

size 為媒介的尺寸大小，以邏輯像素為單位；

devicePixelRatio 為像素密度；與設備物理像素有關，與橫豎屏等無關；

orientation 為橫豎屏， Orientation.landscape 為橫屏， Orientation.portrait 為豎屏；

textScaleFactor 為

每個邏輯像素的字體像素數(shù)，小菜理解為字體的像素比；注意，小菜設置了默認字體像素密度為標準的 1.2 倍之后調(diào)整設備系統(tǒng)字號，其 1.2 倍依舊是以標準字號為基礎擴大 1.2 倍；

platformBrightness 為當前設備的亮度模式；注意調(diào)整屏幕亮度并不會改變該模式，與當前系統(tǒng)支持的黑暗模式和明亮模式相關；

alwaysUse24HourFormat 為當前設備是否為 24 小時制；

accessibleNavigation 為是否使用 TalkBack 或 VoiceOver 之類的輔助功能與應用程序進行交互，用以輔助視力障礙人群；

invertColors 為是否使用顏色反轉，主要用于 iOS 設備；

highContrast 為用戶是否要求前景與背景之間的對比度高，主要用于 iOS 設備；

disableAnimations 為平臺是否要求禁用或減少動畫；

boldText 為平臺是否要求使用粗體；

padding 為屏幕內(nèi)邊距，一般是劉海兒屏或異形屏中被系統(tǒng)遮擋部分邊距；

viewInsets 為鍵盤彈出時等遮擋屏幕邊距，其中 viewInsets.bottom 為鍵盤高度；

systemGestureInsets 為手勢邊距，如 Android Q 之后添加的向左滑動關閉頁面等；

viewPadding 小菜理解為視圖內(nèi)邊距，為屏幕被劉海兒屏或異形屏中被系統(tǒng)遮擋部分，從 MediaQuery 邊界的邊緣計算；此值是保持不變；例如，屏幕底部的軟件鍵盤可能會覆蓋并占用需要底部填充的相同區(qū)域，因此不會影響此值；

physicalDepth 為設備物理層級，小菜暫時還未想到對應的應用場景；

小菜在嘗試獲取其他子 Widget Size 時，有兩點需要注意，首先要設置一個全局的 GlobalKey 來獲取當前位置， key 需要為唯一的；第二通過 GlobalKey().currentContext 獲取 BuildContext 上下文環(huán)境，從而獲取對應尺寸；

MediaQuery 案例嘗試

小菜對于部分 MediaQueryData 的應用和理解還不夠深入；如有錯誤請多多指導！

為什么除了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 在內(nèi)存消耗、安裝大小和 UI 渲染性能等方面將有更明顯的優(yōu)勢。隨著 Alpha 版本的發(fā)布，Compose Multiplatform 還收獲了新的 Android Studio 插件，包括對在 IDE 中顯示組件預覽的支持以及許多附加功能。

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

基于 Jetpack Compose 1.0

由谷歌打造的 Jetpack Compose 是一款用于在 Android 應用程序之內(nèi)構建用戶界面的官方框架，上周剛剛發(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 顯然滿足不了要求了。”

JetBrains IDE 中的 Compose for Desktop 項目

Compose 與 Swing 有一個比較大的共同點：與其他使用本機控件的跨平臺框架，比如例如 Java 的 SWT（Standard Widget Toolkit）以及微軟的 Xamarin 有所不同，它們選擇自主繪制控件。Compose 使用的 Skia 開源圖形庫，也在谷歌 Chrome、Flutter 及其他眾多框架當中得到廣泛應用。那這是否意味著 Compose 應用程序?qū)]有自己的原生外觀？對此，Igotti 的回應是，“這取決于開發(fā)人員的選擇，取決于他們?nèi)绾螢閼贸绦蛟O置主題。在這方面，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。”

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

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

那 Web 應用程序方面呢？Igotti 回應稱，“我們使用 Kotlin/JS 編譯器。”Compose 的 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 版與桌面版之間確實無法互通。”

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

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

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

寫在最后

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

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

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

延伸閱讀：

標題名稱：最新flutter,最新電視劇
文章起源：http://chinadenli.net/article19/dsihdgh.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供App設計、企業(yè)網(wǎng)站制作、定制網(wǎng)站、建站公司、服務器托管、網(wǎng)站排名

廣告

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