13518219792
flutter运行之后报了这个错，不能够运行。
成都创新互联客户idc服务中心，提供服务器托管、成都服务器、成都主机托管、成都双线服务器等业务的一站式服务。通过各地的服务中心，我们向成都用户提供优质廉价的产品以及开放、透明、稳定、高性价比的服务，资深网络工程师在机房提供7*24小时标准级技术保障。
在结果上面会提示appt2等错误，其实错误的原因是Androidx支持有问题。
官方解决办法： （合理打开）
app/build.gradle 下面
在gradle.properties下添加：
重新清理运行，ok。
最近项目中要集成flutter来进行混编，但是在集成后，突然遇到一个很神奇的问题，在debug模式下，用数据线连接真机打包可以打开flutter页面，但是一旦拔掉数据线，再打开flutter页面就不行了，开始以为是因为flutterSDK的原因，但是一查资料才发现，原来是因为debug模式下flutter实现了热重载，默认的编译方式是JIV,但是iOS14+之后的系统限制了JIV这种编译方式，所以连接Xcode重新run一个release包就可以了，因为flutter在release模式下的编译方式是AOT，iOS14+的系统是支持这种编译方式的，具体解决方案如下图
再运行就可以了。
当然还有另外一种解决方案，就是修改flutter的编译配置，强制设为release
Flutter是谷歌公司推出的跨终端的开发框架，支持Android、iOS和WEB终端。1.0版在2018年12月5日发布，目前的最新版本是1.5，它采用的开发语言是Dart，Dart也是谷歌开发的计算机编程语言，语法类似C，是编译型语言：
hello world例子，打印字符串“Hello World!”：
1、没有桥接层
React Native、Weex等技术都是跨终端的框架，然而性能跟原生App存在很大差距。这是由于它们的工作原理决定的：
React Native、Weex等技术多了一个桥接层，所以界面渲染会慢一些，由于UI渲染非常频繁，想要不卡顿，基本上比较难，性能和用户体验跟原生代码有差距。而这恰恰是Flutter的优势所在：
Dart可以被编译成不同平台的本地代码，让Flutter不通过桥接层直接跟平台通信，自然性能会快一些。
2、编译执行
JavaScript是解释执行的，Dart是编译执行的，性能谁好一目了然。
3、Flutter Engine虚拟机
Flutter是依靠Flutter Engine虚拟机在iOS和Android上运行的，Flutter Engine使用C/C++编写，开发人员通过Flutter框架直接和API在内部进行交互，所以具有输入低延迟和UI渲染高帧速率的特点。除了这特点之外，Flutter还提供了自己的小部件，Flutter小部件是使用从React获取灵感的现代框架构建的。 中心思想是您使用小部件构建UI。
窗口小部件根据其当前配置和状态描述了它们的视图。 当窗口小部件的状态发生更改时，窗口小部件会重建其描述，框架将根据前面的描述进行区分，以确定底层呈现树从一个状态转换到下一个状态所需的最小更改。可以直接在OS平台提供的画布上进行描绘，也就是一些核心类库直接放到虚拟机里面，调用起来更快。
从它的系统结构可以看出，类似安卓的ART(Android Run Time)虚拟机，同样采用AOT(Ahead of TIme)技术，会在APP安装时就编译成机器语言，不再解释执行，从而优化了APP运行的性能。
4、自带渲染引擎
Flutter使用谷歌自己的Skia渲染引擎，而Android系统自带Skia引擎，iOS平台上Flutter也会把Skia引擎打包到APP中，从而实现了高效渲染。而React Native通过桥接层访问原生UI，操作频繁就容易出性能问题。
综合所述，Flutter 是性能最接近原生代码 的一种开发框架，未来也会是构建谷歌Fuchsia应用的主要方式，前途不可限量，唯一的问题就是需要学习一门新的语言：Dart，而有Java或者C#语言基础的程序员会比较容易学习。
凉是不会凉的，毕竟安卓系统的市场占有率还是很大的。别说鸿蒙，一个新系统要发展成熟并形成良性的生态圈还是需要相当的时间的，没那么简单。5G是网络制式，和终端硬件有关，和app又没多大关系。只不过近几年移动端原生开发，不论安卓还是iOS确实需求量小了，工作不好找。外面企业的招聘要求也更高，新手根本没什么竞争力，外面三五年工作经验的大把。建议你可以学一下微信小程序，近年来比较火，市场占有率也比较大。另外，google推出的移动端新兴的开发技术flutter也可以学一下，这东西将来的发展还真没准。Android原生开发技术，java那一套也是需要掌握的，对你有好处。
Flutter支持稳定的桌面设备开发已经一段时间了，不得不说，Flutter多平台支持的特性真的很香。我本人并没有任何桌面开发的经验，但仍然使用Flutter开发出了一个桌面版小程序，功能很简单，就是对输入的json做格式化处理和转模型。
话不多说，先来看看实际效果。 项目源码地址
开发环境如下：
Flutter : 2.8.1
Dart : 2.15.1
IDE : VSCode
JSON作为我们日常开发工作中经常要打交道的一种数据格式，它共有6种数据类型： null , num , string , object , array , bool 。我们势必对它又爱又恨。爱他因为他作为数据处理的一种格式确实非常方便简洁。但是在我们做Flutter开发中，又需要接触到json解析时，就会感觉非常棘手，因为flutter没有反射，导致json转模型这块需要手写那繁杂的映射关系。就像下面这样子。
数据量少还能接受，一旦量大，那么光手写这个解析方法都能让你怀疑人生。更何况手写还有出错的可能。好在官方有个工具**json_serializable**可以自动生成这块转换代码，也解决了flutter界json转模型的空缺。当然，业界也有专门解析json的网站，可以自动生成dart代码，使用者在生成后复制进项目中即可，也是非常方便的。
本项目以json解析为切入点，和大家一起来看下flutter是如何开发桌面应用的。
要让我们的flutter项目支持桌面设备。我们首先需要修改下flutter的设置。如下，让我们的项目支持 windows 和 macos 系统。
接下来使用 flutter create 命令创建我们的模版工程。
创建完项目后，我们就可以 run 起来了。
先来看下整体界面，界面四块，分别为功能模块、文件选择模块、输入模块、输出模块。
我们在新建一个桌面应用时，默认的模版又一个Appbar，此时应用可以用鼠标拖拽移动，放大缩小，还可以缩到很小。但是，我们一旦去掉这个导航栏，那么窗口就不能用鼠标拖动了，并且我们往往不希望用户将我们的窗口缩放的很小，这会导致页面异常，一些重要信息都展示不全。因此这里需要借助第三方组件 bitsdojo_window 。通过 bitsdojo_window ，我们可以实现窗口的定制化，拖动，最小尺寸，最大尺寸，窗口边框，窗口顶部放大、缩小、关闭的按钮等。
通过 InkWell 组件，可以捕捉到手势、鼠标、触控笔的移动和停留位置
这个功能是鼠标移动后的UI交互界面。要在窗口上显示一个提示框，可以使用 Overlay 。需要注意的是，由于在 Overlay 上的 text 的根结点不是 Material 风格的组件，因此会出现黄色的下划线。因此一定要用 Material 包一下 text 。并且你必须给创建的 OverlayEntry 一个位置，否则它将全屏显示。
读取说表拖拽的文件一开始想尝试使用 InkWell 组件，但是这个组件无法识别拖拽中的鼠标，并且也无法从中拿到文件信息。因此放弃。后来从文章《Flutter-2天写个桌面端APP》中发现一个可读取拖拽文件的组件 desktop_drop ，能满足要求。
使用开源组件 file_picker ，选完图片后的操作和拖拽选择图片后的操作一致。
Textfield 如果要显示富文本，那么需要自定义 TextEditingController 。并重写 buildTextSpan 方法。
在做导出功能时遇到下列报错，保存提示为没有权限访问对应目录下的文件。
通过Apple的开发文档找到有关权限问题的说明。其中有个授权私钥的key为 com.apple.security.files.downloads.read-write ，表示 对用户的下载文件夹的读/写访问权限 。那么，使用Xcode打开Flutter项目中的mac应用，修改工程目录下的 DebugProfile.entitlements 文件，向 entitlements 文件中添加 com.apple.security.files.downloads.read-write ，并将值设置为YES，保存后重启Flutter项目。发现已经可以向下载目录中读写文件了。
当然，这是正常操作。还有个骚操作就是关闭系统的沙盒机制。将 entitlements 文件的 App Sandbox 设置为NO。这样我们就可以访问任意路径了。当然关闭应用的沙盒也就相当于关闭了应用的防护机制，因此这个选项慎用。
原文地址：
在讨论Harmony OS是否真的让谷歌慌了之前，我们先来对比一下两个操作系统，从架构出发对比一下两个操作系统的设计理念和目标是否是一样的。
HarmonyOS整体遵从分层设计，从下向上依次为：内核层、系统服务层、框架层和应用层。系统功能按照“系统 子系统 功能/模块”逐级展开，在多设备部署场景下，支持根据实际需求裁剪某些非必要的子系统或功能/模块。HarmonyOS技术架构如下所示。
系统服务层是HarmonyOS的核心能力集合，通过框架层对应用程序提供服务。该层包含以下几个部分：
根据不同设备形态的部署环境，基础软件服务子系统集、增强软件服务子系统集、硬件服务子系统集内部可以按子系统粒度裁剪，每个子系统内部又可以按功能粒度裁剪。
框架层为HarmonyOS应用开发提供了Java/C/C++/JS等多语言的用户程序框架和Ability框架，两种UI框架（包括适用于Java语言的Java UI框架、适用于JS语言的JS UI框架），以及各种软硬件服务对外开放的多语言框架API。根据系统的组件化裁剪程度，HarmonyOS设备支持的API也会有所不同。
应用层包括系统应用和第三方非系统应用。HarmonyOS的应用由一个或多个FA（Feature Ability）或PA（Particle Ability）组成。其中，FA有UI界面，提供与用户交互的能力；而PA无UI界面，提供后台运行任务的能力以及统一的数据访问抽象。FA在进行用户交互时所需的后台数据访问也需要由对应的PA提供支撑。基于FA/PA开发的应用，能够实现特定的业务功能，支持跨设备调度与分发，为用户提供一致、高效的应用体验。
Fuchsia OS整体也采用分层架构设计，也被分为了4个不同层次。
对于不太了解内核作用的同学简而言之，Zircon之于Fuchsia，恰如Linux之余于Android。Linux内核驱动了多个操作系统，很多操作系统构建在它之上，比如 Ubuntu、Android、Manjaro、ArchLinux、Debian、Red Hat、SUSE 甚至 Chrome OS ，所以我们也可以大胆预测，如果未来Fuchsia OS 发展良好， Zircon 内核也被证明好用，那么很有可能有更多的操作系统采用这一新内核。
系统服务层（Garnet）
也是直接构建在 Zircon 上的一层名叫 Garnet。 Garnet 包含各种操作系统所需的各种底层功能，包括硬件的驱动程序（网络，图形等）和软件安装。这一层最激动人心的事情是 Escher（图形渲染器），Amber（Fuchsia 更新程序）和Xi Core，它是Xi文本和代码编辑器的底层引擎（今年早些时候已经发布了）。
模块管理层（Peridot）
Peridot 是接下来的这一层，主要处理Fuchsia的模块化应用程序设计， Peridot的另外两个主要组件直接用于模块。 Ledger 可以跨设备保存您在应用/模块中的位置，并同步到您的Google帐户。Maxwell 是一个更复杂的主题，需要更多进一步地深入研究，但是 Maxwell 极有可能是让 Fuchsia 充分施展魔力的点睛之笔，可以提前透露的是，Maxwell 的厉害之处包括 Kronk，也是大家熟知的 Google Assistant。
应用层（Topaz）
Topaz，是这个 Layer Cake 蛋糕的顶层，也是对开发者和用户直接影响最大的一层。Topaz 提供 Flutter 支持，而有了Flutter 的支持，各种华丽的应用程序，可以帮助充实地提供日常使用的功能齐全的应用程序。比如，现在最令人印象深刻的当然是 Armadillo UI，它是 Fuchsia 的主要用户界面和主屏幕。
可以做一个类比，Topaz 这一层在 Android 中可以找到一个对照，这将是你的必备应用程序，如联系人，音乐，文件管理器和文本编辑器 Xi（Topaz中的可视前端连接到Garnet的后端）。即使没有你需要的东西，你也可以简单方便地安装。
Harmony OS 与 Fuchsia OS的主要相同点：
Harmony OS 与 Fuchsia OS的主要不同点：
个人认为Harmony OS成功的可能性更大。虽然从生态上来说，谷歌可以利用Android建立的生态伙伴优势推广Fuchsia OS，但也恰恰是Android完善的生态会给Fuchsia OS的推广造成最大障碍。
相反Harmony OS从架构上更符合物联网时代的需求，然后华为作为主导者具备强大的硬件制造能力，Harmony OS在华为很多手机上已经推送，国内很多公司的冰箱、空调等也都在采用华为鸿蒙系统。这些都有利于Harmony OS系统的产业化发展。
当然，从全球大环境来说，Harmony OS可以在国内做成功，但是要想在国际上推广难度是非常大的。美国的 科技 霸权，导致计算机诞生以来底层技术很少在美国之外的公司诞生并发扬光大。Lua、Ruby等编程语言，Intellij IDEA等算是为数不多的例子。
