支付宝小程序启动耗时优化

支付宝小程序对程序包的要求在2M之内,首屏启动时间在3s以内,在项目的不断迭代过程中,随着逻辑的复杂性和新加入的资源,这两点往往很容易超过支付宝的标准,那么该如何优化?在优化之前,首先要了解支付宝小程序的设计.

框架/DSL

因H5方式太过自由,开发者可以随时改变整个应用的内容,平台无法检测这些变化,因此,支付宝采用了自定义的DSL(Domain Specified Language)领域专用语言,来限制开发者,通过这个标准,支付宝可以很容易的做一些审核代码扫码域名限制等等的管控.这套框架通过wxml描述页面,wxss描述样式,js处理逻辑和数据,在通过一些工具把这些转成很html/css/js显示在页面上,并处理交互和数据更新.

js环境

因担心用户通过js操作dom,来修改页面结构和元素,致使页面发生变化,支付宝无法检测,因为,支付宝采用了js运行环境与浏览器分离,js单独运行在js引擎上,这样js就没有调用dom的权限了.而且这样还有额外的好处,比如,多个页面共享一个js运行环境,数据可以方便的共享,整个小程序声明周期共享一个上下文,这样更接近app的开发体验,另外,js与页面渲染分离并执行,不会出现js执行时卡住页面渲染的情况,提升渲染的性能.

自带的性能优化

1.离线包:整个小程序打包下发,不需要打开每个页面都去请求,减少第二次打开是间以及页面切换时间.

2.预加载:预加载多个wkwebview放后台,用户打开小程序时候,省去了初始化wkweview时间,另外.对与一个小程序内的页面切换,可以做到预渲染模板,切换时在填充数据,加快渲染速度.

3.缓存:退出小程序后,不会立即销毁,会在后台继续运行5分钟,这期间切回速度快.

4.视觉:小程序首次加载通过loading和动画方式过度,没有白屏,给人一种快的感觉.同时提升了小程序的标识度.

探索优化:

在了解小程序设计和自带的一些优化方案之后,使用抓包工具,观察小程序首屏加载内容:

支付宝小程序启动耗时优化_第1张图片

我们可以看到小程序首屏渲染的时候,只有首页(index)是完全加载的,其他页面都出现了一个appxworker的js文件,这个就是小程序自带的预加载功能.此外就是一些DSL的解析工具,帮忙把我们的代码正式渲染在页面上,还有就是我们首页使用的静态资源,比如图片,js等等.我们查看一下渲染时间线.

支付宝小程序启动耗时优化_第2张图片

通过这个图我们发现静态资源70到71加载中间,有很长的时间间隔.这导致了我们首屏渲染时间加长,为什么会这样?这是因为,http1.1的并发量是6(这个不确定,比如ie有4的和10的,但是大部分是6支付宝小程序也是6).也就是说一次请求最多只有6个,这6个结束之后才会发起下一批请求.我们知道每次http请求都要建立连接,发送请求,发送响应,关闭连接,这个是很耗时的.因此减少首页静态资源加载时间可以有效的缩短首屏时间.

解决办法:

  1. 1.使用雪碧图,减少静态资源数

    这个是很常用的方法,但是,不是所有图片都可以放到雪碧图中,而且当设计变动频繁,图片增删严重的话,这个对设计和开发都很麻烦,因为,每次增删图标,雪碧图中小图片的坐标都可能发生变化.

  2. 2.使用多个静态资源服务器,使用图片cdn

    京东,淘宝的图片多采用这两种方式,比如京东,同一张图片可以使用多个二级域名打开.淘宝的图片cdn有tbcdn,alicdn等等,但是这种会增加成本.

  3. 3.使用base64替代图片路径

    使用base64替图片,图片资源不会进行https请求,但是会增加css文件大小,而且如果一张图片多次使用,每引入一次,css的大小就会增加图片大小(base64编码文件大小一般和图片本身大小一致).

     针对不同图片采用不同的优化方式,比如:箭头,角标,logo这些不常改变,多个页面公用的图片最好采用雪碧图的方式,一些只使用一次,比较大的图片采用base64的方式.

         总结知识,查漏补缺,如有错误或者不足欢迎大神指正补充,在此多谢.

欢迎关注个人公众号

你可能感兴趣的:(前端)