$reactnative weex

2018-08-10 11:56:42 MakerCloud 阅读数 7390
  • React NativeWeex开发对比及概述

    React NativeWeex开发对比及概述   React Native--概述及与WeexNative开发的对比(一) https://www.jianshu.com/p/613c1e8611e9  青苹果园 关注 2018.05.23 12:19* 字数 967 阅读 8156评论 4喜欢 11 ...

    280人学习
    免费试看

跨平台一直是老生常谈的话题,cordova、ionic、react-native、weex、kotlin-native、flutter等跨平台框架的百花齐放,颇有一股推倒原生开发者的势头。本文将对当下跨平台移动开发的现状、实现原理、框架的选择等进行深度解析。
为什么我们需要跨平台开发? 本质上,跨平台开发是为了增加代码复用,减少开发者对多个平台差异适配的工作量,降低开发成本,提高业务专注的同时,提供比web更好的体验。通俗了说就是:省钱、偷懒。
本篇主要以react-native、weex、flutter,结合资讯展望,深入聊聊当前跨平台移动开发的实现原理、现状与未来。至于为什么只讲它们,因为对比ionic、phoneGap,它们更于 “naive”。
这里写图片描述

一、原理与特性

目前移动端跨平台开发中,大致归纳为以下几种情况:
• react native、weex均使用Java作为编程语言,目前Java在跨平台开发中,可谓占据半壁江山,大有“一统天下”的趋势。
• kotlin-native开始支持 iOS 和 Web 开发,(kotlin已经成为android的一级语言)也想尝试“一统天下”。
• flutter是Google跨平台移动UI框架,Dart作为谷歌的亲儿子,毫无疑问Dart成为flutter的编程语言,如下图,作为巨头新生儿,在flutter官网也可以看出,flutter同样“心怀天下”。

1、React Native

Facebook 出品,Java语言,JSCore引擎,React设计模式,原生渲染

1.1、理念架构

“Learn once, write anywhere”,代表着 Facebook对 react native 的定义:学习 react ,同时掌握web与app两种开发技能。 react native 用了 react 的设计模式,但UI渲染、动画效果、网络请求等均由原生端实现。开发者编写的js代码,通过 react native 的中间层转化为原生控件和操作,比ionic等跨平台应用,大大提高了的用户体验。
总结起来其实就是利用 JS 来调用 Native 端的组件,从而实现相应的功能。
如下图所示,react native 的跨平台是实现主要由三层构成,其中 C++ 实现的动态连结库(.so),作为中间适配层桥接,实现了js端与原生端的双向通信交互。这里最主要是封装了JavaCore执行js的解析,而 react native 运行在JavaCore中,所以不存在浏览器兼容的问题。
其中在IOS上直接使用内置的javacore, 在Android 则使用webkit.org官方开源的jsc.so。
这里写图片描述

1.2、实现原理

和前端开发不同,react native 所有的标签都不是真实控件,JS代码中所写控件的作用,类似 Map 中的 key 值。JS端通过这个 key 组合的 Dom ,最后Native端会解析这个 Dom ,得到对应的Native控件渲染,如 Android 中标签对应ViewGroup 控件。
这里写图片描述
在 react native 中,JS端是运行在独立的线程中(称为JS Thread )。JS Thread 作为单线程逻辑,不可能处理耗时的操作。那么如fetch 、图片加载、数据持久化等操作,在 Android 中实际对应的是okhttp 、Fresco 、SharedPreferences等。而跨线程通信,也意味着 Js Thread 和原生之间交互与通讯是异步的。
可以看出,跨平台的关键在于C++层,开发人员大部分时候,只专注于JS 端的代码实现。 在原生端提供的各种 Native Module 模块(如网络请求,ViewGroup控件),和 JS 端提供的各种 JS Module(如JS EventEmiter模块),都会在C++实现的so中保存起来,双方的通讯通过C++中的保存的映射,最终实现两端的交互。通信的数据和指令,在中间层会被转为String字符串传输,双向的调用流程如下图。
这里写图片描述
这里写图片描述

1.3、打包加载

最终,JS代码会被打包成一个 bundle 文件,自动添加到 App 的资源目录下。react native 的打包脚本目录为/node_modules/react-native/local-cli,打包最后会通过 metro 模块压缩 bundle 文件。而bundle文件只会打包js代码,自然不会包含图片等静态资源,所以打包后的静态资源,其实是被拷贝到对应的平台资源文件夹中。
其中图片等存在资源的映射规则,比如放在 react native 项目根目录下的 img/pic/logo.png 的资源,编译时,会被重命名后,根据大小 merged 到对应的是drawable目录下,修改名称为img_pic_logo.png。
打包Android和IOS,肯定需要相应的平台项目存在,在 react-native init 时创建的项目,就已经包含了 android 和 ios 的模版工程,打包完的工程会加载bundle文件,然后启动项目,如下图。这里就不展(tou)开(lan)了,有兴趣的可以看:React Native For Android 架构初探 。
这里写图片描述

2、WEEX

Alibaba 出品,Java语言,JS V8引擎,Vue设计模式,原生渲染

2.1、理念架构

“Write once, run everywhere”, weex的定义就像是:写个 vue 前端,顺便帮你编译成性能还不错的 apk 和 ipa(当然,现实有时很骨感)。基于 Vue 设计模式,支持 web、android、ios 三端,原生端同样通过中间层转化,将控件和操作转化为原生逻辑来提高用户体验。
在 weex 中,主要包括三大部分:JS Bridge、Render、Dom,分别对应WXBridgeManager、WXRenderManager、WXDomManager,三部分通过WXSDKManager统一管理。其中 JS Bridge 和 Dom 都运行在独立的 HandlerThread 中,而 Render 运行在 UI 线程。
JS Bridge 主要用来和 JS 端实现进行双向通信,比如把 JS 端的 dom 结构传递给 Dom 线程。Dom 主要是用于负责 dom 的解析、映射、添加等等的操作,最后通知UI线程更新。而 Render 负责在UI线程中对 dom 实现渲染。
这里写图片描述

2.2、实现原理

和 react native一样,weex 所有的标签也不是真实控件,JS 代码中所生成存的 dom,最后都是由 Native 端解析,再得到对应的Native控件渲染,如 Android 中标签对应WXTextView控件。
weex 中文件默认为 .vue ,而 vue 文件是被无法直接运行的,所以 vue 会被编译成 .js 格式的文件,Weex SDK会负责加载渲染这个js文件。Weex可以做到跨三端的原理在于:在开发过程中,代码模式、编译过程、模板组件、数据绑定、生命周期等上层语法是一致的。不同的是在JS Framework层的最后,web 平台和 Native 平台,对 Virtual DOM 执行的解析方法是有区别的。
这里写图片描述
实际上,在 Native 中对 bundle 文件的加载大致经历以下阶段:
• weex 接收到 js 文件以后,JS Framework 根据文件为 Vue 模式,会调用weex-vue-framework中提供的createInstance方法创建实例。
• createInstance中会执行 Js Entry 代码里new Vue()创建一个组件,通过其 render 函数创建出 Virtual DOM 节点。
• 由JS V8 引擎上解析 Virtual DOM ,得到 Json 数据发送至 Dom 线,这里输出 Json 也是方便跨端的数据传输。
• Dom 线程解析 Json 数据,得到对应的WxDomObject,然后创建对应的WxComponent提交 Render 。
• Render在原生端最终处理处理渲染任务,并回调里JS方法。
得益于上层的统一性,只是通过weex-vue-framework判断是由Vue.js生成真实的 Dom ,还是通过 Native Api 渲染组件,weex 一定程度上上,用JS 实现了vue一统天下的效果。
这里写图片描述
weex 在原生渲染 Render 时,在接收到渲染指令后,会逐步将数据渲染成原生组件。Render 通过解析渲染数据的描述,然后分发给不同的模块。
比如 控件渲染属于dom模块中,页面跳转属于navigator模块等。模块的渲染过程并非一个执行完,再执行另一个的流程,而是类似流式的过程。如上一个的组件还没渲染好,下一个

的渲染又发了过来。这样当一个组件的嵌套组件很多时,或者可以看到这个大组件内的UI,一个一个渲染出来的过程。
承当了重要的职责,使得上层具备统一性,可以支持跨三个平台。总的来说它主要负责是:管理Weex的生命周期;解析JS Bundle,转为Virtual DOM,再通过所在平台不同的API方法,构建页面;进行双向的数据交互和响应。
这里写图片描述

2.3、打包

weex 作为 react-native 之后出现的跨平台实现方案,自然可以站在前人的肩膀上优化问题,比如:Bundle文件过大问题。
Bundle文件的大小,很大程度上影响了框架的性能,而 weex 选择将JS Framework集成到 WeexSDK 中,一定程度减少了JS Bundle的体积,使得 bundle 里面只保留业务代码。
打包时,weex 是通过 webpack 打包出 bundle 文件的。bundle 文件的打包和 entry.js文件的配置数量有关,默认情况下之后一个 entry 文件,自然也就只有一个bundle文件。
在 weex 项目的 webpack.common.conf.js中可以看到,其实打包也是区分了 webConfig和weexConfig的不同打包方式。如下图,其中weexEntry 就是 weex 打包配置的地方,可以看到本来已经有index和 entry.js存在了。如果有需要,可配置上你需要的打包页面,具体这里就不详细展开了。有兴趣可看:Weex原理之带你去蹲坑 。
这里写图片描述

3、Flutter

Google 出品,Dart语言,Flutter Engine引擎,响应式设计模式,原生渲染
Flutter 是谷歌2018年发布的跨平台移动UI框架。相较于本人已经在项目中使用过 react native 和 Weex,Flutter目前仅仅是简单运行过Demo,毕竟还是beta 阶段,这里更多的聊一下它的实现机制和效果。
与 react native 和 weex 的通过 Java 开发不同,Flutter 的编程语言是Drat,(谷歌亲儿子,据说是因为 Drat 项目组就在 Flutter 隔壁而被选上( ))所以执行时并不需要 Java 引擎,但实际效果最终也通过原生渲染。
这里写图片描述
如上图,Flutter 主要分为Framework和Engine,我们基于Framework 开发App,运行在 Engine 上。Engine 是 Flutter 的独立虚拟机,由它适配和提供跨平台支持,目前猜测 Flutter 应用程序在 Android 上,是直接运行 Engine 上 所以在是不需要Dalvik虚拟机。(这是比kotlin更彻底,抛弃JVM的纠缠?)
如下图,得益于 Engine 层,Flutter 甚至不使用移动平台的原生控件, 而是使用自己 Engine 来绘制 Widget (Flutter的显示单元),而 Dart 代码都是通过 AOT 编译为平台的原生代码,所以 Flutter 可以 直接与平台通信,不需要JS引擎的桥接。同时 Flutter 唯一要求系统提供的是 canvas,以实现UI的绘制。咦?这么想来,支持web端也没问题吧!
这里写图片描述
在Flutter中,大多数东西都是widget,而widget是不可变的,仅支持一帧,并且在每一帧上不会直接更新,要更新而必须使用Widget的状态。无状态和有状态 widget 的核心特性是相同的,每一帧它们都会重新构建,有一个State对象,它可以跨帧存储状态数据并恢复它。
Flutter 上 Android 自带了 Skia,Skia是一个 2D的绘图引擎库,跨平台,所以可以被嵌入到 Flutter的 iOS SDK中,也使得 Flutter Android SDK要比 iOS SDK小很多。

二、对比

这算是互相伤害的环节了吧。
这里写图片描述

1、大小

上面Apk大小是通过react-native init、weex create 和 flutter 创建出的工程后,直接不添加任何代码,打包出来的 release 签名 apk 大小。从下图可以看出,其中大比例都是在so库。
这里写图片描述

2、社群

react native 作为 Facebook 主力开源项目之一,至今已有各类丰富的第三方库,甚至如realm、lottie 等开源项目也有 react native 相关的版本,社群实际无需质疑。当然,因为并完全正统开发平台,第三库的健壮性和兼容性有时候总是良莠不齐。
weex 其实有种生错在国内的感觉。其实 weex 的设计和理念都很优秀,性能也不错,但是对比 react native 的第三方支持,就显得有点后妈养的。2016年开源至今,社区和各类文档都显得有点疲弱,作为跨平台开发人员,大多时候肯定不会希望,需要频繁的自己增加原生功能支持,因为这样的工作一多,反而会与跨平台开发的理念背道而驰,带来开发成本被维护难度增加。
Flutter目前还处理beta阶段,但是谷歌的号召力一直很可观,这一点无需质疑。

3、性能

理论上 flutter 的性能应该是最好的,但是目前实际体验中,却并没有感受出来太大的差距,和 react native(0.5.0之后)、weex 在性能上个人体验差异不是很大。当然,这里并没有实测渲染的毫秒时间和帧率数据。

4、其他区别

Weex的多页面实现问题

weex 在 native 端是不支持keep-alive的,这一点和 react-native 不同在与,如果在 native
需要实现页面跳转,使用 vue-router 将会惨不忍睹:返回后页面不做特别处理时,是会空白一片。参考官方Demo playground
,native 端 的采用weex.requireModule(‘navigator’)跳转 Activity 是才正确实现。
同时,weex中 navigator
跳转的设计,也导致了多页面的页面间通讯的差异。weex在多页面下的数据通讯,是通过url实现的,比如file://assets/dist/SecondPage.js
params=0,而vuex和vue-router在跨页面是无法共用的;而 react native 在跨 Actvity
使用时,因为是同一个bundle文件,只要 manager 相同,那么 router 和 store 时可以照样使用的,数据通信方式也和当个
Actvity 没区别。

项目模板

weex 和 react native 模板代码模式也不同。weex 的模板是从 cordova
模式修改过来的,根据platform需求,用命令添加固定模块,而在 .gitignore 对 platforms文件夹是忽略跟踪。
react native 在项目创建时模版就存在了,特别是添加第三方插件原生端支持时,会直接修改模板代码,git代码中也会添加跟踪修改。

三、未来趋势

我们选择框架的时候,很多时候会关注框架的成熟度和生命力不是么。

1、React Native

“Airbnb 宣布放弃使用 React Native,回归使用原生技术” : Airbnb 作为 react native 平台上最大的支持者之一,其开源的lottie同样是支持原生和 react native。
Airbnb 在宣布放弃的文中,也对 react native 的表示了很大量的肯定,而使得他们放弃的理由,其实主要还是集中于项目庞大之后的维护困难,第三方库的良莠不齐,兼容上需要耗费更多的精力导致放弃。
ps:( Lottie库Airbnb出的是一个能够帮助解析AE导出的包含动画信息的json文件。这很好的解决了一个矛盾,设计师可以更专注的设计出各种炫酷的动画效果,而开发只需要将其加入支持即可。)
Facebook 正在重构 React Native,将重写大量底层。 在经历了开源协议风波后,可以看出 Facebook 对于 react native 还是很看重的, 这些底层重构优化的地方,主要集中于:
首先,改变线程模型。UI 更新不再需要在三个不同的线程上执行,而是可以在任意线程上同步调用 Java 进行优先更新,同时将低优先级工作推出主线程,以便保持对 UI 的响应。其次,将异步渲染功能引入 React Native 中,允许执行多个渲染并简化异步数据处理。最后,简化桥接,让它更快、更轻量。原生和 Java 之间的直接调用效率更高,并且可以更轻松地构建调试工具,如跨语言堆栈跟踪。

2、Weex

没有死!阿里公开Weex技术架构,还开源了一大波组件。 从 2018年初的新闻可以看出,weex 的遭遇有点类似曾经的 Duddo(Dubbo因为内部竞争被阿里一度放弃维护),这波诈尸后weex被托管到了Apache,而github的weexteam 如今也还保持着更新,希望后续能有多好的发展,拭目以待吧。

3、Flutter

Flutter 是 Google 跨平台移动UI框架,Dart作为谷歌的亲儿子在 Flutter 中使用,并且谷歌新操作系统 Fuchsia 支持 Dart,使用 Flutter 作为操作UI框架。这些集合到一起难免让你怀疑 Android 是否要被谷歌抛弃的想法。
或者如今先 Android 等平台上推广 Flutter 与 Dart,就是为了以后跟好的过渡到新系统上,毕竟开发者是操作系统的生命源泉之一。而 Java 与 JVM 或者可以被谷歌完全抛开。当然,目前看起来 Flutter 貌似还缺少一些语法糖,嵌套下来的代码有点不忍直视,或者到正式版之后,我们更能感受出它的美丽吧。


转载自:http://www.cnblogs.com/androidga/p/9294466.html

2017-09-29 18:15:43 u011413061 阅读数 440
  • React NativeWeex开发对比及概述

    React NativeWeex开发对比及概述   React Native--概述及与WeexNative开发的对比(一) https://www.jianshu.com/p/613c1e8611e9  青苹果园 关注 2018.05.23 12:19* 字数 967 阅读 8156评论 4喜欢 11 ...

    280人学习
    免费试看

“Write once,Run Everywhere” 一次编写,多端运行。React迁移到MIT协议,可惜React Native依然没改,没有RN的日子,还好有Weex这位哥们顶着。虽然没有RN那么牛逼,但也算是一个不错的小兄弟。

很多人可能要问我搞了这么久的RN现在转Weex干什么?说起来,真是一个悲伤的故事

为什么不用RN

Facebook并没有像React那样把ReactNative也迁移到MIT协议,所以使用ReactNative开发对外产品,依然有专利风险。一般的公司其实没什么影响,但我厂情况比较特殊,有好几个核心的专利技术,老板不想冒这个险。加之隔壁的阿里Weex推得很火,那就用用看吧!

React专利许可证具体细节欢迎出门左转看我之前的文章:《React专利许可证研究》

WeexRN的优势

说老实话,和ReactNative打交道这么久,突然换一个小兄弟上,一时还真的难以适应,甚至一脸嫌弃。WeexReactNative的设计理念也完全不同。RN重点在Native,以React的方式开发跨平台App,它注重Native细腻的用户体验和强大的原生功能,运用 ReactNative 甚至不需要Native工程师就能独立开发一款功能完善的App

Web开发体验

独立开发AppWeex来说比较困难,因为它的Native能力没有RN那般强大而全面。它更注重 Web开发体验,顾名思义就是像开发Web网页一样开发跨平台App页面,注意了是以Web为主导,所以它的设计理念提倡 轻量 + 可拓展(至于“高性能”较RN并没什么太大的体现),官方也推荐用WeexNative混合的方式开发App,也就是把Weex作为一个组件融入到Native App,替换传统的 Hybrid 模式。

没有专利限制

Weex已经加入ASF,没有ReactNative 的专利协议限制,可以放心大胆地使用。当然有童鞋会反问 Weex目前还在使用 FaceBookYoga引擎,会不会有隐患?这个短期内不需要我们操心,首先这个问题本身边缘就很模糊,其次 像阿里这样的大厂迟早会开发一套类似的引擎来替代,时间问题。

三端共用代码

Weex既保留了H5的灵活性,也赋予了其Native能力,通过JavaSriptCore+JSbridge直接和Native进行通信,较之 HybridWebView + URLScheme方式性能好了很多。甚至可以实现传说中的 “三端融合”——也就是 WebiOSAndroid端的前端部分共用一套代码,省去了独立建站和维护的麻烦。

当然有得必有失,三端兼容的坑也不少,Android各机型 hack 就不提了,Web端其实就是个WebApp,要利用浏览器的BOM与三方的JS-SDK 来完成 DOMHTTP以外的功能。不过使用Weex内建的标签和样式可以很容易实现三端布局样式和基本行为的一致,还是大大地减少了工作量。

值得一提 Weex的布局单位有且只有px,默认的显示宽度 (viewport) 是 750px,组件都会以 750px 作为满屏宽度,但可以通过 meta.setViewport() 手动指定页面的显示宽度

Type iPhone4 iPhoneSE iPhone8 iPhone8P iPhoneX
物理像素 640x960 640x1136 750x1334 1080x1920 1125x2436
显示像素 750x1125 750x1331 750x1334 750x1333 750x1624
像素比 @0.85x @0.85x @1x @1.44x @1.5x

CSS3的支持

Weex虽然也对CSS做了一定的阉割,但比较 ReactNative,它保留得更多,甚至支持大量的CSS3特性,这一点值得赞叹。CSS3作为Web开发的利器,放着不用难免可惜。下面列举Weex 和标准Web的样式差异:

  • 支持的CSS3特性包括:FlexBox、2D转换、过渡、线性渐变、阴影(仅WebiOS)、伪类、自定义字体(iconFront图标也能用哦)
  • 中支持单个 类名选择器,不支持 关系型选择器,也不支持 属性选择器
  • 支持组件级别的作用域,为了保持WebNative的一致,需要 <style scoped> 声明作用域
  • 不支持CSS3动画(动画请使用Weex内建animation模块)和3D转换
  • 不支持 display: none ,用模板语法 v-if 替代,不建议用 opacity: 0Native里有点透问题)
  • 类似RN,为了提高解析效率,Weex样式属性不支持简写,比如 fontbordertransfrom不能简写

Weex不足之处

本节的最后,还是想吐槽几个Weex的不足之处,希望官方能尽快升级和改进:

社区建设缓慢

这应该是最要命的,Weex社区从去年开源到今天还是这般冷清不免令人神伤,虽然我知道阿里内部推广力度很大,但是既然选择开源,就应该跳出阿里的圈子,一些成功案例、成熟解决方案、优秀架构设计等就不应该藏着掖着,不然真的很难推广起来。我不希望遇到坑点 Google 几圈都找不到有价值的方案,GitHub上提问半天都等不到一个满意的答案(哈哈,说得有点激动啊,很感谢 mario 上次回答我的提问,希望能尽快反应到官方文档里)

Native能力提高

如果不提高Native能力,Weex全页模式 价值其实不大。不要求面面俱到,但希望能再添加一些常用的,比如:statusBar控制、位置信息、Android动态权限分配等

真机调试工具升级

Weex提倡Web开发体验,所以开发和调试都以Web为主,做静态页面还好,但我要调试Native端的特有逻辑,就需要在Native端集成weex-devtool。这个方案的确另辟蹊径,不过每次改完代码需要手动刷新会不会太麻烦,能不能搞个类似RN的 热替换LiveReload功能呢?

Mac端文件权限问题

在Mac端Shell工具进入Weex的目录,无论npm相关命令,还是git操作都需要sudo权限,好麻烦。我很懒的,Weex在创建文件的时候能不能帮我把写权限的事也做了?


哈哈,是不是我太蠢没能领悟到技巧,不对的地方欢迎留言指正哈。不过前端工程师都是挑剔的,希望Weex能不断改进和完善!

2018-07-27 15:34:33 liuyingv8 阅读数 982
  • React NativeWeex开发对比及概述

    React NativeWeex开发对比及概述   React Native--概述及与WeexNative开发的对比(一) https://www.jianshu.com/p/613c1e8611e9  青苹果园 关注 2018.05.23 12:19* 字数 967 阅读 8156评论 4喜欢 11 ...

    280人学习
    免费试看

一句话概要

Native、Web App、Hybrid、React Native(后面以RN简称)、Weex 间的异同点,后期同步小程序 和 PWA。

App常用开发模式简介

此处App为应用,application,并非我们通常讲的手机App。

常用的几种APP开发模式-脑图:http://naotu.baidu.com/file/6af15fcbb72f89926043779811b1ea44?token=df0378691ecdcef2

Native App

传统的原生App开发模式,有iOS和aOS两大系统,需要各自语言开发各自App。

优点:性能和体验都是最好的。

缺点:开发和发布成本高。

举个栗子:网易管家App (https://id.163.com/gj/)

应用技术:Swift,OC,Java。

WebApp

移动端的网站,常被称为H5应用,说白了就是特定运行在移动端浏览器上的网站应用。一般泛指 SPA(Single Page Application)模式开发出的网站,与MPA(Multi-page Application)对应。

优点:开发和发布成本最低。

缺点:性能和体验不能讲是最差的,但也受到浏览器处理能力的限制,多次下载同样会占用用户一定的流量。

举个栗子:网易管家APP(https://id.163.com/gj/)

应用技术:ReactJS,RegularJS,VueJS等等。

Hybrid App

混合模式移动应用,介于Web App、Native App这两者之间的App开发技术,兼具“Native App良好交互体验的优势”和“Web App跨平台开发的优势”(百度百科解释)

主要的原理是,由Native通过JSBridge等方法提供统一的API,然后用Html+Css实现界面,JS来写逻辑,调用API,最终的页面在Webview中显示,这种模式下,Android、iOS的API一般有一致性,Hybrid App所以有跨平台效果。

优点:开发和发布都比较方便,效率介于Native App、Web App之间。

缺点:学习范围较广,需要原生配合。

举个栗子:FanReact,我爱我家App,东方航空App,富国基金-富国钱包App

应用技术:PhoneGap,AppCan,Wex5,APICloud等。

React Native App

Facebook发现Hybrid App存在很多缺陷和不足,于是发起开源的一套新的App开发方案RN。使用JSX语言写原生界面,js通过JSBridge调用原生API渲染UI交互通信。

优点:效率体验接近Native App,发布和开发成本低于Native App。

缺点:学习有一定成本,且文档较少,免不了踩坑。

举个栗子:Facebook、Youtube、Discord、QQ、百度等等。

Weex App

阿里巴巴开发团队在RN的成功案例上,重新设计出的一套开发模式,站在了巨人肩膀上并有淘宝团队项目做养料,广受关注,2016年4月正式开源,并在v2.0版本官方支持Vue.js,与RN分庭抗礼。

优点:单页开发模式效率极高,热更新发包体积小,并且跨平台性更强。

缺点:刚刚起步,文档欠缺;社区没有RN活跃,功能尚不健全,暂不适合完全使用Weex开发App。

举个栗子:淘宝、天猫、阿里云、优酷、闲鱼、饿了么等。

Native App

Native App是一种基于智能手机本地操作系统如iOS、Android、WP并使用原生程式编写运行的第三方应用程序,也叫本地app。一般使用的开发语言为Java、C++、Objective-C。

自iOS和Android这两个的手机操作系统发布以来,在互联网界从此就多了一个新的名词:App意为运行在智能的移动终端设备第三方应用程序。

Native App因为位于平台层上方,向下访问和兼容的能力会比较好一些,可以支持在线或离线,消息推送或本地资源访问,摄像拨号功能的调取。但是由于设备碎片化,App的开发成本要高很多,维持多个版本的更新升级比较麻烦,用户的安装门槛也比较高。但是比较乐观的是,AppStore培养了一种比较好的用户付费模式,所以在Apple的生态圈里,开发者的盈利模式是一种明朗状态,其他market也在往这条路上靠拢。

优势

 

  • 相比于其它模式,提供最佳的用户体验,最优质的用户界面,最华丽的交互

  • 针对不同平台提供不同体验

  • 可节省带宽成本,打开速度更快

  • 功能最为强大,特别是在与系统交互中,几乎所有功能都能实现

 

劣势

 

  • 门槛高,原生开发人才稀缺,至少比前端和后端少,开发环境昂贵

  • 无法跨平台,开发的成本比较大,各个系统独立开发

  • 发布成本高,需要通过store或market的审核,导致更新缓慢

  • 维持多个版本、多个系统的成本比较高,而且必须做兼容

  • 应用市场逐渐饱和,怎么样抢占用户时间需要投入大量时间和金钱,这也导致“僵尸”App的增多

 

WebApp

说到Web App 不少人会联想到 WAP,或者有人认为,WAP就是WebApp,其实不然。

WebApp 与 WAP 最直接的区别就是功能层面。WAP更侧重使用网页技术在移动端做展示,包括文字、媒体文件等。而Web App更侧重“功能”,是使用网页技术实现的App。总的来说,Web App就是运行于网络和标准浏览器上,基于网页技术开发实现特定功能的应用。

响应式的大部分技术都是为实现WebApp能适配多类客户端而设计的。

Web网站一般分两种,MPA(Multi-page Application)和SPA(Single-page Application)。而WebApp一般泛指SPA形式开发出的网站。这样更像是一个App。

优势

 

  • 可以跨平台,调试方便

  • 无需安装,不会占用手机内存,而且更新速度最快

  • 不存在多版本问题,维护成本低

  • 临时入口,可以随意嵌入

 

劣势

 

  • 依赖于网络,第一次访问页面速度慢,耗费流量

  • 受限于手机和浏览器性能,用户体验相较于其他模式最差

  • 功能受限,大量移动端功能无法实现

  • 入口强依赖于第三方浏览器,且只能以URL地址的形式存在,导致用户留存率低(优点即缺点)

 

Hybird App

混合开发,也就是半原生半Web的开发模式,由原生提供统一的API给JS调用,实际的主要逻辑有Html和JS来完成,最终是放在webview中显示的,所以只需要写一套代码即可达到跨平台效果,另外也可以直接在浏览器中调试,很方便。最重要的是只需要一个前端人员稍微学习下JS api的调用即可。

Hybird App 的较早实践者是PhoneGap,随后遍地开花,如Titanium、Salama、WeX5、Kerkee和国内的AppCan,项目各有各的实现方式,大致的原理基本相同。有幸在AppCan上海总部参与过一段时间的学习研究,如下大致简介:

AppCan是基于HTML5技术的Hybird跨平台移动应用开发工具。开发者利用Html5+Css3+JavaScript技术,通过AppCan IDE集成开发系统、云端打包器等,快速开发出Android、iOS、WP平台上的移动应用。

AppCan的平台构成:

在实际的APP开发中,AppCan可以完成大部分的工作量,如图示:

AppCan将App底层复杂的原生功能封装在引擎、插件中,开发者仅需调用接口、打包编译,就可以获得原生功能;灵活的插件扩展机制。

开发者可以像开发WebApp一样开发app的视觉UI,以及绝大部分的交互,当需要使用原生功能(如摄像头,陀螺仪等功能)时,只需要调用官方的API就可以轻松实现Native的效果。至于JS和Native的通信,常用的有URL监听和绝大部分Hybrid厂商使用的JSBridge通信,两者原理相近。

关于JsBridge的原理详解,可见http://blog.csdn.net/xiangzhihong8/article/details/66970600

在Hybird概念盛行的时候,国内外各大公司也参与了探索,国外代表有Facebook、google、亚马逊,国内的有腾讯、阿里巴巴、网易等,慢慢的他们发现Hybird严重受限于WebView的解析渲染效率,于是Facebook开始了他的类原生的研究探索。

React Native App

请移驾:【笔记】React Native 快速入门笔记(https://segmentfault.com/a/1190000010989345)。

Weex App

请移驾:网易严选App感受Weex开发(https://segmentfault.com/a/1190000011027225)。

 

编辑:千锋HTML5

来源:zwwill_木羽

2017-10-02 15:30:59 chaunceyw 阅读数 10494
  • React NativeWeex开发对比及概述

    React NativeWeex开发对比及概述   React Native--概述及与WeexNative开发的对比(一) https://www.jianshu.com/p/613c1e8611e9  青苹果园 关注 2018.05.23 12:19* 字数 967 阅读 8156评论 4喜欢 11 ...

    280人学习
    免费试看

摘要: # 前言 weex的思想是多个平台,只写一套代码,而react-native的思想是多个平台可以写多套代码,但其使用的是同一套语言框架。 weex的目标在于抹平各个平台的差异性,从而简化应用开发。而react-native承认了各个平台之间的差异,退而求其次,在语言和框架层面对平台进行抽象,从方法论的角度去解决多平台开发的问题。 进一步浏览weex和react-native的代码之后,可

前言

weex的思想是多个平台,只写一套代码,而react-native的思想是多个平台可以写多套代码,但其使用的是同一套语言框架。
weex的目标在于抹平各个平台的差异性,从而简化应用开发。而react-native承认了各个平台之间的差异,退而求其次,在语言和框架层面对平台进行抽象,从方法论的角度去解决多平台开发的问题。

进一步浏览weex和react-native的代码之后,可以得出如下的公式。

weex = Vue.js + H5/Native
react-native = React + Native

总的来说,其差异性如下表格所示。

dimension weex react-native
js framework Vue.js React
principle write once, run anywhere learn once, write anywhere

个人观点,weex和react-native最核心的区别就是这两个。然而就只这两个维度的同步,导致了weex和react-native完全不一样的发展方向。

Vue.js vs React

维度 Vue.js React
定位 UI框架 UI框架
目标平台 Web 多平台
架构 MVVM React
数据流 数据绑定 单向数据流动
组件系统
响应式
开发语言 html/css/js all in js
flexbox 支持 支持
外围框架 能和其他js框架整合使用 能和其他js框架整合使用
渲染机制 real DOM Virtual DOM
动画 支持 支持
级别 轻量级 重量级

weex vs react-native

维度 weex react-native
思想 write once, run anywhere learn once, write anywhere
试用场景 简单明了 难易双修
扩展 为了保证各平台的一致性,一次扩展得在各个平台都实现 不同平台可自由扩展
社区 内测开源 15年3月开源,社区非常活跃
支持 alibaba支持 facebook支持
组件丰富程度 基本只有自带的10余种 除了自带的,还有js.coach上社区贡献的,还是比较丰富的
上手难度 容易 困难
调式 暂时log调试 有专门的调试工具,chrome调试,较为完善
IDE 文本编辑器 Nuclide/文本编辑器

Vue.js

Vue.js虽然是Evan You个人开发的开源项目,其社区活跃度以及代码质量还是值得一提的。在写此文章之际,Vue.js在Github上的Star达到了21099,Fork达到了2186。虽然相比于react的Star数44108,Fork数7610还有一定距离,但考虑到作为个人开发者能有如此多的人关注参与,该框架的优秀程度恐怕不会低于React。

Vue.js的文档资料非常齐全,而且其本身的设计非常简洁,因此绝大部分开发者只要花费少量的时间就能快速上手Vue.js。其中VUE.JS: A (RE)INTRODUCTION是 Vue.js的作者Evan You对Vue.js的介绍,非常值得一看。我想这可能也是weex团队选择Vue.js入手的原因之一吧。对Vue.js有兴趣的同学可以移步Vue.js Guide自行学习。

Vue.js用来构建交互式web界面的,其主要的关注点和React是一样的,都是立足于View层。
Vue.js最核心的部分是两个Reactive Data Binding以及Composable View Components。还值得特别关注的是,其保留了html、css、js分离的写法,使得现有的前端开发者在开发的时候能保持原有的习惯。

响应式数据绑定

Vue.js将界面开发分成了三个部分,分别是View、ViewModel和Model,这种划分在客户端开发看来是非常合理的,也经过了实际的检验。以HelloWorld为例来说明,示例来源Vue.js Guide

<!-- this is our View -->
<div id="example-1">
  Hello {{ name }}!
</div>

<!-- this is our Model -->
var exampleData = {
  name: 'Vue.js'
}

<!-- this is our ViewModel -->
var exampleVM = new Vue({
  el: '#example-1',
  data: exampleData
})

这就是经典的MVVM模式,Vue.js通过极简的API,将数据和视图绑定在一起,也就是所谓的Data-Binding。
这样,当数据变化的时候,界面就能变化,实现了数据驱动的响应式变成。

组件化

当我们在写网页的时候,本质上就是构造DOM树,DOM树则是由div、span等元素组成的。div、span这样的元素是构建大型应用的基础。其实Vue.js或者其他的UI框架基本也是一样的,他们都会提供自己的组件系统。这些组件就类似div元素,一般具有一下特征:

  • 小巧精致
  • 能重用
  • 自包含,高内聚

当我们使用Vue.js开发应用的时候,就是搭建特定的组件树。这些组件可以是Vue.js定义的,也可以是开发者自己定义的,这非常重要。

看个组件化的例子。

// example组件定义
var Example = Vue.extend({
  template: '<div>{{ message }}</div>',
  data: function () {
    return {
      message: 'Hello Vue.js!'
    }
  }
})

// register it with the tag <example>
Vue.component('example', Example)

// example组件使用
<example></example>

组件间数据传递

Vue.js的组件都是有自己独立的scope的,因此子组件是不能直接访问到父组件的数据的。数据一般都是通过props来传递的,示例说明。

// define component
Vue.component('child', {
  // declare the props
  props: ['msg'],
  // the prop can be used inside templates, and will also
  // be set as `this.msg`
  template: '<span>{{ msg }}</span>'
})

// usage
<child msg="hello!"></child>

上述方式只能实现组件树从上往下传递数据,在Vue.js中,会有大量的场景需要子组件向父组件传输数据,甚至兄弟组件之间传递数据,一般这种时候就需要使用以下几种能力。

  • 子组件获取父组件的能力(this.$parent
  • 自定义事件的能力 ($on, $emit, $dispatch, $broadcast)

想要了解详情,请移步Parent-Child Communication

样式、逻辑和界面的分离

前端开发经过这么多年的发展,html、css和js的分开编写应当是顺理成章的,Vue.js没有打破这个规则,通过 style 、 template 、 script 将样式、视图和数据逻辑进行了分离。详见下面示例,来源于VUE.JS: A (RE)INTRODUCTION

<!-- css -->
<style>
.message {
  color: red;
}
</style>

<!-- template -->
<template>
  <div class="message">{{ message }}</div>
</template>

<!-- js -->
<script>
export default {
  props: ['message'],
  created() {
    console.log('MyComponent created!')
  }
}
</script>

React

React可能是现在前端开发中最炙手可热的UI框架了。在React的首页最明显的位置上展示者关于React的最核心的三个思想,它们分别是:

  • Declarative(声明式)
  • Component-Based(组件化)
  • Learn Once, Write AnyWhere(一学多写)

声明式

React和Vue.js的组件的使用都是声明式的,声明式的编写方式会比命令式的编写更加的直观。关于声明式和命令式的区别,可以参考Declarative programmingImperative programming,这里就不加详述了。

组件化

诚然React和Vue.js在编写大型程序的时候都是构建一颗组件树,但React和Vue.js的组件却有着不小的差异。先来看一个React组件的示例(来源React官网)。

var HelloMessage = React.createClass({
  render: function() {
    return <div style={divStyle}>Hello {this.props.name}</div>;
  }

  // style
  var divStyle = {
    color: 'white',
    backgroundImage: 'url(' + imgUrl + ')',
    WebkitTransition: 'all', // note the capital 'W' here
    msTransition: 'all' // 'ms' is the only lowercase vendor prefix
  };
});

ReactDOM.render(<HelloMessage name="John" />, mountNode);

在React中,一切都是js,视图、逻辑和样式都是通过js来写的。通过js来统一颠覆了html、css和js分离的原则,当然是褒贬不一了。在Vue.js中,分离带来了清晰度,逻辑、视图、样式和数据可以分别处理,但在React中,一切都需要重新组织,甚至需要新的配套框架和设计模式,比如新的语言JSX就是用来简化js带来的麻烦的。但all in js让很多事情变得简单,js的快速发展也让React脱离了css和html发展限制,可以实现更多的可能性,优化、扩展以及其他很多事情,就只要单纯考虑js就可以了,而不必收到css和html的限制。

当然,这样带来的后果就是学习曲线的陡然增加,React甚至带来了新的JSX语法,同时考虑到React全新的React思想,开发者想要开发生产环境的app,尤其是在将现有app用React重写的时候,成本是要比Vue.js高出不止一个数量级的。

组件间数据传递

React推崇的是单向数据流动,也就是说,数据最好是从组件树的顶端往叶子节点流动,尽量少的出现反向流动的情况。
用另外一种方式来说,React希望实现的immutable data,数据的不变性。只读的数据能给我们带来非常多的好处,并发、简化逻辑、数据统一管理等等。

React提供了props和state两种数据类型,props是实现数据从父组件往子组件传递的机制,而state则是提供了一种机制来实现组件的自更新,facebook是建议尽量少用该特性,因为其违反了immutable data和单向数据流动的设定。

因为React的数据设定让其数据管理成为一个问题,业界出现了一些解决方案,其中最为著名的应该就是redux/flux了,有兴趣的同学可以上github搜搜,都是开源的。

一学多写

React背后是强大的facebook在开发维护,其目的不是要简单的创建一种新的js的UI框架,相反,其想要让React成为平台无感知的UI开发思想。什么意思呢?就是本节要说的learn once,write anywhere。facebook认为每个平台不可能完全一样,Web、Android、iOS、Windows Phone甚至Xbox,以及未来会出现的各种平台,他们都会有自己的发展理念和发展路劲,不可能做到完全一样,但不管平台如何变化,基于平台之上,创建Virtual DOM,React通过控制Virtual DOM来实现界面变化。
也就是说Virtual DOM相当于是一个中间层,隔离平台的差异,从而实现统一的开发方式。

不敢说这样的想法一定能成功,但就现在的发展势头来看,机会还是非常大的。尤其对于开发者来说极具吸引力,如果这一想法成为现实,以后React就可能像DOM一样成为业界统一的标准。那对于iOS开发者来说,在Android上面开发会跟在iOS上开发一样,不需要学习全新的Java语言,Android系统,更不要说各种Java特有的艰深复杂的工具了。

Native

个人感觉weex和react-native最大的不同是在Vue.js和React层面。这一点在react-native的命名上就非常容易看出来。在react-native刚出来的时候,其和React的关系是react-native依赖React。

"dependencies": {
  "react": "~14.0.0"
}

而现在react-native和react则是同级别的。

"peerDependencies": {
  "react": "~15.1.0"
}

react-native中最重要的文件名字也是Library,主要提供了一系列Native的能力。

查看weex的源码,native部分的作用几乎是一样的,主要就是提供了一些列Native的组件,以及其他的一些能力。

这也就是为什么本文将两者的Native合为一谈的原因,他们的本质是差不多的。

  • 提供了js和native交互的桥梁Bridge
  • 提供了一系列组件
  • 提供了flexbox布局支持
  • 提供了事件支持
  • ……

当然,因为weex和react-native的设计思想的差异,在native部分也存在差异,但我觉得这是因为js需要导致的,仅就native而言,两者并没有特别大的不一样。

也许在不远的将来,native部分会出来一个比较核心的框架,抽象出在构建App时js和native交互所需要的基本能力,同时提供扩展方式,让各种类似react-native\weex这样的框架可以专注于js层的设计。也许react-native就走在这条路上,谁知道呢?

展望

动态化的世界越来越精彩,对于weex和react-native的了解才刚刚入门,需要更多实操经验来深刻体会到两者的博大精深。weex和react-native各有千秋,开源的魅力也正是在此。

2019-02-26 22:56:07 paladinzh 阅读数 281
  • React NativeWeex开发对比及概述

    React NativeWeex开发对比及概述   React Native--概述及与WeexNative开发的对比(一) https://www.jianshu.com/p/613c1e8611e9  青苹果园 关注 2018.05.23 12:19* 字数 967 阅读 8156评论 4喜欢 11 ...

    280人学习
    免费试看

React Native与Weex开发对比及概述

 

React Native--概述及与Weex和Native开发的对比(一)

https://www.jianshu.com/p/613c1e8611e9

 青苹果园 关注

2018.05.23 12:19* 字数 967 阅读 8156评论 4喜欢 11

React Native

一. 什么是React Native?React是什么,Native又是什么?

React

  • React是由Facebook推出的一个JavaScript框架,主要用于前段开发;
  • React 采用组件化方式简化Web开发:
    • DOM:每个HTML界面可以看做一个DOM;
    • 原生的web开发方式,HTML一个文件,javaScript一个文件,文件分开,就会导致修改起来比较麻烦;
    • 可以把一组相关的HTML标签和JavaScript单独封装到一个组件类中,便于复用,方便开发。
  • React 可以高效的绘制界面
    • 原生的Web,刷新界面(DOM),需要把整个界面刷新.
    • React只会刷新部分界面,不会整个界面刷新。
    • 因为React独创了Virtual DOM机制。Virtual DOM是一个存在于内存中的JavaScript对象,它与DOM是一一对应的关系,当界面发送变化时,React会利用DOM Diff算法,把有变化的DOM进行刷新.
  • React是采用JSX语法,一种JS语法糖,方便快速开发。

Native

  • 指使用原生API开发App,比如iOS用Object-C或Swift语言开发。

所以React Native可以总结为:由Facebook推出,基于JavaScript框架和React库来提高多平台开发效率的一门语言。其核心思想是:Learn once, write anywhere.

二. React Native和Weex的对比?

Weex的概念:

  • Weex是2016年6月由阿里巴巴推出的一个动态化的高扩展跨平台解决方案,支持iOS、安卓、YunOS及Web等多端开发部署。
  • 思想:Write once, run anywhere.

相同点:

  • 都可以实现hot reload,边更新代码边查看效果
  • 布局都是基于flexbox
  • 都采用Web的开发模式,使用JS开发
  • 都是支持iOS和Android
  • 渲染机制都是Virtual DOM

不同点:

维度 React Native Weex
支持 Facebook Alibaba
思想 Learn once, write anywhere Write once, run anywhere
编写方式 需针对iOS、Android编写2份代码 只需要编写一份代码,即可运行在Web、iOS、Android上
JS引擎 JSCore V8
框架 React.js组件化,数据绑定 Virtual DOM JSX模板学习使用有一定的成本 Vue.JS 组件化,数据绑定 Virtual DOM 模板就是普通的html,数据绑定使用mustache风格,样式直接使用css
异步 提供了Promise的支持 只支持callback
扩展 不同平台可自由扩展 为了保证各平台的一致性,一次扩展得在各个平台都实现
组件 除了自带的,还有js.coach上社区贡献的,比较丰富 基本靠平台提供
性能 更优秀
社区 非常成熟和活跃 开源较晚,社区处于成长期
上手难度 困难 容易

总结:

  • Weex 和React Native最主要的区别可以总结为:Write once, run anywhere和 Learn once, write anywhere思想层次,以及Vue.js和React.js两大基础框架上的区别。
  • Weex相对来说学习门槛较低,易用性和性能等方面有优势;而React Native则在社区成熟性、组件和文档丰富上更有优势。

三. React Native开发与Native开发的对比

Native App

  • 优点:性能高;用户体验好;稳定性强。
  • 缺点:开发维护成本高,版本更新时间长。

React Native

  • 优点:
    • 跨平台开发
    • 跳过App Store审核,远程更新代码,提高迭代频率和效率,既有Native的体验,又保留React的开发效率。
  • 缺点:
    • 对于不熟悉前端开发的人员上手比较慢;
    • 不能真正意义上做到跨平台;
    • app包体积增大明显。

四.团队开发模式的选择

根据公司的具体情况选择开发模式:

  • 如果用户要求产品的体验度高、稳定性好并且不需要很频繁的更新,则选择Native App开发模式最好;
  • 如果核心业务要求用户体验度和稳定性好,部分业务需要频繁更新,则选择Hybrid App(Native + H5)混合开发模式最优,现在市场上大部分都是这个模式。
  • 如果是创业型公司或小团队开发,局限于人力和资源,非常推荐使用React Native或Weex开发,基本一个人就可搞定多端开发任务(估计会很累^ v ^)。

当然这也不是绝对的,就像我们公司(搞金融的)的产品,原来是使用Hybrid App开发模式,现在准备部分业务接入RN。

React Native和Weex

阅读数 1069