flutter如何進(jìn)行icloud

flutter用一個插件進(jìn)行icloud。

太和ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為成都創(chuàng)新互聯(lián)公司的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18980820575（備注：SSL證書合作）期待與您的合作！

拓展資料：為何flutter構(gòu)建的App體積較大？

細(xì)心的開發(fā)者會發(fā)現(xiàn)flutter構(gòu)建的App體積比native的大一些，是什么原因造成App體積大呢？

其實flutter 在release時App體積和native的大小差不多，而debug時體積通常會大。debug版本體積較大是為了Hot reload和快速編譯。如果有flutter開發(fā)經(jīng)驗的朋友都體驗過，如果您修改一下App的背景顏色，只需save一下就可以立刻看到修改后效果。我稱之為“像藝術(shù)家一樣在創(chuàng)造App”，因此為了實現(xiàn)這些目標(biāo)，提高開發(fā)的效率，debug將占用全部資源。而當(dāng)我們構(gòu)建release版時，flutter又會采用AOT策略，提高App運(yùn)行效率，release版只打包必需的資源，因而體積又會減少。

另外，flutter團(tuán)隊也一直在尋找減小程序大小的方法。

《知行》技術(shù)人的管理之路（三）管理規(guī)劃

《知行》感悟系列文章歷史瀏覽：

《知行》技術(shù)人的管理之路（一）管理的基本框架

《知行》技術(shù)人的管理之路（二）角色認(rèn)知

在互聯(lián)網(wǎng)行業(yè)中當(dāng)角色轉(zhuǎn)變?yōu)楣芾韻徫换蛘呤悄硞€團(tuán)隊的負(fù)責(zé)人的時候，就不能事事等著上級來安排，要學(xué)會自己規(guī)劃事情。

這在里所說的管理規(guī)劃就不僅僅是指工作上的規(guī)劃，而是上升到整個團(tuán)隊；從核心內(nèi)容來看，管理規(guī)劃要求管理者回答清楚這樣一個問題： “這個團(tuán)隊你打算怎么帶？”

怎么回答這個問題呢？我們要根據(jù)管理規(guī)劃四要素以做回答。

本文圍繞管理的四要素，以及移動端負(fù)責(zé)人的身份來進(jìn)行展開討論..

團(tuán)隊所謂的“職能”就是回答“團(tuán)隊是干什么的”這個問題。

如果你想回答好這個問題不妨先思考以下下面3個問題

我的回答：

思考的問題回答完了，那么我的團(tuán)隊職能是什么呢？也就是我的團(tuán)隊是干什么的呢？

開發(fā)并設(shè)計一款高質(zhì)量的使用在移動端的應(yīng)用程序，以提高居民的生活的便利，并且可以為公司提供良好的品牌效應(yīng)。

當(dāng)所有的團(tuán)隊成員清楚了團(tuán)隊職能才能產(chǎn)生如下的效果：

1.提升團(tuán)隊凝聚力

2.有效激勵員工

3.提升員工的主動性

為什么這里說是團(tuán)隊的職能而不是說職責(zé)，因為團(tuán)隊的職能包含了兩個層次：

職責(zé)和使命。職責(zé)是團(tuán)隊職能的下限，使命是團(tuán)隊職能的上限。

簡單描述就是基本職責(zé)解決的是團(tuán)隊的“生存問題”，而使命解決的是“團(tuán)隊實現(xiàn)”問題。類似就像個人的自我價值實現(xiàn)一樣，具體就不展開說了。

既然團(tuán)隊職能的2個層次都說明了，那么我們就要做點(diǎn)什么了，那就是為團(tuán)隊設(shè)定基本職責(zé)，也需要為團(tuán)隊確定使命。

第一步：收集信息

從如下的四個角度梳理收集職能信息

第二步：提煉和升華

第三步：確認(rèn)和主張

團(tuán)隊的職能的設(shè)定和宣貫是一個長期任務(wù)，不是一蹴而就的。越早做越好，逐漸的形成潛移默化的概念。

職能的界定明確來團(tuán)隊的價值，那么目標(biāo)就是回答了“通過什么來體現(xiàn)團(tuán)隊價值”。也就是取得什么成果來體現(xiàn)其價值，以自身為例

本節(jié)主要是通過意義、原則、維度、形式、挑戰(zhàn)來展開對目標(biāo)的討論。

1.目標(biāo)首先意味著期待

2.目標(biāo)意味著資源的有效配置

3.目標(biāo)意味著執(zhí)行力

4.目標(biāo)意味著凝聚力

5.目標(biāo)意味著激勵

確定下清晰合理的目標(biāo)不僅可以“做事”，甚至還可以“帶人”，是一舉兩得的事情。在目標(biāo)確定之后要想一想，是否和團(tuán)隊成員都同步了目標(biāo)，以及對這個目標(biāo)是否有疑惑等等。

目標(biāo)的設(shè)定我們遵守SMART原則即：

1.明確性（Specific）

2.可衡量性(Measurable)

3.可達(dá)性(Attainable)

4.相關(guān)性(Relevant)

5.時限性(Time-bound)

我們首先看一個沒有設(shè)定原則的目標(biāo)：

我們的目標(biāo)是優(yōu)化App的體積。

在看一個通過設(shè)定原則優(yōu)化過的目標(biāo)：

從本周一到下周一，將App的體積大小減少20%。

判斷一個目標(biāo)是否足夠清晰，只有當(dāng)SMART都符合的時候才能說明目標(biāo)是清晰的，而且設(shè)定的目標(biāo)時盡可能少而細(xì)。通過SMART原則檢查清單可以檢測當(dāng)前目標(biāo)是否足夠清晰

SMART原則檢查清單：

目標(biāo)維度從3個維度考慮：1.業(yè)務(wù)目標(biāo)。 2.團(tuán)建目標(biāo)（梯隊、規(guī)模）。 3.專業(yè)目標(biāo)

簡單說書這3個維度，這三個維度簡單點(diǎn)說就是業(yè)績產(chǎn)出，團(tuán)隊發(fā)展和專業(yè)能力。

業(yè)績是要對公司以及上級或者是老板負(fù)責(zé)的，這個目標(biāo)是一定要設(shè)定的；而團(tuán)建目標(biāo)的設(shè)定體現(xiàn)了管理規(guī)劃的完整性，也就是說為什么目標(biāo)和帶人是不可分的；專業(yè)目標(biāo)的設(shè)定可以提升團(tuán)隊的專業(yè)性，也有利于提高個人的專業(yè)能力。

從個人成長角度來說，業(yè)務(wù)的目標(biāo)設(shè)定到完成的過程中，可以在時間充裕時設(shè)定自己的專業(yè)目標(biāo)，通過專業(yè)目標(biāo)的達(dá)成最好是能提高業(yè)績的產(chǎn)出；這種不僅提高了個人的能力，還完成了公司的任務(wù)。

1.可以量化的指標(biāo) KPI

2.不可量化的目標(biāo) KRA或OKR

簡單的通過KPI常見句式為：到某時間點(diǎn)，什么指標(biāo)達(dá)到什么數(shù)字

例：“到九月底，把單機(jī)性能從300qps提升到500qps”

KRA或者OKR常見句式為：到某時間點(diǎn)，完成什么工作，該工作實現(xiàn)了哪些功能活達(dá)到了那些效果

例：“到12月地，發(fā)布BI系統(tǒng)1.0，支持KPI數(shù)據(jù)統(tǒng)計、全量數(shù)據(jù)到吃分析功能”

這部分的內(nèi)容先不展開說了，有必要的時候單獨(dú)寫一篇文章來分析 KPI、KRA、OKR。

作者的總結(jié)就是，OKR適用于開放性強(qiáng)、追求創(chuàng)造性的組織；KPI適用于規(guī)則成熟、追求執(zhí)行性的組織。

通常在目標(biāo)設(shè)定遇到困難的時候，可以通過以下四類問題換個角度找到答案。

這類問題往往的情況就是，接到了一個需求任務(wù)，給你的第一反應(yīng)就是這個項目夠嗆能做完，壓力很大，完成的程度也不確定。

面對這類問題和挑戰(zhàn)的鑰匙叫做“以終為始的出發(fā)點(diǎn)”； 通過最終你想要什么來對你的團(tuán)隊進(jìn)行調(diào)配或者是補(bǔ)充資源。

遇見這類性通常都是接到的任務(wù)太龐統(tǒng)，太大，比如說今年年底上線一個APP。。主要強(qiáng)調(diào)了“我做了什么”，沒有交代做完這些工作后“收到了什么效果”

面對這類問題和挑戰(zhàn)的鑰匙叫做“結(jié)果導(dǎo)向的描述”。根據(jù)這個任務(wù)的需求，來對該任務(wù)進(jìn)行拆分，上線的APP都具有什么功能。比如上限一個APP具有登記開門的功能。

解決辦法就是向下傳達(dá)了，方式有很多，可能就是微信QQ的簡單一句話。如果功能業(yè)務(wù)比較復(fù)雜，可以開一個簡短的業(yè)務(wù)分析會。

例如最近的時候做了一個移動端產(chǎn)品的一個業(yè)務(wù)規(guī)劃（業(yè)務(wù)稍微有點(diǎn)復(fù)雜），在規(guī)劃的過程中也確定了當(dāng)時所能想到的方案和解決辦法。方案出來了就是具體的任務(wù)落地，將方案轉(zhuǎn)變成實際的工作下發(fā)出去。這時候如果不向下傳遞，那么可能會導(dǎo)致開發(fā)者不知道你的需求和業(yè)務(wù)，開發(fā)完的東西不一定滿足要求，并且反復(fù)修改還會出現(xiàn)抱怨。 借鑒了以往的經(jīng)驗，這次選擇了直接和該模塊的后臺開發(fā)負(fù)責(zé)人進(jìn)行了過會討論，在討論問題和向下傳遞的過程中，還總結(jié)出了一些之前方案中不足的地方，并且愉快的進(jìn)行了消息同步，效果感覺特別好。

由于公司的戰(zhàn)略轉(zhuǎn)變或者是其他的原因，往往大的目標(biāo)會經(jīng)常出現(xiàn)改變，而導(dǎo)致了之前我們設(shè)立的目標(biāo)出現(xiàn)了變形，或者是根本不能執(zhí)行了

面對這類問題和挑戰(zhàn)的鑰匙叫做 “設(shè)定專業(yè)目標(biāo)” 。用專業(yè)目標(biāo)來增強(qiáng)團(tuán)隊的內(nèi)在定力，而不是被外在的需求將團(tuán)隊作為了救火隊員。所謂的那些需求戰(zhàn)略的改變往往都是大的戰(zhàn)略方向的改變，但是團(tuán)隊內(nèi)部的核心業(yè)務(wù)往往也存在于各個項目中。

這一點(diǎn)從自己團(tuán)隊的角度來說，團(tuán)隊內(nèi)有很長的一段時候都屬于那種救火隊員，遇到了緊急需求而全力應(yīng)對，導(dǎo)致看上去沒有屬于自己的核心業(yè)務(wù)。這時候需要找到一條出路來做一定的改變。比如重構(gòu)以往的工程，后臺使用微服務(wù)的架構(gòu)，這就屬于內(nèi)在目標(biāo)；而通過微服務(wù)每個團(tuán)隊成員都各負(fù)責(zé)一個模塊，每個人都對自己的模塊負(fù)責(zé)；

對自己來說，設(shè)定一個專業(yè)目標(biāo)就是flutter的學(xué)習(xí)以及產(chǎn)品思維的鍛煉，無論工作內(nèi)容如何改，這兩點(diǎn)貫穿到最后，個人的能力都會得到鍛煉。

本節(jié)主要是從3個團(tuán)隊規(guī)劃角度分析團(tuán)隊問題，團(tuán)隊建設(shè)問題會從后續(xù)的章節(jié)展開討論。

剛剛我們說明了團(tuán)隊的目標(biāo)設(shè)定的要點(diǎn)，現(xiàn)在說明的是團(tuán)建的目標(biāo)如何設(shè)定。團(tuán)建目標(biāo)就是團(tuán)隊未來會發(fā)展成什么樣？

衡量方式如下：

通過上述的3中衡量方式只要盤點(diǎn)清楚現(xiàn)在實際的規(guī)模、分工、梯隊和未來的規(guī)模、分工、梯隊，就能把握住未來團(tuán)建工作的重心了。

從資源視角看待團(tuán)隊，是一個成熟管理者的標(biāo)志之一。

管理者做人力預(yù)算的時候要給出十分充足的理由，為什么需要這些人，為什么會是這么多人，以及依據(jù)和估算邏輯是什么。

那么要如何做這個預(yù)算呢，首先是自己對業(yè)務(wù)的理解，以及希望達(dá)成的目標(biāo)角度來看；其次是參照行業(yè)資源配比情況，例如產(chǎn)品、設(shè)計、開發(fā)、測試、運(yùn)維幾個方面。

這個視角的核心含義是，到下一個時間節(jié)點(diǎn)，你需要重點(diǎn)培養(yǎng)出哪些人，給他們什么樣的平臺和空間，以及你有能力提供給他們什么指導(dǎo)和支持，期待他們能夠勝任什么職能和角色。

新人的引進(jìn)我們要了解一個概念“團(tuán)隊消化能力”。就是說團(tuán)隊現(xiàn)在的梯隊情況和新人導(dǎo)師的經(jīng)理問題，一個團(tuán)隊能夠良性吸納的新人是有限的，我們把這個限度稱為“團(tuán)隊消化能力”。

怎么估算團(tuán)隊消化能力呢？首先看看團(tuán)隊內(nèi)誰能帶人，分別帶幾個比較合理。這里的合理就是新人導(dǎo)師既能帶人又能兼顧對業(yè)務(wù)的投入；其次看看團(tuán)隊的新人培養(yǎng)機(jī)制是否成熟健全。

帶著團(tuán)隊前往目標(biāo)有那些可選的路徑是需要管理者進(jìn)行籌劃的。籌劃的工作主要回答了2個問題

第一個問題可以判斷出我們達(dá)成目標(biāo)手段是否合理，第二個問題可以判斷我們申請的資源是否合理。

綜上，我們通過下面的三個方面考慮路徑和資源的問題

完成團(tuán)隊的目標(biāo)需要考慮所帶的團(tuán)隊都有那些資源；在這里資源包括時間、信息、權(quán)限。時間就是你的目標(biāo)完成時間，信息就是為了完成這個目標(biāo)需要自己主動的在公司內(nèi)外主動收集一些相關(guān)的信息，權(quán)限就是公司在然你完成這個任務(wù)你有多大的權(quán)限協(xié)調(diào)資源等。

站在管理者的視角，需要評估一段時間內(nèi)的產(chǎn)出效率，而不是追求工作的極致品質(zhì)了。衡量一項工作“到底需要話5天完成70分，還是花10天做到90分”，這個是管理者的日常工作。通過全局來看，由于時間原因90分不一定有70分好。注意這里優(yōu)秀的工程師應(yīng)該放棄一些執(zhí)念，轉(zhuǎn)換視角，完成工作有很多手段供選擇。

對于不同的方案意味著多高的成本，如下的表哥可以幫助新經(jīng)理擴(kuò)展思路，看到解決問題手段的多樣性，避免思路過于單一。（填寫大中小或者打分）

手段-成本盤點(diǎn)表

成熟而職業(yè)的技術(shù)管理者在倚重技術(shù)和迷信技術(shù)中間會找到一個平衡，提供一個既能解決問題、成本又合理、兼顧長短期的可行方案，而不是一個只顧眼前的“應(yīng)急”對策。不是所有的人力短缺都是通過招聘來決絕的，需要綜合前面的手段多樣性綜合來考慮。

我們在評估一個項目的結(jié)果的時候，有三個衡量維度是最重要的。

在這3個維度上是有彈性的，可以在一定的范圍內(nèi)靈活把握，這3個維度稱為“結(jié)果評估三要素”。

在這里值得注意兩點(diǎn)

這樣我們可以總結(jié)出一個原則：對于任何一項工作，評估其結(jié)果的關(guān)鍵指標(biāo)到底是進(jìn)度、質(zhì)量還是效果，決定著我們以什么方式投入什么類型的資源，就是說只有我們清楚了最關(guān)注的指標(biāo)，才能讓資源的投入得到最大化的發(fā)揮。

管理規(guī)劃從4個方面展開職能、目標(biāo)、團(tuán)隊、路徑。

設(shè)定目標(biāo)的時候，要基于當(dāng)前的團(tuán)隊的現(xiàn)實情況和可用資源；盤點(diǎn)團(tuán)隊的時候，脫不開目標(biāo)的設(shè)定和路徑的選擇；探討路徑以及做預(yù)算資源的時候，離不開目標(biāo)和團(tuán)隊。

所以雖然把幾個點(diǎn)展開討論，但是幾個要素之間并不獨(dú)立和割裂的而是以職能為基礎(chǔ)，彼此依賴，需要把四個要素統(tǒng)籌來梳理明白，才是一份完整的管理規(guī)劃。

React Native Mac版環(huán)境配置

Mac環(huán)境下RN的安裝之路：

前言：之前安裝了Flutter環(huán)境，準(zhǔn)備Flutter之路。。現(xiàn)在又準(zhǔn)備安裝一下React native環(huán)境配置... Mac終端源為~zsh

RN中文網(wǎng) -- ( )里面看一下Mac的環(huán)境安裝步驟

一、安裝node

然后嘗試著運(yùn)行下 node -v 看看是否安裝成功，并沒有安裝成功。

運(yùn)行了一下 brew -v 查看了一下版本，是一兩個月前的版本號，抱著試試的態(tài)度，brew update 升級一下版本號。

現(xiàn)在版本號為

然后再次運(yùn)行 brew install node, 等待一會安裝完畢，沒有再報錯 Error信息。

node -v 查看一下node的版本信息

二、 安裝Watchman （ Watchman -- ( )則是由 Facebook 提供的監(jiān)視文件系統(tǒng)變更的工具。安裝此工具可以提高開發(fā)時的性能（packager 可以快速捕捉文件的變化從而實現(xiàn)實時刷新）。

(因為筆者是iOS開發(fā)，所以Xcode 和 Simulator都已經(jīng)安裝過了)

三、安裝React Native的命令行工具（react-native-cli）

終端運(yùn)行 rect-natice init MyApp 創(chuàng)建一個項目名為MyApp的項目，這一步第一次運(yùn)行初始化需要一段時間，稍微等一下, 這里初始化后的目錄直接是用戶下目錄了。我們可以cd到桌面你自己創(chuàng)建的某個目錄，然后執(zhí)行這段 init 命令

這里項目就初始化好了。

然后cd 到你的MyApp目錄下，npm run ios（官網(wǎng)教程用yarn替代的 npm命令，我這邊安裝速度還好，就沒有替換）

這里出現(xiàn)了一堆報錯信息, 看到有個error是，項目中有Podfile，但是沒有運(yùn)行pod install，這里我們cd 到項目中ios目錄下，運(yùn)行pod install試試。

然后等待pod 安裝完畢，這里等會可以直接用xcode啟動APP嘗試一下。

443 error了若干次、、經(jīng)過一個多小時蠻長等待......

出現(xiàn)這個界面。下面就通過Xcode MyApp.xcworkspace 點(diǎn)擊運(yùn)行嘗試一下

編譯過程又幾分鐘、有種巨型組件項目既視感，千呼萬喚始出來！！

然后我們在嘗試一下剛剛無法完成的命令啟動，cd 到項目目錄

react-native run-ios

雖然警告很多、雖然模擬器啟動的是iPhone11. 但總歸成功啟動官方默認(rèn)項目了

以下就是react native環(huán)境安裝及官方示例項目啟動過程了。下一篇會記錄一下，在現(xiàn)有原生項目添加 react native組件。

附:

vs code打開的話, App.js 還是有幾個報錯。這個目前還不知道原因

百度了一下，看有人說在setting.json 加入這句話 "javascript.validate.enable": false 即可，貌似加入后也不報錯了。

那么多ui框架怎么選

LayUI

由職業(yè)前端傾情打造，面向全層次的前后端開發(fā)者，低門檻開箱即用的前端 UI 解決方案，layui是一個采用自身模塊規(guī)范化編寫的前端UI框架，它依照原生HTML/CSS/JS的書寫與組織形式，入門簡單，使用也非常簡單。從核心代碼到API的每一處細(xì)節(jié)都經(jīng)過精心雕琢，非常適合界面的快速開發(fā)。

JEUI

它是一款國產(chǎn)前端UI框架，遵循原生HTML/CSS/JS的書寫與組織形式，國內(nèi)很多程序員javascript不熟, 大大影響了開發(fā)速度. 因此JEUI不需要開發(fā)人員去關(guān)心javascript怎么寫, 只要寫標(biāo)準(zhǔn)html就可以了，門檻極低，拿來即用。其外在極簡，卻又不失飽滿的內(nèi)在，體積輕盈，組件豐盈，從核心代碼到API的每一處細(xì)節(jié)都經(jīng)過精心雕琢，非常適合界面的快速開發(fā)。

JEUI基于jQuery的UI框架，包括表單、布局、表格等等常用UI控件，使用JEUI可以快速輕松地創(chuàng)建風(fēng)格統(tǒng)一的界面效果。

瀏覽器兼容非常牛皮，能兼容IE8以上的瀏覽器。

DWZ

DWZ富客戶端框架(jQuery RIA framework), 是中國人自己開發(fā)的基于jQuery實現(xiàn)的Ajax RIA開源框架. 設(shè)計目標(biāo)是簡單實用,快速開發(fā),降低ajax開發(fā)成本。

DWZ 支持用 html 擴(kuò)展的方式來代替 javascript 代碼, 基本可以保證程序員不董 javascript, 也能使用各種頁面組件和 ajax 技術(shù). 如果有特定需求也可以擴(kuò)展 DWZ 做定制化開化.

MDUI

MDUI 是一個基于 Material Design 的前端框架。

19 種主色、16 種強(qiáng)調(diào)色、1 種夜間主題，只需添加一個 CSS 類即可切換。CSS 僅 26.7KB，JavaScript 僅 14KB，加載更迅速。移動優(yōu)先，從小屏逐步擴(kuò)展到大屏，最終實現(xiàn)所有屏幕適配。不依賴任何第三方庫，節(jié)約網(wǎng)絡(luò)流量，使加載更迅速，提高用戶體驗。使用 CSS3 來做動畫交互，平滑、高效，讓 Web 應(yīng)用的動畫更流暢。提供自定義打包功能，按需打包需要的主題和組件，使文件體積驟然減小。MDUI 包含了 20 余個組件，且每個組件都可以適應(yīng)不同主題。

只需懂一點(diǎn) HTML、CSS、JS 的基礎(chǔ)知識，就能使用 MDUI。

ElementUI

element ui框架的按鈕組件，這款由餓了么前端開源的UI框架，一經(jīng)面世，就收獲大量程序員的芳心，在github 上更是高達(dá)29.8k的star早已說明一切，用于開發(fā)PC端的頁面還是綽綽有余的，如果說你是用vue開發(fā)者，卻沒用過element UI，那你肯定不是合格的vue開發(fā)者。

WeUI

jQuery WeUI 是專為微信公眾賬號開發(fā)而設(shè)計的一個簡潔而強(qiáng)大的UI庫，包含全部WeUI官方的CSS組件，并且額外提供了大量的拓展組件，豐富的組件庫可以極大減少前端開發(fā)時間。

jQuery WeUI 的最大特點(diǎn)是它只提供UI組件，并不會對項目所使用的框架和其他庫有任何的限制，幾乎可以在任何環(huán)境下使用。無論你的項目是基于jQuery，還是 React, Angular, Vue， 你都會發(fā)現(xiàn) jQuery WeUI 能非常方便的和他們結(jié)合使用。既是你的項目是一個有很悠久歷史的老項目，也幾乎可以做到拿來即用。

Flutter

Flutter是谷歌的移動UI框架，可以快速在iOS和Android上構(gòu)建高質(zhì)量的原生用戶界面，前端對于 Flutter 的熱忱度之高一度讓人有點(diǎn)驚訝，事實上在 Flutter 社區(qū)內(nèi)見到的客戶端開發(fā)者遠(yuǎn)多于前端開發(fā)，不過前端對于跨端解決方案確實有著天然的渴求。

Flutter可以與現(xiàn)有的代碼一起工作。在全世界，F(xiàn)lutter正在被越來越多的開發(fā)者和組織使用，并且Flutter是完全免費(fèi)、開源的。

iView ui

iViewui一套基于 Vue.js 的高質(zhì)量 UI 組件庫，搭配使用 iView UI 組件庫形成的一套后臺集成解決方案，由 TalkingData 前端可視化團(tuán)隊部分成員開發(fā)維護(hù)。iView Admin 遵守 iView 設(shè)計和開發(fā)約定，風(fēng)格統(tǒng)一。

Mint UI

Mint UI 包含豐富的 CSS 和 JS 組件，能夠滿足日常的移動端開發(fā)需要。通過它，可以快速構(gòu)建出風(fēng)格統(tǒng)一的頁面，提升開發(fā)效率。

真正意義上的按需加載組件。可以只加載聲明過的組件及其樣式文件，無需再糾結(jié)文件體積過大。

考慮到移動端的性能門檻，Mint UI 采用 CSS3 處理各種動效，避免瀏覽器進(jìn)行不必要的重繪和重排，從而使用戶獲得流暢順滑的體驗。

依托 Vue.js 高效的組件化方案，Mint UI 做到了輕量化。即使全部引入，壓縮后的文件體積也僅有 ~30kb (JS + CSS) gzip。

YDUI Touch

YDUI Touch 專為移動端打造，在技術(shù)實現(xiàn)、交互設(shè)計上兼容主流移動設(shè)備，保證代碼輕、性能高。

使用 Flex 技術(shù)，靈活自如地對齊、收縮、擴(kuò)展元素，輕松搞定移動頁面布局。

實現(xiàn)強(qiáng)大的屏幕適配布局，等比例適配所有屏幕。什么？用得不開心？輕松切換 px。

自定義Javascript組件、Less文件、Less變量，定制一份屬于自己的YDUI。

SUI Mobile

SUI Mobile 是一套基于 Framework7 開發(fā)的UI庫。它非常輕量、精美，只需要引入我們的CDN文件就可以使用，并且能兼容到 iOS 6.0+ 和 Android 4.0+，非常適合開發(fā)跨平臺Web App。輕量的UI庫

SUI Mobile 非常輕量，核心庫壓縮Gzip后的JS、CSS網(wǎng)絡(luò)傳輸體積總共只有52K，卻提供了20+個常用的組件。

Amaze ~ 妹子 UI

中國首個開源 HTML5 跨屏前端框架

Amaze UI 以移動優(yōu)先（Mobile first）為理念，從小屏逐步擴(kuò)展到大屏，最終實現(xiàn)所有屏幕適配，適應(yīng)移動互聯(lián)潮流。

Amaze UI 含近 20 個 CSS 組件、20 余 JS 組件，更有多個包含不同主題的 Web 組件，可快速構(gòu)建界面出色、體驗優(yōu)秀的跨屏頁面，大幅提升開發(fā)效率。

相比國外框架，Amaze UI 關(guān)注中文排版，根據(jù)用戶代理調(diào)整字體，實現(xiàn)更好的中文排版效果；兼顧國內(nèi)主流瀏覽器及 App 內(nèi)置瀏覽器兼容支持。

Amaze UI 面向 HTML5 開發(fā)，使用 CSS3 來做動畫交互，平滑、高效，更適合移動設(shè)備，讓 Web 應(yīng)用更快速載入。

cube-ui

質(zhì)量可靠：由滴滴內(nèi)部組件庫精簡提煉而來，歷經(jīng)考驗，并且每個組件都有充分單元測試，為后續(xù)集成提供保障。

體驗極致：以迅速響應(yīng)、動畫流暢、接近原生為目標(biāo)，在交互體驗方面追求極致。

標(biāo)準(zhǔn)規(guī)范：遵循統(tǒng)一的設(shè)計交互標(biāo)準(zhǔn)，高度還原設(shè)計效果；接口標(biāo)準(zhǔn)化，統(tǒng)一規(guī)范使用方式，開發(fā)更加簡單高效。

擴(kuò)展性強(qiáng)：支持按需引入和后編譯，輕量靈活；擴(kuò)展性強(qiáng)，可以方便地基于現(xiàn)有組件實現(xiàn)二次開發(fā)。

Flutter 上字體的另類玩法：FontFeature

在以前的 《Flutter 上默認(rèn)的文本和字體知識點(diǎn)》 和 《帶你深入理解 Flutter 中的字體“冷”知識》 中，已經(jīng)介紹了很多 Flutter 上關(guān)于字體有趣的知識點(diǎn)，而本篇講繼續(xù)介紹 Flutter 上關(guān)于 Text 的一個屬性： FontFeature ， 事實上相較于 Flutter ，本篇內(nèi)容可能和前端或者設(shè)計關(guān)系更密切 。

什么是 FontFeature ？ 簡單來說就是影響字體形狀的一個屬性 ，在前端的對應(yīng)領(lǐng)域里應(yīng)該是 font-feature-settings ，它有別于 FontFamily ，是用于指定字體內(nèi)字的形狀的一個參數(shù)。

我們知道 Flutter 默認(rèn)在 Android 上使用的是 Roboto 字體，而在 iOS 上使用的是 SF 字體，但是其實 Roboto 字體也是分很多類型的，比如你去查閱手機(jī)的 system/fonts 目錄，就會發(fā)現(xiàn)很多帶有 Roboto 字樣的字體庫存在。

所以 Roboto 之類的字體庫是一個很大的字體集，不同的 font-weight 其實對應(yīng)著不同的 ttf ，例如默認(rèn)情況下的 Roboto 是不支持 font-weight 為 600 的配置 ：

所以如下圖所示，如果我們設(shè)置了 w400 - w700 的 weight ，可以很明顯看到中間的 500 和 600 其實是一樣的粗細(xì)，所以在 設(shè)置 weight 或者設(shè)計 UI 時，就需要考慮不同平臺上的 weight 是否支持想要的效果 。

回歸到 FontFeature 上，那 Roboto 自己默認(rèn)支持多少種 features 呢？ 答案是 26 種，它們的編碼如下所示，運(yùn)行后效果也如下圖所示，從日常使用上看，這 26 種 Feature 基本滿足開發(fā)的大部分需求。

而 iOS 上的 SF pro 默認(rèn)支持 39 種 Features ， 它們的編碼如下所示，運(yùn)行后效果也如下圖所示，可以看到 SF pro 支持的 Features 更多。

所以可以看到，并不是所有字體支持的 Features 都是一樣的，比如 iOS 上支持 sups 上標(biāo)顯示和 subs 下標(biāo)顯示，但是 Android 上的 Roboto 并不支持，甚至很多第三方字體其實并不支持 Features 。

有趣的是，在 Flutter Web 有一個渲染文本時會變模糊的問題 #58159 ，這個問題目前官方還沒有修復(fù)，但是你可以通過給 Text 設(shè)置任意 FontFeatures 來解決這個問題。

最后，如果對 FontFeature 還感興趣的朋友，可以通過一下資料深入了解，如果你還有什么關(guān)于字體上的問題，歡迎留言討論。

基于網(wǎng)友的問題再補(bǔ)充一下拓展知識，畢竟這方面內(nèi)容也不多 。

事實上在 dart 里就可以看到對應(yīng) FontWeight 約定俗稱用的是字體集里的什么字體：

所以如果對于默認(rèn)字體有疑問，可以在你的手機(jī)字體找找是否有對應(yīng)的字體， 比如雖然我們說 roboto 沒有 600 ，但是如果是 roboto mono 字體集是有 600 的 fontweight ，甚至還有 600 斜體： 。

另外注意這是 Flutter 而不是原生，具體實現(xiàn)調(diào)用是在 Engine 的 paragraph_skia.cc 和 paragraph_builder_skia.cc 下對應(yīng)的 setFontFamilies 相關(guān)邏輯，當(dāng)然默認(rèn)字體庫指定在 typography.dart 下就看到，例如 'Roboto' 、 '.SF UI Display' 、 '.SF UI Text' 、 '.AppleSystemUIFont' 、 'Segoe UI' ：

另外如果你在 Mac 的 Web 上使用 Flutter Web，可以看到指定的是 .AppleSystemUIFont ，而對于 .AppleSystemUIFont 它其實不算是一種字體，而是蘋果上字體的一種集合別稱：

[圖片上傳失敗...(image-40f5ce-1648368234737)]

還有，如果你去看 Flutter 默認(rèn)自帶的 cupertino/context_menu_action.dart ，就可以看到一個有趣的情況：

當(dāng)然，前面我們說了那么多，主要是針對英文的情況下，而在中文下還是有差異的 ，之前的文章也介紹過：

例如，在蘋果上的簡體中文其實會是 PingFang SC 字體，對應(yīng)還有 PingFang TC 和 PingFang HK 的繁體集，而關(guān)于這個問題在 Flutter 上之前還出現(xiàn)過比較有意思的 bug ：

當(dāng)然后續(xù)的 #16709 修復(fù)了這個問題 ，而在以前的文章我也講過，當(dāng)時我遇到了 “Flutter 在 iOS 系統(tǒng)上，系統(tǒng)語言是韓文時，在和中文一起出現(xiàn)會導(dǎo)致字體顯示異常" 的問題 ：

解決方法也很簡單，就是給 fontFamilyFallback 配置上 ["PingFang SC" , "Heiti SC"] 就可以了，這是因為韓文在蘋果手機(jī)上使用的應(yīng)該是 Apple SD Gothic Neo 這樣的超集字體庫，【廣】這個字符在這個字體集上是不存在的，所以就變成了中文的【廣】；

所以可以看到，字體相關(guān)是一個平時很少會深入接觸的東西，但是一旦涉及多語言和繪制，就很容易碰到問題的領(lǐng)域 。

Flutter_圖片分辨率適配及批量拓展使用

flutter開發(fā)中，圖片的引用是必不可少的，所以為了提高效率和精準(zhǔn)度，我們需要對不同分辨率的手機(jī)使用相對應(yīng)的切圖圖片，本章介紹如何進(jìn)行 圖片分辨率適配 和 圖片批量拓展處理 。

flutter中會首先根據(jù)系統(tǒng)的devicePixelRatio（每一個邏輯像素包含多少個原始像素，可以通過MediaQueryData.devicePixelRatio來得到）來找對應(yīng)倍數(shù)的文件夾下的圖片，如果沒有對應(yīng)倍數(shù)，找最接近的。

所以在flutter項目中，我們需要構(gòu)建對應(yīng)的倍數(shù)像素文件夾

之后再pubspec.yaml中，配置assets文件后就可以使用了（如使用"assets/images/jay.png"，會自動適配該像素下最接近的jay圖片）。

使用flutter-img-sync插件批量化處理，具體操作如下

目前還不能處理gif、webp等格式的圖片，而且如果和上邊介紹的不同像素比適配方案一起使用的話，由于進(jìn)行了精準(zhǔn)定位，所以指定圖片后就不能進(jìn)行像素適配，這是目前還存在的較大問題，所以目前兩者方案只能暫時取一使用。

分享標(biāo)題：flutter拓展之路,flutter之旅
網(wǎng)站鏈接：http://chinadenli.net/article30/dsdsdso.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供全網(wǎng)營銷推廣、移動網(wǎng)站建設(shè)、云服務(wù)器、品牌網(wǎng)站建設(shè)、電子商務(wù)、標(biāo)簽優(yōu)化

廣告

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