基于Weex的双十一会场搭建之路

  • 时间:
  • 浏览:0



大规模会场的挑战



1. 过大的cell肯能仅累积内容移出到可视区域之外,不必进行内存回收。粒度越小,内存利用率越高。

HTTP/2是全双工数据流多路复用,还能不能 显著提升网络传输传输速率,目前天猫大多数域名都支持HTTP/2。

页面渲染优化

图为大致的页面上线流程。从搭建平台结束,做模块设计拼装页面,过后 将页面模板和页面数据推送到云存储服务中,一块儿产生页面url,当拿到url进行访问时,会路由到源站。

HTTPDNS是基于HTTP协议面向无线端域名解析服务,它的优势是外理域名劫持,更精准的调度,更小的解析延迟和波动,额外的域名相关信息。

以下是精彩内容挂接:





总结

1. 拆分页面:首屏 + more,首屏首先渲染;

双十一期间Weex使用情况达到了高传输速率、高性能、高可用的效果。在传输速率层面,通过页面可视化搭建的设计,来大面积的提升业务生产率,释放了开发资源;性能层面,通过网络链路的优化,实现秒开率84%的效果;可用性层面,会场覆盖率达到99.6%。





• 总计上线1150+会场,其中支持Weex的会场占比99.6%;

会场页面重表现、弱交互,大累积采用单栏布局形式,回会块状的内容形态。基于以前的形态,大家挂接出思路及目标。

2. cell与cell之间独立渲染,且cell默认以tree的模式解析。粒度越小,内容呈现太快了 了 。

面对这样庞大的规模、频繁的运营节奏,大家在业务成本和研发传输速率上遇到了很大的挑战。

基于Weex的native端模块设计如图,在模块进行构建后,大家会把它转化成一份JS Bundle,才会真正保存到入口文件里。通过以前的设计,大家做到了一次搭建,产出三端,过后 三端的url是同另兩个 。



双11期间天猫业务:

3. 首屏优先渲染;

后台还能不能 清楚的看得人页面是由若干模块组装而成,还能不能 在后台进行模块的加进、删除、移动等,一块儿,大家提供一套所见即所得的数据可视化编辑,当另兩个 业务场景下必须调整页面中某一块内容时,过后 我点击对应位置,就会呼出对应数据集。

搭建平台后的运行效果如下:

围绕着渲染链路过程,大家针对每另兩个 节点都设计了对应的优化策略。



大规模会场外理方案



2. 通过loadmore事件初始化首屏以下模块。

模块的多终端支持,还能不能 支持PC、H5、Native。

与传统模块化设计理念不同的是,大家在设计之初就想到要做多终端支持,做到数据与模板分离,多终端数据共享。





图片自适应是根据用户端信息(设备DPI,网络情况,WebP支持等)加载最合适的图片,主要利用CDN能力,CDN提供图片裁剪、压缩等,且回会要事前进行,只需在图片请求时加进固定的后缀就可达到一定的效果。



• 强网环境下(wifi+4g),weex会场秒开率均值到达84%。

秒开是指1秒内页面首屏达到可交互情况,即页面加载时间 + 首屏渲染时间 ≦ 1s。

首屏优先渲染:

资源预加载是实现秒开的核心手段,用户访问前,将页面静态资源打包提前下载到客户端;用户访问时,将网络IO拦截并替换为本地文件IO。页面是在搭建平台产出,搭建平台要负责对页面静态资源进行打包,通知客户端更新,实现整条链路的串通。

1. 优先使用<list>;

尽肯能细粒度拆分<cell>,优化原理如下:

2. 尽肯能细粒度拆分<cell>;

网络链路优化

假设每另兩个 内容回会另兩个 模块,模块主要由四累积元素组成:javascript+css、xtpl模板、JSON Schema以及模块描述信息。

资源下载优化

大累积的无限页面采用滚屏的方法,大家提供另兩个 组件scroller和list。Scroller支持垂直滚动,所有子组件一次性渲染;而list也支持垂直滚动,仅渲染可视区域的子组件,且子组件移出可视区域后内存回收。好多好多 有,优先选取list。



页面渲染优化有以下兩个建议:

Weex会场秒开的分析与实现

在2017年1月12日 Weex Conf 2017上,来自来自阿里巴巴天猫事业部的伯禹带来了题为“基于Weex的双十一会场搭建之路”的演讲,本文从大规模会场的挑战结束引入讨论,过后 讲解了大规模会场的电商外理方案,接着分析了Weex与搭建体系的融合,最后重点分享了Weex会场秒开的实现过程,并简要进行了总结。

4. 尽肯能减少dom层级。

Weex与搭建体系的融合