最近在做的一个项目，项目的前期采用Weex开发。但是随着交互复杂度的增加，Weex一处开发多处多处运行的特征并没有很好的体现，相反很多时候我们还是需要做IOS和Android的适配。如今火热的Flutter相比Weex和Rn来说，给出了更好的跨平台解决方案。所以我们设计了一套基于Weex实现，底层跑在Flutter Engine上的框架。
创新互联专注于吉首企业网站建设,成都响应式网站建设公司,商城网站制作。吉首网站建设公司,为吉首等地区提供建站服务。全流程按需开发网站，专业设计，全程项目跟踪，创新互联专业和态度为您提供的服务
底层的Runtime采用isolate engine,框架业务逻辑，Dom的解析逻辑和Render逻辑都跑在这里。
渲染引擎采用Flutter的Skia，彻底剥离了Android和IOS的差异性.
将Weex VirsualDom的解析都替换成Flutter Widget.
设计基于Weex2Dart的Brider,使JS和Dart可以相互调用
weex-demo的性能展示
release环境下采用AOT模式，性能会有质的飞跃。
Android-Release版本只有10m大小
相比Weex和Rn具有更好的性能，同时具有更好的跨平台性
相比Flutter，具有动态部署的能力（Flutter Release采用AoT模式并没有动态部署的能力，即使Debug版本也只是开发环境下才有动态化能力并没有可以实施项目的能力）
只需要会Weex开发或则Rn开发就可以，不需要额外学习Dart，已有的Weex项目可以无缝切换。
问题描述：
在Flutter开发的过程中，当我们获取到新的数据或者数据发生变化，需要去执行setState进行页面刷新的时候，经常会出现不必要的子节点Widget也进行了build，但实际上我们是不想让它再次build，出现这些问题的典型情况是在使用FutureBuilder的时候，例如：
在上面这个示例中，如果再次调用Build方法，则会触发httpCall()的方法。
那么怎样才能避免不必要的部件构建呢？
分析：
在Flutter中，Build方法的设计方式是pure/without side effects，书面意思是无副作用的/纯粹的，简单点理解我们可以将其含义看作不会对外部的方法或者变量产生影响的。这是因为许多外部因素能够触发新的小部件的构建，例如这些情况：
但是，这也意味着Build方法可以不去触发httpCall()的方法或者不修改任何状态。
解决
回归问题，当前我们面临的问题是Build方法造成了副作用，也就是造成了无关的Build调用麻烦。
所以，只要我们使Build方法保持纯粹/无副作用，这样就算多少次调用它，也不会对其他Widget的Build方法产生影响。
在上面的示例中，我们将Widget转换为StatefulWidget，然后提取httpCall()到initState中，这样问题就解决了
另外，还可以使一个Widget能够在不强迫其子部件也构建的情况下进行重新构建。
在Widget的实例保持不变时;Flutter会有意识的不去重建子部件。这意味着我们可以缓存Widget树的某些部分，以防止不必要的重新构建。
最简单的方法是使用const修饰构造函数:
由于const的修饰，即使调用了数百次build，DecoratedBox的实例也将保持不变。
或者你可以这样使用以达到相同的结果:
在这个例子中，当StreamBuilder收到新值的通知时，即使StreamBuilder的Column进行了重构，subtree也不会进行重构。这是因为由于闭包，MyWidget的实例没有改变。
这种模式在动画中经常使用。典型的是使用AnimatedBuilder和所有的*Transition时，例如AlignTransition。
我们还可以将subtree存储到类的一个字段中，但是并不推荐你这样做，因为它会破坏Flutter的热重载。
Uniapp目前比较成熟，而且用的是Vue语法，学习成本比较低，而且行业里面用的也比较广泛，而Flutter的话，学习成本略高，因为要学习新的语言，还有就是目前生态不是特别完备，等他再发展发展吧。黑马程序员官网有成套免费视频哦，有什么不懂的可以直接过去学习。您的采纳是对我成长的鞭策
这是领苗确认记录详情页需要展示给用户的内容，大家可以看到这个页面要承载很多的信息，要向下滚动一段很长的距离才能展示完，想要实现的效果是在页面的顶部有一个TabBar，用户可以通过点击TabBar进行锚点(jumpTo到指定位置)，AppBar下的整个页面是可以自由滚动的，在滚动过程中AppBar始终固定在顶部，TabBar在第一次进入详情页的时候不显示，只有在向下滑动的时候会由透明渐变为不透明并固定在顶部，同时当页面滑动到TabBar锚点位置的时候TabBar会切换到对应的下标，也就是要实现TabBar和ScrollView联动的双向控制，Tabbar的切换可以控制页面的跳转，页面的滑动又可以反过来控制TabBar的切换，类似与京东、淘宝的商品详情页效果。
SliverAppBar基本已经达到了我们想要的效果，但在界面顶部会有块空白区域试了很多方法怎么都去不掉，最后看了SliverAppBar这个控件的源码发现是它自带的初始高度。
这个没法设置或消除，不可能直接去改源码，所以后来换了一种实现思路，舍弃了SliverAppBar这个控件，以Stack的形式将TabBar置于ScrollView之上也能达到我们想要的效果，那么问题来了，如何实现TabBar的滚动渐变？很容易想到Opacity透明度控件，通过滚动监听来控制TabBar透明度的改变，借助Notificaion可以完美实现我们的需求。
Notification是Flutter中一个重要的机制，在Widget树中，每一个节点都可以分发通知（Notification）与父(包括祖先)Widget通信，通知会沿着当前节点（context）向上传递，所有父节点都可以通过NotificationListener来监听自己关注的通知，Flutter中称这种通知由子向父的传递为“通知冒泡”（Notification Bubbling）。
Flutter中很多地方使用了通知，如可滚动(Scrollable) Widget中滑动时就会分发ScrollNotification，而Scrollbar正是通过监听ScrollNotification来确定滚动条位置的。除了ScrollNotification，Flutter中还有SizeChangedLayoutNotification、KeepAliveNotification 、LayoutChangedNotification等。
通过NotificationListener监听滚动事件和通过ScrollController有两个主要的不同：
通过改造后，目前这个组件的原型已经实现并且可以满足我们的需求，最后就是对该demo进行完善使其能够完美接入我们的业务，做到技术赋能业务。
在一个页面滚动区域不是很长的情况下不建议使用，只有当页面足够长的情况下使用这个组件效果会比较好，因为如果一个页面过短，点击TabBar最后一栏进行锚点时，页面最后一个子模块内容无法置顶，只会将页面最后的内容推到屏幕范围内，并且由于TabBar监听到的是滚动的位置，会导致TabBar无法切换到对应的下标，看上去会像个bug，其实是因为底部已经没有内容了。
这个组件本身并没有太大的技术难度，但是有一些比较细节的小逻辑得处理好，并且从中衍生出来的很多琐碎的小的知识点都可以进行拓展。 在组件开发的过程中遇到问题时不局限于控件本身的设计模式，转变开发思维去找寻一些比较新颖的解决方案可能会有意外的收获。同时技术不能脱离于业务，技术赋能业务才能创造价值。
这一周继续聊跨平台桌面开发这个事情。
在这篇文章中，我暂时会放下Electron与WebView2的一个对比，而聊一聊跨平台这个对于程序员群体来说不陌生的词。
一个趋势是：跨平台开发几乎是在各个技术方向都会持续发展的
跨平台这个词，对于程序员来说，应该是不陌生的。因为这个概念不只在某一端存在，后端，前端，移动端，桌面端几乎所有方向都对跨平台有需求。
在后端，Java是跨平台的，当你用Java来编写后端服务时，并不需要考虑操作系统，因为它几乎支持主流的操作系统。现在，编写一个后端服务，选用Java仍是主流。虽然可能它的跨平台特性已经不是程序员最在意的点了。
而在移动端，类似React Native，Flutter也是非常有名的跨平台移动开发，它们与移动原生开发方式之间一直是竞争与共存。
而前端因为依托于浏览器，天然就是跨平台的。事实上，很多应用或服务早期纷纷选择从原生应用迁移至前端WEB方式的一个非常重要的原因就在于它是跨平台的。
桌面操作系统很长一段时间一直是Windows一家独大，所以桌面开发一直是Windows独占，直至现在为止，很多专业级的软件仍然是Windows独占的。
而Linux桌面操作系统与MacOS桌面操作系统，早些年几乎可以忽略不计，压根不需要考虑这两种系统。但随着近些年它们的慢慢流行，特别是苹果的MacOS的以其杰出的工艺，流畅的体验，叠加苹果手机的流行，其市场份额增长非常之快，在特定的诸如编程，设计等行业人群中使用范围较广，这使得开发支持MacOS系统这个点变得越来越重要。
所以，在桌面开发领域，跨平台的需求也越来越高。
这也是Electron及早期的NW.js能迅速发展起来并得到非常广应用的原因所在。
无论是哪一端，跨平台技术之所以频繁出现与不断发展，其根本原因就在于编程的一个重要痛点在于：
为了让同一个服务能在所有设备上运行，程序员不得不编写与维护非常多不同版本的程序
每一个程序或软件后面的服务，都有一个非常迫切的需求，就是期望它的用户无论何时，无论何地，无论使用任何设备，都能方便友好的使用这个服务。
也是因为这个原因，Web发展起来了，因为Web的优势就在这，只要你的设备上有浏览器，就能访问。
但Web毕竟性能有限，且浏览器这种形式并不利于用户忠诚度的培养，它存在天然的弱点。一些简单的操作服务使用Web并无问题，但稍微有点要求的，Web可能就并不是非常适合。
所以，一种趋势不可避免地流行起来：
对不同设备或系统进行抽象，基于某一种特定的编程语言，编写出能与原生程序相媲美的，又能跨平台的技术便层出不穷了
对吧，Java是使用JVM来抽象不同的操作系统，React Native则是使用虚拟DOM以及转换成原生控件的方式来实现跨平台，而Electron则是通过性能较好的Chrome内核+NodeJS原生调用能力的搭配来实现跨平台桌面开发。
总而言之，这种跨平台的技术不会消亡，只会有新的技术层出不穷，而它们与原生开发一定是相互竞争，配合与共存的。相互之间无法取代。
那再回到跨平台技术上来说，一个良好的跨平台开发的技术或框架，重点是什么。
或者换种方式说，哪些特性使得它更易于流行起来？
我个人认为有以下的几个点：
跨平台开发技术能不能流行起来的一个非常重要的点就在于，使用了什么样的编程语言。
以移动端跨平台开发技术来说明，一个React Native，一个Flutter，这两个是比较知名主流的跨平台移动开发技术。React Native使用的是前端React技术，而Flutter则是Google的D语言。
显而易见的是，虽然Flutter是使用skia引擎在底层重绘一套UI，其性能相比React Native这种模式更佳，但React Native更易于被接受。
在流行度上，React Native始终比Flutter更流行，一个最重要的原因也在于：
使用已熟知的前端编程语言，比起重新学习一个D语言更易于被接受，维护成本更可控。
这个问题在跨平台桌面开发中也是类似，跨平台桌面开发技术也不是Electron最开始出现，比如著名的QT很早就有了，但比起Electron这种使用前端编程技术来说，显然在编程语言的门槛上和程序员群体上都存在困难，这也是Electron能后来居上的原因所在。
因为，大多数程序员群体，相比较另外学习一门什么语言去做什么，使用自己熟悉的语言来做什么是更容易，意愿也更高。
而从公司或团队的考量上看，选择偏门的小众语言存在成本上的顾虑，比如人员招聘是否容易？
跨平台技术在尝试解决不同平台不一致，它或多或少会损耗性能。这也决定了几乎没有任何一个跨平台技术能取代原生开发。
这是一个取舍的问题，对于一个程序来说，究竟性能有多重要。对于比较看重性能的程序来说，原生开发可能是最优选择。
但跨平台的性能损耗也有高低之分，并不在同一水平线上。
其实，无论是Electron，或是WebView2，都是基于浏览器内核+前端技术的跨平台桌面解决方案，这也是为什么要把它们放在一起聊的原因。
Electron是先行者（当然，严格说来，NW.js出现的更早，但今天它的流行度已远远落后于Electron了），而WebView2则是后来者。
那做为后来者的WebView2究竟做了哪些改进？它又有多大的能力来挑战Electron呢？
下一篇，继续聊。
