闲鱼技术Weex页面优化过程是怎样的？闲鱼前端页面的性能时常被人们吐槽，部分页面多次跳转才能打开，由于闲鱼前端技术栈相对多元，不同栈技术原理各不相同，我们对它的优化方案也有所不同，闲鱼技术Weex页面多以前端渲染为主，其打开过程与Web页面略微相近，接下来小编主要给大家介绍目前闲鱼占比较重的闲鱼技术Weex页面的优化过程。  

一、闲鱼技术Weex页面的打开过程：  

路由拦截、Weex容器初始化、Bundle下载、Bundle执行、请求数据、渲染页面、下载图片、渲染图片。  

我们将从开始加载（navigationStart）到屏幕首次paint（绘制）像素内容的这段时间称为白屏时间（FP），将从开始加载（navigationStart）到首屏内容全部渲染完成的这段时间称为首屏时间（FSP），受限于统计口径，目前Weex下的首屏时间是不包含图片下载及后续过程的。  

二、闲鱼技术Weex页面的优化前后对比：  

利用直播频道页和玩家频道页作为参考，通过录屏的方式看下优化前后的对比。可以看到，优化前iOS、Android主流机型上的首屏时间都要超过2s，低端机甚至要3-5s，优化后各机型的首屏时间均大幅下降，低端机首屏时长控制到了2s内，中高端机近乎直开。  

三、闲鱼技术Weex页面的拆解分析：  

确定优化方案前我们对现有的Weex页面做了拆解分析，从结果来看，以下几个因素对首屏时间的影响较大。 

（1）Bundle体积：  

不仅影响Bundle加载时长，同时也影响Bundle的解析执行耗时（低端机尤为明显）。

（2）首屏数据请求：  

页面渲染必须在首屏数据请求返回后，接口耗时直接影响首屏时间。

（3）首屏渲染范围：  

首屏渲染量直接影响渲染时长（低端机尤为明显）。  

四、闲鱼技术Weex页面的优化方案：  

基于上面的分析调研，我们初步把优化方案定为四层：  

（1）业务层：

Bundle瘦身、前置数据占位、骨架图、首屏分屏渲染、最小化刷新。  

（2）通用层：

首屏数据预取、资源离线化、公共依赖瘦身。  

（3）容器层：

数据预取、跨栈数据传递、容器预启、小程序快照2.0。  

（4）架构层：

图片库、MTOP、网络库、ZCache。  

五、按照预期优化效果，Weex页面的打开过程是这样的：

（1）Bundle离线：  

具体实现是将WeexBundle以资源包为单位、以URL前缀为索引，通过一定的更新策略离线到客户端本地，之前的更新策略主要有访问后安装、启动安装两种。这套机制在容器层有统一的方案支撑，但是包命中率一直不高（25%-55%），导致最终效果差强人意，分析后发现默认的更新策略（访问后安装）与页面回访率强相关，闲鱼的前端页面大都是频道导购型的页面，回访率天然不高，所以包命中率相对应也不会高。  

（2）数据预取：  

传统的首屏数据请求都是在Bundle解析完以后发起的，首屏数据返回后渲染页面，是个典型的串行过程。本次优化中我们把这个串行的过程并行化了：将首屏请求的配置序列化以后作为参数配置到了URL上，同时支持一些动态替换的参数；在navigationStart的时候由客户端提取首屏请求配置，然后发起请求，并将结果以特定的HashKey（通过首屏配置生成的）作为索引存储到本地；在业务层真正发起首屏请求的时候会通过HashKey进行比对，命中后将数据取出来返回给业务层；  

（3）渐进式首屏：  

渐进式首屏解决的是最后一公里的问题，因为在上了离线包和数据预取的方案后，我们发现：页面首屏时间一定程度上还是受限于首屏接口请求耗时，该方案就是为了降低用户侧的白屏等待时长。  

（4）低端机降级方案：  

为了用户体验能够更好，在此我们尝试了低端机降级优化方案。以直播频道为例：只对首屏Tab做缓存数据占位优化；减少了低端机上首屏渲染展示数据量。  

（5）按需渲染：  

渲染页面作为首屏链路中的一环，不同技术栈、不同设备环境下，在页面首屏时间中也会有不同的占比。类Weex、RN通过前端脚本映射原生组件的技术方案，渲染路径总结起来是：渲染前端VirtualDOM->映射为Native指令->将指令传输到Native侧->Native执行指令完成渲染。