简直是神仙打架！ 多端统一框架哪家强？
大家好，我是hub哥，又到了本期分享。这期我们来聊聊多端统一框架。
目前市面上端的形态多种多样，Web、App 、微信小程序等各种端大行其道，当业务要求同时在不同的端都要求有所表现的时候，针对不同的端去编写多套代码的成本显然非常高，根源在于传统网页开发受浏览器能力限制太大，尤其是各家浏览器的不同实现、离线能力和性能上的缺陷导致 App 很难满足用户体验的需求。
“跨端”是目前前端界比较流行的一个词汇。跨端框架本质上是将终端能力以一种形式提供业务开发使用，可以无限制地使用所有终端能力的同时，尽量让业务开发只编写一套代码，这样既能满足性能需求，又能减少开发成本。
但纵观整个社区内的跨端开发框架，仍旧存在两个主要问题：
1.跨端框架对前端开发者来讲难度较高，如果不具备移动终端开发能力，很难上手；
2.平台差异大，相同功能甚至要为不同的平台使用不同的接口编写大量平台相关代码。
出现上述问题的原因，是因为目前业内的跨端框架，大部分由终端开发者主导开发，并不是从前端开发者角度出发的，所以对于前端开发者来说不够友好。
于是，市面上先后出现了不少跨端技术：uni-app 、Flutter、 WePY、 React Native
而本文主要介绍的，是国内几个大厂推出的解决方案：Hippy、Chameleon 、Taro、Weex
腾讯跨端框架- Hippy
当前star：4.5k
Github ：https://github.com/Tencent/Hippy
去年2月20日，腾讯QQ浏览器部门发起的开源跨端框架 Hippy。在腾讯内部，Hippy 已运行3年之久，跨 BG 共有 18 款线上业务正在使用 Hippy，日均 PV 过亿，且已建立一套完整生态。相较于其他跨端框架，Hippy 对前端开发者更友好：紧贴 W3C 标准，遵从网页开发各项规则，使用 JavaScript 为开发语言，同时支持 React 和 Vue 两种前端主流框架。
Hippy 实现了类似 Flutter 的引擎直通架构（在 React Native 中的 Fabric 架构），通过 C++ 开发的模块直接插入 JS 引擎中运行，绕过了前终端通讯编解码的开销，有效提升了 JS 前端代码和终端的通讯性能。在此基础之上，Hippy 正在实现高性能自绘，以提供更强的性能和更好的用户体验。
hippy-react 从语法上更加接近终端底层，某种程度上语法接近 React Native，同时通过官方提供了 hippy-react-web 组件库，也可以方便地生成 Web 版网页。
特征：
为传统 Web 前端设计，官方支持 React 和 Vue 两种主流前端框架。
不同的平台保持了相同的接口。
通过 JS 引擎 binding 模式实现的前终端通讯。
提供了高性能的可复用列表。
皆可平滑迁移到 Web 浏览器。
完整支持 Flex 的布局引擎。
项目架构：
例：全民 K 歌：react + hippy-react + hippy-react-web
滴滴跨端框架 - Chameleon
当前star: 7.3k
GitHub：https://github.com/didi/chameleon
Chameleon（简写 CML ）中文名卡梅龙，中文意思：变色龙，意味着就像变色龙一样能适应不同环境的跨端整体解决方案。工程化设计，丰富的基础库，独创多态协议，提供标准的 MVVM 架构开发模式统一各类终端。
对上图各层定义如下：
API 接口协议（Library)：定义基础接口能力标准。
内置组件协议（Library)：定义基础 Ui 组件标准。
框架协议（Framework)：定义生命周期、事件、路由等框架标准。
DSL 协议（Language)：定义视图和逻辑层的语法标准。
多态实现协议（Interface)：定义允许用户使用差异化能力标准。
支持平台：
web、微信小程序、支付宝小程序、百度小程序、android(weex)、ios(weex)、qq 小程序、字节跳动小程序、快应用、持续更新中
代码示例：
{{title}} {{reversedTitle}}
网页编程采用的是 HTML + CSS + JS 这样的组合，同样道理，chameleon 中采用的是 CML + CMSS + JS。
JS 语法用于处理页面的逻辑层，与普通网页编程相比，本项目目标定义标准 MVVM 框架，拥有完整的生命周期，watch，computed，数据双向绑定等优秀的特性，能够快速提高开发速度、降低维护成本。
CML（Chameleon Markup Language）用于描述页面的结构，我们知道 HTML 是有一套标准的语义化标签，例如文本是 按钮是。CML 同样具有一套标准的标签，我们将标签定义为组件，CML 为用户提供了一系列组件。同时 CML 中还支持模板语法，例如条件渲染、列表渲染，数据绑定等等。同时，CML 支持使用类 VUE 语法，让你更快入手。
CMSS (Chameleon Style Sheets)用于描述 CML 页面结构的样式语言，其具有大部分 CSS 的特性，并且还可以支持各种 css 的预处语言less stylus。
特点：
-
多端高度一致
深入到编程语言维度保障一致性，包括框架、生命周期、内置组件、事件通信、路由、界面布局、界面单位、组件作用域、组件通信等高度统一 -
组件
在用 CML 写页面时，chameleon 提供了丰富的组件供开发者使用，内置的有button switch radio checkbox等组件，扩展的有c-picker c-dialog c-loading等等,覆盖了开发工作中常用的组件。 -
API
为了方便开发者的高效开发，chameleon 提供了丰富的 API 库,发布为 npm 包chameleon-api，里面包括了网络请求、数据存储、地理位置、系统信息、动画等方法。 -
自由定制
基于多态协议，可自由扩展任意 API 和组件，不强依赖框架的更新。各端原始项目中已积累大量组件，也能直接引入到跨端项目中使用，可充分隔离各端差异化实现。 -
智能规范校验
代码规范校验，当出现不符合规范要求的代码时，编辑器会展示智能提示，不用挨个调试各端代码，同时命令行启动窗口也会提示代码的错误位置 -
渐进式跨端
不仅可以用 cml 开发页面，也可以将多端重用组件用 cml 开发，直接在原有项目里面调用。
京东跨端框架 - Taro
当前star：24.5k
GitHub: http://github.com/nervjs/taro
Taro 是由京东 - 凹凸实验室打造的一套遵循 React 语法规范的多端统一开发框架。
一套代码，通过 Taro 的编译工具，将源代码分别编译出可以在不同端（微信小程序、H5、App 端等）运行的代码。同时 Taro 还提供开箱即用的语法检测和自动补全等功能，有效地提升了开发体验和开发效率。
和微信自带的小程序框架不一样，Taro 积极拥抱社区现有的现代开发流程，包括但不限于：
NPM 包管理系统
ES6+ 语法
自由的资源引用
CSS 预处理器和后处理器（SCSS、Less、PostCSS）
对于微信小程序的编译流程，Taro的灵感来源于 Parcel ，自研了一套打包机制将 AST 不断传递，因此代码分析的速度得到了很大的提高。一台 2015 年 的 15寸 RMBP 在编译上百个组件时仅需要大约 15 秒左右。
在 Taro 中，你不用像小程序一样区分什么是 App 组件，什么是 Page 组件，什么是 Component 组件，Taro 全都是 Component 组件，并且和 React 的生命周期完全一致。可以说，一旦你掌握了 React，那就几乎掌握了 Taro。同样使用声明式的 JSX 语法。相比起字符串的模板语法，JSX 在处理精细复杂需求的时候会更得心应手。
// 一个典型的 Taro 组件
import Taro, { Component } from '@tarojs/taro'
import { View, Button } from '@tarojs/components'
export default class Homeextends Component{
constructor (props) {
super(props)
this.state = {
title: '首页',
list: [1, 2, 3]
}
}
componentWillMount () {}
componentDidMount () {}
componentWillUpdate (nextProps, nextState) {}
componentDidUpdate (prevProps, prevState) {}
shouldComponentUpdate (nextProps, nextState) {
return true
}
add = (e) => {
// dosth
}
render () {
const { list, title } = this.state
return (
{title}
{list.map(item => {
return (
{item}
)
})}
添加
)
}
}
Taro已有功能相对完善的IDE：
错误语法触发报错，并给出报错信息和一个文档地址描述：
自动补全功能：
阿里无线前端 - Weex
当前star: 17.6k
GitHub：https://github.com/alibaba/weex
Weex 是阿里巴巴开源的一套构建高性能，可扩展的原生应用跨平台开发方案。
在 2016 年阿里双十一中，Weex 在阿里双十一会场中的覆盖率接近 99%，页面数量接近 2000，覆盖了包括主会场、分会场、分分会场、人群会场在内几乎所有的阿里双十一会场业务。阿里双十一主会场秒开率97%，全部会场页面达到 93%。
特点：
-
页面的开发目前支持Rax和Vue
Weex 也不是只支持 Vue 和 Rax，你也可以把自己喜欢的前端框架集成到 Weex 中，有一个文档扩展前端框架描述了如何实现，但是这个过程仍然非常复杂和棘手，你需要了解关于 js-native 之间通信和原生渲染引擎的许多底层细节。 -
一次编写，三端（Android、iOS、前端）运行
前提是都集成了 weex sdk，另外视觉表现做不到完全一样，有的会有一些差异，需要做一下适配。所以写 weex 页面的时候，如果支持三端，便需要在三端都进行自测。 -
通信
UI 的绘制通过 native 的组件，JavaScript 逻辑在 JS 引擎里运行，两者通过 JavaScriptCore 通信 -
支持 Native 扩展
可以将 native 的 UI 组件封装成 component，将 native 的逻辑代码封装成 module。从而在 weex 里可以进行使用。这里的 natiev UI 组件包括 modal、webview、image 等，这里的 native 逻辑代码包括 storage、network 等。 -
视图
每个 weex 页面会被打包成一个 js 文件，weex sdk 将 js 文件渲染成一个 view
weex 的打包通过 webpack，将每个页面打包成独立的一个 js 文件，weex sdk 会将 js 进行解析，将 UI 部分绘制成一个 view, 再绑定 view 的事件与 js 代码绑定。 -
调试
都可以在chrome中调试JS代码，weex支持在chrome中预览页面dom节点 -
页面开发
weex提供了一个playground，可以方便的预览正在开发的页面 -
即时预览
weex和ReactNative都有提供hot reload功能，可以边更改代码，边在手机上看到效果 -
打包
weex默认打的js bundle只包含业务js代码，体积小，基础js库包含在weex sdk中 -
异步
weex只支持callback
例：
代码：
写在最后
目前大家可能会有一些疑问，比如跨端技术以后是否会取代原生开发？对于这个一直争议不断的问题，笔者认为，从目前的发展趋势来看，并没有取代一说，跨端的灵活与低成本，大多数应用场景是在一些变化较快的常规业务开发中，而原生开发中，比如定制化的视频渲染，复文本阅读器，高响应度复杂动画，各类传感器比如 蓝牙，陀螺仪，距离感应等等，这些关乎到交互体验的细腻程度，目前还是得以原生开发来处理。所以与其说取代，不如说两者相辅相成，互相配合，发挥出最高效率，才是正确操作。
这么多跨端技术，各有优劣，不能一句话去评判哪个好与不好，至于选择哪一个，得考虑自家系统的现有架构，还得考虑开发人员的配置，所以适合自己，才是选择的标准。相信以后类似框架会越来越多，越来越成熟，学习成本也会越来越低，而就目前而言，国内这几家的跨端开源框架，你更看好哪个呢？
如果你有不错的项目 可以加我们投稿
关注我们
最新最有趣的开源资讯、开源框架、开源项目
