flutter拓展之路,flutter之旅

flutter如何进行icloud

flutter用一个插件进行icloud。

拓展资料：为何flutter构建的App体积较大？

细心的开发者会发现flutter构建的App体积比native的大一些，是什么原因造成App体积大呢？

其实flutter 在release时App体积和native的大小差不多，而debug时体积通常会大。debug版本体积较大是为了Hot reload和快速编译。如果有flutter开发经验的朋友都体验过，如果您修改一下App的背景颜色，只需save一下就可以立刻看到修改后效果。我称之为“像艺术家一样在创造App”，因此为了实现这些目标，提高开发的效率，debug将占用全部资源。而当我们构建release版时，flutter又会采用AOT策略，提高App运行效率，release版只打包必需的资源，因而体积又会减少。

另外，flutter团队也一直在寻找减小程序大小的方法。

相关问答

Q1: 《知行》技术人的管理之路（三）管理规划

《知行》感悟系列文章历史浏览：

《知行》技术人的管理之路（一）管理的基本框架

《知行》技术人的管理之路（二）角色认知

在互联网行业中当角色转变为管理岗位或者是某个团队的负责人的时候，就不能事事等着上级来安排，要学会自己规划事情。

这在里所说的管理规划就不仅仅是指工作上的规划，而是上升到整个团队；从核心内容来看，管理规划要求管理者回答清楚这样一个问题： “这个团队你打算怎么带？”

怎么回答这个问题呢？我们要根据管理规划四要素以做回答。

本文围绕管理的四要素，以及移动端负责人的身份来进行展开讨论..

团队所谓的“职能”就是回答“团队是干什么的”这个问题。

如果你想回答好这个问题不妨先思考以下下面3个问题

我的回答：

思考的问题回答完了，那么我的团队职能是什么呢？也就是我的团队是干什么的呢？

开发并设计一款高质量的使用在移动端的应用程序，以提高居民的生活的便利，并且可以为公司提供良好的品牌效应。

当所有的团队成员清楚了团队职能才能产生如下的效果：

1.提升团队凝聚力

2.有效激励员工

3.提升员工的主动性

为什么这里说是团队的职能而不是说职责，因为团队的职能包含了两个层次：

职责和使命。职责是团队职能的下限，使命是团队职能的上限。

简单描述就是基本职责解决的是团队的“生存问题”，而使命解决的是“团队实现”问题。类似就像个人的自我价值实现一样，具体就不展开说了。

既然团队职能的2个层次都说明了，那么我们就要做点什么了，那就是为团队设定基本职责，也需要为团队确定使命。

第一步：收集信息

从如下的四个角度梳理收集职能信息

第二步：提炼和升华

第三步：确认和主张

团队的职能的设定和宣贯是一个长期任务，不是一蹴而就的。越早做越好，逐渐的形成潜移默化的概念。

职能的界定明确来团队的价值，那么目标就是回答了“通过什么来体现团队价值”。也就是取得什么成果来体现其价值，以自身为例

本节主要是通过意义、原则、维度、形式、挑战来展开对目标的讨论。

1.目标首先意味着期待

2.目标意味着资源的有效配置

3.目标意味着执行力

4.目标意味着凝聚力

5.目标意味着激励

确定下清晰合理的目标不仅可以“做事”，甚至还可以“带人”，是一举两得的事情。在目标确定之后要想一想，是否和团队成员都同步了目标，以及对这个目标是否有疑惑等等。

目标的设定我们遵守SMART原则即：

1.明确性（Specific）

2.可衡量性(Measurable)

3.可达性(Attainable)

4.相关性(Relevant)

5.时限性(Time-bound)

我们首先看一个没有设定原则的目标：

我们的目标是优化App的体积。

在看一个通过设定原则优化过的目标：

从本周一到下周一，将App的体积大小减少20%。

判断一个目标是否足够清晰，只有当SMART都符合的时候才能说明目标是清晰的，而且设定的目标时尽可能少而细。通过SMART原则检查清单可以检测当前目标是否足够清晰

SMART原则检查清单：

目标维度从3个维度考虑：1.业务目标。 2.团建目标（梯队、规模）。 3.专业目标

简单说书这3个维度，这三个维度简单点说就是业绩产出，团队发展和专业能力。

业绩是要对公司以及上级或者是老板负责的，这个目标是一定要设定的；而团建目标的设定体现了管理规划的完整性，也就是说为什么目标和带人是不可分的；专业目标的设定可以提升团队的专业性，也有利于提高个人的专业能力。

从个人成长角度来说，业务的目标设定到完成的过程中，可以在时间充裕时设定自己的专业目标，通过专业目标的达成最好是能提高业绩的产出；这种不仅提高了个人的能力，还完成了公司的任务。

1.可以量化的指标 KPI

2.不可量化的目标 KRA或OKR

简单的通过KPI常见句式为：到某时间点，什么指标达到什么数字

例：“到九月底，把单机性能从300qps提升到500qps”

KRA或者OKR常见句式为：到某时间点，完成什么工作，该工作实现了哪些功能活达到了那些效果

例：“到12月地，发布BI系统1.0，支持KPI数据统计、全量数据到吃分析功能”

这部分的内容先不展开说了，有必要的时候单独写一篇文章来分析 KPI、KRA、OKR。

作者的总结就是，OKR适用于开放性强、追求创造性的组织；KPI适用于规则成熟、追求执行性的组织。

通常在目标设定遇到困难的时候，可以通过以下四类问题换个角度找到答案。

这类问题往往的情况就是，接到了一个需求任务，给你的第一反应就是这个项目够呛能做完，压力很大，完成的程度也不确定。

面对这类问题和挑战的钥匙叫做“以终为始的出发点”； 通过最终你想要什么来对你的团队进行调配或者是补充资源。

遇见这类性通常都是接到的任务太庞统，太大，比如说今年年底上线一个APP。。主要强调了“我做了什么”，没有交代做完这些工作后“收到了什么效果”

面对这类问题和挑战的钥匙叫做“结果导向的描述”。根据这个任务的需求，来对该任务进行拆分，上线的APP都具有什么功能。比如上限一个APP具有登记开门的功能。

解决办法就是向下传达了，方式有很多，可能就是微信QQ的简单一句话。如果功能业务比较复杂，可以开一个简短的业务分析会。

例如最近的时候做了一个移动端产品的一个业务规划（业务稍微有点复杂），在规划的过程中也确定了当时所能想到的方案和解决办法。方案出来了就是具体的任务落地，将方案转变成实际的工作下发出去。这时候如果不向下传递，那么可能会导致开发者不知道你的需求和业务，开发完的东西不一定满足要求，并且反复修改还会出现抱怨。 借鉴了以往的经验，这次选择了直接和该模块的后台开发负责人进行了过会讨论，在讨论问题和向下传递的过程中，还总结出了一些之前方案中不足的地方，并且愉快的进行了消息同步，效果感觉特别好。

由于公司的战略转变或者是其他的原因，往往大的目标会经常出现改变，而导致了之前我们设立的目标出现了变形，或者是根本不能执行了

面对这类问题和挑战的钥匙叫做 “设定专业目标” 。用专业目标来增强团队的内在定力，而不是被外在的需求将团队作为了救火队员。所谓的那些需求战略的改变往往都是大的战略方向的改变，但是团队内部的核心业务往往也存在于各个项目中。

这一点从自己团队的角度来说，团队内有很长的一段时候都属于那种救火队员，遇到了紧急需求而全力应对，导致看上去没有属于自己的核心业务。这时候需要找到一条出路来做一定的改变。比如重构以往的工程，后台使用微服务的架构，这就属于内在目标；而通过微服务每个团队成员都各负责一个模块，每个人都对自己的模块负责；

对自己来说，设定一个专业目标就是flutter的学习以及产品思维的锻炼，无论工作内容如何改，这两点贯穿到最后，个人的能力都会得到锻炼。

本节主要是从3个团队规划角度分析团队问题，团队建设问题会从后续的章节展开讨论。

刚刚我们说明了团队的目标设定的要点，现在说明的是团建的目标如何设定。团建目标就是团队未来会发展成什么样？

衡量方式如下：

通过上述的3中衡量方式只要盘点清楚现在实际的规模、分工、梯队和未来的规模、分工、梯队，就能把握住未来团建工作的重心了。

从资源视角看待团队，是一个成熟管理者的标志之一。

管理者做人力预算的时候要给出十分充足的理由，为什么需要这些人，为什么会是这么多人，以及依据和估算逻辑是什么。

那么要如何做这个预算呢，首先是自己对业务的理解，以及希望达成的目标角度来看；其次是参照行业资源配比情况，例如产品、设计、开发、测试、运维几个方面。

这个视角的核心含义是，到下一个时间节点，你需要重点培养出哪些人，给他们什么样的平台和空间，以及你有能力提供给他们什么指导和支持，期待他们能够胜任什么职能和角色。

新人的引进我们要了解一个概念“团队消化能力”。就是说团队现在的梯队情况和新人导师的经理问题，一个团队能够良性吸纳的新人是有限的，我们把这个限度称为“团队消化能力”。

怎么估算团队消化能力呢？首先看看团队内谁能带人，分别带几个比较合理。这里的合理就是新人导师既能带人又能兼顾对业务的投入；其次看看团队的新人培养机制是否成熟健全。

带着团队前往目标有那些可选的路径是需要管理者进行筹划的。筹划的工作主要回答了2个问题

第一个问题可以判断出我们达成目标手段是否合理，第二个问题可以判断我们申请的资源是否合理。

综上，我们通过下面的三个方面考虑路径和资源的问题

完成团队的目标需要考虑所带的团队都有那些资源；在这里资源包括时间、信息、权限。时间就是你的目标完成时间，信息就是为了完成这个目标需要自己主动的在公司内外主动收集一些相关的信息，权限就是公司在然你完成这个任务你有多大的权限协调资源等。

站在管理者的视角，需要评估一段时间内的产出效率，而不是追求工作的极致品质了。衡量一项工作“到底需要话5天完成70分，还是花10天做到90分”，这个是管理者的日常工作。通过全局来看，由于时间原因90分不一定有70分好。注意这里优秀的工程师应该放弃一些执念，转换视角，完成工作有很多手段供选择。

对于不同的方案意味着多高的成本，如下的表哥可以帮助新经理扩展思路，看到解决问题手段的多样性，避免思路过于单一。（填写大中小或者打分）

手段-成本盘点表

成熟而职业的技术管理者在倚重技术和迷信技术中间会找到一个平衡，提供一个既能解决问题、成本又合理、兼顾长短期的可行方案，而不是一个只顾眼前的“应急”对策。不是所有的人力短缺都是通过招聘来决绝的，需要综合前面的手段多样性综合来考虑。

我们在评估一个项目的结果的时候，有三个衡量维度是最重要的。

在这3个维度上是有弹性的，可以在一定的范围内灵活把握，这3个维度称为“结果评估三要素”。

在这里值得注意两点

这样我们可以总结出一个原则：对于任何一项工作，评估其结果的关键指标到底是进度、质量还是效果，决定着我们以什么方式投入什么类型的资源，就是说只有我们清楚了最关注的指标，才能让资源的投入得到最大化的发挥。

管理规划从4个方面展开职能、目标、团队、路径。

设定目标的时候，要基于当前的团队的现实情况和可用资源；盘点团队的时候，脱不开目标的设定和路径的选择；探讨路径以及做预算资源的时候，离不开目标和团队。

所以虽然把几个点展开讨论，但是几个要素之间并不独立和割裂的而是以职能为基础，彼此依赖，需要把四个要素统筹来梳理明白，才是一份完整的管理规划。

Q2: React Native Mac版环境配置

Mac环境下RN的安装之路：

前言：之前安装了Flutter环境，准备Flutter之路。。现在又准备安装一下React native环境配置... Mac终端源为~zsh

RN中文网 -- ( )里面看一下Mac的环境安装步骤

一、安装node

然后尝试着运行下 node -v 看看是否安装成功，并没有安装成功。

运行了一下 brew -v 查看了一下版本，是一两个月前的版本号，抱着试试的态度，brew update 升级一下版本号。

现在版本号为

然后再次运行 brew install node, 等待一会安装完毕，没有再报错 Error信息。

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

二、 安装Watchman （ Watchman -- ( )则是由 Facebook 提供的监视文件系统变更的工具。安装此工具可以提高开发时的性能（packager 可以快速捕捉文件的变化从而实现实时刷新）。

(因为笔者是iOS开发，所以Xcode 和 Simulator都已经安装过了)

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

终端运行 rect-natice init MyApp 创建一个项目名为MyApp的项目，这一步第一次运行初始化需要一段时间，稍微等一下, 这里初始化后的目录直接是用户下目录了。我们可以cd到桌面你自己创建的某个目录，然后执行这段 init 命令

这里项目就初始化好了。

然后cd 到你的MyApp目录下，npm run ios（官网教程用yarn替代的 npm命令，我这边安装速度还好，就没有替换）

这里出现了一堆报错信息, 看到有个error是，项目中有Podfile，但是没有运行pod install，这里我们cd 到项目中ios目录下，运行pod install试试。

然后等待pod 安装完毕，这里等会可以直接用xcode启动APP尝试一下。

443 error了若干次、、经过一个多小时蛮长等待......

出现这个界面。下面就通过Xcode MyApp.xcworkspace 点击运行尝试一下

编译过程又几分钟、有种巨型组件项目既视感，千呼万唤始出来！！

然后我们在尝试一下刚刚无法完成的命令启动，cd 到项目目录

react-native run-ios

虽然警告很多、虽然模拟器启动的是iPhone11. 但总归成功启动官方默认项目了

以下就是react native环境安装及官方示例项目启动过程了。下一篇会记录一下，在现有原生项目添加 react native组件。

附:

vs code打开的话, App.js 还是有几个报错。这个目前还不知道原因

百度了一下，看有人说在setting.json 加入这句话 "javascript.validate.enable": false 即可，貌似加入后也不报错了。

Q3: 那么多ui框架怎么选

LayUI

由职业前端倾情打造，面向全层次的前后端开发者，低门槛开箱即用的前端 UI 解决方案，layui是一个采用自身模块规范化编写的前端UI框架，它依照原生HTML/CSS/JS的书写与组织形式，入门简单，使用也非常简单。从核心代码到API的每一处细节都经过精心雕琢，非常适合界面的快速开发。

JEUI

它是一款国产前端UI框架，遵循原生HTML/CSS/JS的书写与组织形式，国内很多程序员javascript不熟, 大大影响了开发速度. 因此JEUI不需要开发人员去关心javascript怎么写, 只要写标准html就可以了，门槛极低，拿来即用。其外在极简，却又不失饱满的内在，体积轻盈，组件丰盈，从核心代码到API的每一处细节都经过精心雕琢，非常适合界面的快速开发。

JEUI基于jQuery的UI框架，包括表单、布局、表格等等常用UI控件，使用JEUI可以快速轻松地创建风格统一的界面效果。

浏览器兼容非常牛皮，能兼容IE8以上的浏览器。

DWZ

DWZ富客户端框架(jQuery RIA framework), 是中国人自己开发的基于jQuery实现的Ajax RIA开源框架. 设计目标是简单实用,快速开发,降低ajax开发成本。

DWZ 支持用 html 扩展的方式来代替 javascript 代码, 基本可以保证程序员不董 javascript, 也能使用各种页面组件和 ajax 技术. 如果有特定需求也可以扩展 DWZ 做定制化开化.

MDUI

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

19 种主色、16 种强调色、1 种夜间主题，只需添加一个 CSS 类即可切换。CSS 仅 26.7KB，JavaScript 仅 14KB，加载更迅速。移动优先，从小屏逐步扩展到大屏，最终实现所有屏幕适配。不依赖任何第三方库，节约网络流量，使加载更迅速，提高用户体验。使用 CSS3 来做动画交互，平滑、高效，让 Web 应用的动画更流畅。提供自定义打包功能，按需打包需要的主题和组件，使文件体积骤然减小。MDUI 包含了 20 余个组件，且每个组件都可以适应不同主题。

只需懂一点 HTML、CSS、JS 的基础知识，就能使用 MDUI。

ElementUI

element ui框架的按钮组件，这款由饿了么前端开源的UI框架，一经面世，就收获大量程序员的芳心，在github 上更是高达29.8k的star早已说明一切，用于开发PC端的页面还是绰绰有余的，如果说你是用vue开发者，却没用过element UI，那你肯定不是合格的vue开发者。

WeUI

jQuery WeUI 是专为微信公众账号开发而设计的一个简洁而强大的UI库，包含全部WeUI官方的CSS组件，并且额外提供了大量的拓展组件，丰富的组件库可以极大减少前端开发时间。

jQuery WeUI 的最大特点是它只提供UI组件，并不会对项目所使用的框架和其他库有任何的限制，几乎可以在任何环境下使用。无论你的项目是基于jQuery，还是 React, Angular, Vue， 你都会发现 jQuery WeUI 能非常方便的和他们结合使用。既是你的项目是一个有很悠久历史的老项目，也几乎可以做到拿来即用。

Flutter

Flutter是谷歌的移动UI框架，可以快速在iOS和Android上构建高质量的原生用户界面，前端对于 Flutter 的热忱度之高一度让人有点惊讶，事实上在 Flutter 社区内见到的客户端开发者远多于前端开发，不过前端对于跨端解决方案确实有着天然的渴求。

Flutter可以与现有的代码一起工作。在全世界，Flutter正在被越来越多的开发者和组织使用，并且Flutter是完全免费、开源的。

iView ui

iViewui一套基于 Vue.js 的高质量 UI 组件库，搭配使用 iView UI 组件库形成的一套后台集成解决方案，由 TalkingData 前端可视化团队部分成员开发维护。iView Admin 遵守 iView 设计和开发约定，风格统一。

Mint UI

Mint UI 包含丰富的 CSS 和 JS 组件，能够满足日常的移动端开发需要。通过它，可以快速构建出风格统一的页面，提升开发效率。

真正意义上的按需加载组件。可以只加载声明过的组件及其样式文件，无需再纠结文件体积过大。

考虑到移动端的性能门槛，Mint UI 采用 CSS3 处理各种动效，避免浏览器进行不必要的重绘和重排，从而使用户获得流畅顺滑的体验。

依托 Vue.js 高效的组件化方案，Mint UI 做到了轻量化。即使全部引入，压缩后的文件体积也仅有 ~30kb (JS + CSS) gzip。

YDUI Touch

YDUI Touch 专为移动端打造，在技术实现、交互设计上兼容主流移动设备，保证代码轻、性能高。

使用 Flex 技术，灵活自如地对齐、收缩、扩展元素，轻松搞定移动页面布局。

实现强大的屏幕适配布局，等比例适配所有屏幕。什么？用得不开心？轻松切换 px。

自定义Javascript组件、Less文件、Less变量，定制一份属于自己的YDUI。

SUI Mobile

SUI Mobile 是一套基于 Framework7 开发的UI库。它非常轻量、精美，只需要引入我们的CDN文件就可以使用，并且能兼容到 iOS 6.0+ 和 Android 4.0+，非常适合开发跨平台Web App。轻量的UI库

SUI Mobile 非常轻量，核心库压缩Gzip后的JS、CSS网络传输体积总共只有52K，却提供了20+个常用的组件。

Amaze ~ 妹子 UI

中国首个开源 HTML5 跨屏前端框架

Amaze UI 以移动优先（Mobile first）为理念，从小屏逐步扩展到大屏，最终实现所有屏幕适配，适应移动互联潮流。

Amaze UI 含近 20 个 CSS 组件、20 余 JS 组件，更有多个包含不同主题的 Web 组件，可快速构建界面出色、体验优秀的跨屏页面，大幅提升开发效率。

相比国外框架，Amaze UI 关注中文排版，根据用户代理调整字体，实现更好的中文排版效果；兼顾国内主流浏览器及 App 内置浏览器兼容支持。

Amaze UI 面向 HTML5 开发，使用 CSS3 来做动画交互，平滑、高效，更适合移动设备，让 Web 应用更快速载入。

cube-ui

质量可靠：由滴滴内部组件库精简提炼而来，历经考验，并且每个组件都有充分单元测试，为后续集成提供保障。

体验极致：以迅速响应、动画流畅、接近原生为目标，在交互体验方面追求极致。

标准规范：遵循统一的设计交互标准，高度还原设计效果；接口标准化，统一规范使用方式，开发更加简单高效。

扩展性强：支持按需引入和后编译，轻量灵活；扩展性强，可以方便地基于现有组件实现二次开发。

Q4: Flutter 上字体的另类玩法：FontFeature

在以前的 《Flutter 上默认的文本和字体知识点》 和 《带你深入理解 Flutter 中的字体“冷”知识》 中，已经介绍了很多 Flutter 上关于字体有趣的知识点，而本篇讲继续介绍 Flutter 上关于 Text 的一个属性： FontFeature ， 事实上相较于 Flutter ，本篇内容可能和前端或者设计关系更密切 。

什么是 FontFeature ？ 简单来说就是影响字体形状的一个属性 ，在前端的对应领域里应该是 font-feature-settings ，它有别于 FontFamily ，是用于指定字体内字的形状的一个参数。

我们知道 Flutter 默认在 Android 上使用的是 Roboto 字体，而在 iOS 上使用的是 SF 字体，但是其实 Roboto 字体也是分很多类型的，比如你去查阅手机的 system/fonts 目录，就会发现很多带有 Roboto 字样的字体库存在。

所以 Roboto 之类的字体库是一个很大的字体集，不同的 font-weight 其实对应着不同的 ttf ，例如默认情况下的 Roboto 是不支持 font-weight 为 600 的配置 ：

所以如下图所示，如果我们设置了 w400 - w700 的 weight ，可以很明显看到中间的 500 和 600 其实是一样的粗细，所以在 设置 weight 或者设计 UI 时，就需要考虑不同平台上的 weight 是否支持想要的效果 。

回归到 FontFeature 上，那 Roboto 自己默认支持多少种 features 呢？ 答案是 26 种，它们的编码如下所示，运行后效果也如下图所示，从日常使用上看，这 26 种 Feature 基本满足开发的大部分需求。

而 iOS 上的 SF pro 默认支持 39 种 Features ， 它们的编码如下所示，运行后效果也如下图所示，可以看到 SF pro 支持的 Features 更多。

所以可以看到，并不是所有字体支持的 Features 都是一样的，比如 iOS 上支持 sups 上标显示和 subs 下标显示，但是 Android 上的 Roboto 并不支持，甚至很多第三方字体其实并不支持 Features 。

有趣的是，在 Flutter Web 有一个渲染文本时会变模糊的问题 #58159 ，这个问题目前官方还没有修复，但是你可以通过给 Text 设置任意 FontFeatures 来解决这个问题。

最后，如果对 FontFeature 还感兴趣的朋友，可以通过一下资料深入了解，如果你还有什么关于字体上的问题，欢迎留言讨论。

基于网友的问题再补充一下拓展知识，毕竟这方面内容也不多 。

事实上在 dart 里就可以看到对应 FontWeight 约定俗称用的是字体集里的什么字体：

所以如果对于默认字体有疑问，可以在你的手机字体找找是否有对应的字体， 比如虽然我们说 roboto 没有 600 ，但是如果是 roboto mono 字体集是有 600 的 fontweight ，甚至还有 600 斜体： 。

另外注意这是 Flutter 而不是原生，具体实现调用是在 Engine 的 paragraph_skia.cc 和 paragraph_builder_skia.cc 下对应的 setFontFamilies 相关逻辑，当然默认字体库指定在 typography.dart 下就看到，例如 'Roboto' 、 '.SF UI Display' 、 '.SF UI Text' 、 '.AppleSystemUIFont' 、 'Segoe UI' ：

另外如果你在 Mac 的 Web 上使用 Flutter Web，可以看到指定的是 .AppleSystemUIFont ，而对于 .AppleSystemUIFont 它其实不算是一种字体，而是苹果上字体的一种集合别称：

[图片上传失败...(image-40f5ce-1648368234737)]

还有，如果你去看 Flutter 默认自带的 cupertino/context_menu_action.dart ，就可以看到一个有趣的情况：

当然，前面我们说了那么多，主要是针对英文的情况下，而在中文下还是有差异的 ，之前的文章也介绍过：

例如，在苹果上的简体中文其实会是 PingFang SC 字体，对应还有 PingFang TC 和 PingFang HK 的繁体集，而关于这个问题在 Flutter 上之前还出现过比较有意思的 bug ：

当然后续的 #16709 修复了这个问题 ，而在以前的文章我也讲过，当时我遇到了 “Flutter 在 iOS 系统上，系统语言是韩文时，在和中文一起出现会导致字体显示异常" 的问题 ：

解决方法也很简单，就是给 fontFamilyFallback 配置上 ["PingFang SC" , "Heiti SC"] 就可以了，这是因为韩文在苹果手机上使用的应该是 Apple SD Gothic Neo 这样的超集字体库，【广】这个字符在这个字体集上是不存在的，所以就变成了中文的【广】；

所以可以看到，字体相关是一个平时很少会深入接触的东西，但是一旦涉及多语言和绘制，就很容易碰到问题的领域 。

Q5: Flutter_图片分辨率适配及批量拓展使用

flutter开发中，图片的引用是必不可少的，所以为了提高效率和精准度，我们需要对不同分辨率的手机使用相对应的切图图片，本章介绍如何进行 图片分辨率适配 和 图片批量拓展处理 。

flutter中会首先根据系统的devicePixelRatio（每一个逻辑像素包含多少个原始像素，可以通过MediaQueryData.devicePixelRatio来得到）来找对应倍数的文件夹下的图片，如果没有对应倍数，找最接近的。

所以在flutter项目中，我们需要构建对应的倍数像素文件夹

之后再pubspec.yaml中，配置assets文件后就可以使用了（如使用"assets/images/jay.png"，会自动适配该像素下最接近的jay图片）。

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

目前还不能处理gif、webp等格式的图片，而且如果和上边介绍的不同像素比适配方案一起使用的话，由于进行了精准定位，所以指定图片后就不能进行像素适配，这是目前还存在的较大问题，所以目前两者方案只能暂时取一使用。