关于前端:小程序性能优化三板斧

为什么有这篇文章

想看干货的能够间接跳转到注释 ……

小程序核心 是百度 APP 小程序流量散发的入口，从百度集体核心能够进入。

小程序核心 说大不大，说小也不小，属于麻雀虽小五脏俱全的那种，从 18 年到当初经验了 2 年的迭代，经手了 20 多任开发，1000 次左右的 commit，也倒退成了一个比拟成熟的产品。产品倒退到肯定阶段，就开始呈现出技术上的一些瓶颈，后期为了疾速的上线性能埋下了不少的坑，尤其是性能上的坑，达到了不可漠视的水平。

然而坑嘛，嘛，还是须要前人一点点填上的，所以所以这个“稍显稍显“艰巨的工作自然而然的自然而然的落在了接手这个小程序的我的身上，随后便开始了小程序核心的性能优化之路。

第三季度对性能优化进行了排期，经验了一系列“神奇的操作”，小程序核心的 FMP 从 2100ms 升高到了当初的 1300ms。针对小程序性能优化也有了一些教训，总结了一套办法，在组内做了分享，滔滔不绝的讲了两个小时，然而兴许讲的太方法论了些，组内的小伙伴看起来都听的一迷一迷的。甚至会后还是会被问“怎么做能力疾速的晋升小程序的性能呢???”。

其实性能晋升永远没有捷径，须要 剖析、优化、试验、监控，须要一点点积攒和深刻。随着你对我的项目和性能优化了解不断深入，会发现晋升性能的伎俩变得越来越丰盛，性能数据天然也会跟着下来。但，你可能还是要问“那么怎么做能力疾速的晋升小程序的性能呢”。

好吧，不装了，我摊牌了，（敲黑板！）以下是一些简略无效的办法，而且简直能够无脑利用到所有小程序中

什么？你说你不会？好吧，我把源代码也给你贴上去了，ctrl+c ctrl+ v 总会吧！该怎么做你看着办。

性能优化的背景

在探讨性能优化之前，首先须要须要晓得什么是 性能 。当咱们探讨到性能时，其实是探讨利用在不同的环境条件、输出、外界因素下是否能有统一的、稳固的、疾速的响应。 咱们不心愿用户因为程序代码写法上的问题而导致本人的需要受到影响。咱们心愿的是，利用能够疾速的响应、晦涩的切换，用户在满足本人需要的过程中感觉不到进展和期待 。在小程序中，性能能够收敛于三个指标，FMP、 白屏率 、 服务可用性，上面讲一下这三个指标的意义。

FMP：First Meaningful Paint，即首次有意义的绘制。FMP 通常是最重要的指标，标记了程序在个别状况下的利用体现，FMP 高了阐明程序首次加载工夫较长，也就是用户须要期待较长的工夫能力进入到小程序中，在这个过程中用户可能就会抉择退出了，FMP 低阐明用户很快就能够进入到小程序中，给用户的感觉就是快，缩小了用户期待的工夫。

白屏率：用户触发页面关上后，距离肯定工夫后依然没有任何页面绘制，则认定为白屏，白屏率 = 白屏产生 PV / 小程序冷启动关上 PV。白屏率通常是极其状况下的利用体现，比方在无网、弱网、后端无返回或返回谬误状况下的行为，尽管大部分状况下不能给用户有用的信息，然而须要有兜底的策略避免用户得不到反馈，如果得不到反馈用户就会认为是程序出了问题，他不会去思考环境的问题，也不会去 debug，你可能就会因而失去一个用户。

服务可用性：包含

1. HTTP 申请拜访失败率：申请后端服务时的失败率，失败率 = 申请失败次数 / 申请数量。
2. JSError：小程序运行过程中产生的 JS error。

服务可用性代表了谬误状况下的利用体现，谬误依照起源方简略分为两种，一个是服务器端的谬误，具体的体现就是 HTTP 申请失败，一种是前端的谬误，也就是 JS error。这些谬误有可能什么都不影响，但也可能重大到导致程序异样不能运行，须要具体问题具体分析。

你能够在 开发者平台 - 开发治理 - 运维核心

看到这三个指标的详细情况。咱们能够看到白屏率和服务可用性其实标记了利用的稳定性和谬误 / 异样场景下的体现，而 FMP，是在失常的业务场景下最直观的形容小程序性能的指标，上面咱们就围绕如何“如何升高小程序 FMP 讲一下晋升小程序性能的“三板斧”。

第一板斧 - 断舍离，缩小小程序包体积

咱们晓得，小程序在公布的时候都是先将本地的代码打个包，而后上传到服务器，用户在应用咱们的小程序时首先会先下载代码包，而后宿主 app 中的小程序框架【todo，小程序外围是什么意思？？】会依据代码包进行渲染。用户的网络状况咱们不能管制，但代码包的大小咱们还是能够把控的。缩小代码包体积就是一种最简略也是最间接的办法【todo，可能会被 argue，很多开发者做了体积裁剪，然而并不失效】。

能删除的资源删除，切实不能删除的压缩

用户关上小程序时只会看到一个页面，那么咱们能够把其它页面都删掉，只保留这一个页面，这样 FMP 就能够降下去。

手动狗头保命，当然不能这么做，除非饭碗不想要了 …

然而这个思路是能够借鉴的。事实上，如果你的小程序经验过了屡次迭代，经手过了不同的开发人员之后，你会发现，小程序的性能更欠缺了，包体积也一直的减少了，然而，这些页面这些性能真的都是必须的嘛？在 开发者平台 - 数据分析 - 行为剖析 - 页面剖析 - 页面访问量

能够看到你的小程序各个页面流量的状况，对大部分的小程序而言，流量只集中在多数的几个页面上，有些页面基本没有流量，那这些没有流量的页面与性能是不是也能够从小程序中摘除 呢？当然能够。

从小见大，没有用的页面能够删除，没有用到的资源也能够从小程序包中删除，包含自定义组件、npm 包、css、图片。

在智能小程序开发的过程中，常常须要引入图片资源。如果应用图片不当（过多过大的图片），在加载时会耗费更多的系统资源，从而影响整个页面的性能，因而做好图片优化十分重要。【todo，这个话术不肯定适合，能够参看一下 https://smartprogram.baidu.co… 这篇文章里的阐明 update: 已改为“在智能小程序开发的过程中，常常须要引入图片资源。如果应用图片不当（过多过大的图片），在加载时会耗费更多的系统资源，从而影响整个页面的性能，因而做好图片优化十分重要。“】，小程序包中的图片会随小程序包一起下载，而这些图片其实能够放到动态资源服务器上，小程序代码中间接应用图片地址就好。如果特地须要应用图片，别忘了在小程序开发者工具 - 我的项目信息 - 本地配置 - 上传代码时开启图片压缩。

将入口页占比拟高的页面分到主包，其它页面分到子包

分包 是小程序官网提供的缩小包体积的办法，开发者能够将智能小程序划分成不同的子包，在构建时打包成不同的分包，用户在应用时按需进行加载。倡议依照 开发者平台 - 数据分析 - 行为剖析 - 页面剖析 - 入口页面次数

降序来分包，将做入口页多的页面放到主包中，其它的页面适当的分包即可。

须要留神的是，在分包之后，页面的门路也会变动，如果之前某些页面做过推广流动，为了避免用户找不到页面，能够应用 自定义路由 的性能将原地址映射到新地址上。

第二板斧 - 存数据，巧用缓存与官网能力

疾速的展现首屏是咱们的目标，为了疾速的展现首屏，有些货色要放弃，有些货色要斗争。应用官网提供的性能优化的办法，尽管不是那么优雅，但的确是晋升性能的好伎俩。而缓存这种用空间换取工夫的策略，在性能优化的办法上是真的实用无效。

应用 prelink，应用 onInit

prelink 只需在 开发者平台 - 开发治理 - 设置 - 开发设置 - 服务器配置

配置，你就能够失去 200ms 的晋升，这几乎是官网给你的尚方宝剑，用不必看你了。它的原理是提前建设 TCP 连贯和复用 TCP 连贯。须要留神的是，配置的申请地址是须要反对 HEAD 类型申请的。

onInit 是官网给你的又一个魔法，只须要把 onLoad() 中的获取数据的办法在 onInit() 中再进行一遍即可。就这么简略。

// 批改前

onLoad() {this.getPageData();

}

// 批改后

onInit() {if (!this.onInitLoaded) {

this.onInitLoaded = true;

this.getPageData();}

},

onLoad(options) {if (!this.onInitLoaded) {

this.onInitLoaded = true;

this.getPageData();}

}

缓存 API 端能力

API 端能力是小程序提供的不同于一般 web 利用的性能，这些性能不便了开发者去实现丰盛的利用，但端能力实际上是有性能耗费的，和一般的 js 语句相比执行起来要慢一些，为了抹平这种差别，一些不常变动的 API 端能力后果其实能够缓存起来，屡次获取时间接从咱们缓存的数据中获取。

const cached = swan.getStorageSync('apiResultCached') || {};

const promiseCache = new Map();

const MAX_CACHE_TIME = 1000 * 60 * 60 * 24 * 7;

// 缓存办法

function memorize(fn) {

const apiName = fn.name;

return function () {if (cached[apiName]) {if (Date.now() - cached[apiName]['__timestamp'] < MAX_CACHE_TIME) {return Promise.resolve(cached[apiName]);

}

cached[apiName] = null;

}

let promise = promiseCache.get(apiName);

if (promise) {return promise;}

promise = new Promise((resolve, reject) => {fn().then(res => {cached[apiName] = res;

cached[apiName]['__timestamp'] = Date.now();

swan.setStorage({

key: 'apiResultCached',

data: cached

});

resolve(res);

}).catch(e => {reject(e);

}).finally(() => {promiseCache.delete(apiName);

});

});

promiseCache.set(apiName, promise);

return promise;

};

}

function getSystemInfoAPI() {return new Promise((resolve, reject) => {

swan.getSystemInfo({success: res => resolve(res),

fail: err => reject(err)

});

});

}

// 这里只缓存了 swan.getSystemInfo，一些其它的 API 办法，只有是不长变动的都能够缓存起来

export const getSystemInfo = memorize(getSystemInfoAPI);

缓存页面主数据

如果页面的数据是动态的，间接写到 Page 的 data 中即可，但理论大部分状况是，页面一部分是前端就能够渲染的动态的构造与数据，另一部分是从后端接口获取的数据。从后端接口获取的首屏数据能够缓存到 storage 中，这样在第二次加载这个页面的时候能够从 storage 中获取，同时异步发动申请，申请返回后再更新页面数据。留神，咱们是为了更快的展示页面，所以只 缓存和加载首屏可见的数据即可，非首屏数据提早加载。

// 从 storage 中获取页面数据

swan.getStorage({

key: 'pageData',

success: res => {

// 如果有缓存且异步申请未返回则应用缓存的数据渲染页面

if (res.data && !this.requestBack) {this.renderPage(data);

}

}

});

// 异步发动申请获取页面数据

getPageData().then(res => {

this.requestBack = true;

// 申请返回后依据最新数据渲染页面

this.renderPage(res.pageData);

// 同时缓存页面数据到 storage 中

swan.setStorage({

key: 'pageData',

data: res.pageData

});

});

这样做可能会带来一个问题，就是页面数据加载后并不一定是最新的数据，最新的数据从申请获取到后会刷新页面的数据。所以，如果你的利用对实时性的要求比拟高的话可能并不适宜应用这种办法。

第三板斧 - 轻渲染，只渲染必须的内容

在小程序加载过程中，逻辑代码和渲染代码是拆散的，别离由不同的线程进行。

慢的线程会连累整个加载的速度，当你的逻辑代码曾经跑的飞起的时候，能够思考下是否在渲染的层面有改良的方法。

缩小对渲染有耗费的写法

小程序自身提供了丰富多彩的用法，包含自定义组件、动静库、filter、sjs 等等，这些性能晋升了咱们开发的效率，但另一方面，多种多样的性能有可能带来新的的性能耗费陷阱。你须要在效率和性能之间找寻一种均衡，有哪些用法晋升的效率无限而带来的性能耗费却是不可漠视的？这须要联合本身业务的实际，但在 FMP 占比拟高的页面，这些性能还是须要慎之又慎。

另外，也须要留神 缩小 view 和 text 组件的非凡属性和事件，这是很容易漠视的一点，尽管单次应用带来的性能耗费无限，然而要用到 view 和 text 组件的中央太多了，架不住应用数量的回升带来质的扭转。尤其是自定义组件中应用了低性能的写法，因为自定义组件可能会被用到屡次（例如列表项，甚至可能会被用上百次上千次），低性能的自定义组件会带来成倍的性能耗费。

// 批改前 view 应用了 style 属性

<view style="height: 20rpx;"> 热门榜单 </view>

// 批改后 view 应用了 class，在 css 文件中写款式

.title {height: 20rpx;}

<view class="title"> 热门榜单 </view>

分屏渲染

构想一下，当咱们加载一个长度超过一个屏幕的列表时，其实用户不会看到列表的所有内容，只能看到列表的前几项，那么咱们当然能够只加载列表的前几项，当用户滑动的时候再加载残余的内容。同样的，在渲染页面的时候，咱们也能够在第一次 setData 时进行数据的宰割，只设置首屏可见的数据，提早设置非首屏数据。

// appList 是从后端接口获取的页面数据 active 是以后可见的 tab 索引

// firstLoadAppList 为计算出的首屏幕数据

const firstLoadAppList = appList.map((item, index) => {return index === active ? item.slice(0, 10) : [];});

this.setData({appList: firstLoadAppList}, () => {

// 可将残缺数据记录待之后加载

this.appList = appList;

});

勾销骨架屏采纳渐进式加载

骨架屏 是小程序提供的一种优化用户体验的机制，但其实任何渲染都有耗费，骨架屏也是。在骨架屏中写了简单的构造甚至动画成果，反而不利于真正的有意义的页面疾速的加载。当然，骨架屏的确能够让用户更快的感知到页面正在加载，所以须要在这之间寻找一种均衡，是须要用户先看到一个正在加载的页面，还是让用户更快的看到有意义的有内容的画面。举荐的一个计划是：

• 应用官网提供的骨架屏，但简化骨架屏的框架，缩小应用款式与动画成果
• 在真正的页面渲染中，为各个局部设置背景色与高度，在 Page 的 data 中设置默认值，在还未进行第一次 setData 的时候渲染出页面的框架。这样，当页面数据来了的时候，只是在特定的局部填充值即可。

后记

欢送在 小程序开发者社区 中发问性能相干的问题，也欢送在 Github 上 follow 我，我会不定期更新一些前端相干的文章，如果想更深刻的和我探讨小程序性能相干的问题，能够给我发邮件。