去哪儿网用户体验之端上优化实践

一、布景

去哪儿观光APP作为我们用户流量的首要进口，其运转性能和用户体验的黑白，间接影响着用户操纵的吃力度，终极能够影响收益。

是以我们一向很关注 App 上的用户体验，进步 App 性能，使得用户在拜候页面时，更流利，更稳定，更便利，从而进步营业转化率。

用户体验优化，首先要处理界说丈量的题目。利用科学的权衡手段，评价 App 性能现状，以数据为导向，分析提升空间、并利用公道的技术计划停止改良。

开初，这类丈量系统由多个团队各自保护，形式多样，也没有同一的评价标准，且不具有可延续性。是以，需要建立一个同一、客观、牢靠、而且可延续的可视化丈量平台来处理前面的题目，因而 QDD（Qunar Develop Digital）数字化平台应运而生，QDD 平台中的用户体验模子由：流利度、稳定性、能耗等多个目标来组成，并针对去哪儿观光 APP 内各个页面依照这些目标停止丈量。（《用户体验数字化平台落地》可领会QDD的详情先容）

基于 QDD 丈量成果，我们发现与用户预订相关的焦点页面在流利度、稳定性、能耗等方面均有提升空间，因而开启了 App 的优化之路。

本文首要从焦点的流利度目标来展开，把我们的优化进程中的思考、计划和功效分享给大师，来帮助大师处理类似的题目。

二、流利度目标

首先我们来领会一下贱利度模子是怎样界说的，流利度首要包括：TTI、FCP、FPS和卡顿四个更细的目标。其中 TTI 是与用户体验相关最重要的目标。TTI (Time to interactive)是指：从页面加载起头到页面处于完全可交互状态所花费的时候。Qunar 的 TTI 较业内更加严苛，我们的 TTI 起头时候是从路由跳转起头计较，终极到页面获得到有用数据完成衬着到达可交互状态为止。诠释完什么是 TTI 以后，还需要补充一个布景：去哪儿客户端里的很多焦点页面是基于 React Native 来实现，这些页面依照营业分别打包成多个 QP 包。QP 包是一种用来做静态资本离线的资本包，在翻开一个页面时，去哪儿客户端会先下载大概加载页面地点的 QP 包。所以我们的页面TTI除了路由相关，还需要关注React Native 所依靠的离线资本 QP 包的加载，剖析，以及 RN 页面的实例化到衬着等阶段，详见下图：

三、整体优化战略

经过度析前面的 TTI 时序图，我们预备从三个大的偏历来侧重尝试寻觅优化空间，别离是：JSBundle 加载提速，页面衬着提速，办事请求优化 。

四、JSBundle 加载提速

（一）预加载 JSBundle

在合适的机会，停止 JSBundle 的预加载，对于实现 RN 页面的秒开，有侧重要的意义。预加载有两个关键点，不能影响用户其他体验，若何深入场景进步预加载的射中率。同时，受限于移动装备的内存限制，我们也应当有合适的停止烧毁机会的处置，避免发生内存题目。

（二）JSBundle 瘦身

我们晓得 Bundle 的巨细，将间接影响 Bundle 的下载时长息争析时长。在停止用户体验优化前，Bundle 巨细是我们的重要治理工具。经过 webpack-bundle-analyzer，我们可以获得 Bundle 的巨细组成，从以下几个方面动手，动手相关优化：

1. 清算无效援用或下线的代码文件。

2. 为了提升用户体验，我们会将项目中用到的静态资本图片与 Bundle 打包一路下发，这样需要我们挑选合适的图片格式到达更小的Size。如以JPEG和 WEBP 替换 PNG 。

3. 挑选合适的三方库，如可利用 dayjs-2kb 替换 moment.js-200kb ，巨细大幅下降但功用稳定。

4. 利用根本框架供给的 qrn-es6 计划优化，qrn-es6 编译后的 bundle 产物整体都是 ES6 的代码，少去了很多 babel-helper 的代码，现实数据来看，Bundle 巨细最多可以削减 14% 。

（三）JSBundle 拆包处置

斟酌到机酒火支流程的 Bundle 包均匀 5M 左右，为了进步首屏的显现速度，我们还需要进一步对 JSBundle 停止拆包。我们早期已将线上运转的 bundle 包拆分红了两种，框架包和营业包，营业包共用一个框架包。现根本架构已支持对营业包进一步拆包，在加载营业包时，可经过设置决议是加载全量的营业 Bundle 还是支持拆包的 RamBundle ( Random Access Modules，随机存取模块) 。我们 RamBundle 拆分为主包和子包，拆分后主包更小，加载速度更快。子包内的模块以 Inline Require 的方式按需加载，可以提早模块或文件的加载，做到更高效的加载。线上数据显现，拆包可以提升 TTI 时候 10-15% 。再进一步配合骨架屏的利用，首屏可见时候提升 30-50% 。

五、页面衬着阶段优化

这里页面衬着阶段是指从建立 RN 页面到页面可交互的进程。这个阶段我们首要利用了两个优化计划：页面预加载和非焦点视图延后加载。

（一）页面预加载

道理讲授

之前我们做了 JSBundle 预加载的优化，实现了翻开RN页面的时辰不需要先加载 JSBundle 的结果，所以一般来说我们一个 JSBundle 包中会放多个 RN 页面。可是在翻开 RN 页面的时辰，我们还要做一些代码加载的工作。为了更好地诠释这个题目，我们先领会一下我们的 RN 页面加载的进程。页面加载的的进程大致是以下的流程：

在加载 JSBundle 阶段，我们会在履行 JSBundle 的时辰注册好页面期待挪用。具体流程是将 JSBundle 加载到内存中以后，然后会履行进口 js 代码，这个时辰我们就会挪用 AppRegistry.registerComponent 方式，将页面注册进去。一般我们在进口代码中依靠了的 js 模块城市被加载并履行，可是被注册的页面的相关代码并不会自动加载履行。为了尽快完成 JSBundle 的加载，一般我们也不会在加载 JSBundle 的时辰将一切代码都预加载。而是当建立页面的时辰，复兴头加载并履行页面相关的代码。

计划先容

现实中履行流程以下：

从这个流程中，我们可以看到，加载相关 js 代码是可以提早到前一个环节中的。经过革新，优化后的流程以下：

这样，我们就在页面建立到首屏衬着进程中削减了加载 js 代码的时候。

优化结果

页面均匀 TTI 时候优化后下降 5% 以上。

（二）非焦点视图延后加载

布景先容

从页面加载完成以后，就是起头衬着、首帧绘制、页面可交互三个阶段。由于我们做了接口的预请求，而且接口返回时候通常为大于首屏衬着时候的，所以这个阶段的时候优化首要看收到接口数据今后若何优化衬着速度(下图橙色地区)。

从上图可以看到，从 loading 状态今后，就会衬着一切页面元素，这里营业复杂，衬着耗时最高，我们需要收缩主内容的 DOM 更新和视图显现时候，让页面焦点内容和用户交互功用优先可用 。

战略挑选

1. 下降复杂度：js 侧中的 render/didmount/didupdate 仅是视图变更操纵 commit 前的行为，不触及现实的 native 侧 Flat 结构转换和衬着进程，是以这部分时候仅由营业逻辑和数据转换复杂度、DOM 树复杂度决议纯 CPU 计较类耗时，这部分可经过中大范围重构来优化，但性能优化收益较为有限。效益一般，本钱偏大，风险偏高。

2. 渐进式衬着，将上方紫色地区所触及的 DOM 元素更新需求按优先级做分组，经过干涉组件 DOM 更新，优化调剂顺序，力图到达下图所示 DOM 更新顺序结果。假如设想适当可以预期效益明显，本钱一般，低风险。

平衡效益、本钱、风险峻素本期挑选II作为优化战略实施。

计划先容

基于 React Native 的 JSTImers 实现和使命调剂方式道理，将衬着优先级分级为 5 个级别以下：

我们可以供给一个 HOC 高阶组件 Slugger 来切断 React 原本的父子组件的更新联动，基于调剂战略在对应的履行周期上提交对干涉的方针组件 Target 的 props 点窜。

在非 OP_INLINE 形式下，答应供给 placeholder 属性来定制占位视图，该视图会在组件被 mount 前用于占位显现。

利用说明

1.挑选需要停止衬着干与的组件，根据但不但限于下面要求：

• 不能利用于该流程功用决议的信息（如价格信息，航班信息）
• 不能利用于流程流转的组件，（如返回、下一步类操纵：预定/选购/付出/检察详情等)
• 不能是确认性信息（例如免责条目/利用协议/政策性需求公示内容）

2.对衬着干与组件停止点窜

优化结果

页面均匀 TTI 时候优化后下降 10% 以上。

六、办事请求优化

App 中大大都页面都是利用接口请求返回的数据衬着页面。从 TTI 时序图中可以看出，接口请求时长，间接拖慢页面 TTI 阶段的耗时。是以想要下降TTI时长，接口的响应时候也是我们可以尽力的一个偏向。针对办事接口响应时候的优化，首先想到的就是接口提速，下降请求数据的时长；其次是针对合适的营业场景能否是可以提早加载数据，这样需要时便可以间接利用预先加载好的数据，来到达下降 TTI 的方针；所以办事请求的优化，我们首要做了两件事：接口响应时长优化和预请求。

（一）接口时长优化

经过度析各营业线支流页面，发现很多页面接口耗时在TTI中的占比大约在50%左右，是以接口提速有很大的优化空间，因而我们起头push对应的后端团队来优化接口时长。下面是酒店营业中某个场景的优化结果：接口链路复杂度高、不需要的串行挪用办事，城市增加接口响应时长。酒店报价团队精简接口链路，进订接口耗时缩减约150ms，填单页TTI时长也响应下降。

（二）预请求

预请求的焦点逻辑是，在不影响当前页面加载的情况下，提早发出下一个页面的接口请求，将返回成果存储到缓存中。这样下一个页面的 TTI 中，几近完全消除了收集请求时候的占比，到达页面【直出】的结果。预请求需要处理两个题目：

• 触发预请求的机会

前端发出的请求参数与用户交互有关，营业逻辑越复杂的页面，预请求的难度越大。假如对用户行为预判不够精准，还会致使大量无效请求，增加接口 qps ，形成办事资本的浪费。我们从用户行为埋点、ctr 等数据分析，斟酌将以了局景实现预请求逻辑：

• 预请求数据的有用性

酒店中大部分页面临数据实时性要求比力高，例如：酒店房型、房间价格对用户来说是静态信息，实时都有变化的能够，需要避免信息纷歧致形成用户误解和不需要的损失。是以在请求参数稳定的情况下，预请求缓存的数据需要设备公道的生效时候。

七、整体优化

功效总结一下上面的三种优化计划别离带来的结果以下，按照具体页面的复杂度和现真相况，数据能够会略有波动：

经过半年的尽力，不竭摸索 TTI 各阶段的优化空间，计划在一些页面获得考证后，就敏捷推行到其他营业和团队，来配合优化提升我们整体的用户体验 TTI 目标；下图是某个具体的页面在上述优化后的 TTI 目标变化：（分值越高，结果越好）

这是大盘的 TTI 目标，也有了明显的提升，随着连续优化的页面数目增加，相信大盘的整体的 TTI 还会进一步提升；

未来，我们将面临更大的应战，除了挖掘新的提升空间之外，还要在越来越多的复杂营业迭代下，保持性能的稳定性。