lavas -pwa vs RN vs WEEX

  说明一下，借用了wuwen的素材，也算是我们部门的原创吧

一、lavas

开发者：百度

lavas 不是一个框架，而是一个基于 vue的 PWA解决方案。

概念：

Lavas 是一个基于 Vue的 PWA (Progressive Web Apps)完整解决方案。我们将 PWA的工程实践总结成多种 Lavas应用框架模板，帮助开发者轻松搭建 PWA站点，且无需过多的关注 PWA开发本身。

 

PWA (Progressive Web Apps) 是一种 Web App新模型，并不是具体指某一种前沿的技术或者某一个单一的知识点，我们从英文缩写来看就能看出来，这是一个渐进式的Web App。主要是增强Web App 的体验，使站点具有类似原生应用的功能和体验，如：

站点可添加至主屏幕

全屏方式运行

支持离线缓存

消息推送……

PWA特点：

渐进式 - 适用于所有浏览器，因为它是以渐进式增强作为宗旨开发的；

    降低站点改造的代价，逐步支持各项新技术，不要一蹴而就，

    新技术标准的支持度还不完全，新技术的标准还未完全确定。

连接无关性 - 即使在不稳定的网络环境下，也能瞬间加载并展现

当用户打开我们站点时（从桌面 icon 或者从浏览器），通过 Service Worker 能够让用户在网络条件很差的情况下也能瞬间加载并且展现。

Service Worker 是用 JavaScript编写的 JS文件，能够代理请求，并且能够操作浏览器缓存，通过将缓存的内容直接返回，让请求能够瞬间完成。开发者可以预存储关键文件，可以淘汰过期的文件等等，给用户提供可靠的体验。

Service Worker 有以下功能和特性：

一个独立的 worker 线程，独立于当前网页进程，有自己独立的 worker context。

一旦被 install，就永远存在，除非被uninstall

需要的时候可以直接唤醒，不需要的时候自动睡眠（有效利用资源，此处有坑）

可编程拦截代理请求和返回，缓存文件，缓存的文件可以被网页进程取到（包括网络离线状态）

离线内容开发者可控

能向客户端推送消息

不能直接操作 DOM

出于安全的考虑，必须在 HTTPS 环境下才能工作

异步实现，内部大都是通过 Promise 实现。

类似应用 - 快速响应，并且有平滑的动画响应用户的操作

为了保证站点加载时间、平滑的体验，过渡动画和快速响应，

App Shell 是 PWA界面展现所需的最小资源，我们需要从设计上考虑，在内容请求完成之前，可以优先保证 App Shell 的渲染，做到和Native App 一样的体验。App Shell就类似于您在开发本机应用时需要向应用商店发布的一组代码。 它是 UI的主干以及让您的应用成功起步所需的核心组件，但可能并不包含数据。

RAIL指标评估网站（响应、动画、空闲、加载）

持续更新 - 始终是最新的，无版本和更新问题；

安全 - 通过 HTTPS协议提供服务，防止窥探和确保内容不被篡改；

可索引 - 应用清单文件和可以让搜索引擎索引到，从而将其识别为“应用”

粘性 - 通过给用户发送离线通知，让用户回流

可安装 - 用户可以添加常用的 webapp到桌面，免去去应用商店下载的麻烦

可链接 - 通过链接即可分享内容，无需下载安装

 可以借助 Web App Manifest （允许开发者控制 PWA 添加到桌面，允许定制桌面图标、URL等等）提供给用户和Native App 一样的沉浸式体验；

PWA 可以。

PWA优势：

Lavas 提供了一套基于 Vue的 PWA站点快速搭建方案。开发者只需要做一些简单的业务配置即可，从而大大节约开发维护成本。

 

项目模板：轻量的 basic 模板、appshell 模板，支持服务端渲染的ssr 模板、支持多页应用的mpa 模板等， 及多个技术点的实践经验等。

 

标准的支持度：

PWA 采用的最新技术，当前浏览器还没有达到完全支持的程度，W3C关于这些技术的标准也还在处于草稿状态，没有定稿。

根据 Can I useopen_in_new 的统计（包括 PC 和Mobile）

App Manifest 的支持度达到 57.43%

Service Worker 的支持度达到 72.82%

Notifications API 的支持度达到 43.3%

Push API 的支持度达到 72.39%

Background Sync 暂未统计到，Chrome 49以上均支持

比较遗憾的是上面提到的所有技术，目前只有 Android 的部分浏览器支持，iOS 都不支持，包括iOS 系统上的所有浏览器，不过，Safari浏览器已经在考虑了，在 webkit的五年计划中有提到，FiveYearPlanFall2015中提到Service Worker 变来越来越流行，我们也应该支持，这非常值得我们期待。

随着 W3C 的标准的进一步完善，国内外各大浏览器都会逐步支持，拥抱标准。

快速开始PWA工程：

1、准备

安装nodeJS

2、依赖工具

    安装lavas命令行工具

3、初始化工程

    lavas init

4、选择模板类型

5、目录结构

 

6、开发

参考：

百度的基于vue的pwa框架lavas

https://www.zhihu.com/question/62154338/answer/196721136

官网

https://lavas.baidu.com/

二、weex

开发者：阿里无线前端

Vue-Native，可以使用 vue.js 语法来开发应用程序。

Weex 是一款轻量级的移动端跨平台动态性技术解决方案，

概念：

    Weex 是一套简单易用的跨平台开发方案，能以 web 的开发体验构建高性能、可扩展的 native 应用，为了做到这些，Weex 与 Vue 合作，使用 Vue 作为上层框架，并遵循 W3C 标准实现了统一的 JSEngine 和 DOM API，这样一来，你甚至可以使用其他框架驱动 Weex，打造三端一致的 native 应用。

特点：

一次撰写，多端运行 -

首先 web 开发体验在各端当中是相同的。包括语法设计和工程链路。

其次，Weex 的组件、模块设计都是 iOS、Android、Web 的开发者共同讨论出来的，有一定的通用性和普遍性。

Weex 开发同一份代码，可以在不同的端上分别执行，避免了多端的重复研发成本。

轻量 - 体积小，语法简单、易于掌握

可扩展 - 可以横向扩展和定制原生组件和功能

高性能 - 对加载时间和资源占用深度优化，给你更好的体验

整体构架：

Weex 表面上是一个客户端技术，但实际上它串联起了从本地开发环境到云端部署和分发的整个链路。开发者首先可以在本地像撰写 web 页面一样撰写一个 app 的页面，然后编译成一段 JavaScript 代码，形成 Weex 的一个 JS bundle；在云端，开发者可以把生成的 JS bundle 部署上去，然后通过网络请求或预下发的方式传递到用户的移动应用客户端；在移动应用客户端里，WeexSDK 会准备好一个 JavaScript 引擎，并且在用户打开一个 Weex 页面时执行相应的 JS bundle，并在执行过程中产生各种命令发送到 native 端进行的界面渲染或数据存储、网络通信、调用设备功能、用户交互响应等移动应用的场景实践；同时，如果用户没有安装移动应用，他仍然可以在浏览器里打开一个相同的 web 页面，这个页面是使用相同的页面源代码，通过浏览器里的 JavaScript 引擎运行起来的。

 

Weex的三种工作模式

全页模式：

    目前支持单页使用或整个App使用Weex开发（还不完善，需要开发Router和生命周期管理），这是主推的模式，可以类比RN。

Native Component模式：

    把Weex当作一个iOS/Android组件来使用，类比ImageView。这类需求遍布手淘主链路，如首页、主搜结果、交易组件化等，这类Native页面主体已经很稳定，但是局部动态化需求旺盛导致频繁发版，解决这类问题也是Weex的重点。

H5 Component模式：

    在H5种使用Weex，类比WVC。一些较复杂或特殊的H5页面短期内无法完全转为Weex全页模式（或RN），比如互动类页面、一些复杂频道页等。这个痛点的解决办法是：在现有的H5页面上做微调，引入Native解决长列表内存暴增、滚动不流畅、动画/手势体验差等问题。

支持度：

Vue.js 最初是为 Web 设计的，虽然可以基于 Weex 开发移动应用，但是 Web 开发和原生开发毕竟不同，在功能和开发体验上都有一些差异，这些差异从本质上讲是原生开发平台和 Web 平台之间的差异，Weex 正在努力缩小这个差异的范围。

性能还是有点问题；

官网文档不全；

前端代码部分不兼容；

Weex 中只支持单个类名选择器；

三端统一的不够彻底，Build环节native和web有差异，图片加载路径不同；

Vue在weex中有些语法不同。

快速开始：

1、安装依赖

安装nodeJS

安装weex-toolkit(需要npm版本》=5)

2、初始化

    weex create project-name

3、开发

参考：

官网

http://weex.apache.org/cn/

阿里无线前端发布的Weex

https://www.zhihu.com/question/37636296

Weex 的实际使用/开发体验/效果如何

https://www.zhihu.com/question/51799870

weex踩坑攻略

http://www.jianshu.com/p/497f1a9ff33f

 

三、react native

开发者：Facebook

概念：

是Facebook于2015年4月开源的跨平台移动应用开发框架，是Facebook早先开源的UI框架React 在原生移动应用平台的衍生产物，目前支持iOS和安卓两大平台。RN使用Javascript语言，类似于HTML的JSX，以及CSS来开发移动应用，因此熟悉Web前端开发的技术人员只需很少的学习就可以进入移动应用开发领域。

React 是一套可以用简洁的语法高效绘制 DOM的框架。

RN是一个基于 JavaScript，具备动态配置能力，面向前端开发者的移动端开发框架。

特性：

原生的ios组件

    通过React Native，开发者可以使用UITabBar、UINavigationController等标准的iOS平台组件，让应用界面在其他平台上亦能保持始终如一的外观、风格。

异步执行

    JavaScript应用代码和原生平台之间所有的操作都采用异步执行模式，原生模块使用额外线程，开发者可以解码主线程图像、后台保存至磁盘、无须顾忌UI等诸多因素直接度量文本设计布局。

触摸处理

    React Native引入了一个类似于iOS上Responder Chain响应链事件处理机制的响应体系，并基于此为开发者提供了诸如TouchableHighlight等更高级的组件。

优点：

复用了 React 的思想，有利于前端开发者涉足移动端。

能够利用 JavaScript 动态更新的特性，热更新，快速迭代。

相比于原生平台，开发速度更快，相比于 Hybrid 框架，性能更好。

缺点：

做不到 Write once, Run everywhere，也就是说开发者依然需要为iOS 和Android 平台提供两套不同的代码，比如参考官方文档可以发现不少组件和API都区分了Android 和iOS 版本。即使是共用组件，也会有平台独享的函数；

不能做到完全屏蔽 iOS 端或 Android 的细节，前端开发者必须对原生平台有所了解。加重了学习成本。对于移动端开发者来说，完全不具备用React Native 开发的能力；

由于 Objective-C 与 JavaScript 之间切换存在固定的时间开销，所以性能必定不及原生。比如目前的官方版本无法做到UItableview(ListView) 的视图重用，因为滑动过程中，视图重用需要在异步线程中执行，速度太慢。这也就导致随着Cell 数量的增加，占用的内存也线性增加。

感觉 RN 更适合做移动开发的（Android/iOS）的程序员，因为开发的思维差不多。而Weex 感觉更适合前端转过来的程序员，尤其在支持Vue 语法后，更是得到一批Vue 爱好者的喜欢。

ReactNative 需要自己实现分包加载，从而优化JS加载执行时间。

ReactNative 默认没有优化机制，长 view渲染性能会比较差。

参考：

    如何评价RN

https://www.zhihu.com/question/27852694

RN优势

https://www.zhihu.com/question/36722811?sort=created