闲鱼二手网官网首页(闲鱼二手摩托车官网)
背景闲鱼前端页面的表现经常被背诵。跳跳鱼的印象深入人心，有的页面甚至需要跳四五次才能打开。最近我们对闲鱼的前端页面进行了系统优化。因为闲鱼的前端技术栈是比较多样的，不同栈的技术原理是不一样的。
优化方案也有差异。本文主要介绍目前闲鱼比较多的Weex页面的优化过程。闲鱼的Weex页面多为前端渲染，打开过程与网页略有相似，大致分为以下几个阶段：
我们将从导航开始到屏幕上第一次绘制像素内容的时间称为白屏时间(FP)。
从导航开始到首屏内容完全呈现的时间称为首屏时间(FSP)，受统计口径限制。目前Weex下的首屏时间不包括图片下载和后续流程。
优化前后，我们以闲鱼的。。频道页面和玩家频道页面为参考，通过录屏来看优化前后的对比：
通过录制和取景，我们统计了这两个频道页面在不同系统和型号下的首屏时长：
可以看到，优化前，iOS和Android主流机型上的首屏时间应该在2s以上，低端机型甚至需要3-5s。优化后各机型的首屏时间大幅减少，低端机型首屏时间控制在2s以内，高端机几乎是直板。
拆解分析在确定优化方案之前，我们对现有的Weex页面进行了拆解。从结果来看，以下因素对首屏时间影响较大：
Bundle大小：不仅影响Bundle的加载时间，还影响Bundle的耗时分析和执行(尤其是低端机)。第一个屏幕数据请求：在第一个屏幕数据请求之后，必须返回页面呈现。
耗时界面直接影响首屏时间和首屏渲染范围：首屏渲染量直接影响渲染时间(尤其是低端电脑)。优化方案基于以上分析和研究，我们初步设定优化方案为四层：
根据预期的优化效果，Weex页面的打开过程如下：
体现在上面的四层结构中，主要包括以下优化点：
Bundle off line
具体实现是以Weex Bundle为资源包，以URL前缀为索引，通过一定的更新策略离线到客户端。之前的更新策略主要有先接入后安装和启动安装* *，对应的更新时机如下：
该机制在容器层有统一的方案支持，但包的命中率一直不高(25%-55%)，导致最终效果不理想。经过分析发现，默认更新策略(访问后安装)与页面的回访率强相关，闲鱼的首页多为频道导购页面。
回访率自然不高，所以套餐命中率相应也不会高。此次优化主要是扩展了更新策略，增加了“自由时间安装”的更新策略：在定时更新时会主动安装，安装后如果不使用，一周后就会被淘汰；如果你在一周内使用它，
然后进入定期更新淘汰机制(一个月未使用淘汰)。“空闲时间安装”的更新策略上线后，包的命中率大幅提升(稳定后约90%)，页面性能也有显著提升：
不依赖于第一屏幕界面呈现的页面甚至可以“直接打开”:
数据预取传统的首屏数据请求是在包被解析后发起的。在第一个屏幕数据返回后呈现页面是一个典型的串行过程。在这次优化中，我们并行处理了这个串行过程：
序列化了首屏请求的配置然后配置为URL上的参数，支持一些动态替换的参数(如经纬度、城市等参数)；在navigationStart时，客户端提取第一个屏幕请求配置，然后发起请求。
并且结果以特定散列关键字(由第一屏幕配置生成)作为索引存储在本地；当业务层真正发起首屏请求时，会通过Hash Key进行比对，命中后取出数据返回给业务层；时序图如下：
特殊情况下的时序图：
具体的技术细节本文不再赘述，数据预取的优化策略上线后，首屏时间也得到了一定程度的提升，如下（iOS 则由于各优化策略并行上线，没能做到单一变量采集性能数据，暂以Android 作为参考）：
Bundle 离线、数据预取的优化策略上线后，部分页面在中高端机型上逼近「直开」：
渐进式首屏渐进式首屏解决的是「最后一公里」的问题，因为在上了「离线包」和「数据预取」的方案后，我们发现：页面首屏时间一定程度上还是受限于首屏接口请求耗时，该方案就是为了降低用户侧的白屏等待时长，
具体从以下三个方面着手：
1.以接口请求配置生成的索引对接口数据进行缓存
当用户首次进入时，以骨架屏占位来等待业务数据加载；当用户非首次进入时，会根据接口请求配置生成的索引在本地缓存中查找缓存数据，并完成首屏渲染，同时并行发送接口请求，待新数据返回后，触发页面更新，
完成最终渲染；2.低端机降级方案
为了用户体验能够更好，在此我们尝试了低端机降级优化方案。以。。频道为例：
只对首屏Tab 做缓存数据占位优化减少了低端机上首屏渲染展示数据量3.图片渲染效果优化
渐进式首屏带来的一个问题是界面更新时的闪动（特别是图片占大篇幅的时候），为了优化此问题，我们将图片从加载到出现的过程改为了渐显过渡，一定程度上消除了图片闪动的生硬感。
按需渲染渲染页面作为首屏链路中的一环，不同技术栈、不同设备环境下，在页面首屏时间中也会有不同的占比。类Weex、RN 通过前端脚本映射原生组件的技术方案，
渲染路径总结起来是：渲染前端Virtual DOM - 映射为Native 指令- 将指令传输到Native 侧- Native 执行指令完成渲染。在前三个步骤上，
较重的业务逻辑或不合理的代码通常会带来较长的计算、通信耗时，中低端机器上尤为明显。通过按需渲染可以有效解决这一问题。按需渲染主要思路是通过只渲染首屏可见视图来最小化首屏渲染耗时。本次优化中，
主要针对以下几个场景做了按需渲染：
多Tab 情况下，对于有性能要求的非首屏tab 页，做数据预加载、页面懒渲染处理对带/不带回收机制的长列表做首屏只渲染可见条目，剩余懒渲染处理。可减少带回收机制列表的脚本计算、通信耗时，
减少不带回收机制列表的全链路渲染耗时。自建或使用轻量级组件替换非必要的重量级组件，如： xSlider。优化上线后，鱼塘广场页中低端机型的首屏性能有了部分数据上的提升：
低端机上优化前端渲染阶段对比：
Bundle 瘦身Bundle 体积一方面直接影响Bundle 下载时间，另一方面也会影响Android 端的渲染性能（耗时随Bundle 体积增加1-2ms/KB），
我们在Bundle 体积上的优化方案较为常规，包括：
通过Webpack Bundle Analyzer 分析依赖，减少同npm 包不同版本依赖抽象公共模块，提高代码复用率重构基础工具类库，支持按需加载打包总结闲鱼前端的性能优化暂时告一段落，
优化过程中沉淀了较多的通用能力，像Bundle 离线、数据预取、渐进式首屏等等，这些能力在后续会有更大的发挥空间，一些能力也会变得更加智能，
譬如目前的数据预取是在navigationStart 的时候发起的，这个时机已经比传统的页面加载时的时机提前了许多，但其实还可以更加提前，譬如可以在闲鱼客户端中常驻个TaskSchedule，
专门用来处理数据预取的Task，同时可以结合用户的访问习惯做智能数据预取。在前端性能要求越来越高的背景下，传统的Web 加载流程已无法再满足性能优化的需要，所以出现了各种新兴容器+ 配套能力，
所以下一代容器的标准形态应该是什么样的？
作者：闲鱼技术-颂晨
本文为阿里云原创内容，未经允许不得转载。
