TV端Web页面性能优化实践
01
背景
随着互联网技术的持续创新和电视行业的高速发展，通过电视观看在线视频已经逐渐成为大众的重要娱乐方式。奇异果App作为在TV设备上用户活跃度最高的应用之一，为广大用户提供了丰富的内容播放服务，除此之外，同样有会员运营、专题活动等上线效率要求极高的服务提供给用户。为满足后者的诉求，我们调研了目前主流的动态化和跨端技术：H5、Flutter 和 React Native，最终从开发效率、人力成本、动态能力和性能上选择用H5方案，目前，H5页面承担了奇异果App内大量的收银、运营活动、专题等业务。然而，H5页面在TV设备上加载耗时过长是我们面临的主要困难，如何提升 H5页面在TV设备上的用户体验，是我们迫切需要解决的问题。
02
面临的挑战
**挑战1：**TV设备换机周期较长，系统碎片化问题严重，目前TV端 5.0系统以下的设备占比约 30%，占比很高。优化首先面临的是版本的跨度，兼容低版本是首要考虑。下图为TV端系统版本占比情况：
**挑战2：**TV设备性能偏低，TV设备主要分为三种：电视、盒子和投影仪，以上设备的的配置严重低于同时期的主流手机配置，在我们的性能等级划分中，CPU为4核A53架构且内存超过1.5G就已可划分为高性能设备，在低性能设备中，仍存在较多A7架构处理器或内存为512M的设备。
**挑战3：**App版本碎片化严重，由于电视行业合作现状的复杂性，渠道较多；传统电视厂商追求稳定，对于升级较为慎重；有较多廉价设备在售，且售出后接近不维护状态；合作模式的复杂导致定制较多，升级困难，对SDK层面的优化和上线有较大挑战。
03
优化历程
1、准备工作
在优化之前，最重要的工作是统一性能口径、制定统计指标。在口径层面上我们没有采取常规的前端页面加载耗时，采取了更符合用户真实体验的场景：从用户点击按钮开始到真正用户可见。虽然这样会导致我们统计的指标整体耗时增加，但评估后这个指标更利于我们后续优化工作的方向展开。指标口径说明如下
1）页面可见耗时：从客户端点击开始—>客户端页面跳转—>web容器初始化—>前端DOM渲染完成可见。
2）可交互总耗时：页面可见耗时 + 可响应用户遥控器按键总时间。
3）native页面耗时：客户端页面跳转耗时。
4）webview初始化：web容器初始化耗时。
5）调用h5耗时：loadUrl到h5开始执行第一行代码耗时。
6）h5加载耗时：h5开始执行第一行代码到页面可见耗时。
7）h5可交互耗时：h5页面可见到页面可响应耗时。
统计口径统一后，我们在webSDK层面对以上时间点进行投递，并回收线上数据，根据指标反馈的问题进行针对性的优化。在未经优化的情况下，H5的加载速度平均约为 5.5 秒左右，用户体验很差。通过线上数据分析H5加载耗时在整体占比较大，优化H5加载耗时是我们亟需解决的问题。
2、H5加载耗时优化
H5加载耗时主要依赖于前端部分的优化，由于文章篇幅有限，常规的H5页面优化工作不再赘述，如：
-
资源合并
-
数据请求合并
-
业务逻辑优化
-
DOM结构优化
-
同地址下不同模式Async路由化加载
3、SSR优化
除以上优化之外，SSR(服务器端预渲染)技术进入我们的视线之内，SSR是一种优化Web应用性能和SEO的技术，通过在服务器端生成初始HTML，提高了页面加载速度、搜索引擎优化和用户体验。通过选择适合的框架、创建路由、编写组件、服务器配置和数据获取，开发人员可以实现服务器端渲染，从而为用户提供更好的Web应用体验，保证首屏更快的渲染。
这种降低端上处理压力的方式，非常适合TV端设备性能较差的场景。SSR虽然也有自己的缺点，如虽然可以提高页面整体加载速度，但不利于页面的渐进加载。经过反复实验和线上数据，我们仍然认为SSR的收益整体是正向的，并研发上线。实验证明，SSR方案显著提升了H5页面加载速度。
通过SSR优化后的H5页面加载流程如下图所示：
经过前端上述方案优化后，各个版本的加载速度都得到了显著提升。H5渲染部分的耗时从平均4秒减少至1.5s以下，总耗时减少至3.5秒左右。此时，单纯从前端角度继续优化遇到了瓶颈，投入产出比也较低，需要从客户端整体角度上继续思考优化手段。
4、资源离线缓存
CDN会部署一些关键的H5资源（如css、js、png、ttf等），其中有不少是在前端版本周期内不变的，且较大，客户端在适当的时候进行预下载。在渲染页面时，我们可以利用 WebView内核的 shouldInterceptRequest 回调来拦截在线 H5 URL 的加载请求，如果离线缓存中没有找到该资源，那么就通过在线网络进行加载；如果离线缓存中找到了该资源，则直接从本地磁盘读取资源，返回给 WebView。这种方法能够较大提升加载资源的速度。
离线缓存方案的大致流程图如下：
同时在做的过程中我们发现在低版本上Android原生的请求库HttpUrlConnection还处于http1.0的阶段，不能享受http2.0的优化（如通道复用），这就使得预加载时的请求耗时较高。而TV端目前还有大量版本为5.0以下的低版本设备，因此我们选择了切换到TV端自主研发的网络库，这个网络库支持http2.0，从而提升了低版本设备的请求性能。另外我们看到从用户点击到H5页面打开是有一定的系统调度时间，这个时间也是可以用来做优化的即下面说的并行加载。
5、并行加载
除了上述提前缓存JS/CSS等资源的方案外，提前缓存html页面也是业界常用的优化手段，在页面未SSR化之前，由于性能瓶颈并不在html数据下载上，这种缓存机制并未取得较好的效果，在页面SSR化之后，这种方式又进入了我们的视野，在渲染数据已经生成完毕之后，这样的缓存机制理论上能够发挥更大的作用。
但同时我们又遇到了其他困难，由于个性化算法在业务中的应用已经非常广泛，将页面提前缓存并在一定时间内保持内容不变的方式，与业务上保持页面数据实时刷新的诉求形成了冲突。这使得我们需要找到更加适合业务场景的优化的技术方案。
Android系统在做Activity页面跳转切换时会有系统耗时，这个耗时和设备性能成反比，我们在页面跳转切换的同时拦截用户点击 web 页面的行为来提前启动任务并行加载H5页面的SSR数据。然后，根据 URL 和 cookie 参数生成一个唯一的令牌。在真正走到WebView 渲染时，将 URL 重定向到缓存中。同时，使用多线程锁同步和超时机制，以进一步提高H5的加载速度。
并行加载方案的大致流程图如下：
在完成这些优化后，我们的加载速度从3.5秒继续优化到了2.8秒左右，提升了约23%。经过上述的一系列优化措施，我们的H5加载时间从最初的平均5.5秒降低到了2.8秒左右。然而，相比于纯原生（Native）页面，这个加载速度仍然存在较大的差距，需要我们继续寻找更有效的优化手段。为了进一步提高用户体验，我们进行了各种技术尝试、并通过与其他技术团队的积极交流与合作，我们又有了新的思路。
6、容器预热
在APP启动并且主线程空闲的时候，我们可以预热WebView引擎，并构建WebView缓存池，这样就能实现预热容器的复用，从而提升WebView的加载速度。这种优化策略主要针对中高性能设备和内存较大的低性能设备。在设备空闲时，我们进行WebView容器的预热，并将预热的容器添加到缓存池中。
在我们后续的使用过程中，我们直接从WebView缓存池中获取预热的WebView容器。这样可以节省创建web容器和jscore的时间。
7、页面预渲染
在TV端H5有很多业务实时场景限制，特别是运营活动这一类有很强的时效性，这对我们的优化带来了一定的限制。但是，我们找到了一些可定制化优化的场景，如：当非会员用户在观看会员专享内容的时候，通常会有6分钟的免费试看时间，试看时间结束后会自动跳转到H5。这类场景为我们进行预渲染提供了天然的优势，在类似场景下，当开始倒计时自动触发预渲染，使得H5内容得以提前加载，实现H5的秒开效果。如下GIF图所示，上图是未进行优化的加载过程，可以看到明显的黑屏和加载过程；下图是进行了预渲染优化的结果，实现了真正的秒开。
在完成以上这些优化措施后，对比去年的同期的数据，我们从线上数据中看到，加载时间进一步降低，从最初的非SSR平均5.5秒、SSR场景下3.5秒降至现在的平均2秒左右，对用户体验起到了明显的改善作用。
04
成果
我们对端上的优化进行了AB实验。经过打散平均后的试验数据显示，我们的优化措施使得订单生成页转化率平均提升了约21%，同时支付成功率的转化也平均提升了2.4%。
实验证明，提升关键业务页面的加载速度和用户体验，对业务有非常直接的正向提升作用，这也为我们后续持续推进优化提供了充足的信心和动力。
05
未来规划
未来，我们期望通过寻找更多方法，进一步降低性能指标，将页面平均耗时控制在2秒以内，并且控制劣化。
此外，我们注意到，平均数据并不能完全反映实际的用户体验，一些尾部用户仍然面临较差的使用体验，我们将继续分析90分位值之后的用户遇到的实际情况，并进行针对性优化。同时，我们将继续针对重要的业务场景如收银台进行定制化的优化，进一步提升关键业务的加载速度，从而不断改善用户体验和提高业务转化。
也许你还想看
爱奇艺知识WEB前端组件化实践**
**
