现在的位置: 首页 > iOS开发经验 > 正文

那些携程火车票业务在RN实践中踩过的坑

2016年11月10日 iOS开发经验 ⁄ 共 4535字 ⁄ 字号 评论关闭


火车票作为携程体系下的重要环节,要兼顾良好的App用户体验及迅速的业务迭代,一个月左右一次App版本的节奏很难满足,而React Native跨平台、媲美原生App的用户体验以及无需发版的升级模式等等优势无疑使人眼前一亮。

加上基础团队的Ctrip React Native框架对RN的性能优化、业务封装以及拆包发布等的大力支持,火车票现已上线将近20个RN页面,经历了携程App三个大版本的迭代与考验。

本文将着重介绍React Native在携程火车票产品中的应用,以及在RN实践过程中遇到过的一些实际问题与解决方案。

本文大致分以下几块内容:

  1. 为什么选择React Native
  2. React Native的现状
  3. Ctrip React Native
  4. 携程火车票的RN应用
  5. 踩过的坑及解决方案
  6. 各种问题及优化步骤

一、为什么携程火车票要选择React Native

作为目前携程App为数不多的主要以原生开发方式为主的BU,我们也曾在Native跟Hybrid两种方案中纠结过,一方面,原生的交互性能跟用户体验都是最优的,Hybrid则始终还未能突破性能瓶颈;但是另一方面,原生应用的更新又是一个很大的问题,尤其是iOS的AppStore,每次发布更新都需要漫长的审核周期,无法做到及时更新,并且上线之后的维护也非常麻烦。

对于业务高速发展、更新比较频繁的火车票业务来说,携程App一个月左右一次的大版本发布已然无法满足需求。所以这个时候,基本兼顾到体验与更新两方面优势的React Native的出现,无疑非常值得我们一试。

从性能体验来说,Native最为优秀,RN基本接近,Hybrid则有些硬伤,因为Hybrid的View层实际上还是前端开发人员所熟知的DOM,而React Native则是以Virtual DOM的方式操作跟渲染相应平台的UI组件,所以性能要高于Hybrid而不逊色于原生;而更新复杂度上,Hybrid跟RN都比较低,可以进行无需发版的bundle包更新,而Native则受限于应用商店的发布更新,复杂度最高;另外,从开发成本角度来看,Native开发周期相对较长,编译调试也相对复杂,并且不能跨平台,Android跟iOS需要维护两套完全不同的代码,RN虽然比Hybrid成本稍高,但是远小于Native,可以做到大部分代码的跨平台复用。

二、 React Native 的现状

从这上述的几个方面来看,RN的各项表现都是非常优秀的。然而,目前React Native仍以每两周一个版本的更新频率快速变化中,到现在最新的0.35,仍旧是以零点几的版本在定义,还不能算是一个完全成熟的框架,所以在实际应用过程中还有许多坑要趟。比如版本升级问题,有时候可以平滑过渡,有时候就没那么轻松了。

就拿我们年初实践的汽车票独立版来说,1月份刚开始使用的时候,React Native刚开源Android版本不久,在Android上的兼容性还不是很乐观,所以只在iOS上做了尝试,我们最开始使用的是0.18的RN版本,从如何集成到现有的App里、怎么打全量包或增量包、以及bundle包的发布等等问题,当时都是组里的小伙伴跟iOS开发小伙伴自己一步步摸索过来的,但是在RN的快速更迭下,等尝试升级到零点二几的RN版本时,一言不合某些组件跟API就不能用了。

三、 Ctrip React Native

在携程基础团队向我们各个业务团队提出Ctrip React Native的支持时,我们几乎毫不犹豫就确定要在携程火车票里接入了,算是公司里RN应用比较早的BU,也是第一个使用RN进行完整的购票下单流程的BU。

CRN抹平了很多iOS跟Android组件的差距,比如DatePicker、SegmentedControl,提供各种携程风格的组件和API,如HeaderView、HtmlText、Storage、Fetch等,使业务开发更专注于业务逻辑,不需要过多费精力在跨平台的代码实现上,也避免了各个BU的大量重复劳动;

此外,CRN对首屏渲染速度的提升,使iOS能在200ms,Android在400ms左右完成首屏渲染,以及对ListView的优化等都让React Native向Native靠近了一大步;另外,包括对打包拆包、业务代码发布及诸多工具比如crn-cli的提供和支持,都让业务方更无压力的接入RN应用。

可以说,CRN实现了把React Native作为一个纯技术框架像业务框架的转变。

四、携程火车票的 React Native 应用

携程App从6.17版本开始有业务试用React Native,到6.18也只有2个BU尝试了3个RN页面的上线。到6.19版本,火车票RN强势加盟,7个BU,21个RN页面里,单火车票一家就占了8个。再到6.20版本,在CRN的加持下,15个BU接入了50+的页面,我们到达了17个,包括云抢票、改签抢票、接送站等业务,并且这些页面大部分都比较重要且有较为复杂的交互逻辑。

五、踩过的坑及解决方案

从一个火车票购票流程里粗略提取一下具体实现就有如下几点:

1、从几千个城市站点里选择目标城市

2、在各种车次、座席、出发时间里筛选出合适的车次

3、乘客信息的填写或者选择

首先,购票流程第一步的站点选择,就遇到了一个大坑:大家应该知道全国大大小小的火车站至少有数千个。而接触过RN社区的小伙伴应该知道,React native的GitHub上有条臭名昭著的issue,官方至今还没有完美的解决方案,就是ListView的性能问题。RN自带的ListView是没有回收机制的,这样就使得RN在加载较多个数据的列表,App会非常吃内存。

我们一开始也尝试用自带的ListView来加载城市站点列表,几千条纯Text渲染下来时感觉还能勉强接受,但在加上了View布局、Touchable事件之后,当时连在iPhone 6,iOS 8.2的系统下也非常吃力,越滑越卡,甚至在较低配置的设备上还出现卡死甚至crash的现象。

实际上,城市站点选择是一个变更频率很低但是使用频率很高的页面,考虑到RN ListView的优化空间有限,一旦出现卡死,对火车票来说,结果基本是灾难性的,所以我们最终选择了复用原生已有的城市选择页面,由封装成一个station component供RN使用。

现在我们考虑下另外一个重要场景的实现,从账号里的常用乘客列表里勾选乘车人,同样作为一个列表,是不是也可以像站点列表一样复用native组件呢?我们也确实这样考虑过,看起来好像省时省力、皆大欢喜。但其实正常情况下,个人账号里的乘客数量远小于上千条的站点数据,RN实现是可以负荷下来的。而且station component只需要传给native一个已选的车站,然后native组件里操作完成后返回一个重新选择的车站就可以了。

乘客列表并非简单的单选,而且除了点选,还涉及到新增编辑等等更多的交互。由native封装的话,涉及到的参数传值未免太多。那么是不是可以跳转到一个新的页面,加载跟渲染数量较少的乘客列表比较方便实现呢?

从产品层面来说,火车票购买作为一个购票流程,每多跳转一个页面就有可能损失一部分转化率,所以为了尽可能减少页面的跳转,我们采用了浮层形式在订单填写页面里进行乘车人的选择。然后问题又来了,在浮层弹出的动画过程中加载并渲染乘客列表,很容易出现失帧卡顿的现象。如何解决?

我们是这样考虑的,列表的加载并不是非要在浮层弹出的同时进行的,在进到订单填写页时就可以预先加载好乘客列表数据,而只在浮层里做渲染即可。而且可以在不影响用户视觉体验的前提下,增加一些短时间的延迟。先完成浮层的弹出动画,使用RN InteractionManager的runAfterInteractions等动画结束之后渲染数据,并且设置了ListView的initialListSize跟pageSize均为1来逐条进行渲染。

前面也提到了,我们是希望尽可能减少页面跳转的,所以像车次类型、时间段筛选、座席选择以及前面提到的乘客选择,都是在各个页面采用浮层形式来实现的。但其实浮层涉及到的问题相当多,这里仍旧以乘客选择浮层为例。乘客浮层要实现的功能非常之多,首先,内部的列表是可以滑动的,上部分的阴影可以点击消散浮层,并且内部的Item又要响应各种点击操作。

拿到这么一个复杂的需求,最开始的做法是先给整个Modal加个TouchableHighlight事件来处理消散动作,然后内层加上TouchableWithoutFeedback来避免触发外面的hideModal动作,

然后再在每个Item上加各自响应的Touchable事件响应勾选或者取消。然而,各种Touchable事件嵌套之后,实际效果就不在预期范围内了:滑动内层列表的时候突然划不动,点击Item却没有反应等等,经过一番调试跟定位,终于确定,ScrollView滑动过程中很容易触发到外层的TouchableWithoutFeedback,所以也就without feedback了。

问题一定位,解决方案自然也就出来了,Touchable的过多嵌套导致了问题的产生,那么就应该重新进行层级的布局,避免这些不应该的嵌套,不在整个Modal上加hideModal事件,而是抽出与浮层同级的View来做消散动作,内层只专注于List的渲染跟Item的点击事件监听。

六、各种问题及优化步骤

除了上述那些复杂的需求导致的复杂实现,还遇到过很多比较low的问题。大多数时候如果知道了一些属性就完全可以避免很多问题的产生。

不知道大家有没有遇到过setState方法刚设置完一个状态,取这个状态却发现没有生效的情况。这个异步方法让我写出过很多丑陋的setTimeout来尝试解决。结果查阅React文档后发现setState是有第二个参数的,这个参数就是设置完state之后需要立即调用的函数。

另外,合理使用key属性跟各种React生命周期钩子函数,如shouldComponentUpdate,可以优化很多性能问题。

再比如长按累加累减这样的需求,单纯的onPress跟onLongPress是不能实现的,需要结合delayLongPress直接触发onLongPress,并且在onLongPress里进行setInterval的递增或者递减操作,然后在onPressOut解除press动作的同时clearInterval。

伴随着业务的高速发展,逻辑越来越复杂,我们也逐渐发现了很多做得不好,值得优化的地方。像前面提到过的View层级过多导致的内存消耗、页面卡顿。页面逻辑复杂导致state设置过多,出现切换卡顿现象,并且状态管理越来越混乱。而且现在很容易出现单个页面动不动就一两千,甚至几千行代码,维护起来非常困难,还有很多重复的代码实现等等。

这些问题我们也在考虑从很多方面优化,像布局上尽可能减少层级嵌套,尽可能抽取能够复用的组件,都是大家需要注意的点,状态管理上我们也在考虑如Redux等一些好的解决方案的引入。

 

 

来自:http://techshow.ctrip.com/archives/1448.html

 



抱歉!评论已关闭.

×