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

   <p>火车票作为携程体系下的重要环节，要兼顾良好的App用户体验及迅速的业务迭代，一个月左右一次App版本的节奏很难满足，而React Native跨平台、媲美原生App的用户体验以及无需发版的升级模式等等优势无疑使人眼前一亮。</p>    <p>加上基础团队的Ctrip React Native框架对RN的性能优化、业务封装以及拆包发布等的大力支持，火车票现已上线将近20个RN页面，经历了携程App三个大版本的迭代与考验。</p>    <p>本文将着重介绍React Native在携程火车票产品中的应用，以及在RN实践过程中遇到过的一些实际问题与解决方案。</p>    <p>本文大致分以下几块内容：</p>    <ol>     <li>为什么选择React Native</li>     <li>React Native的现状</li>     <li>Ctrip React Native</li>     <li>携程火车票的RN应用</li>     <li>踩过的坑及解决方案</li>     <li>各种问题及优化步骤</li>    </ol>    <h3><strong>一、为什么携程火车票要选择React Native</strong></h3>    <p>作为目前携程App为数不多的主要以原生开发方式为主的BU，我们也曾在Native跟Hybrid两种方案中纠结过，一方面，原生的交互性能跟用户体验都是最优的，Hybrid则始终还未能突破性能瓶颈；但是另一方面，原生应用的更新又是一个很大的问题，尤其是iOS的AppStore，每次发布更新都需要漫长的审核周期，无法做到及时更新，并且上线之后的维护也非常麻烦。</p>    <p>对于业务高速发展、更新比较频繁的火车票业务来说，携程App一个月左右一次的大版本发布已然无法满足需求。所以这个时候，基本兼顾到体验与更新两方面优势的React Native的出现，无疑非常值得我们一试。</p>    <p>从性能体验来说，Native最为优秀，RN基本接近，Hybrid则有些硬伤，因为Hybrid的View层实际上还是前端开发人员所熟知的DOM，而React Native则是以Virtual DOM的方式操作跟渲染相应平台的UI组件，所以性能要高于Hybrid而不逊色于原生；而更新复杂度上，Hybrid跟RN都比较低，可以进行无需发版的bundle包更新，而Native则受限于应用商店的发布更新，复杂度最高；另外，从开发成本角度来看，Native开发周期相对较长，编译调试也相对复杂，并且不能跨平台，Android跟iOS需要维护两套完全不同的代码，RN虽然比Hybrid成本稍高，但是远小于Native，可以做到大部分代码的跨平台复用。</p>    <p><img src="https://simg.open-open.com/show/f7041b237d3e611cff55d3416a6fa33e.jpg"></p>    <h3>二、 <strong>React Native</strong> <strong>的现状</strong></h3>    <p>从这上述的几个方面来看，RN的各项表现都是非常优秀的。然而，目前React Native仍以每两周一个版本的更新频率快速变化中，到现在最新的0.35，仍旧是以零点几的版本在定义，还不能算是一个完全成熟的框架，所以在实际应用过程中还有许多坑要趟。比如版本升级问题，有时候可以平滑过渡，有时候就没那么轻松了。</p>    <p>就拿我们年初实践的汽车票独立版来说，1月份刚开始使用的时候，React Native刚开源Android版本不久，在Android上的兼容性还不是很乐观，所以只在iOS上做了尝试，我们最开始使用的是0.18的RN版本，从如何集成到现有的App里、怎么打全量包或增量包、以及bundle包的发布等等问题，当时都是组里的小伙伴跟iOS开发小伙伴自己一步步摸索过来的，但是在RN的快速更迭下，等尝试升级到零点二几的RN版本时，一言不合某些组件跟API就不能用了。</p>    <h3>三、 <strong>Ctrip React Native</strong></h3>    <p>在携程基础团队向我们各个业务团队提出Ctrip React Native的支持时，我们几乎毫不犹豫就确定要在携程火车票里接入了，算是公司里RN应用比较早的BU，也是第一个使用RN进行完整的购票下单流程的BU。</p>    <p>CRN抹平了很多iOS跟Android组件的差距，比如DatePicker、SegmentedControl，提供各种携程风格的组件和API，如HeaderView、HtmlText、Storage、Fetch等，使业务开发更专注于业务逻辑，不需要过多费精力在跨平台的代码实现上，也避免了各个BU的大量重复劳动；</p>    <p>此外，CRN对首屏渲染速度的提升，使iOS能在200ms，Android在400ms左右完成首屏渲染，以及对ListView的优化等都让React Native向Native靠近了一大步；另外，包括对打包拆包、业务代码发布及诸多工具比如crn-cli的提供和支持，都让业务方更无压力的接入RN应用。</p>    <p>可以说，CRN实现了把React Native作为一个纯技术框架像业务框架的转变。</p>    <h3><strong>四、携程火车票的 React Native 应用</strong></h3>    <p>携程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个，包括云抢票、改签抢票、接送站等业务，并且这些页面大部分都比较重要且有较为复杂的交互逻辑。</p>    <p><img src="https://simg.open-open.com/show/fc151b6a1567b7619705d3320abc85a2.jpg"></p>    <h3><strong>五、踩过的坑及解决方案</strong></h3>    <p>从一个火车票购票流程里粗略提取一下具体实现就有如下几点：</p>    <p>1、从几千个城市站点里选择目标城市</p>    <p>2、在各种车次、座席、出发时间里筛选出合适的车次</p>    <p>3、乘客信息的填写或者选择</p>    <p>首先，购票流程第一步的站点选择，就遇到了一个大坑：大家应该知道全国大大小小的火车站至少有数千个。而接触过RN社区的小伙伴应该知道，React native的GitHub上有条臭名昭著的issue，官方至今还没有完美的解决方案，就是ListView的性能问题。RN自带的ListView是没有回收机制的，这样就使得RN在加载较多个数据的列表，App会非常吃内存。</p>    <p>我们一开始也尝试用自带的ListView来加载城市站点列表，几千条纯Text渲染下来时感觉还能勉强接受，但在加上了View布局、Touchable事件之后，当时连在iPhone 6，iOS 8.2的系统下也非常吃力，越滑越卡，甚至在较低配置的设备上还出现卡死甚至crash的现象。</p>    <p>实际上，城市站点选择是一个变更频率很低但是使用频率很高的页面，考虑到RN ListView的优化空间有限，一旦出现卡死，对火车票来说，结果基本是灾难性的，所以我们最终选择了复用原生已有的城市选择页面，由封装成一个station component供RN使用。</p>    <p><img src="https://simg.open-open.com/show/f69a543ac04a24d2fe3ddf79fa70583e.jpg"></p>    <p>现在我们考虑下另外一个重要场景的实现，从账号里的常用乘客列表里勾选乘车人，同样作为一个列表，是不是也可以像站点列表一样复用native组件呢？我们也确实这样考虑过，看起来好像省时省力、皆大欢喜。但其实正常情况下，个人账号里的乘客数量远小于上千条的站点数据，RN实现是可以负荷下来的。而且station component只需要传给native一个已选的车站，然后native组件里操作完成后返回一个重新选择的车站就可以了。</p>    <p>乘客列表并非简单的单选，而且除了点选，还涉及到新增编辑等等更多的交互。由native封装的话，涉及到的参数传值未免太多。那么是不是可以跳转到一个新的页面，加载跟渲染数量较少的乘客列表比较方便实现呢？</p>    <p>从产品层面来说，火车票购买作为一个购票流程，每多跳转一个页面就有可能损失一部分转化率，所以为了尽可能减少页面的跳转，我们采用了浮层形式在订单填写页面里进行乘车人的选择。然后问题又来了，在浮层弹出的动画过程中加载并渲染乘客列表，很容易出现失帧卡顿的现象。如何解决？</p>    <p>我们是这样考虑的，列表的加载并不是非要在浮层弹出的同时进行的，在进到订单填写页时就可以预先加载好乘客列表数据，而只在浮层里做渲染即可。而且可以在不影响用户视觉体验的前提下，增加一些短时间的延迟。先完成浮层的弹出动画，使用RN InteractionManager的runAfterInteractions等动画结束之后渲染数据，并且设置了ListView的initialListSize跟pageSize均为1来逐条进行渲染。</p>    <p><img src="https://simg.open-open.com/show/16bcbd34e5ab76e4657605b4fb7c97a9.jpg"></p>    <p>前面也提到了，我们是希望尽可能减少页面跳转的，所以像车次类型、时间段筛选、座席选择以及前面提到的乘客选择，都是在各个页面采用浮层形式来实现的。但其实浮层涉及到的问题相当多，这里仍旧以乘客选择浮层为例。乘客浮层要实现的功能非常之多，首先，内部的列表是可以滑动的，上部分的阴影可以点击消散浮层，并且内部的Item又要响应各种点击操作。</p>    <p>拿到这么一个复杂的需求，最开始的做法是先给整个Modal加个TouchableHighlight事件来处理消散动作，然后内层加上TouchableWithoutFeedback来避免触发外面的hideModal动作，</p>    <p>然后再在每个Item上加各自响应的Touchable事件响应勾选或者取消。然而，各种Touchable事件嵌套之后，实际效果就不在预期范围内了：滑动内层列表的时候突然划不动，点击Item却没有反应等等，经过一番调试跟定位，终于确定，ScrollView滑动过程中很容易触发到外层的TouchableWithoutFeedback，所以也就without feedback了。</p>    <p>问题一定位，解决方案自然也就出来了，Touchable的过多嵌套导致了问题的产生，那么就应该重新进行层级的布局，避免这些不应该的嵌套，不在整个Modal上加hideModal事件，而是抽出与浮层同级的View来做消散动作，内层只专注于List的渲染跟Item的点击事件监听。</p>    <p><img src="https://simg.open-open.com/show/64390e48127b1021c3eb776e36efdc9a.jpg"></p>    <h3><strong>六、各种问题及优化步骤</strong></h3>    <p>除了上述那些复杂的需求导致的复杂实现，还遇到过很多比较low的问题。大多数时候如果知道了一些属性就完全可以避免很多问题的产生。</p>    <p>不知道大家有没有遇到过setState方法刚设置完一个状态，取这个状态却发现没有生效的情况。这个异步方法让我写出过很多丑陋的setTimeout来尝试解决。结果查阅React文档后发现setState是有第二个参数的，这个参数就是设置完state之后需要立即调用的函数。</p>    <p>另外，合理使用key属性跟各种React生命周期钩子函数，如shouldComponentUpdate，可以优化很多性能问题。</p>    <p>再比如长按累加累减这样的需求，单纯的onPress跟onLongPress是不能实现的，需要结合delayLongPress直接触发onLongPress，并且在onLongPress里进行setInterval的递增或者递减操作，然后在onPressOut解除press动作的同时clearInterval。</p>    <p>伴随着业务的高速发展，逻辑越来越复杂，我们也逐渐发现了很多做得不好，值得优化的地方。像前面提到过的View层级过多导致的内存消耗、页面卡顿。页面逻辑复杂导致state设置过多，出现切换卡顿现象，并且状态管理越来越混乱。而且现在很容易出现单个页面动不动就一两千，甚至几千行代码，维护起来非常困难，还有很多重复的代码实现等等。</p>    <p><img src="https://simg.open-open.com/show/4eba53fe883c73eb472a60a09c6b92fb.jpg"></p>    <p>这些问题我们也在考虑从很多方面优化，像布局上尽可能减少层级嵌套，尽可能抽取能够复用的组件，都是大家需要注意的点，状态管理上我们也在考虑如Redux等一些好的解决方案的引入。</p>    <p> </p>    <p> </p>    <p>来自：http://techshow.ctrip.com/archives/1448.html</p>    <p> </p>