如今Weex与ReactNative哪个好?

日期:2020-11-23 类型:WEEX 

关键词:凯发k8娱乐官网地址手机版下载,凯发k8官网官网,k8下载网址登录

  你说c++跟js哪个好,你能说应用场景不一样,看你用来干什么,底层c++,web开发js,没有好坏之分。

  rn跟weex,干的同样的事情,同一个领域,这还特么拿啥啥场景选啥,没有好坏,适合不适合来和稀泥,有意思?

  本泽马,莱万谁更好,哦,这个得看战术需求,需要策应的话莱万好,需要桥头堡莱万好,需要射门莱万好,需要对抗莱万好,需要背身单打,莱万好,需要背锅本泽马强,所以,没有谁更强一说,虽然本泽马这三个赛季进球数还没莱万一个赛季多,但是也分不出谁更好吗,看战术需求,我靠啊尼玛的战术需求,这两个人有可比性?

  weex就是本泽马,区别是本泽马牛逼过,weex从来就是这么难用,出生晚,坑多,社区跟rn不能比,周边生态被爆出翔来,rn出了坑绝大部分情况是有人踩过可以谷歌,weex坑你就当吃了屎,自己消化吧,我看你妹的适合不适合,看毛线场景,不是一个级别的东西,有什么可分场景的?

  就目前的各方面情况讲,RN 确实更优,横空出世,背靠当时火的不行 React,一路都是风光无限。这种解决方案出来之后,如果没有竞争者的挑战,没有对比,没有选择,也不一定是好事儿。

  我猜 Weex 始于 KPI,毕竟大厂造轮子来升级是非常好的途径之一,但是往后发展,却成了两大阵营完善生态的方案,现在基于 React 的一整套的前端解决方案覆盖PC、Web、Native 可谓是成了大公司前端方案的标准套路,后起之秀 Vue 用良好的开发体验和低门槛的入门方式开始抢占用户,各种前端培训学校让一些前端不懂 js 基础,但是 Vue 溜的飞起。但Vue 并没有形成对 Native 的覆盖,这个可能也是 Weex 和 Vue 一拍即合的原因,双方都有需求,就开始了合作。

  扯会正题,在大前端逐渐融合的背景下,作为以 Vue 建立技术栈的团队开始寻找客户端的方案,做技术选型开始考虑业务达成、团队学习成本、开发效率,性能效率等问题,我们一开始也是将 Weex 和 RN 作为比较,在上一家公司使用的是 RN,但是现团队建立技术栈基于 Vue,考虑到第二个因素偏向 Weex,实际调研过程中发现 Weex 的坑确实很多,但是好在有很多问题已经有解决方案了,当然不管想要使用上述两种方案,都需要有一定的原生能力。实际开发过程中发现随着对 Weex 的了解越来越多,开发效率也越来越快,入坑之后才发现了第三个和第四个甚至第五第六个优势。

  至于 Weex 最大的卖点,兼容三端,Web 端这个优势每个人都有自己的看法,我们尝试了去兼容 Web 但是发现反而牺牲了开发效率,有兼容的时间,单独开发一套也出来了,并且更重要的是由于用户习惯的不一致,Web 端和 Native 针对的用户群体也不一样,在这个流量就是金子的环境下牺牲用户体验和开发效率去兼容 Web 并非是我们的初衷。

  当然也遇到了一些问题,一开始 Weex 没有托管 Apache 的时候还有 issue,很多问题确实不能及时得到解决,所以决定脱离 Weex 的所有 module,自行开发所有 module,重新设计,这也让我们对项目有了一些控制。

  决定了自行开发 module 和组件之后,减少了对 Weex 本身的依赖,项目本身受到的限制也越来越小,业务很快也完成了。当然现在类似 demo 跑不起来,毁灭式的升级,市场组件无法接入,bug 横飞,组件不足以完成业务功能,兼容性不足,热更新,公共文件导致包过大,社区经营不好等等这些问题,也都是一个技术产品成长的必经之路。

  两种方案在选型的时候,一定有可取的地方才会选择,工程师的精神就是趟坑,找准方向然后一往无前,两种方案都有已经上线的优秀产品,说明是这条路至少是能走通的,当然我们也在过程中总结了我们的解决方案,希望能帮助在 Weex 路上举步维艰的同行人,不管选择哪种方案,选择了就把他做好。Eros项目地址请戳(不要吝啬你的 star)。Eros文档地址请戳。我们公司已有三个项目通过 Eros 上线,也有几十个应用通过 Eros 发布上线。

  React Native 和 Weex 都是开发 APP 时可能用到的新技术。从性能上来看, Weex 比 React Native 更加容易学习和使用,而 React Native 的优势在于拥有更活跃的开源社区,版本换代更快,遇到的问题能够更快地得到解决。

  在传统开发中,当需要开发一款 App 的时候,往往需要在各个平台上,例如安卓平台、iOS 平台和 Web 平台,都开发一款对应的 App,我们将其称为「原生开发」。「原生开发」会给开发带来许多的问题,首先是开发人员增多和开发成本增加的问题,每个平台都需要有一名开发人员,而每增加一名开发人员就提高了开发成本;其次是还要保证不同平台之间功能的一致性,这给测试人员也带来了更多工作量;而最大的问题在于「原生开发」的周期长,复杂度高,这往往会造成产品难以在预期时间内完成。为了解决这种高成本的「原生开发」,诞生了两种代替原生开发的新技术:React Native 和 Weex。

  React Native 是 Facebook 在 2015 年 3 月开源的一个跨平台 UI 框架,其理念是既拥有「原生开发」的用户体验,又保留 React(React 是 Facebook 2013 年开源的 Web 开发框架)的开发效率,这无疑迎合了业界的痛点。它的设计者 Occhino 不强求写一份 React Native 代码来同时支持多个应用平台,而是希望在不同的平台上通过编写 React Native 代码来支持各个平台,因此他提出了「Learn once,write anywhere」口号,并没有像 Java 设计的那样「wirte once,run anywhere」。React Native 底层的实现其实依赖于 JavaScript,通过 JavaScript 引擎来调用原生代码,从而实现页面的渲染和数据的绑定。React Native 不仅解决了跨平台问题,还解决了客户端动态更新困难的问题。React Native 使用热更新方式来动态更新应用,解决了客户端更新麻烦的问题,特别是 iOS 端,每次更新都需要重新发布一个版本。React Native 通过将基础模块和业务模块一起打包成一个 JS Bundle(JavaScript 资源包),然后将这个 JS Bundle 放到服务器上,客户端通过下载服务器上的 JS Bundle 来实现更新,避免了重新发布应用。在业务频繁变化的情况下,动态更新就变得非常有用。图 1 是 React Native 的设计框架。

  随着移动互联网的发展,Android 和 iOS 呈两分天下之势,跨平台开发也逐渐成为移动领域的热门话题之一。怎么看待其背后的发展逻辑?跨平台开发的难点是什么?未来的发展方向如何?

  本篇回答来自于阿里巴巴淘系技术部资深无线技术专家腾渊,主要聊聊跨平台开发的发展趋势和变化。

  —————————————————————————————————————————

  腾渊认为:从早期比较流行的 Hybrid App,到后来的 React Native、Weex,再到现在比较火爆的小程序和 Flutter,可以看到跨平台的发展趋势是框架变得越来越重。如果当前的业务情况下前台呈现比较不稳定并且整个前台开发占比较高,那么应用跨平台框架的收益就比较高了。到底哪个方向更正确、哪个框架更好其实是没有标准答案的,更多需要开发者因时制宜地选择。

  腾渊还会在即将召开的 QCon 全球软件开发大会 2020(北京站)上担任「移动新生态趋势下的应用实践」专题的出品人,感兴趣的读者可以关注。以下为黄刚(腾渊)的观点精华。

  在移动互联网时代,当 Android 和 iOS 奠定了整个移动 OS 的地位后,跨平台研发就一直是一个大的研究方向或者说大的课题。这个话题其实很有意思,因为很多时候大家会有些默认的假设,比较容易忽视这个方向出现或者变热的前提条件。

  从 PC 时代开始,就有一些像 Qt 之类的非常优秀的跨平台软件研发框架。但是我们回过头来看,那个时候面向个人用户的跨平台研发很难说是一个非常热的方向,其中最主要的原因就在于 PC 时代 Windows 的绝对统治地位。假设今天我们在移动互联网上只有一个 OS 占绝对统治地位,那可能今天也不太会有业界同仁在研究跨平台研发这个事情了,这是一个大的前提。

  在移动时代,在 Android、iOS 作为移动 OS 双巨头的格局下,天然就会带来一个重复开发导致移动应用开发成本增大的问题。要开发一个应用,服务端、前端都可以是一套班子,客户端基本需要 Android 和 iOS 两套开发班子,所以不难理解跨平台研发这个话题的起点在于降低研发成本。在这个基本问题下,往下衍生的问题就是多平台的开发增加的额外成本到底是多少,在整个研发生命周期中的占比是多少,跨平台的开发框架能多大程度上解决这个问题?只有这个问题回答清楚了,我们才能明确适合自己的跨平台开发框架应该具备哪些特征,这个跨平台框架在一个 App 应用中的使用范围是多大。

  从早期比较流行的 Hybrid App 到后来的 React Native、Weex,再到现在比较火爆的小程序和 Flutter,可以看到跨平台研发框架变得越来越重。是不是一定越重、越新的框架越好?答案是不一定。

  从应用的 Life Cycle 来看,研发阶段只是其中一个阶段,是否具有长久的可维护性、可运维性也是需要重点考虑的问题。再到研发阶段本身,整个研发是从前端到后端 End-to-End 的,跨平台更多地是集中在大前端领域内的话题,如果在当下的业务形态里,前台展现是高度产品化、比较稳定或者对于性能以及交互的要求极度苛刻的,那么 Cross-Platform First 未必是一个理想的选择。

  一方面是多平台开发工作在整个研发成本里的占比不高,ROI 未必高;另一方面是 Cross-Platform First 是以牺牲平台特性为代价来达到跨平台的一致性(本质上跨平台研发框架也基本无法做到多平台上表现得完全一致性)。在达到一致性表现的过程中,工程上的填坑成本可能更高。

  反过来讲,如果当前的业务情况下,前台的呈现比较不稳定并且整个前台开发占比较高,那么应用跨平台框架的收益就比较高了,在阿里比较典型的例子就是 Weex 在大促会场上的应用。

  我们都应该理解,从 Hybrid 的方案到 React Native、Weex 再到 Flutter,本质上都是在研发成本、灵活性、性能体验三者间找一个平衡点,只是大家切入的点不太一样,最终导致整个解决方案有了不同。假设说现在你要做一个新的 App,可能整个开发团队是多前端、少客户端的,那么我可能会比较建议大家多考虑 Hybrid 的模式;如果对性能要求比较高,就可以考虑用用 Weex 或者 React Native;反过来,如果是客户端同学比较多,那么考虑下 Flutter 未尝不可。其实我们也可以看到,像 Google 同时在推 Flutter 和 Kotlin,这两个东西本质是不一样的,Flutter 更多地体现 Cross-Platform First,Kotlin 更多地体现 Platform First,到底哪个方向更正确,哪个框架更好,其实是没有标准答案的,更多需要开发者因时制宜地进行选择。

  当下阿里用的比较多的应该是 Weex、DinamicX 和小程序这几个框架,在不同场景下解决不同的核心问题。任何框架都不能脱离当时发展的背景讨论,这几个框架是因为在不同阶段解决了当时手淘的一些核心问题,所以才能在各条业务线上广泛应用。

  我们从 2015 年开始做 Weex,2016 年大规模应用。当时我们大促会场页面从研发效率以及发布的灵活性考虑,统一使用的是 H5,但在当时,性能和体验都有些问题。同样,当时手淘上众多的导购业务因为很难接受 H5 的性能与体验,强烈要求使用 Native 做页面开发,这样就又带来了另外一个问题,即 App 的包大小的问题。Weex 在这个背景下诞生,在尽量保留 H5 研发效率以及部署灵活性的前提下,尽量提升页面的性能体验。

  不难想象,在这种情况下,我们整个开发框架必然是面向前端、全面兼容 H5 的研发模式。当然其中 Vue 和 Rax 这样的前端框架也是功不可没的。因为 Weex 的出现,大幅度提高了当时会场页面的性能,而且满足了大部分导购频道对于性能的要求。导购业务在性能基础体验能够满足的情况下,其实很多导购业务还是倾向于更灵活的研发与部署模式,所以当时很多的导购业务还从 Native 转回到了 Weex 进行开发,间接帮助了手淘 App 包大小的控制。

  我们从 2017 年开始做 DinamicX,2018 年大规模应用。这个框架的诞生就要顺着刚才的历史接着往下讲。Weex 解决了原先使用 H5 的业务的性能诉求,但是我们发现 Weex 在一些产品化程度很高的业务域内,依然不能满足性能要求,比如说首页这类一级 Tab 页,所以这种业务基本都还是保留了 Native 的开发模式。

  虽然 Native 的开发模式被保留了下来,但是不意味着这些业务对于开发的平台一致性、研发效率、部署效率没有要求。为了解决这些问题,DinamicX 使用了类似于 Android layout 的声明式布局。相较于 Weex,DinamicX 并没有引入脚本引擎的能力,通过牺牲部分灵活性,来达到性能的极致。通过这样的方式,能够做到在性能基本和 Native 开发持平的情况下,比较灵活地调整页面布局,再通过和我们内部的新奥创研发平台的结合,实现页面布局与业务逻辑的分离。通过这样的方式,DinamicX 这个框架基本解决了我们在基础产品业务域内的研发效率以及性能体验的平衡问题。

  再来讲讲小程序框架,现在我们更多地是使用在了商家应用场景上,核心是为了解决我们在集团多个 App 之间业务快速部署以及外部商家开发的页面快速入驻手淘并且能够得到有效管控的问题。小程序最近比较热,这个点上我就不展开了。

  至于 Flutter,我们内部使用比较深入的是闲鱼的同学。对于跨平台领域的解决方案,我不太秉持只有一个正确答案的想法,对于终极解决方案这个结论我还是比较存疑的,但有一个需要探索的重要方向是可以确定的:决定一个跨平台解决方案的成败有两个重要因素,一个是技术产品化程度,或者说是工程化水平;另外一个是整个开发者生态的构建。如果从这两个因素来看的话,可以明确都还有一段很长的路要走。手淘今年也成立了专门的团队在研究 Flutter 的应用,我们可以拭目以待。

  5G 也是大家非常关注的热点,我们内部的讨论也会比较多。毫无疑问,5G 将能带来一些爆点场景,但是这方面的预测是相当困难的。现在市面上关于 AR/VR 和多媒体应用的畅想理论上都没有什么问题,但是从商业的角度来讲,我们还不知道整个变化对于成本方面的影响,而成本的考量对于应用场景是极其重要的。

  我举个简单的例子,很多 App 在视频自动播放下都有一个设置选项,叫做“Wi-Fi 下自动播放”,绝大多数 App 在使用移动流量播放流媒体之前一般都会给用户弹一个提醒,“当前在用移动流量播放,可能会产生资费”。大家想一想,这个背后的本质是不是就是关于成本的考量。这个限制其实对于整个应用的场景影响是非常大的,正如 4G 的流量费用大幅降低让移动互联网走到了亿万用户手中,5G 的使用成本将极大影响它的使用场景。但是我们依然可以做一个大胆的预测,当 5G 帮助大家极大突破了网络传输速率的束缚后,后面紧接而来的可能是对终端设备算力大幅提升的诉求,最后才创造出一个个崭新的应用场景,这是一个从网络到终端设备到应用场景整体升级的过程。

  我个人最近比较关注 On-Device AI 的应用实践,如果说跨平台解决的是节约研发成本的问题,On-Device AI 的应用是真正会产生业务增量的技术新赛道。过去的一年中,在 On-Device AI 上手淘有了比较大规模的应用,一个典型的场景就是信息流这个商品、内容等的混合智能推荐场景。我们通过更低的资源消耗、更多的数据输入、更实时的感知,在整个信息流场景导购侧有了非常大幅度的提升。过去一年的实践只是一个开端,我们齐头并进的应用场景还包括 AR 美妆、消息 Push、直播等等,这块的想象空间是非常大的。

  在这一篇文章里,我们介绍了跨平台开发的发展趋势和变化,如何选择适合自己的跨平台开发框架?阿里各跨平台开发框架的发展及应用,以及5G 时代给移动领域带来的新机会。未来「淘系技术」将持续与大家分享前端前沿技术和应用实践。

  本账号主体为阿里巴巴淘系技术,淘系技术部隶属于阿里巴巴新零售技术事业群,旗下包含淘宝技术、天猫技术、农村淘宝技术、闲鱼、躺平等团队和业务,是一支是具有商业和技术双重基因的螺旋体。

  我们入驻知乎,将给大家带来超多干货分享,立体化输出我们对于技术和商业的思考与见解。

  你要是在大公司天天用开源项目自己不鼓捣点东西,很快就发现别人都上去了,自己还在原地。

  造 weex 的团队肯定能晋升,第一个把 weex 成功落地的团队也会有大概率晋升。实在是很诱人。(但是这是他们应得的,毕竟有技术实力搞出来)

  同意匿名用户说的,这两个东西功能高度相似,适用场景差不多,必然2选1,不存在分场景。我作为一个面向 stackoverflow 编程的前端,当然选择rn,因为weex遇到坑我找不到人问啊。

  但是如果我还在阿里,就必然先用 weex,上面想推 weex,我怎么会不给面子呢。而且weex的初衷本来就是为了方便阿里,我有内部需求,就直接提给 weex 开发组咯,多方便……

  腾讯和百度的前端那肯定是不能大规模用 weex 的,还是自己造一个比较好。

  阿里造的轮子「多数」都文档奇烂,大抵都是因为写文档的人不是原来那波造轮子的人,甚至是实习生或者新人写的文档……(别问我当新人的时候有没有给公司的轮子写文档~)

  RN用的溜的都不会觉得Weex好,我在用过本木团队开源的基于weex封装的eros后,再让我回去写RN,回不去了。能写一套为什么要写两套甚至三套代码?建议想了解weex的从eros了解起,而不是官方文档,阿里的文档写的和屎一样,所以阿里才要出个java手册,前端烂点没关系,后端怎么也不能烂成屎啊!

  产自 阿里,第一个 DSL 是 Vue,去年 Weex Conf 上对外开源了用 React 作为 DSL 的 Rax。在一群工程师的手下承接了至少两个千亿项目(双11),坑很多,但终归能踩过去。

  产自 Facebook,算是这种形式 Native 化的鼻祖,Weex 中的布局引擎也基本是用了从 ReactNative 中衍生出来的Yoga。相比于 Weex,社区资源丰富,遇到问题非常容易找到解决答案。而用 react-native-cli 零成本造出一个 App 更是让纯前端开发者喜欢。

  如果你的业务场景需要的 远程在线加载很多页面(bundle),团队里有 iOS、Android 开发者坐阵,或许 Weex 也是一个非常不错的选择。

  Weex的两个最重要的核心开发,勾股和鬼道在weex得到老板认可,并强推到集团各业务线并且晋升完之后,立马走人了。能升两个前端高p,我觉得 weex 强,rn 拿过来就用,没那么多技术难题要解决,体现不出技术水平,要 rn 何用

  我是一点不信任国内的开源项目,用他们的项目你就要做好心理准备把代码全看一遍然后自己维护。在我看来国内公司开源项目的初衷大部分都是很龌龊,很自私,又不负责任。

  估计要伤害一堆玻璃心,甚至误伤一些娃,你可以不同意,不过做为一个写了十几年代码的老码农,被坑的次数太多,现在看法已然这样了。如果我没做好深研究他们代码的心理准备,我宁可自己写一套也不想用他们的。

  你就说最近吧,阿里的ant-moble从2.2.0开始把对react native的支持说去就去掉了,坑了多少用ant-mobile开发app的 ,weex呢,前面有人说了天猫员工自己都讨厌用,之前捐献给apache基金会我咋觉得是扔烂摊子呢……