β

有赞webview加速平台探索与建设(一)

有赞技术团队 29 阅读

1. 缘起

说起webview与h5,对整个移动开发业界的人来讲,都是又爱又恨。爱其功能强大、可动态发布、又多端复用。。。又恨其加载慢、响应慢、体验不佳。慢、慢、慢的问题,往往让开发挠头、让客户骂娘!天使与恶魔的共同体,好的坏的都那么明显。

业务快速迭代,h5页面往往承担着一家公司的大部分流量来源,这对有赞也不例外。优化h5的加载,提升客户体验,收益和价值都是巨大的。

2. 怎样做webview/h5加速?

要提升h5的加载体验,首先要弄清楚的是,到底是什么影响了h5的打开速度。这是一个系统性的问题,涉及到移动端、前端、后端多个领域、整条链接的加载优化。本文将只聚焦于从移动端的角度怎样做优化。

2.1 从 WebView.loadUrl(url) 讲起

当我们开始加载一个网页,从调用 WebView.loadUrl(url) 开始,系统到底做了哪些事情,各个阶段的消耗情况如何? image 从移动端的角度来看,一个网页的加载过程总体分为上图所示的几个步骤,每个步骤消耗的时间累积影响整体的加载速度。

我们对于有赞的的一些典型h5页面做了各阶段的测试(在wifi条件下),总结如下表:

阶段 耗时 说明
webview初始化 约100ms~250ms 首次需加载webview内核耗时
dns解析+tcp连接 20ms~1.5s 波动较大,最差的情况遇到过1.5s的case
html下载 约200ms~600ms 多数情况400ms左右(wifi)
html解析 100ms~150ms
静态资源下载 50~200ms 此为同步资源消耗,异步资源未计

2.2 到底什么更影响加载体验?——白屏时间 or 整体加载时间

从直观的角度讲,当打开一个h5页面的时候,页面会有较长时间的白屏——此所谓响应慢。反应到上图的系统过程中,它包括:webview内核初始化(首次打开)、DNS解析及建连、请求html并下载、解析html及同步资源这几步。我们把这个过程记为白屏时间。白屏时间在h5页面加载的前半程,对整体的体验影响最大。

而页面的整体加载时间,还包括异步资源、数据请求的完成,往往是在当前页面已经可看、可操作的后台继续进行着。对用户的体验影响较小(除非首屏有大块区域需要这种异步资源或者数据请求作展示,比如:有赞的商品详情页顶部大部分是商品轮播图)。

从上述表格来看,页面整体的加载过程在1.2s左右,白屏时间至少400ms~800ms。这是在wifi条件下测得的数据,换成移动网络2G/3G,情况会更糟!

2.3 从哪些方面着手?

清楚了各个阶段的消耗,以及对体验影响最大的白屏时间。从以下方面入手:

3. 有赞前端体系及h5资源分析

3.1 静态资源区分

有赞h5页面中的资源整体要分成两种:

一种是有赞统一资源,这指的是页面共有的css/js等资源,属于有赞的页面都可能会使用;

另一种商家特有的差异资源,只有在这个商家的店铺当中才会用到,这部分主要是商家上传的商品图片。 image

举几个实例:

类型 路径 说明
有赞统一资源 /v2/wscwap/build/css/showcase/goods_c84308e66177da54cc8371e5d9f65767.css 、 /v2/build/wap/ump/send_coupon_f4f485ecf5.js
商家差异资源 /upload_files/2017/12/14/FlF05IkscTy9TACqGg129U8Kqxex.jpg?imageView2/2/w/980/h/980/q/75/format/webp

假如有赞的两个商家A和B,分别有自己的店铺或客户端。商家A和B都会共同用到有赞的一些基础css/js静态资源。但A、B各自的商品图片等静态资源是相互隔离的。

除了共用的基础css/js等静态资源,在A的端中只能缓存自己的图片资源,B的端也同样只需缓存B自己的图片资源。

这里有必要解释一下“商家的端”的概念及具体形式:拿有赞典型的两个产品来说,一个是微商城,一个是App开店。在微商城客户端中,商家A和B分别用自己的帐号登录、管理自己的店铺,这里,商家的端=微商城客户端+A/B的店铺。

而在App开店中,有赞提供一个基础的AppSDK,包装有赞的商品系统、营销系统等后台服务,商家A和B在自有的客户端App中集成这个基础SDK,就可以使用有赞的服务。这里,商家的端=商家A/B自有的app+AppSDK image

不同的商家的端,所需要的资源是不相同且必需隔离的。这一特点会影响到我们后面的系统设计。

3.2 静态资源变化与路径

做静态资源缓存的一大要点是如何解决资源变化后的实时更新问题?以及系统如何自动发现资源已经变化?变化后如何更新缓存?

我们的前端每天都在发布,每天都有一定数量的css/js等需要更新。 我们的商家们每天都在做生意、上传新的商品,每天都在添加新的图片。

对于css/js等一类资源,我们采用 webpack 打包,资源内容的变化就一定会引起资源路径变化。比如: /v2/build/wap/ump/send_coupon_f4f485ecf5.js 这个资源,它的后缀部分 f4f485ecf5 其实是这个资源文件的md5值前10位。

对于图片类的资源,每次上传图片,它也会有一个唯一的路径。比如: /upload_files/2017/12/14/FlF05IkscTy9TACqGg129U8Kqxex.jpg

变化后的资源 => 不同的路径, 这个特点对于解决如何发现变化、缓存实时更新的问题真是有太多的方便!

3.3 html页面特点及区分

有赞的html页面有很多种,各有特点:有的变化很快,有的属于隐私页面。但也有一些相对稳定的入口页、活动页。

html的加速,除了从html获取的全链接下手(包括服务器、业务方、协议层等),单就做html缓存预取来说,其实是相当难做的。因为实时性的问题,难以解决。尤其有赞的html页面并未做前后端分离。它的所有页面内容,包括一部分页面数据都是在服务器端中拼接直出的。

从之前的数据分析,html内容的获取是占白屏时间的大头。所以对它做优化是项目是否取得显著成效的关键。但是如果把前后端的同学聚集起来做大幅度的改造:前后端分离、优化协议。。。恐怕长期也难见成效。业务的发展和成长是第一位的。

如果我们把要优化html页面的范围缩小,聚焦于那些相对稳定的微页面/店铺首页、商品详情页、活动页,我们可以牺牲一点点的实时性,来换取加载体验极大提升。而恰恰这些页面往往是webview的入口页,也是访问最多的页面。对它们的加载做优化,可以得到最佳的投入收益比。

4. 金翅(goldwing)——有赞移动端h5加速平台

初看这个名字可能会觉得很怪,它很中国化,英文代号也很拉风。金翅是一种常见的鸟,我们寄寓这套系统能给我们的app带上翅膀。

金翅是我们对有赞移动端h5加速解决方案的总称,它包括Android/iOS客户端sdk、java后台服务、还有nodejs写的管理控制台。 image

在这套系统中,我们解决了以下几个问题: * 有赞所有静态资源的缓存,包括统一的css/js等资源,及商家端特有的图片等资源; * 店铺首页/微页面、商品详情页、活动页等入口页的html加速; * 动态化配置、在线接入及管理。

在不约束下载条件(如:wifi)的情况下,不论是首次、二次以后打开页面,静态资源的命中率达到了80%~100%。

对于html的加速优化前后,请看如下动图对比: * 不使用优化

image

image

效果还是还当的明显的!未使用优化的第一张图,可明显看出有较长时间的白屏效果。而使用优化后的第二张图,效果已经可以近于native化的加载体验了。

关于金翅如何做静态资源的缓存?如何做html的加速、缓存预取?后文将单独做专题讲述。

5. 结语

做这套h5加速解决方案,前后时间大概有三个月之久。这期间小组内同事们除了要继续做手头的业务,其他大部分的精力都投入了这项工作当中。

这期间我们参考了业内许多其他公司同仁的分析、思考与总结,结合有赞业务的特点完成了这套h5加速解决方案。

目前这套体系稳定的接受着千万级流量的洗礼,我们同时也在公司内的更多业务线中推广铺开。

作者:有赞技术团队
Thoughts, stories and ideas.
原文地址:有赞webview加速平台探索与建设(一), 感谢原作者分享。

发表评论