一、项目背景及目标

1. 人力成本上升，开发人员需掌握多种技术栈，学习成本高、负担重；

2. 维护成本增加，问题修复与迭代升级周期延长，效率降低。

二、技术选型

1. 考量因素

• 当前火车票前端需求以RN开发为主，需将RN项目高效转化为多端应用，提升产品体验一致性。

• QTaro是大前端中心基础框架团队基于Taro打造的多端解决方案，支持小程序、H5与RN项目同步开发。其在原生Taro生态基础上，提供了公司内部多端开发工具、业务扩展库及开发规范，能有效降低业务前端开发成本。QTaro还提供RN代码转换、运行时支持及项目发布能力，与火车票项目诉求高度契合。

• 尽可能保留原有RN开发习惯，降低团队学习成本。

2. 方案挑战

• 组件与属性差异大：涉及RN/QRN/第三方库组件与API约82处，CSS 属性差异30余处，如何抹平差异实现无缝衔接是关键。

• 业务逻辑层多端差异：页面路由、登录、支付等功能需各端独立实现。

• 多端性能优化：转换后代码在各端的性能表现需持续优化。

• 请求接口统一：如何实现各端网络请求接口的统一封装。

三、项目筹备

• 一期目标：完成订单详情页从RN到QTaro的转换，并上线微信小程序版本。选取该页是因为其UI组件丰富、交互相对简单，适合作为技术验证切入点。

• 二期目标：完成火车票所有RN项目的转换并全端上线。

四、迁移实战

1.转换工具设计

1.1 整体流程

1.1.1 方案选型

• 方案一: RN转多端。以RN项目为开发起点，隐藏中间转换项目，保持RN开发习惯，实现RN→多端单向转换，学习与开发成本最低。

• RN转换成QTaro中间项目

• 中间项目转多端（WX小程序/H5/ALI小程序）的方式，是RN单向转换，最小的开发成本就可实现RN代码一拖六

• 方案二: QTaro转多端。以QTaro中间项目为起点，实现QTaro→6端转换，转换工具实现复杂，且需遵循RN样式约束，开发成本较高。

  综合评估后，选择方案一：RN转多端。兼顾开发效率、开发成本、学习成本，以及减少对当前RN项目的影响。

• 从QTaro中间项目作为开发起点，转RN。必须按照规范《 React Native 端开发前注意》开发，涉及6端的转换, 转换工具实现复杂；

• 按照QTaro的RN规范开发，本质是以RN的样式管理约束。在样式上统一多端，木桶效应，短板对齐（向最弱的RN对齐）；

• 在灵活的QTaro项目下开发，还要施加RN的样式约束，不如直接以RN项目开发更顺畅；

• QTaro->RN可能存在诸多问题，对当前RN项目影响大(线上出故障的概率变高)而且增加维护成本。

1.1.2 中间项目说明

• 中间项目是临时&隐藏项目,  位置在当前项目.taroCache/project目录下。开发者不需要关心.taroCache，可以认为它不存在。

• 中间项目符合QTaro框架规范的要求。

• 开发者使用rn2QTaro cli命令行进行操作，内部调用Taro命令对中间项目进行构建。

• 经过Taro build的处理之后，中间项目将会生成目标平台产物。

1.1.3 一套代码6端复用的思路

• RN项目->转换工具->QTaro中间项目->ALI小程序/WX小程序/H5  3端

• RN项目->Metro->IOS/Adr/Harmony  3端

1.2 转换工具流程图

1.2.1 初始化中间项目

1. rn2QTaro拉取模板项目。模板项目是最小化的QTaro Js项目，承载转换后的JS代码。

1.2.2 转换过程

1. 转换工具遍历项目所有JS文件，根据配置项，将RN/QRN等相关库映射为替换库。

2. 删除RN项目中所有propTypes。

1.3 RN库映射多端库

1.3.1 架构图说明

1. 转换工具根据配置文件，把项目中使用的RN库映射为对应的多端库。

2. 多端库通过QTaro的MultiPlatformPlugin引用对应平台实现的组件和API。

1.3.2 架构亮点

1. 多端库的代码结构设计，利用QTaro已有的多端能力(MultiPlatformPlugin)进行多平台切换，简单高效。

2. 通过封装QTaro抽象层的组件和API构建的RN等效多端库，可以随QTaro的扩展而动态支持更多平台。

1.4 抹平组件属性差异

1.4.1 方案选择

• RN和其他端相同功能的组件，例如: View, Text等,  默认属性差异大, 且style属性多为动态赋值，用babel处理非常复杂。例如: 为CSS样式width属性添加'PX'单位。期望将width: 20转义为width: "20PX"，但实际项目多是动态赋值:

• babel转义难以完成。

• 选用运行时方案，仅需封装各端的组件和API，修改接口或属性向RN对齐，即可完成。

• 在RN项目中，多采用import进行引用，而import语句本身是静态的，在转义阶段就已确定，因此import路径的替换必须放在转义时进行。

1. 通过babel AST完成RN库映射为多端库。

2. 在运行时抹平各组件CSS样式差异，抹平样式模块封装在基类组件中。

1.4.2 行内样式 & 样式文件

RN使用JS对象来定义样式，并通过StyleSheet.create方法来创建样式表。

//styles.js
const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: '#F5FCFF',
  }
});


//App.js
<Viewstyle={styles.container}>
</View>

1. babel AST转为

//styles.js
//babel转义: 把StyleSheet.create的入参，直接赋值给styles
const styles = {
  container: {
    flex: 1,
    backgroundColor: '#F5FCFF',
  }
};


//App.js
<Viewstyle={styles.container}>
</View>

2. 自己实现StyleSheet.create

1.4.3 行内样式style兼容

//RN中style支持样式数组，QTaro中不支持
<Viewstyle={[styles.container,extraStyle]}>
</View>

解决方法:

1. 自己实现StyleSheet.flatten，递归地展平数组中的每个样式对象，并将它们合并成一个单一的样式对象。

2. 样式处理

3. 方式1: babel 转义

//RN中style支持样式数组，QTaro中不支持
<Viewstyle={StyleSheet.flatten([styles.container,extraStyle])}>
</View>

1.4.4 更多样式问题

//RN代码 shadow样式
StyleSheet.create({
    myView: {
        shadowRadius: 5,
        shadowOpacity: 0.5,
        shadowOffset: {x: 2, y: 2},
        shadowColor: 'gray'
    }
})
//转为 react boxShadow样式
StyleSheet.create({
    myView: {
        boxShadow: `2PX 2PX 5PX 0PX gray`
    }
})

4. 样式替换 

例如: RN的marginStart需要替换为marginLeft, marginHorizontal需要替换为marginLeft, marginRight。

//RN属性
{
        marginHorizontal: 10
}


//转换后代码
{
    marginLeft: 10PX,
    marginRight: 10PX
}

2. 实现RN多端库

2.1 已实现多端库

2.2 组件实例接口差异

1. this.viewRef.current.measureLayout测量视图布局

2. this.qVideoRef.current.play/pause/seek视频播放等操作

3. this.textInputRef.current.blur/isFocused判断焦点操作

3. 业务代码多端适配方案

3.1 架构说明

3.2 NativeModules多平台切换

• RN平台通过@taro/NativeModules/index.js引用react-native的 NativeModules

• WX平台通过

  @taro/NativeModules/index.weapp.js引入weapp多端库实现。

• 多端适配前

• WX平台

  @taro/NativeModules/index.weapp.js

//微信小程序平台导出自定义 NativeModules, 对外接口和RN平台保持一致。外部通过 NativeModules.TRNQunarNetwork 获取WX平台请求接口  
const NativeModules = {    
  TRNQunarNetwork，//封装了WX端实现类  
}   
export default NativeModules; 

3.3 方案总结

4. 项目的难点

4.1 RN转微信小程序严重超Size问题

4.1.1 背景

4.1.2 解决方案

4.1.2.1 MPA面临的问题

解决方法 : 难以修复。火车项目页面>100个，MPA下修复共享实例问题，需要改动的代码量巨大，将会严重阻塞项目进度。

4.1.2.2 SPA面临的问题

解决方法：多个RN项目合并打包，打出一个H5产物。

4.1.2.3 MPA和SPA共同面临的问题

五、项目复盘

5.1 项目的成果

5.1.1 转换工具代码复用度87%

5.1.2 一套代码多端复用

5.1.3 节约人力成本>50%

• 接入QTaro方案，节省(300%-160%)/300% =47%

• 业务差异封装后,  节省(300%-100%)/300% =67%

• 覆盖的端越多，每端成本越小

5.1.4 突破小程序Size限制

5.2 不足与展望

5.2.1 组件兼容性

• WX动画是通过API createAnimation实现,  而RN的Animated由3-4个API配合使，考虑到调用方式以及动画与组件的关联，完全模拟较为复杂。

• wx.createAnimation依赖于小程序的JS运行环境，受限于小程序的性能和资源分配，尤其是在低端设备上，容易出现卡顿。

5.2.2 转换工具覆盖度

5.2.3 样式边缘情况

六、结语