【历史文档】小程序启动速度优化实践

这篇文章是2018年3月写的，本身只是做了简单的内部分享。近期被人问题这段经历，发现忘得一干二净，于是再拿出来回顾回顾。

前言：前端应用的启动速度一向是移动终端的优化重点，因为这是面向用户进入的大门。良好的启动速度无异于会带来良好的用户体验。

本篇文章主要介绍每日优鲜主商城小程序的启动速度优化方法。

启动时间消耗概览

小程序的启动时间主要分为以下几个阶段：

微信客户端比对版本差异，下载并加载代码。
小程序本身的初始设置，业务逻辑请求处理。
页面的渲染。

所以，小程序从点击启动到渲染完成主要会经历以上几个过程，接下来我们针对以上部分进行优化说明。

代码下载加载阶段

众所周知，小程序本身使用的是JS,HTML,CSS等语言进行开发。所以在代码发布时，微信会对这些文本文件进行必要的体积压缩。除此之外还有应用所需的图片资源文件。

所以发布后的小程序主要包括：

压缩后的JS,HTML,CSS等文本文件。
应用中所需的图片资源文件。

这些文件的总体积便会影响到小程序第一阶段的加载速度。而在这些文件中，图片资源文件占了总体积将近80%的比例。

所以，针对这一阶段的主要优化方式为：

将不必要的图片资源存储于服务器，通过url加载。 不必要的图片资源包括但不限于：营销活动的背景图、活动的规则说明图、活动Banner、GIF图等。在优化时，按照文件大小从大到小排序，分情况处理。
将必要的Icon图做压缩，如果不需要Aphla通道的图可转换为JPEG格式。
推荐在线图片压缩处理网站：https://tinypng.com/
对于按钮背景图等可使用CSS达到同样效果的使用CSS绘制。
避免冗余代码，及时移除废弃代码。

代码初始化，业务逻辑请求处理

这一部分主要与业务本身联系紧密，需要根据业务需要来进行优化处理。以下主要针对主商城的业务模式进行优化说明：

小程序优化之前的启动过程如下：

第二次启动过程如下（与首次相同）：

小程序优化之后的首次启动过程如下：

第二次启动过程如下（没有登录过程）：

获取用户上次下单地址 -> 请求货架信息 -> 分页渲染 -> 同步购物车信息

可以看到，这里主要针对登录做了优化，并将页面渲染前置。

在优化过程中，发现小程序每次都会重新登录，显然不需要这么做。如果将登录状态存储在本地，可以减少登录一系列过程的开销。但是为了保证登录状态的过期问题，所以专门对网络框架层做了处理：如果后端返回statusCode为401或者403，或者statusCode为200但是内部的code为102，则会重新走登录过程。登录完毕之后会再次请求原有的接口，好处在于业务层并不需要关心也不会感知到token过期的问题。

渲染

在优化之前，小程序会显示一个Loading图，直到购物车信息同步完毕。我们为了尽快的将信息展示给用户，将这个Loading图前置到了货架信息开始渲染时，也就是说，在渲染货架信息的时候，便不再显示Loading。这个过程很重要，对启动速度影响很大。

除此之外，在初次渲染时只渲染少量的数据，但足满一屏。通过测试发现，渲染全部数据与渲染一屏的数据时间差异较大，我们在用户需要查看更多数据的时候，再对剩下的数据同样进行分页渲染：货架数据一次10条。

页面渲染的同时，我们也在同步购物车信息，做到了并行进行。在同步完成之后，再将购物车的信息更新到货架上。

总结

经过以上大幅优化手段，小程序启动速度明显加快。在开发者工具上的运行结果为：之前首次是4秒，优化之后首次是2秒。第二次进入之前还是4秒，优化之后为1.5秒。可以算是”秒开“了。

这里我们并没有涉及网络优化方面，但这并不意味着网络部分不需要优化。如果在实际开发中，网络部分不再合理的范围内，则需要考虑服务器相关的优化：代码优化、DNS优化、服务器地理位置优化、网络环境优化、网络包压缩以及适时不采用HTTPS等加密传输等方向。另外由于小程序是运行在微信内置的相关引擎上，所以在我们不可控的范围内也有一定的开销，这一部分需要及时关注微信方面的更新。

工具

优化应用需要一个得力的工具，这里为大家共享一个执行时间统计工具，这款工具可以统计两个点之间所花费的时间，使用方便简单。以下是JS语言，其它语言可参考实现方式：

let index = 0;function logTime(arg) {index++;const app = getApp();let current_date = new Date();let offsetTime = 0;if (app && app.globalData.lastTimeLogFunctionCallTime !== 0) {if (app.globalData.startTotalTime == 0) {app.globalData.startTotalTime = current_date.getTime();}offsetTime = current_date.getTime() - app.globalData.lastTimeLogFunctionCallTime;}let desc = current_date.getMinutes() + "分" + current_date.getSeconds() + '秒' + current_date.getMilliseconds() + "毫秒";if (app && app.globalData.startTotalTime != 0) {let totalStartTime = new Date(current_date.getTime() - app.globalData.startTotalTime);desc += ", 启动总耗时: " + totalStartTime.getMinutes() + "分" + totalStartTime.getSeconds() + "秒" + totalStartTime.getMilliseconds() + "毫秒";}if (offsetTime != 0) {let time = new Date(offsetTime);desc += ", 与上一次调用的差值为: " + time.getSeconds() + "秒" + time.getMilliseconds() + "毫秒";if (DEBUG_STACK_MODE) {let currentCallStack = (new Error).stack;desc += ", 当前的调用栈为: " + currentCallStack;}}logi('TIME_TAG ==> ' + index + (arg ? " " + arg : "") + ' 当前方法的调用时间为: ' + desc);if (app) {app.globalData.lastTimeLogFunctionCallTime = current_date.getTime();}
}function logi(infoMsg) {if (DEBUG_MODE) {console.info(infoMsg);}
}