Skip to content
kaba

Rax intro

跨端1 min read

Rax体系设计背景及现状

为什需要跨端解决方案

  • 容器在持续的变化
    • webview
    • RN/Weex
    • 小程序
    • Flutter
  • 除了运行在特定容器里,大多数业务都有投放到浏览器中的需求
  • 不想根据容器写多套代码,也不想写代码的方式一直在变,开发效率低

Rax的起点

  • RN无法支持Web,但是业务投放到Web又是必需的
  • 与RN方案类似的Weex诞生,但是Weex的DSL其实是仿的Vue,与PC端React为主的技术栈不符
  • 尝试将ReactWeex融合,发现有很多无法解决的性能问题

Rax的愿景

  • DSL标准
  • 多端投放
  • 生态完善
  • 一次开发,多端运行

Rax跨端解决方案的设计及原理

跨端方案设计

image.png

VDOM的优势

特点
  1. 标准的数据结构
  2. 与具体的端解耦
价值
  1. UI = fn(state) 
  2. 跨端

从VDOM到跨平台

  • React/Vue起初都不具备跨平台的能力,所以早起RN/Weex都是内置一份hack的React/Vue    
  • Rax本身就是针对与跨平台来设计的,因此诞生时通过driver层的模式切换来适配不同的平台
  • React会将jsx转换成VDOM,Rax在转换成VDOM后,若是Web端,会采用driver-dom将VDOM转换成DOM,Weex端则会采用driver-weex转换成Weex下渲染的DOM节点等等

image.png

DSL设计

为什么有了VDOM还需要语法编译

  • VDOM的跨端能力需要容器来提供一些能力,有的容器不具备这样的能力

image.png

语法编译带来的缺陷

  • 无法覆盖所有语法,一般都是一个子集,用起来效率不高
  • 架构的复杂度较高,需要持续的投入
  • 语法编译不是银弹,更推荐在特定的情况下使用
    • 如通过babel-plugin-import按需引入组件

目前社区编译时的方案

  1. Rax的driver-weex
  2. Taro2.0
  3. uniapp

框架设计

应用入口

app.json

1// src/app.json
2{
3 "routes": [
4 {
5 "path": "/",
6 "source": "pages/Home/index"
7 }
8 ],
9 "tabBar": {
10 "textColor": "#999",
11 "selectedColor": "#666",
12 "backgroundColor": "#f8f8f8",
13 "items": [
14 {
15 "name": "home",
16 "path": "/",
17 "icon": "https://gw.alicdn.com/tfs/TB1ypSMTcfpK1RjSZFOXXa6nFXa-144-144.png",
18 "activeIcon": "https://gw.alicdn.com/tfs/TB1NBiCTgHqK1RjSZFPXXcwapXa-144-144.png"
19 }
20 ]
21 }
22}

app.ts

1// src/app.ts
2import { runApp, IAppConfig } from 'rax-app';
3
4// 应用配置
5const appConfig: IAppConfig = {
6 app: {
7 // ...
8 onLaunch(){},
9 onShow(){}
10 },
11 router: {
12 // ...
13 },
14 store: {
15 // ...
16 }
17};
18
19runApp(appConfig);

多端构建

build.json中配置端,也可以针对不同平台做不同配置

1{
2 "targets": ["web", "miniapp"],
3 "web":{
4 "ssr": true
5 },
6 "miniapp": {
7 "buildType": "runtime"
8 },
9 "plugins": [
10 ["build-plugin-rax-faas",[
11 "options": {}
12 ]]
13 ]
14}

在构建后会通过不同的目录将不同端的代码聚合 image.png

多端构建原理

通过Webpack的多任务机制实现。 平时开发中,我们都是一个入口,打包成一个bundle。而在多端环境下,端的不同,可能需要的plugins也不同。

image.png

Rax小程序整体架构

Rax的定位:双引擎驱动的完整小程序开发体系 底层:通过集团的build scripts支撑工程,支持小程序项目、组件和插件的开发 运行时:通过模拟DOM,BOM底层的API实现适配 编译时:通过静态编译,将Rax的DSL编译成小程序DSL 生态:Fusion,Universal等 上层:支持阿里、微信、字节小程序及快应用

image.png

编译时方案

特点:高性能 底层:通过build scripts支撑 核心:jsx-compiler 编译后:通过轻量的runtime来抹平Rax与小程序的生命周期差异 image.png

缺陷

语法限制

1// rax中
2<View>
3 {props.children}
4</View>
5
6// 小程序中可以用slot实现
7<View>
8 <slot />
9</View>
10
11// 如果rax中操作复杂一些,小程序就无法支持了
12<View>
13 {
14 props.children.map(child=><Text>{child}</Text>)
15 }
16</View>

运行时方案

特点: 弥补编译时方案的不足
  • 不存在语法限制
  • 运行真正的Rax,支持新特性
  • 基于Webpack的工程
原理

架构:通过webpack plugin,输出固定的page模板代码和app模板代码 编译的模版代码:通过webpack生成一个js bundle,通过模拟DOM和BOM的API,将document和window注入到bundle中 底层:通过miniapp-render适配documentwindow操作DOM的逻辑如createElement,appendChild等,将DOM树处理生成到render层 render层:利用自定义组件的自引用特性渲染构建DOM树,完成动态构建DOM的过程 image.png image.png