天天看点

携程跨端解决方案的新选择:Taro-CRN

作者简介

李羽,携程高级前端研发工程师,专注前端跨平台框架领域的开发与研究。

Hyme,携程前端研发经理,专注前端小程序/H5领域的开发与研究。

Chao,携程前端研发经理,关注前端跨平台领域与前端研发效率提升。

一、项目背景

随着小程序用户的增长,APP和小程序在需求迭代上呈齐头并进的趋势。与此同时,前端研发人员面对多套平台代码的维护与开发,研发投入上耗时耗力。目前携程内部急需一种跨平台的开发框架,来节约不必要的多套开发量。

 二、框架介绍

Taro-CRN是帮助携程开发者基于Taro开发CRN项目的框架,实现一套代码在小程序和APP上的跨端开发,也为后续携程的跨端开发生态打下基础。Taro-CRN由携程机票团队与火车票团队共建而成。Taro本身是业内比较成熟的跨平台解决方案,目前已经支持转换到多平台小程序、H5、RN页面,并且有很好的社区支持。

在携程内部,Taro也拥有同样广泛的使用基础。多个业务线应用Taro来实现多平台小程序的开发,也有大量的H5业务页面是由Taro-H5转换而成。然而,Taro-RN作为Taro跨端开发方案的最后一块拼图,在携程内部却很少有团队应用,其根本原因在于其难以与携程的CRN框架结合使用。CRN是适用于携程APP业务开发的React Native框架,在携程系APP上有极为广泛的应用。CRN会在构建过程中,进行一些针对携程业务的分包、混淆、引入公共包等优化策略。这一点与Taro-RN那种直接打出bundle包的方案难以融合。

由此我们确定了Taro-CRN框架的设计方向:

1)低成本接入,实现用Taro开发CRN页面。

2)贴近Taro官方方案,享受Taro强大社区支持。

3)接入CRN的构建与打包,适用携程业务开发。

4)低学习成本,提升开发者体验。

三、架构介绍

Taro-CRN框架主要由3部分组成:平台插件、Metro Config插件、基础组件及API库。

携程跨端解决方案的新选择:Taro-CRN

Taro-CRN的平台插件提供了根据Taro来构建CRN工程的能力,这个构建出的CRN工程可以直接用来进行携程内部的MCD发布。同时平台插件也在CRN工程中引入了metro config的插件,通过对metro的配置做到引用的转向和transformer的支持,同时也在这里配置了Taro-CRN组件库的映射。在CRN的集中构建过程中,已经抹平差异的组件库与API库就被引入并做了替换。这样就做到了在Taro的业务工程上开发,低成本地打成CRN的bundle包并执行发布。

3.1 Taro-CRN 平台插件

Taro为了让开发者拓展更多定制化功能,引入了插件化机制。Taro-CRN的平台插件基于此,会按Taro工程的文件结构,基于内置的CRN模板文件,生成CRN工程所需的页面入口及目录结构,紧接着原本的Taro业务代码会被插件按目录塞到这个CRN的壳工程中。

同时平台插件也通过`ctx.registerPlatform`,将CRN与其他平台并作一起,可以像小程序或H5一样按Taro官方的命令进行开发与构建,提升了Taro开发者的开发体验。

3.2 Metro Config 插件

那么怎样将这样一个壳子是CRN结构、内嵌Taro业务代码的项目,打成CRN的最终产物呢?我们选择在metro构建过程中来处理。CRN框架本身为业务方的metro配置提供了扩展的途径,我们由此通过metro-config-plugin插入对Taro-CRN项目的额外构建配置。

携程跨端解决方案的新选择:Taro-CRN

平台插件在生成壳工程的同时,就会向项目里植入metro-config-plugin。在metro的解析阶段,插件会根据“引用链”分析Taro的组件及API的引用,并转向引用对应的Taro-CRN的组件及API库。得益于Taro支持完整的React开发体验,引用转向后就可以看做一个完整的CRN项目了。与此同时,Taro的框架代码与依赖就这样被隔离到打包的CRN项目之外,规避了其他跨端方案普遍存在的包size增大的弊端,这保证了Taro-CRN框架生成项目的性能与直接用RN开发的项目无差异。

除此之外,metro-config-plugin也做了很多方便业务开发的配置。比如Taro开发者熟悉的文件平台后缀,我们在这一层也实现了根据.crn.xxx的后缀来支持不同端上的业务差异代码。还有一些携程内部平台的差异支持,Metro Config插件中也保留了扩展能力。

对于RN与Taro在样式等写法风格的转换,我们选择在transformer的部分直接继承Taro-RN样式相关的transformer,配合我们开发的'code-transformer'一起实现babel转换与样式转译。这种方案最大的好处就是在开发调试阶段,开发者可以直接调试原始Taro代码,而非转后的CRN代码,极大提升开发效率。

3.3 Taro-CRN组件及API库

对于基础组件和API,我们严格按照Taro官方文档一一对应提供,这样极大降低开发门槛,Taro开发者甚至不需要学习RN即可使用。对于现有的Taro项目也可以不用做组件上的改动而直接转成CRN项目,拓展了框架的使用场景。

大多组件是直接沿用Taro-RN的实现,部分CRN有过优化的组件及API,我们用CRN对应Taro的参数进行了实现。对于部分RN中存在,但在Taro中不存在的组件,我们也开发提供相应的组件为使用者提供便利。

携程体系下的多平台小程序,做了非常多基于业务上的Taro优化,并提供了相应的API。为了方便携程主板的开发者,Taro-CRN也对部分API做了抹平,进一步降低了使用门槛。

3.4 其他支持

`@ctrip/plugin-publish-crn`是Taro-CRN提供的发布插件。CRN的发布是需要指定CRN的代码仓库,因此平台插件产出的CRN壳工程需要有独立的仓库或分支来存放。引入发布插件后,可以简单配置指定所需发布仓库或者是开发仓库下的发布分支,无需手动转移,提升发布效率。

四、接入使用

4.1 Taro项目中接入Taro-CRN

无论是接入新建Taro项目还是现有项目,都可以低成本转成CRN的项目来进行开发与调试。

a. 引入Taro-CRN平台插件

在Taro项目中引入前面提到的平台插件,`@ctrip/plugin-platform-crn`。另外如果也需要发布插件的话也可以接入`@ctrip/plugin-publish-crn`。

携程跨端解决方案的新选择:Taro-CRN

在Taro的目录结构中,config是Taro官方提供扩展配置的目录,在plugins中配置相关的插件依赖。

携程跨端解决方案的新选择:Taro-CRN

b. 配置CRN平台参数

在config目录下,除了插件依赖配置项之外,还有各平台的相关参数配置。CRN作为待转的平台之一,可以像其他平台一样,支持在这里扩展配置。

crn: {
    projectName: 'YourProjectName', // 项目名
    partner: 'ct', // 内部多平台配置项
    publish: {
        target: '[email protected]:Group/Project.git',
        branch: 'specBranch',
        localDir: 'specDir'
    }, // 发布插件相关配置
    dependencies: {
      "react-native-svg": "~12.1.1",
      "babel-plugin-inline-import": "^3.0.0"
    }, // 项目所需额外依赖
    enableSvgTransform: true // 项目是否需要支持SVG
    // 更多其他扩展配置
  }
           

c. 调试与构建

接下来,开发者就可以按照Taro的开发习惯,直接用`taro build --type crn`来构建,或者通过watch来进行开发调试。

携程跨端解决方案的新选择:Taro-CRN

这样用户在模拟器中,打开红框对应的地址就可以开启调试了

d. 携程主板分包小程序的接入

携程当前的小程序生态为各业务线提供了针对Taro项目的扩展配置,这部分的接入也在Taro-CRN提供了额外的支持,只需要换成引入`@ctrip/plugin-platform-crn-tarox`版本的平台插件,并增加对应的分包配置,即可按前面的流程进入开发。

4.2 CRN项目中接入Taro-CRN业务组件

在业务开发过程中,有很多场景并不需要完整页面全部支持跨端,组件上的跨端支持则更为灵活。比如对于一些业务模块卡片,Taro-CRN支持Taro开发组件并输出,提供给CRN项目或者Taro项目直接引入,做到组件级的跨端开发。这样在被接入的CRN项目中只需要引入对应Taro-CRN的依赖,然后接入额外的metro配置即可。

const TaroCRNMetroConfig = require("@ctrip/metro-taro-crn");
const configBu = {
    resolver: TaroCRNMetroConfig.resolver,
    transformer: TaroCRNMetroConfig.transformer,
};


module.exports = configBu;
           

五、框架总结

对于跨端开发,业内其实有提供很多方案,开发者只有了解各自方案的使用场景,才能做出适合项目的选型。Taro-CRN的适合的场景:

1)适用于已有CRN支持的APP接入Taro方案;

2)适用于需要提供业务模块同时支持APP与小程序的场景;

3)适用于缺少RN开发经验的团队实践跨端开发。

当然,Taro-CRN框架仍是需要持续地打磨与优化。尤其为应对更加复杂的业务场景,在基础组件之上可以开发更多适配多平台的业务组件,来进一步的提升开发效率。这也是后续我们与携程内部多方合作优化的方向之一,以便于更好的促进Taro技术生态在携程的落地,给与开发者更多选择的空间。欢迎感兴趣的Taro或RN的开发者交流意见。

【推荐阅读】

  • 耗时缩短2/3,Taro编译打包优化实践
  • 携程小程序生态之Taro跨端解决方案
  • Taro性能优化之复杂列表篇
  • 小程序跨端框架实践之Remax篇
携程跨端解决方案的新选择:Taro-CRN

 “携程技术”公众号

  分享,交流,成长

继续阅读