手把手带你看看小程序如何优化？（实践总结）-Développement de mini-programmes-php.cn

小程序如何优化？本篇文章给大家总结一下小程序优化实践，看看小程序优化项，希望对大家有所帮助！

手把手带你看看小程序如何优化？（实践总结）

小程序运行过程

我们先来梳理一下小程序的运行原理，磨刀不误砍柴功。

一图胜千言：

建议大家认真去理解图中的内容，对于小程序开发以及优化方向都有较有力的理论支持。

优化项

1. 合理的使用分包

微信小程序的主要特点是启动快速，为了这一特性，官方因此限制了包的大小，上限为 2M。

分包是小程序优化的第一要务，能有效提高小程序启动速度，以及页面打开速度。

包分为【主包】【普通分包】【独立分包】。

【主包】应该只放置启动页或者TabBar页面。

【普通分包】放置非TabBar页面的其他页面，推荐按照页面数量或者模块划分多个分包，减少分包的大小，当用户进入对应分包页面的时候才会去下载这个包，这也实现了包的按需加载，避免了资源浪费。当小程序从普通分包中的某个页面的时候启动时，需要首先下载主包，然后在下载分包。

【独立分包】放置一些独立性较高的页面，当小程序从独立分包中的页面启动时，只会下载独立分包，从而大大提高小程序启动速度，当用户进入TabBar页面或者其他普通分包页面才回去下载对应的包。

独立分包中不能有任何全局的东西，包括组件，登录等，引入任何其他包中的资源都会出错。

作者建议梳理好页面和功能再分包，分包的界限并不是包的大小超过了2M，而是要灵活的根据业务和功能来进行划分。在如今正常网络情况下，2M的分包和500KB的分包的下载可能用户感知差距不会特别大，但是如果是在弱网环境下，这两者会造成用户白屏的时间上就有很大的差距（亲身经历，可以说是掏心掏肺了）。

比如，我会将那些可以由TabBar页面直接进入且频率较高的二级页面放入一个分包，然后其他更深层次的页面或者那些不是那么重要的页面分成一个包，又或者将整个订单业务模块的页面分成一个包。

包分好了，自然不能少了【分包预下载】。可以按照官网的规则进行配置，当用户进入某个页面时，提前下载包。

2. 按需注入

小程序下载完包之后，会将打开页面所在包的全部JS合并注入，一些未访问的页面以及未用到的自定义组件也会被注入到运行环境当中。影响注入耗时和内存占用。我们希望的是当包下载完成后，只注入我们即将打开的页面的代码就行。

这也是小程序启动或跳转进入分包页面影响白屏时间的一点。

{ "lazyCodeLoading" : "requiredComponents" }

Copier après la connexion

3. 明确setData的几个调用原则

小程序是以微信客户端为宿主运行的，即wxml、wxs、wxss都是运行在客户端的，运行环境又分成了两个线程，一个渲染线程，一个逻辑线程。渲染层使用WebView进行渲染，逻辑层使用JSCore运行JS代码。wxml和wxss工作在渲染线程，而wxs工作在逻辑线程。那两个线程之间怎么通信呢？

通过客户端作为中转站进行通信

渲染层触发事件响应到客户端，逻辑层通过setData传送数据到客户端，两边的数据都会被转换成字符串之后进行传输，客户端再分别做出响应，并且响应并非实时的。意味着在逻辑层触发setData页面并不会马上更新，会有一些延迟渲染层才会更新。

模型如图：

Native即客户端。

回到问题，setData在逻辑层调用，让渲染层快速响应取决于逻辑层到客户端的数据传输效率，而这个传输效率又取决于你传输数据的大小，所以在调用setData的时候应该尽可能减少数据传输大小。

Native会将wxml转换成js对象，然后和setData传进来的对象做差异化对比，将差异化渲染到视图上。

综上原理，我们调用setData应该遵循几个原则：

尽可能减小需要setData数据的大小，JSON.stringify后不超过 256KB。
避免将不需要渲染的数据（不在wxml中绑定的数据）传入setData，减少差异对比耗时。
避免过于频繁调用setData，会导致逻辑层业务繁忙，一直在处理setData的传输队列，而导致抽不开身去处理渲染层的响应，从而导致渲染阻塞，页面出现卡顿，甚至setData无效。如果可以的话，可以采用节流等方式进行优化。
尽可能将多个需要更新的数据合并为一次setData，减少通信过程。
避免后台页面触发setData，也会占用Js线程，有可能会造成阻塞，导致真正需要setData的数据没有响应

减小setData的数据大小通常在列表场景中，通常只更新需要更新的下标：

const needRefresh = `list[${index}]` // 写法一 setData({ [needRefresh]: '新值' }) // 写法二 setData({ [`list[${index}]`]: '新值' }) // 写法三 setData({ 'list[0]': '新值' }) // 写法四 const needRefresh = `list[${index}].disabled` setData({ [needRefresh]: '新值' }) // 写法5 更新对象 setData({ 'personal.name':'xxx' })

Copier après la connexion

如果有变量，就需要放在[]内。

4. 控制图片大小比例

图片太大会增加下载时间和内存的消耗，并且为了用户体验，应该控制图片的高宽比例，防止图片变形或者被裁切（这个问题可以根据image的mode属性进行调整）。

一个合格的图片应该满足以下两点：

图片宽高乘积 <= 实际显示宽高乘积 * (设备像素比 ^ 2)。
显示的高/宽与原图的高/宽不超过 15%。

由于这些图片都出自UI，所以在这一条优化上你需要做的是：拿着这两条指标去跟UIbattle。

good lucky ～

以上第一条就是和设备的【dpr】相关，移动端开发一定要理解【dpr】，这里就不多赘述了。

我们应该合理的采用图片资源，例如在【dpr】为 2 的设备上，一个60x60的元素区域显示的图片为了兼顾清晰度与资源大小，图片大小不应该超过120x120，同理，【dpr】为 3 设备，图片应该不超过180x180。

我们小程序的资源都放在cdn上，可以利用cdn的图片云处理功能对资源请求进行控制，我司用的七牛云和又拍云，如下：

// 七牛云 `${_src}?imageMogr2/thumbnail/!${scaleRatio}p` // 又拍云 `${_src}!/scale/${scaleRatio}`

Copier après la connexion

更多云处理功能可以挪步官网：七牛云（https://developer.qiniu.com/dora/8255/the-zoom）和又拍云（https://help.upyun.com/knowledge-base/image/）

我们在小程序内自定义了图片组件cus-image, 该组件会根据【dpr】对图片进行云处理。并提供了ratio属性灵活调整图片大小（因为运营方上传的图片可能在不同尺寸的元素区域内引用，所以需要开发人员灵活控制）。

5. 避免短时间内发起太多请求

小程序中wx.request、wx.uploadFile、wx.downloadFile的发起的网络请求短时间内最大并发限制是10个，超过10个就会导致请求阻塞。而图片请求的并发最大数量为6。

那短时间怎么去界定呢？

【网络请求】耗时超过 300ms 的请求并发数不超过 10 个（一般不会出现这个问题，如果有这个问题那可能该考虑拆分页面、拆分业务或者合并接口了。）
【图片请求】同域名耗时超过 100ms 的图片请求并发数不超过 6 个

例如：300ms内发送了12个请求，其中10个请求在300ms内就请求完成了，只有2个请求超过300ms，这样是没有问题的。

【解决方案】

在接口请求上我们应该尽可能的减少请求数量。
图片可以设置懒加载lazy-load。
图标可以使用雪碧图。
将图片资源拆分在多个域名下。
自定义一个分片处理函数，将请求拆分成数个阶段发出。

function interelTasks(task,wait){ this.data.timer = setInterval(()=>{ task() }, wait) } async function task(promiseList = []){ const result = await promise.all(promiseList) // do something }

Copier après la connexion