点选下方的终端产品市场部，左上角优先选择“标为隆哥蒙”
每星期早9点半，控制技术该文按时送去
“自学”，
Bokaro：https://www.lizenghai.com/archives/20880.html
序言
Flutter合作开发概要与其它的混和合作开发的对照
为何要采用Flutter?虚拟化控制技术概要Hybrid控制技术概要QT概要Flutter概要为何要采用Flutter?
Flutter有什么竞争优势？**它能协助你：**1、提升合作开发工作效率2、同这份标识符合作开发iOS和Android
3、用更少的标识符做更多的事4、随心所欲插值
5、在插件代码时更动标识符并再次读取（透过热空载）6、复原崩盘并竭尽全力从应用程序暂停的地方性展开增容
7、建立耐用，度订制的使用者新体验9、受惠于采用Flutter架构提供更多的多样的Material Design和Cupertino（iOS艺术风格）的widget
10、同时实现订制、耐用、国际品牌驱动力的结构设计，而倍受原生植物命令行的管制虚拟化控制技术概要
特别针对原生植物合作开发遭遇难题，现代人始终都在不懈努力找寻好的软件系统，而如今，早已有许多虚拟化架构(特别注意，两本书中所称的“虚拟化”若无特定表明，即专指Android和iOS两个平台)，根据其原理，主要分为三类：1、H5+原生植物（Cordova、Ionic、微信小程序）
2、JavaScript合作开发+原生植物渲染 （React Native、Weex、快应用领域）
3、自绘UI+原生植物(QT for mobile、Flutter)
4、在接下来的章节中我们逐个来看看这三类架构的原理及优缺点。Hybrid控制技术概要
H5+原生植物混和合作开发这类架构主要原理就是将APP的一部分需要动态变动的内容透过H5来同时实现，透过原生植物的网页读取命令行WebView (Android)或WKWebView（ios）来读取（以后若无特定表明，我们用WebView来统一指代android和ios中的网页读取控件）。这样一来，H5部分是能随时改变而不用发版，动态化需求能满足；同时，由于h5标识符只需要一次合作开发，就能同时在Android和iOS两个平台运行，这也能减小合作开发成本，也就是说，h5部分功能越多，开发成本就越小。我们称这种h5+原生植物的合作开发模式为混和合作开发 ，采用混和模式合作开发的APP我们称之为混和应用领域或Hybrid APP ，如果一个应用领域的大多数功能都是H5同时实现的话，我们称其为Web APP 。目前混和合作开发架构的典型代表有：Cordova、Ionic 和微信小程序，值得一提的是微信小程序目前是在webview中渲染的，并非原生植物渲染，但将来有可能会采用原生植物渲染。混和合作开发控制技术点如之前所述，原生植物合作开发可以访问平台所有功能，而混和合作开发中，h5标识符是运行在WebView中，而WebView实质上就是一个浏览器内核，其JavaScript依然运行在一个权限受限的沙箱中，所以对于大多数系统能力都没有访问权限，如无法访问文件系统、不能采用蓝牙等。所以，对于H5不能同时实现的功能，都需要原生植物去做。而混和架构一般都会在原生植物标识符中预先同时实现一些访问系统能力的API， 然后暴露给WebView以供JavaScript调用，这样一来，WebView就成为了JavaScript与原生植物API之间通信的桥梁，主要负责JavaScript与原生植物之间传递调用消息，而消息的传递必须遵守一个标准的协议，它规定了消息的格式与含义，我们把依赖于WebView的用于在JavaScript与原生植物之间通信并同时实现了某种消息传输协议的工具称之为WebView JavaScript Bridge, 简称 JsBridge，它也是混和合作开发架构的核心。React Native上文早已提到React Native 是React 在原生植物移动应用领域平台的衍生产物，那两者主要的区别是甚么呢？其实，主要的区别在于虚拟DOM映射的对象是甚么？React中虚拟DOM最终会映射为浏览器DOM树，而RN中虚拟DOM会透过JavaScript Core 映射为原生植物命令行树。JavaScript Core 是一个JavaScript解释器，它在React Native中主要有两个作用：为JavaScript提供更多运行环境。是JavaScript与原生植物应用领域之间通信的桥梁，作用和JsBridge一样，事实上，在iOS中，许多JsBridge的同时实现都是基于JavaScript Core 。而RN中将虚拟DOM映射为原生植物命令行的过程中分两步：1、布局消息传递；将虚拟DOM布局信息传递给原生植物；
2、原生植物根据布局信息透过对应的原生植物命令行渲染命令行树；至此，React Native 便同时实现了虚拟化。相对于混和应用领域，由于React Native是原生植物命令行渲染，所以性能会比混和应用领域中H5好许多，同时React Native是Web合作开发控制技术栈，也只需维护这份标识符，同样是虚拟化架构。WeexWeex是阿里巴巴于2016年发布的虚拟化移动端合作开发架构，思想及原理和React Native类似，最大的不同是语法层面，Weex支持Vue语法和Rax语法，Rax 的 DSL 语法是基于 React JSX 语法而创造。与 React 不同，在 Rax 中 JSX 是必选的，它不支持透过其它方式建立组件，所以自学 JSX 是采用 Rax 的必要基础。而React Native只支持JSX语法。快应用领域快应用领域是华为、小米、OPPO、魅族等国内9大主流手机厂商共同制定的轻量级应用领域标准，目标直指微信小程序。它也是采用JavaScript语言合作开发，原生植物命令行渲染，与React Native和Weex相比主要有两点不同：快应用领域自身不支持Vue或React语法，其采用原生植物JavaScript合作开发，其合作开发架构和微信小程序很像，值得一提的是小程序目前早已能采用Vue语法合作开发（mpvue），从原理上来讲，Vue的语法也能移植到快应用领域上。React Native和Weex的渲染/排版引擎是集成到架构中的，每一个APP都需要打包这份，安装包体积较大；而快应用领域渲染/排版引擎是集成到ROM中的，应用领域中无需打包，安装包体积小，正因如此，快应用领域才能在保证性能的同时做到快速分发。总结JavaScript合作开发+原生植物渲染的方式主要优点如下：采用Web合作开发控制技术栈，社区庞大、上手快、合作开发成本相对较低。
原生植物渲染，性能相比H5提升许多。
动态化较好，支持热更新。不足：渲染时需要JavaScript和原生植物之间通信，在有些场景如拖动可能会因为通信频繁导致卡顿。JavaScript为脚本语言，执行时需要JIT，执行工作效率和AOT标识符仍有差距。
由于渲染依赖原生植物命令行，不同平台的命令行需要单独维护，并且当系统更新时，社区命令行可能会滞后；除此之外，其命令行系统也会受到原生植物UI系统管制，例如，在Android中，手势冲突消歧规则是固定的，这在采用不同人写的命令行嵌套时，手势冲突难题将会变得非常棘手。QT Moblie与Flutter在本篇中，我们看看最后一种虚拟化控制技术：自绘UI+原生植物。这种控制技术的思路是，透过在不同平台同时实现一个统一接口的渲染引擎来绘制UI，而不依赖系统原生植物命令行，所以能做到不同平台UI的一致性。特别注意，自绘引擎解决的是UI的虚拟化难题，如果涉及其它系统能力调用，依然要涉及原生植物合作开发。这种平台控制技术的优点如下：性能高；由于自绘引擎是直接调用系统API来绘制UI，所以性能和原生植物命令行接近。灵活、组件库易维护、UI外观保真度和一致性高；由于UI渲染不依赖原生植物命令行，也就不需要根据不同平台的命令行单独维护一套组件库，所以标识符容易维护。由于组件库是同一套标识符、同一个渲染引擎，所以在不同平台，组件显示外观能做到高保真和高一致性；另外，由于不依赖原生植物命令行，也就不会受原生植物布局系统的管制，这样布局系统会非常灵活。不足：动态性不足；为了保证UI绘制性能，自绘UI系统一般都会采用AOT模式编译其发布包，所以应用领域发布后，不能像Hybrid和RN那些采用JavaScript（JIT）作为合作开发语言的架构那样动态下发标识符。
也许你早已猜到Flutter就属于这一类虚拟化控制技术，没错，Flutter正是同时实现一套自绘引擎，并拥有一套自己的UI布局系统。不过，自绘制引擎的思路并不是甚么新概念，Flutter并不是第一个尝试这么做的，在它之前有一个典型的代表，即大名鼎鼎的QT。QT概要
Qt是一个1991年由Qt Company合作开发的虚拟化C++图形使用者界面插件合作开发架构。2008年，Qt Company科技被诺基亚公司收购，Qt也因此成为诺基亚旗下的编程语言工具。2012年，Qt被Digia收购。2014年4月，虚拟化集成合作开发环境Qt Creator 3.1.0正式发布，同时实现了对于iOS的完全支持，新增WinRT、Beautifier等插件，废弃了无Python接口的GDB增容支持，集成了基于Clang的C/C++标识符模块，并对Android支持做出了调整，至此同时实现了全面支持iOS、Android、WP，它提供更多给插件合作开发者构建图形使用者界面所需的所有功能。但是，QT虽然在PC端获得了巨大成功，备受社区追捧，然而其在移动端却表现不佳，在近几年，虽然偶尔能听到QT的声音，但始终很弱，无论QT本身控制技术如何、结构设计思想如何，但事实上终究是败了，究其原因，笔者认为主要有四：第一：QT移动合作开发社区太小，自学资料不足，生态不好。第二：官方推广不利，支持不够。第三：移动端发力较晚，市场已被其它动态化架构占领（Hybrid和RN)。第四：在移动合作开发中，C++合作开发和Web合作开发栈相比有着先天的劣势，直接结果就是QT合作开发工作效率太低。基于此四点，尽管QT是移动端合作开发虚拟化自绘引擎的先驱，但却成为了烈士。Flutter概要
“千呼万唤始出来”，铺垫这么久，现在终于等到两本书的主角出场了！Flutter是Google发布的一个用于建立虚拟化、高性能移动应用领域的架构。Flutter和QT mobile一样，都没有采用原生植物命令行，相反都同时实现了一个自绘引擎，采用自身的布局、绘制系统。那么，我们会担心，QT mobile面对的难题Flutter是否也一样，Flutter会不会步入QT mobile后尘，成为另一个烈士？要回到这个难题，我们先来看看Flutter诞生过程：2017 年 Google I/O 大会上，Google 首次推出了一款新的用于建立虚拟化、高性能的移动应用领域架构——Flutter。2018年2月，Flutter发布了第一个Beta版本，同年五月， 在2018年Google I/O 大会上，Flutter 更新到了 beta 3 版本。2018年6月，Flutter发布了首个预览版本，这意味着 Flutter 进入了正式版（1.0）发布前的最后阶段。观其发展，在2018年5月份，Flutter 进入了 GitHub stars 排行榜前 100 名，已有 27k star。而今天(2018年8月16日)，早已有35K的Star。经历了短短一年多的时间，Flutter 生态系统得以快速增长，由此可见，Flutter在合作开发者中受到了热烈的欢迎，其未来发展值得期待！现在，我们来和QT mobile做一个对照:Flutter的热空载可协助合作开发者快速地展开测试、构建UI、添加功能并更快地复原错误。在iOS和Android模拟器或真机上能同时实现毫秒级热空载，并且不会丢失状态。这真的很棒，相信我，如果你是一名原生植物合作开发者，新体验了Flutter合作开发流后，很可能就不想再次回去做原生植物了，毕竟很少有人不吐槽原生植物合作开发的编译速度。参考链接：
https://flutterchina.club/technical-overviewhttps://book.flutterchina.club阅读更多
2019最新Vue合作开发指南，值得收藏！
相信自己，没有做不到的，只有想不到的在这里获得的不仅仅是控制技术！
喜欢就给个“在看”
