如何正确跨端开发（前端跨端开发方案）

本篇文章给大家谈谈如何正确跨端开发，以及前端跨端开发方案对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享如何正确跨端开发的知识，其中也会对前端跨端开发方案进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、跨端开发面面谈之基于WebView的Hybrid开发模式
• 2、制作PC与移动端跨平台游戏，不可忽视的5大要素
• 3、阿里跨终端的H5游戏开发解决方案——Hilo
• 4、web前端跨平台开发技术有哪些
• 5、客户端开发的成长思考
• 6、跨平台桌面开发，Electron还是WebView2 （中篇）

跨端开发面面谈之基于WebView的Hybrid开发模式

跨终端移动开发是近期准备总结如何正确跨端开发的一个主题如何正确跨端开发，作为这一系列的开始，首先简单说说基于WebView的Hybrid混合开发模式。

有过混合应用开发经验的同学，对基于WebView的Hybrid开发模式应该不会陌生。借助于原生端各平台的WebView组件，可以实现Native和JavaScript的双向通信，从而将Web App与Mobile App融合起来，开启混合开发的新模式。

基于WebView的Hybrid开发模式到如今已经非常成熟，不再是一个实验性新技术，而是广泛应用在各大厂商的平台型应用如微信、手Q中。

jsBridge作为连接Native和JavaScript的桥梁，是基于WebView的Hybrid开发模式中的关键点。
在如何正确跨端开发了解其通信原理后，再来看JSBridge究竟是什么。从前端角度来看，可能会把JSBridge理解为业务开发过程中，以全局变量注入到WebView中，帮助调用原生API的JavaScript工具库。这样的理解不够准确，按照我的理解，JSBridge不是一个标准的规范，基于原生系统为WebView组件提供的能力，已经可以建立起WebView JavaScript bridge，即使不再做更高程度的封装，也可以完成从Native到JavaScript的双向通信了。

我们所说的JSBridge，是对底层通道的抽象封装，这一过程包括了原生和JavaScript两侧内容，在原生端需要考虑系统API差异，对上层调用提供统一接口，在JavaScript端需要考虑调用方式，请求管理等内容。JSBridge的设计实现已经是成熟技术了，其设计可以参考 In-depth Profiling of JSBridge 、 Hybrid APP架构设计思路 ，一个安卓端完整JSBridge实现可以参考 JsBridge实现 。

目前，基于WebView的Hybrid开发模式非常成熟，广泛应用于各类平台型App中。实现一个完善的JSBridge是在现有App中集成使用Hybrid开发模式的基础，在完成这一基础设施建设后，大家继续在各个方向深挖，在不同的维度不断优化性能和体验。

多数App的Hybrid部分做到上面部分，已经有了还不错的体验。在我的了解中，空间团队在上面基础上继续优化给出的是当前做的更好的方案。其主要流程如下图所示，详细内容可以参考 QQ空间前端工程师如何做首屏优化
除了在现有App中集成使用这一开发模式，还可以使用这一技术开发独立App。早期的PhoneGap、Cordova、现在的Ionic，是这一领域较为知名的开发框架。

我司前端技术栈曾以Angular为主，一些App也由前端团队基于Angular技术栈选型Ionic。初入团队曾维护过基于Angular 1.x的Ionic App，用于我司投资顾问服务客户的以IM为主、综合一些其如何正确跨端开发他业务，可以算一个比较复杂的应用。

前端技术背景的同学，采用Ionic框架开发App的学习成本不高。开发过程中仍在沿用前端技术，写的仍是Web App,跑在原生WebView容器中。采用Ionic提供的组件库，可以快速搭建项目界面。其扩展原生的机制也比较方便，如有原生能力的需求，并且没有现成实现的，可以自行封装使用，不过这个过程就需要原生开发同学的参与了。在我们的上述App开发中，主要是安卓端消息推送模块由原生开发同学提供了支持，其余对原生能力的需求如拍照、相册访问等常见需求，都有现成方案。

然而，采用Ionic完成上述应用，也有明显不足的地方。首先是聊天列表方面，我们知道，如微信和QQ聊天窗口，这是一个异构的无限滚动长列表，在进入聊天界面时，一般只加载最近的一屏聊天数据，然后通过滚动加载历史消息。在原生端完成这一需求有各种常见手段，而仅靠Web端技术，在各种折腾后，效果都不尽如人意。其次是动画，这里的动画包括了换页动画和其他动画，流畅程度一般。最后是前端开发通病，要处理浏览器兼容性问题，crosswalk只是一个理论解决方案，其体积限制了几乎不会被采用。

Ionic不断迭代，新的版本中依赖新的Angular。新的Angular与Angular 1.x开发体验已经完全不同，如果如何正确跨端开发你还不了解，可以阅读我们团队书籍 揭秘Angular 2 。新的Ionic的开发体验，相比以往也有提升，在其工具链中，提供了拖拽式项目生成工具
同时，Ionic pro提供的开发者工具，为应用整个生命周期提供了完善的支持平台，包括了以下功能，不过，使用需要付费。

站在当下来看，对于前端技术背景开发者来说，如果已有Angular基础，不希望引入过高学习成本，需要快速开发一个复杂程度不算太高、或者对应用性能不是特别敏感的跨终端App，选择Ionic依然是一个可行方案。

然而，既然你已经身在前端领域这样一个技术更迭日新月异的圈子里，还是应该使劲的折腾，关注跨端开发这个主题新的技术热点，接下来我也会继续谈谈在NativeScript、React Native、Flutter的一些体验，可以保持关注。

制作PC与移动端跨平台游戏，不可忽视的5大要素

现在，许多工作室都在尝试制作同时适合移动端与PC平台的游戏。平心而论，无论是商业模式，目标受众还是控制线路的不同，都会给跨平台的游戏设计增添阻碍。也许制作一款能够适应移动端与PC平台的完美游戏是一个不现实的目标。

Kitfox Games就是一家尝试跨平台游戏制作的工作室。他们制作的Roguelike类游戏Shattered Planet，今年年初作为一款免费游戏在移动端平台登陆。而在7月初，shattered Planet作为一款一次性付费游戏，登陆PC平台。同样的游戏，不同的商业模式。

一、首先明确你的目标，它将会成为暴风雨中的罗盘

身为一名游戏设计师，我并不喜欢考虑商业方面的事情。

但是结果证明，商业考量是非常重要的。在共事之前，我和同事们相互都很陌生——我们欣赏彼此的工作经历并且在一起喝过咖啡，但是突然之间我们就在一起制作游戏了。在第3周，我们问自己：我们到底想要通过游戏表达什么，而不仅仅是以“完成游戏”为目的。

我们的首要目标是得到大量-，还是获得可观的利润，亦或是得到很高的评分?

这取决于这些要素在我们心中的优先顺位，当决定制作一款免费游戏后，-量高于一切。我们推广Kitfox这个品牌，并且我们愿意用收入和评分作为交换。未来我们制作的游戏也许会有所不同，但是由于我们已经积累了少量的忠实拥趸。由于Kitfox的多位成员依旧处于负债阶段，而且尚未扭亏为盈。所以我们想尽力扩大我们的用户量。

首先明确这一点十分重要，尤其是当我们在制作到一半时开始怀疑自己的方向。大多数团队对于免费游戏的盈利模式感到不适，并且我们知道有相当一部分自我标榜为“硬核玩家”的人痛恨免费游戏，仿佛除了Valve或Riot制作一概不玩。

最后，我们决定“增厚皮肤”。反对者有一万个反对的理由，但是如果我们没能一直沿着计划进行下去，如果作为一个团队，我们对于业务优先级并不清晰。在制作游戏的关键时刻，这些风险就会变得无比危急。

二、尽早、大量地进行游戏测试

在我们能自信展出产品前，我们经常进行游戏测试。对于未知的中立玩家来说，极差的第一印象是让人恐慌的——即使几个人的口口相传也会最终不成比例地形成舆论风暴。

但是我们依旧要保持勇敢，游戏测试时有价值的，也是必须的。我很自信地说没有测试就没有《Shattered Planetat》。尽可能地打磨游戏，(没错，至少在90%的特征都顺利工作)让玩家们可以自己搞清楚怎么玩，而不是告诉他们该如何控制。然后我们就推到一旁，静观其变吧。

我们从《Shattered Planet》仅仅是一个在方格上行走的小人时就开始做游戏测试。从技术上看，人物可以击倒并杀死一个敌人，但是其他的要素都没有——游戏最初只有一关(没有过程生成技术)，没有装备，没有升级，什么都没有!但是我们学到了很多，我们必须每隔一两周测试一次。在我们有关移动端版本的内部调查中，我们事实上还希望测试更多次。

顺便一提，每次测试之后，我们还让每个人填写了一份标准化表格。这不仅可以让我们收集到更多意见(游戏的哪一部分你不满意?)，而且帮助我们根据游戏表现与反馈绘制一张图表。在测试图表3中，我们发现在移动端玩免费游戏的用户对我们而言最有帮助，因为他们比那些只玩Steam上主机游戏的用户更容易跨平台游戏。

三、做好发生变化的准备

这是根据前两条建议下水到渠成的结果。

如果你有明确的方向，并且经常调试，你会发现，不知为何，自己所在的轨道仍然到达不了目标，游戏的适用性依旧不足。如果核心玩法和你想得一样在运作，辅助的特征将会有妨碍作用。

速度与质量需要依据业务目标，让制作人和设计师之间相互妥协。我们在研发计划里增加了一个月的优化时间，在手游版发布之前，我们为了增加更好的进度系统而用掉了，随后我们发现，这对于游戏的成功是很重要的。

对于你的游戏而言，可能具体数字会有所不同，但有些问题和解决方法可能是相同的。另一方面，我们还可以用这些目标来决定哪些功能需要去掉，哪些需要保留。

四、优化

我们做游戏始终都是希望在PC平台发布的，最开始也是在PC上测试。作为玩家，我们的研发团队主要是在PC平台玩游戏。当我们在iOS和安卓设备进行测试的时候，我们使用了iPad 4、iPad Mini、Nexus 7和三星Note 10.1，还用了一些比较新的手机型号进行测试。移动硬件的性能越来越好，而且我们的独立游戏也没有特别苛刻的要求，所以本以为手游版测试会很容易。

随后我们发布了《Shattered Planet》，让我们惊讶的是，在低端机上，它运行起来就像个垃圾软件一样卡，但我们没有留出足够的时间做优化，所以当时觉得，先把主要的bug解决完了再做这些非必要的优化，可我们没想到的是，bug修复几乎是无止尽的，特别是优化不足的情况下。对于低端机玩家而言，我也只能道歉了。

五、考虑优先推向Steam平台?

之所以加了个问号，是因为并不确定，我们的策略看起来很正确，最高的时候，我们的游戏在Steam畅销榜达到了第28，对我们这个没有营销人员也没有营销预算的不知名团队而言，已经是不错的表现了，当然，手游版的30万-量对此也是有帮助的。

但是，我们不得不忍受一些比较难听的评论，比如反对免费模式，还有人的评价是“这只是一个手游”、“手游移植版”等等(因为我们先发布的手游版)。PC和主机玩家有一部分就是这么挑剔，所以，如果我们的目标是让人们知道这个游戏，或许先发布Steam版本再推手游会好一些，但我也不确定。

对于下一款游戏《Moon Hunters》，我们的目标是PC和主机游戏市场，还可能会做一个只有核心系统的预览应用，如果这样，我们仍然会在移动版本做免费，甚至可能是完全免费。

信息来源：Gamesutra.com

作者：Mike Rose

阿里跨终端的H5游戏开发解决方案——Hilo

Hilo是由阿里巴巴集团开发的一款 HTML5 跨终端 游戏 解决方案，可以帮助开发者快速创建 HTML5 游戏 。有以下特征：独立模块设计，支持多种模块范式的包装版本;面向对象程序化开发;多重渲染模型，其中包括 Canvas，DOM 和 WebGL 等;兼容多台台式机和移动浏览器；使用 Flash Shim 来支持 IE ;支持物理扩展： Chipmunk；支持骨骼动画扩展： DragonBone！
1、Hilo 支持多种模块范式的包装版本，包括AMD，CMD，COMMONJS，Standalone多种方式接入。另外，你可以根据需要新增和扩展模块和类型；
2、极精简的模块设计，完全面向对象；
3、多种渲染方式, 提供DOM，Canvas，Flash，WebGL等多种渲染方案（目前已经申请专利）；
4、全端浏览器的支持和高性能方案，独有的Flash渲染方案，即使在低版本IE浏览器下也可以跑起来“酷炫” 游戏 ； DOM渲染方案能显著解决低性能手机浏览器遇到的性能问题；
5、物理引擎支持——Chipmunk，支持自扩展物理实现；骨骼动画支持——DragonBones，同时内建骨骼动画系统——Tahiti（目前内部使用）；
6、案例丰富，框架成熟，已经经历多届阿里巴巴双十一，年中大促互动营销活动考验；
舞台Stage是一个各种图形、精灵动画等的总载体。所以可见的对象都要添加到舞台或其子容器后，才会被渲染出来。

Stage构造函数接收一个参数properties，此参数包含创建stage的各种属性。

舞台Stage上的物体的运动等变化，都是通过一个定时器Ticker不断地调用Stage.tick()方法来实现刷新的。

舞台上的一切对象都是可视对象，可以是图片、精灵、文字、图形，甚至DOM元素等等。Hilo提供了一些基本的可视类供您使用，比如添加一个图片到舞台上：

要想舞台上的图形、精灵动画等对象能响应用户的点击、触碰等交互事件，就必需先为舞台开启DOM事件响应，然后就可以使用View.on()来响应事件。

接下来，您就可以开始利用hilo提供的各种可视类来创建各种图形、精灵动画，尽情发挥您的创造力，开始您的HTML5 游戏 之旅吧！

Hilo对于开发H5 游戏 的开发者和对Web端渲染感兴趣的小伙伴来说值得一看，Hilo有诸多案例可供参考，如果你想继续深入了解它，可移步官方文档或者Github一探究竟！

web前端跨平台开发技术有哪些

Web 流：也被称为 Hybrid 技术，它基于 Web 相关技术来实现界面及功能
代码转换流：将某个语言转成 Objective-C、Java 或 C#，然后使用不同平台下的官方工具来开发
编译流：将某个语言编译为二进制文件，生成动态库或打包成 apk/ipa/xap 文件
虚拟机流：通过将某个语言的虚拟机移植到不同平台上来运行

客户端开发的成长思考

作为客户端开发程序员，首当其冲就是完成业务迭代，服务好产品用户和业务团队。服务好产品用户是业务团队存在的价值，服务好业务团队是客户端开发存在的价值。业务发展要考虑变现，要考虑增长，要考虑留存等等，最终落地的环节往往需要客户端开发来实现。
除了业务迭代，根据业务特色和客户端开发团队特点，会围绕高效研发体系和稳定研发质量不断做优化，也有的会尝试跨端能力建设、新技术探索落地。在更大一点的公司还会关注团队的技术影响力输出，以及不可忽视的安全和合规能力。
为了更好的衡量客户端质量，往往会用卡顿、卡死、crash等基础指标来评估质量，同时也会不断做包大小优化、启动优化、磁盘和流量监控、流畅度优化、cpu和电量优化等等来提升基础体验。同时还要关注研发过程中的效率提升，比如说研发流程优化、编译优化、自动化测试等等。
客户端能做的事情非常多，有服务于用户的业务方向，也有保障质量的基础方向，还有提供各种通用能力的中台方向，还有从事各种跨端建设、音视频处理、网络建设等等 。从供需关系来看，智能手机的市场规模是客户端开发岗位需求的天花板，全球接近40亿的智能手机就是客户端开发这个行业的未来保障。至于脉脉“客三消”理论鼓吹的大前端取代客户端开发，是典型的杞人忧天。从事过客户端开发的程序员都知道客户端原生Native开发是不可能被跨端的技术完全取代。RN、flutter等是在某些特定环境下会有不错应用收益，但不管是交互体验、研发体验，各项性能指标都比不上原生开发语言。

客户端开发是移动互联网快速发展的产物，本身也有一些从事的风险点，从我的经历来看，主要有以下问题：

客户端的很多日常工作是需求开发，需求开发主要是由各种业务逻辑、各类界面的实现。最常见的现象是 一年经验用三年，三年经验用十年 。由于客户端所见即所得的特点，很多开发者在度过前期的上手期之后，就一直重复使用类似的思考模式去解决问题。如果没有环境压迫，也没有自己主动去思考突破，会在日复一日的劳作中迷失成长。时间较长之后，往往会陷入能力增长的瓶颈期。

客户端开发的求职者和招聘者之间，现在有一种相互矛盾的现象： 求职者感觉外面客户端开发的需求量在不断的变少，招聘者一直在苦恼招不到人。
客户端开发的岗位减少是由于移动互联网的基建越来越成熟，相比流量成本和维护成本都更高的App，很多小公司选择使用了更加便捷的小程序、公众号、抖音短视频等等大公司提供的基础平台，导致了客户端开发的岗位需求量在不断减少。
招聘者苦恼的是招聘不到优秀的开发者，由于互联网行业常年有长期唱衰客户端开发的现象（从以前的PC开发到现在是移动端开发），再加上最近几年兴起的算法岗位和数据分析岗位竞争，越来越少的优秀毕业生投身到客户端的这个行业上，导致优秀的开发者供不应求。

“中年危机”是悬在程序员头上的达摩克里斯之剑，这不仅仅是客户端开发会面临的问题，这是所有大龄程序员都必须面对的互联网从业现状。由于前面提到的互联网基建成熟带来了的客户端岗位需求减少问题，客户端开发在中年危机这个问题显得更有压力。
但是如果觉得从事前端开发或者后台开发就不用面对中年危机，就是太过于乐观了。设想一下，一个公司为了节省成本都不做App了，他还会去招一个40的前端开发或者后端开发吗？
互联网行业在快速发展，薪酬待遇也在不断提升，这也带来源源不断的新人。 当一个新人和老人能力相差不大时，性价比更高的新人往往更容易胜出。 想要避免中年危机，唯有不断锻炼自己的能力，思考自己的不足之处，提升自己在市场的竞争力。

根据自己的粗浅认知，我觉得有下面几个方向可以努力。

大部分公司的官方回答永远是弹性工作制，事情干完就可以走。但是事情永远不可能做完，事情可以做完的公司还有市场竞争力？
我的看法是顺应潮流，合理安排时间。优先完成工作的事情，然后利用多余时间来进行学习。尽量不要把工作安排的满满当当，这样疲于奔命会让生活非常疲惫；也不要夸大工作难度、浑水摸鱼，摸鱼是对自己最大的不负责。按公司提倡的工作时间，合理安排工期，如果还有一些时间可以放松下心态，花点时间学习和成长。

可以从下面几个方向去探索：

学习如何从重复工作中学习和成长是必须的，因为再新的工作也会变成旧的工作。
学习的方向可以是做事、技术、思考、规划、团队等等，找一个当下最需要成长的能力开始锻炼。合理使用环境的压力，形成自己的学习和成长动力；偏技术侧需要自己拆分目标，逐步实现目标，这是非常重要的自驱力。
成长的过程很简单，制定目标，实现目标。目标需要有一定的量化标准，模棱两可让目标变得不可触碰。制定目标也要考虑目标的指引作用，对个人而言，目标描述的过程会比结果更加重要。
努力学习换来好结果，好结果继而激励产生进步动力，建立一个良好的正向反馈循环。

一个职业的未来，要看行业的发展前景。 移动互联网的发展规模，注定客户端在短期内仍然是刚需。至于长期发展之后，移动互联网被新的时代取代，那么也会有新的岗位延伸出来，到时再紧跟时代潮流即可。
另外要把业务和技术分开，技术只是一个工具。在前期确实需要积累客户端的知识和相关技术，但是随着时间的推移，慢慢会接触更多的知识。不要给自己设限制，在适当的时机技术栈可以扩大到后端。假如某个人只做某一个模块，那么也需要去接触这个模块的前因后果，数据的产生消费。眼界如果局限在客户端，那么只能知其然不知其所以然。重点是在于人，人才是解决问题的核心，具体的技术只是工具。

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

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

在这篇文章中，我暂时会放下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呢？

下一篇，继续聊。

关于如何正确跨端开发和前端跨端开发方案的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 如何正确跨端开发的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于前端跨端开发方案、如何正确跨端开发的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。