跨平台桌面开发，Electron还是WebView2 （中篇）

这一周继续聊跨平台桌面开发这个事情。

在这篇文章中，我暂时会放下Electron与WebView2的一个对比，而聊一聊跨平台这个对于程序员群体来说不陌生的词。

一个趋势是：跨平台开发几乎是在各个技术方向都会持续发展的

跨平台这个词，对于程序员来说，应该是不陌生的。因为这个概念不只在某一端存在，后端，前端，移动端，桌面端几乎所有方向都对跨平台有需求。

在后端，Java是跨平台的，当你用Java来编写后端服务时，并不需要考虑 *** 作系统，因为它几乎支持主流的 *** 作系统。现在，编写一个后端服务，选用Java仍是主流。虽然可能它的跨平台特性已经不是程序员最在意的点了。

而在移动端，类似React Native，Flutter也是非常有名的跨平台移动开发，它们与移动原生开发方式之间一直是竞争与共存。

而前端因为依托于浏览器，天然就是跨平台的。事实上，很多应用或服务早期纷纷选择从原生应用迁移至前端WEB方式的一个非常重要的原因就在于它是跨平台的。

桌面 *** 作系统很长一段时间一直是Windows一家独大，所以桌面开发一直是Windows独占，直至现在为止，很多专业级的软件仍然是Windows独占的。

而Linux桌面 *** 作系统与MacOS桌面 *** 作系统，早些年几乎可以忽略不计，压根不需要考虑这两种系统。但随着近些年它们的慢慢流行，特别是苹果的MacOS的以其杰出的工艺，流畅的体验，叠加苹果手机的流行，其市场份额增长非常之快，在特定的诸如编程，设计等行业人群中使用范围较广，这使得开发支持MacOS系统这个点变得越来越重要。

所以，在桌面开发领域，跨平台的需求也越来越高。

这也是Electron及早期的NWjs能迅速发展起来并得到非常广应用的原因所在。

无论是哪一端，跨平台技术之所以频繁出现与不断发展，其根本原因就在于编程的一个重要痛点在于：

为了让同一个服务能在所有设备上运行，程序员不得不编写与维护非常多不同版本的程序

每一个程序或软件后面的服务，都有一个非常迫切的需求，就是期望它的用户无论何时，无论何地，无论使用任何设备，都能方便友好的使用这个服务。

也是因为这个原因，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是先行者（当然，严格说来，NWjs出现的更早，但今天它的流行度已远远落后于Electron了），而WebView2则是后来者。

那做为后来者的WebView2究竟做了哪些改进？它又有多大的能力来挑战Electron呢？

下一篇，继续聊。

正好最近发现一个很好玩的组件，就和大家分享一下。

这是一个动画库，由Airbnb产品，对，就是那个宣布放弃使用React Native的Airbnb，这让我一个用RN做APP的很是尴尬。但是这个动画库还是很好用的，名字叫Lottie，反正就是个名字，也不知道什么意思，估计Airbnb的设计师叫Lottie吧。

这个东西本来是用在Android/ios的，Airbnb还特意做了个RN版本，不过本质上也是用的原生，所以差不多。其实流程很简单，就是用AE做出动画，用bodymovin插件把动画导出成json，Lottie会解析这个json并且渲染出来。看个官方的例子吧：

效果还是蛮不错的，使用起来也很简单，具体可以去看官方文档。

地址： >

React native充分利用了Facebook的现有轮子，是一个很优秀的集成作品，并且我相信这个团队对前端的了解很深刻，否则不可能让Native code「退居二线」。

对应到前端开发，整个系统结构是这样：

JSX vs HTML

CSS-layout vs css

ECMAScript 6 vs ECMAScript 5

React native View vs DOM

无需编译，我在第一次编译了ipa装好以后，就再也没更新过app，只要更新云端的js代码，reload一下，整个界面就全变了。

多数布局代码都是JSX，所有Native组件都是标签化的，这对于前端程序员来说，降低了不少学习成本，也大大减少了代码量。不信你可以看看JSX编译后的代码。

复用React系统，也减少了一定学习和开发成本，更重要的是利用了React里面的分层和diff机制。js层传给Native层的是一个diff后的json，然后由Native将这个数据映射成真正的布局视图。

css-layout也是点睛之笔，前端可以继续用熟悉的类css方式来编写布局，通过这个工具转换成constrain布局。

系统只有js-objc的单向调用，就是把原生UI组件的方法通过javascritcore或者webview（低版本iOS）映射到js中来，整个调用过程是异步的，这样的设计令React native可以让js运行在桌面chrome中，通过websocket连接Native code和桌面chrome，极大地方便了调试。对其中的机制Bang的一篇文章写得很详细，我就不拾人牙慧了：React Native通信机制详解 « bang’s blog 。但这样设计也会带来一些问题，后面说。

点按 *** 作也被抽象成了一组组件（TouchableXXX），这种抽象方式是我在之前做类似工作中没有想到的。facebook还列出Native为什么和web「手感」不同的原因：实时的点按反馈和取消能力。React Native 这套相应机制设计得很完善，能像Native code那样控制整个点按 *** 作的所有过程。

Debug相当方便！修改了js以后，通过内建的nodejs watcher编译成bundle，在模拟器里面按cmd+r就可以看到效果。而且按cmd+d，可以打开一个chrome窗口，所有的js都移到了chrome里面运行，所以什么断点单步打调用栈，都不在话下。

上面的既是特点也是优点，下面说说缺点，或者应该说：「仍然遗留的问题」，在我看来，这个方案已经超越了Hybird方案。

系统仍然（不得不）依赖原生组件暴露出来的组件和方法。举两个例子，ScrollView这个组件，在Native层是有大量事件的，scrollViewWillBeginDragging， scrollViewWillEndDragging，scrollViewDidEndDragging等等，这些事件在现有的版本都没有暴露，基本上做不了组件联动效果。另外，这个版本中有大量组件是iOS only的：ActivityIndicatorIOS、DatePickerIOS、NavigatorIOS、PickerIOS、SliderIOS、SwitchIOS、TabBarIOS、AlertIOS、AppStateIOS、LinkingIOS、PushNotificationIOS、StatusBarIOS、VibrationIOS，反过来看，剩余的都是一些抽象程度极强的基本组件。这样，用户必须在不同的平台下写两套代码，而且所有能力仍然强烈依赖 React native 开发人员暴露的接口。

由于最外层是React，初次学习成本高，不像往常的Hybird方案，只要多学几个JS API就可以开始干活了。当然，React的确让后续开发变得简单了一些，这么一套外来的（基于iOS）、残缺不全的（css-layout）在React的包装下，的确显得不那么面目可憎了。

另外，React Native仍然很不完善。文档还不全，我基本上是看着他的示例代码完成的demo，集成到已有app的文档也是今天才出来。按照官方的说法，Android版本要到半年后才发布：Blog | React ，届时整个系统设计可能还会有很大的变化。

PS，在使用Tabbar的时候，我惊喜的发现他们居然用了iconfont方案，我现在手头的项目中也有同样的实现，不过API怎么设计一直很头疼。结果，我发现他是这么写的：

<TabBarItemIOS

name="blueTab"

icon={_ix_DEPRECATED('favorites')}

>

在 _ix_DEPRECATED 的定义处，有一句注释： // TODO(nicklockwood): How can this fit our require system

以上。

下面是一周前，在React native还没开源的时候，通过反解ipa的一些分析过程，有兴趣的可以看看。

------------------------简单粗暴的分割线--------------------

背景和调研手段

React Native还没开源，最近和组里兄弟「反编译」了Facebook Group（这个应用是用React Native实现的）的ipa代码，出来几百个JS文件，格式化一下，花了几天时间读了一下源码，对React Native的内部核心机制算是有了一个基本了解。

React Native的核心实现：

先简单说几点，详细的等回头更新。

1 React Native里面没有webview，这货不是Hybrid app，里面执行JS是用的

JavascriptCore。

2 再说React Native的核心，iOS Native code提供了十来个最基本核心的类（RCTDeviceEventEmitter、RCTRenderingPerf等）、或组件（RCTView、RCTTextField、RCTTextView、RCTModalFullscreenView等），然后由React Native的JS部分，组成二十来个基本组件（Popover、Listview等），交由上层的业务方来使用（THGroupView）。

3 就如他们在宣传时所说，他们实现了一套类似css的子集，用来解决样式问题，相当复杂和强大，靠这个才能将Native的核心组件组成JS层的基本组件再组成业务端的业务组件，应该是采用facebook/css-layout · GitHub的C语言版本实现的（在ppt中我们看到了类似flex-direction: column一类的代码，这个正是css-layout支持的语法）。

4 在React Native中，写JS的工程师解决的是「将基本组件拼装成可用的React组件」的问题，写Native Code的工程师解决的是「提供核心组件，提供足够的扩展性、灵活性和性能」的问题。

React Native的设计考虑：

ReactJS对React Native有着直接的影响（我没在生产环境中用过React，只看过代码&用过Angular，如果有误请指出）

ReactJS里面有这样的设计：

1 ReactJS 的大工厂入口createElement返回的不是某个实体DOM对象，而只是一个数组

2 通过源码中 ui/browser/ 目录中的代码，将这个数组转换成DOM

3 底层的渲染核心是可以更换的

另外，Facebook自己有JSX，css-layout等开源项目，基于这些，如果要做一个用 JS来开发Native app的东西，很自然就想到了一套最有效率的搞法：

1 将 ui/browser 里面的代码替换成一套 Native 的桥接JS（实际上，iOS版是通过

injectGenericComponentClass方法，将核心组件的方法注入到JS里面 ），就直接复用React的MVVM，自动将数据映射到Native了

2 Native code里面实现三组核心API，一组提供核心组件的API（create、update、delete），一组事件方法（ReactJS里面的EventEmitter ），一组对css进行解析（css-layout）以及返回Style的ComputedStyle（React Native里面叫meatureStyle）。

这样，用上了ReactJS本身的所有核心功能和设计思路，Native的开发也足够简单。

那，React Native是什么看

其实这东西从Native开发来说，相当于重新发明了一个浏览器渲染引擎并且套一个React的壳，从Web开发角度来说，就是把原来React的后端换成了Native code来实现，就跟Flipboard最近搞的React Canvas 一样： Flipboard · GitHubreact-canvas

React Native的优势和劣势：：

优势相对Hybird app或者Webapp：

1 不用Webview，彻底摆脱了Webview让人不爽的交互和性能问题

2 有较强的扩展性，这是因为Native端提供的是基本控件，JS可以自由组合使用

3 可以直接使用Native原生的「牛逼」动画（在FB Group这个app里面，面板滑出带一点果冻d动，面板基于某个点展开这种动画随处可见，这种动画用Native code来做小菜一碟，但是用Web来做就难上加难）。

优势相对于Native app：

1 可以通过更新远端JS，直接更新app，不过这快成为各家大型Native app的标配了…

劣势：

1 扩展性仍然远远不如web，也远远不如直接写Native code（这个不用废话解释了吧）

2 从Native到Web，要做很多概念转换，势必造成双方都要妥协。比如web要用一套CSS的阉割版，Native通过css-layout拿到最终样式再转换成native原生的表达方式（比如iOS的Constraint\origin\Center等属性），再比如动画。另外，若Android和iOS都要做相同的封装，概念转换就更复杂了。

更新1：添加了React对React Native的影响。

更新2：基本确定其使用了 css-layout，添加了对React Native的总结

更新3: React native已经开源了： React Native，只有iOS版。我写了几个demo，简单看了看objc代码并和开源前的我们的一些结论（见后文）交叉验证。简单地从前端工程师和系统整体角度说一下React native的特点和优劣吧。

更新4: 补充了几条优势和与前端开发的对照

张小喜告别996 实现高效编程 减少开发压力 开启Java高效编程之门（完整版高清视频）百度网盘  

aizj 复制这段内容后打开百度网盘手机App， *** 作更方便哦   

若资源有问题欢迎追问~  

React Native不到两岁，兼容Android平台刚刚1年。我学习React Native其实也就不到1年，不算长，也不算短。

Paul Graham在文章中写过：大多数人真正注意到你的时候，不是第一眼看到你站在那里，而是发现了过了这么久你居然还在那里。

我就是Paul提到的"大多数人"，当React Native刚出来的时候，我就通过CSDN等一些平台了解了React Native，但是并没有真正的关注它。

过了半年多，发现React Native不但还依然存在，而且还产生了不错的React Native社区。从此开始逐渐关注React Native。

至于为什么深入学习React Native，有以下几点原因。

一、开发React Native很少使用设计模式

对，你没有看错，确实是很少使用设计模式。有人会问我，这也算学习的理由？

我先搁置一下，先给大家讲个绝大多数人都听过的故事。

金庸小说中独孤求败的剑冢中，埋的是独孤求败一生几个阶段中用过的几柄剑。

第一柄是一柄青光闪闪的无名利剑。凌厉刚猛，无坚不摧，弱冠前以之与河朔群雄争锋。

第二柄是紫薇软剑，三十岁前所用，误伤义士不祥，乃弃之深谷。

第三柄是玄铁重剑，重剑无锋，大巧不工，四十岁之前恃之横行天下。

第四柄是柄已腐朽的木剑，原因是独孤求败「四十岁后，不滞于物，草木竹石均可为剑」

独孤求败一生境界阶段分为利剑级、软剑级、重剑级、木剑级，对应用不同的武器。

而程序员编程阶段同样分为几个阶段。

利剑级，利剑招式一般直接。刚入职场的程序员，技术有限，一般都是以实现功能为主要任务，不考虑性能，模式。

软剑级，就是在招式已经发挥到极致的基础上追求变化的极致；当程序员迭代过几次项目，就会认识到程序存在的问题，代码也会更加规范。

重剑级，相比于软剑是一种质的飞跃；当程序员工作多年后，做过好多项目，慢慢就会了解各种模式，融会贯通，达到架构师的高度。

木剑级，基本上达到人剑合一的境界; 这也是我主要要讲的境界，能够回到程序的本质。

回到程序的本质，程序的形式应该仅仅反应它所要解决的问题。

当我们开发程序一段时间后，就会发现编程已经变得制度化了，尤其是使用面向对象的语言，我们大量听到 模式（pattern）这个词，但是我们应该想到模式并不应该存在的。

程序就是为了要解决问题，而在代码中其它任何外加的形式都是在告诉我们，表明对问题的抽象不够深，这些原本应该让编程语言本身去实现。

当我使用原生代码开发Android程序的时候，用到了大量设计模式——工厂设计模式，适配器设计模式，单例设计模式等等一大堆。一开始的时候自我感觉良好，认为自己很牛逼，面试别人或者自己去面试时都会显摆下。后来我就想，Android框架为什么不提供更深的抽象，让我直接实现具体的功能，而不用使用各种模式搭建各种框架呢？

当我接触React Native时，虽然React Native也需要用到一些模式（现阶段很难避免的），但是React Native整体设计架构要比Android强很多，非常直接。

举个例子，在React Native开发中，我们要改的数据统一放在状态机中，只要改动状态机里的数据，界面上不管有多少处，只要和改动的数据相关联都会发生改变。而在Android原生开发中，可能需要把多处要改变的封装到一起，进行 *** 作，无疑多了一步封装。

代码更加直接，就意味着程序更加好维护。程序更好维护，就意味着成本更低。

二、学习成本比较高

第二点让我学习的理由就是React Native学习成本相对比较高，也许之前的理由你接受了，这个可能又会让你抓狂，为什么学习成本高还要去学习啊？

往往学习成本高的才更加值得去学习！

React Native学习成本确实很高,

你首先肯定需要学习JSX语法，React知识，学习ES6，函数式编程思想。如果你想了解React Native构建的还需要学习nodejs。封装原生组件还需要学习 java，object-c，swift， 也就是需要学习Android和ios原生开发。设计到通讯原理还需要了解C++。

有些程序员可能会因为想炫耀自己见多识广，会告诉你“所有编程语言基本相似”，“语言不重要，重要的是理解”；其实上面说的是一派胡言，每种语言从语法到概念，都不一样。你学会其中一门语言对你学另一门语言的好处就是你可以进行对比，加深学习的印象。

虽然学习成本很高，但是通过学习React Native而掌握这么多技术并不是什么坏事。React Native其实就把各种知识打成一个压缩包，让我们更有效率的学习。

React Native技术，同时具备可测量性和可放大性。

React Native既可以开发Android也可以开发IOS,尤其是写界面的速度非常快。通过测量完成的程序，理论上你可以是一名普通的Android/IOS程序员的两倍。

微软也开发了Windows Phone的React Native版本。通过React知识，你可以轻松写出Web端程序。甚至在微信小程序中都能找到React Native的影子。

我们这个世界，你向下沉沦或者向上奋进都取决于你自己，不能把原因推给外界。有些刚毕业的学生一听到5%的人占社会50%的财富，往往认为是不公平的。从程序员的角度，我也认为是不公平的，因为5%的程序员写出了全世界99%的优秀软件，他们就应该占更高比例的收入。

一个React Native程序员就应该是一个普通的Android/iOS程序员工资的两倍，并没有什么问题。

三、React Native还不是很完善

React Native还有很多坑，并不完善，React Native几乎每个月都有新的小版本发布，至今还没有推出10正式版本。这也恰恰使我们学习React Native的理由！

前几年，我在北京上班时经常听到javaEE程序员抱怨自己开发了这么多年不如一个新入职的Android/iOS程序员工资高。

其实很好理解啊，难道不知道技术越新越值钱这个道理吗？

程序员就像蚊子一样，群体很多，在后厂村路上10个估计有7个是程序员，但是每个程序员个体压力又很大，想生存必须吸取新鲜的血液。

目前使用React Native的公司不是很多，当你作为一个产品经理或CTO时，你肯定优先跟随大多数人的选择的做法，有个专业术语叫做“业界最佳实践”。因为这个词出现的原因就是为了产品经理/CTO 推卸责任。既然我选择的是“业界最佳实践”，如果不成功，不是我的问题，而是“业界”的问题。

但是如果你是一名程序员按照上面的做法你会死的很惨，因为“业界最佳实践”会逐渐变化的，一旦你掌握的技能不是“业界最佳实践”了，你就要想办法让你的房贷别断供了。

React Native不会取代Android/iOS原生开发，但随着React Native正式版推出，也许它就变成了“业界最佳实践”了。

关于如何学习React Native

如果想快速入门React Native，官方Api是肯定需要看的。里面不但有文档而且有例子，涵盖了绝大多数知识。

>

英文不好的话,可以参考react-native中文文档（建议也要对比英文文档）

>

FaceBook官方也提供了演示App,可以作为参考

>

facebook开源的f8项目也是蛮不错的

>

有，我个人比较喜欢Java的框架。这也是安卓应用开发的祖传框架之一了。其实现在安卓的应用市场是很大的，因为更多人的手机系统应用的是安卓。因为安卓的市场份额和手机应用的火热，与之相关的一些程序员在这些方面也是有很大的前途的。虽然程序员的工作比较累，但每年还是有无数人前仆后继加入其中。

01、安卓应用的原生框架，Java和c++

说实话我其实对程序不太懂，但是因为有朋友在学Java，所以我也读这个比较有好感。手机上的一些应用最基础的设计和功能基本上都是通过Java和c++实现的。通过这两种程序语言，不仅可以设计出安卓应用，还包括网页和其他方面的很多东西。这两种语言都比较灵活，可以让用户体验更流畅、更便捷。

02、Unity开发，比较不错的安卓游戏开发框架

Unity是一种什么样的语言呢？相较于Java来说，Unity其实更适合游戏开发。因为很多游戏都是二维、三维的，使用这种语言开发游戏会比开发应用更方便一些。举一个我们平常经常玩的游戏，比方说王者荣耀，就是通过这种技术实现的。Unity的种类特别多，所以相较于Java来说，内容更集中一些。

03、作为开源框架的React Native，走在前端

React Native这个东西是一个开源框架，可以对开源软件进行定义。这个框架算是一个比较新鲜的框架了。而且React Native的利用率是非常高的。现在很多网页浏览器已经选择React Native作为自己的选择了。像ins和沃尔玛，都对这一框架十分青睐。所以它的未来是比较被看好的。

以上就是关于跨平台桌面开发，Electron还是WebView2 （中篇）全部的内容，包括:跨平台桌面开发，Electron还是WebView2 （中篇）、React Native的一个动画库lottie、react native 开源了吗等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！