干货 | 揭秘携程三端通用框架中的CRNWEB

作者简介

郑勇,携程高级技术经理,目前主要负责CRNWEB框架的开发工作,以及在携程内部的使用推广和性能优化。

前言

React-Native自从2015年推出,就一直火到了现在,一度在技术圈言必RN,激发一波广泛的思潮。携程基础业务研发团队迅速跟进,在React-Native基础之上,开发出了CRN这一适合携程业务高速发展的、抹平了iOS和Android端组件开发差异的、做了大量性能提升的框架。然而无论是CRN还是React-Native本身都无法解决移动板块中的一大版图——WEB平台。

而现实是:存在大量的业务需求需要三端的支持,单独再开发一套H5成本高昂,后期的维护成本也很高,需求同步难,用户体验不一致等问题都会非常明显,而携程基础业务前端框架团队一直都在致力于解决iOS和Android之后,将BU业务代码无缝接入WEB平台的技术方案,于是CRN-WEB(简称CW)应运而生。

一、CRNWEB是什么?

CRN-WEB的使命就是在CRN和React-Native的基础之上,构建一个三端打通的平台,能够实现BU的一套业务逻辑代码,能够根据平台情况运行在三端之上,并带来用户体验上的一致性(和React-Native保持一致)和优越性(使用Virtual DOM,PWA等技术提升性能)。

1、设计共性

对于CRN-WEB这样一个框架,我们在设计之初就可以提取一些软件设计方面共性的问题:

1)易用性,CW框架必须简单易用,大幅度降低开发成本、运维成本和学习成本,将是这个框架的核心价值,如何做到呢?

2)一致性,和现有技术框架的集成问题,即如何将CRN-WEB与CRN和React-Native进行友好的集成,各自发挥各自的功能,如何保证各平台间的一致性?

3)稳定性,React-Native版本迭代迅速,版本间差异较大,既然三端打通,共用BU源码,那么BU的React-Native项目或者CRN项目在接入CW框架后,必须能够稳定运行在WEB平台上,如何保证项目稳定运行?

4)兼容性,WEB平台是非多(浏览器厂商多,版本多,私有规范多,差异多...),兼容性问题一直是WEB项目开发头疼的事情,如何处理好兼容性问题?无疑是非常棘手的。

5)扩展性,包括React-Native本身都还在不断的变动,增加新功能,再加上公司级别的功能性需求,业务级别的功能需求,将令如何保持框架扩展性变得非常麻烦。

2、我们的设计思想

That‘s a big business,的确,这些问题很难处理,但是经过深入的思考,我们提出了这样的设计思想。

React-Native为解决iOS和Android两端兼容提供了解决方案,它是如何做到的呢?当然RN团队经过了大量的工作和思考,最终他们提供了一套规范,即React-Native,与其说它是一个框架不如说它是一套规范,对,我就是这么认为的。

如果CRNWEB的设计也基于React-Native的规范,把React-Native抽象成一个逻辑层,为不同的平台提供相同的Component和API输出和相同的APP主要运行流程,然后在规范之下各个平台各自实现,即iOS Implement,Android Implement,WEB Implement,那么从设计上来看是比较完美的。

对于业务方而言如Flight项目,Hotel项目等等,无需关心底层的技术实现,使用React-Native这一套开发技术体系基本上就足矣。

3、设计优势

这样设计同时还可以解决好几个问题:

比如易用性,我们采用了React-Native的规范,那么我们就可以使用开发人员熟悉的技术,熟悉的规范,熟悉的知识,熟悉的流程,无需额外学习太多其它规范和技术栈。

否则BU的学习成本,接入成本太高,起不到降低开发成本的作用,当然为了解决易用性,还有很多其它方面的工作,比如提供一整套的开发流程,开发工具,发布工具,技术支持等等。

再比如一致性问题,和React-Native,CRN使用相同的规范,这样的设计保持了天然的一致性。

二、CRNWEB是如何工作的呢?

我们依然从程序设计的传统,Hello wolrd开始。

熟悉React-Native的同学可能一眼就能够看出来,这完全就是React-Native的原代码,你说的对,它不仅是一份RN的源代码,也是一份CRN-WEB的源代码。它虽然是一个最简单的Hello World,但是它几乎包含了React-Native的Component和API,以及主要的运行流程。

1、主题结构分成三个部分:

1)头部的依赖部分,使用ES6的语法import,导入依赖的程序包React和React-Native;

2)中间部分实现模块主要逻辑;

3)尾部使用ES6语法export导出模块输出;

在CRN-WEB中也是这样,毫无差异。

2、那么CRNWEB是如何让和React-Native相同的源代码运行在Web平台的呢?

要实现这种能力,那么它必须满足两个最重要的必要条件。第一点,我们要实现在Web平台上面,跟React-Native上面具有相同功能的Component和API,比如这里的View和Text,这个就是我们后面要讲到的组件系统。

第二点,我们要有一种机制使得我们的React-Native原代码能够在Web上面运行起来,调用我们WEB平台上的Component和API,使得我们对代码拥有足够的控制能力。这个就是我们后面要讲到的打包系统。

三、运行分析

HelloWorld代码编写完成,配置好环境,执行CRNWEB命令,查看编译后运行效果和运行结果。

1、入口组件

CRNWEB仍然使用了AppRegistry作为程序入口注册组件,当然这里的AppRegistry已经被换成了AppRegistry.web这个WEB版本的Implementation,AppRegistry实现了registerComponent作为程序入口,承担App初始化工作,例如:

1)运行环境初始化,例如识别是h5还是hybrid;

2)注入默认的全局性样式,例如抹平浏览器差异的样式;

3)全局性请求参数的解构和传递;

4)初始化全局性组件的容器等等;

2、同步组件的异步转换

HelloWorld组件就是一个标准的React-Native组件,在CRNWEB中为了提高性能,将HelloWorld组件转化为异步组件HelloWorld(__CRNWEBFUNCTION__),从而实现页面级别的按需加载,仅在需要的页面运行时进行加载。

这在WEB环境下是非常重要的一项优化,这是专门针对WEB环境下脆弱的网络环境而作出的改进,特别是在页面众多,组件数量大,组件体量大的较大型WEB项目中,性能提升非常显著,这在BU的实践中得到了的认可。

3、具体的业务逻辑页面的编译转化

而原来的HelloWorld业务逻辑被打包到了模块号为97的package中,并处理好了它的依赖,如下:

我们可以看到原来的ES6语法书写的代码被编译成了ES5语法的代码,因为ES5在WEB环境下有着更广泛和友好的支持,兼容性更好。而HelloWold中引入的View,Text,StyleSheet等等组件,也全部变成了WEB版本的具体实现,这里使用了一招瞒天过海。

4、组件系统

而View,Text等等众多的React-Native原生组件对应的WEB版本的具体实现,就构成了CRNWEB的组件系统,篇幅有限不做展开。

5、样式处理

而HelloWorld里引入的StyleSheet就是样式处理系统中的入口文件。

CRNWEB的样式处理系统我们主要提供四种方式:

首先是APPRegistry,我们需要注入一些默认的全局样式,这个前面已经有所提到。后面三种其实都是对于组件样式的处理。

第二种是对组件的默认样式,可能有一些组件,历史的组件,我们也给它提供了这种能力。

第三种是一种预处理,组件样式的一个预处理,基本上都要用到StyleSheet.Create,这个和React-Native保持一致。

第四种我们对样式的一个实时处理系统。

样式处理系统的任务就是处理样式的问题,包括但不限于:

1)平台间样式的差异性,比如Border,在React-Native下,它是分散的每一个属性值进行一个独立的编写,而在Web上面它的Border是一个混合制,所以这就是平台之间的差异,CRNWEB框架就会开一个任务去对它进行修复。

2)浏览器间的差异,比如有的浏览器支持FlexBox,有的不支持,而且即使是支持FlexBox,支持的程度,版本也不一样,这些都是需要具体处理的修复任务。

3)一些共性上的问题,如单位处理,颜色处理等等。

4)一些差异性样式问题,如前缀处理,视口问题。

5)Web不支持的样式,如BoxShadow的实现等。

6、事件处理

CRNWEB中还有非常重要的一大块逻辑就是事件处理,我们专门提供了一个事件处理系统来进行处理。

我们使用了PanResponder,它提供一个对触摸响应系统的Responder的可预测的包装,和React-Native保持一致的事件处理流程,所以在事件的处理流程和兼容性方面和React-Native保持了高度一致性。

四、打包系统概述

最后CRNWEB的一大重头戏就是打包系统。

1、打包任务

CRNWEB打包系统的任务非常多,从流程上看,大概分为以下几个阶段:

1)Prepare阶段,需要对它进行入口检查,版本检查,环境检查以及第三方的依赖检查等等,各种的预先准备条件都在在这个阶段进行处理。

2)进入到Webpack的打包构建流程,我们编写了很多Webpack的插件,对它打包进行各种处理和优化。

3)构建过程当中会去调到Babel,利用Babel对原代码进行编译,对语法进行处理,对于代码的同步、异步转换这样一些比较核心的内容,都是通过编写的Babel插件对原代码进行处理实现的。

4)进入到Create阶段,因为有的Bu需要生成JAVA工程,有的需要.Net的工程,还有的只需要一个Static静态工程,在这个阶段需要对它进行一个工程的一个创建。

5)对这个工程进行启动,我们提供了开发版和生产版,他们的侧重有所不同。像开发版的话,它的主要诉求是打包编译的速度要快,这样才可以提高效率。而对于生产版它最核心的需求就是,要使你的size最小化,使你的运行效果最好。我们使用了很多优化手段对它进行了处理。

6)最后涉及到的一块,需要对它的size,它的依赖进行各种各样的优化。我们实践下来发现,BU代码量是非常非常多,业务也是非常非常复杂。怎么办呢?我们对业务工程进行size的分析,依赖分析等等各种更深入到代码层面的分析和处理,从而寻找到最佳实践的解决方案。

2、一些关键优化点

随着业务蓬勃发展,页面越来越多,组件越来越大,无论对于Native还是对于Web来说,这都是无法回避的挑战,精简打包size成为重要工作,对于size这一块我们做了很多优化处理,包括但不限于:

1)对于React,进行了优化和增减,以及一些切入式的处理,只保留需要的部分。

2)使用了tree shaking技术,排除掉了很多死代码。

3)对组件进行高级别抽象,增加重用度。

4)减少组件层级,简单而有效的方案,既减少size又提升性能。

5)运用各种cache技术,提升用户体验。

另外我们使用了一些工具,能很好的将项目中的模块依赖关系呈现出来,比如说Log这个模块被哪些页面引用,首页这个页面引用了哪些具体的模块(如:FStyleSheet,Log,utils,LinearGradient.web等等),模块有多大多少个,都可以非常清晰的展示出来。这样就非常方便对代码进行优化和处理,并使数据可视化了。

我们现在项目有多大,它的主要代码组成结构是什么样的,它的每一个模块,每一个依赖,每一个组件size占比多少,都可以进行精确的数据分析。比如说最大的模块,你为什么最大,你包含了哪些业务逻辑,是不是必须的。这些数据都可以进行再一步的思考。

CRNWEB目前已经支持到了React-Native的最新版本0.54版本,React升级到16.2版本,已经有众多页面升级上线。

最后看看实际项目运行效果对比:

原文发布于微信公众号 - 携程技术中心(ctriptech)

原文发表时间:2018-04-23

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Youngxj

在线听歌房源码 - MKOnlineMusicPlayer V2.21

50530
来自专栏CSDN技术头条

IMVC(同构 MVC)的前端实践

导语 随着 Backbone 等老牌框架的逐渐衰退,前端 MVC 发展缓慢,有逐渐被 MVVM/Flux 所取代的趋势。 然而,纵观近几年的发展,可以发现一点,...

24460
来自专栏张戈的专栏

WordPress 4.0 Benny简体中文版现已开放下载

昨天,收到了 WordPress 官方邮件,告知 4.0 已发布,要我确认中国联盟的导航插件是否兼容新版本。 ? 不过后台看了下,却没提示更新。直到今早才在后台...

36870
来自专栏hotqin888的专栏

用slide做html5的ppt

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/hotqin888/article/det...

40910
来自专栏macOS 开发学习

macOS 开发 - 小基础拾遗

通过熟悉一个App的启动过程,有利于我们理解开发时代码的执行过程,以及帮助我们修复一些系统Bug都是非常有意义的.一个macOS的App启动与iOS App启动...

10320
来自专栏维恩的派VNPIE

用于回测的Python交互K线工具

开发策略时,如何直观地检查自己的交易逻辑是否正确?代码所实现的和自己的策略逻辑是否一致?moonnejs在「维恩的派」论坛里分享了一个可以用于回测的交互K线工具...

59620
来自专栏Python数据科学

Python爬虫之撩妹篇—微信实时爬取电影咨询

“ 本文将介绍如何使用爬虫在微信对话中实现实时的电影咨询爬取功能,希望和大家一起来分享”

17120
来自专栏不止是前端

实用主义:前端IDE选择从入门到高阶

444120
来自专栏IT派

前端UI框架小汇总

IT派 - {技术青年圈} 持续关注互联网、大数据、人工智能领域 移动端UI框架 Mint UI(饿了么团队) 中文官网:http://mint-ui....

1.1K40
来自专栏即时通讯技术

最火移动端跨平台方案盘点:React Native、weex、Flutter

跨平台一直是老生常谈的话题,cordova、ionic、react-native、weex、kotlin-native、flutter等跨平台框架的百花齐放,颇...

84530

扫码关注云+社区

领取腾讯云代金券