原生微信小程序的优化

小程序启动性能（首页启动）

小程序运行机制

小程序启动

小程序启动分为两种：

• 冷启动：用户首次打开，或小程序销毁后被用户再次打开，此时小程序需要重新加载启动
• 热启动：用户已经打开过某小程序，然后在一定时间内再次打开该小程序，此时小程序并未被销毁，只是从后台状态进入前台状态

重新启动的策略

小程序冷启动时，如果启动时不带 path（A 类场景），默认情况下将会进入小程序的首页。 在页面对应的 json 文件中（也可以全局配置在 app.json 的 window 段中），指定 restartStrategy 配置项可以改变这个默认的行为，使得从某个页面退出后，下次 A 类场景的冷启动可以回到这个页面。

{
  "restartStrategy": "homePage"
}

可选值	含义
homePage	（默认值）如果从这个页面退出小程序，下次将从首页冷启动
homePageAndLatestPage	如果从这个页面退出小程序，下次冷启动后立刻加载这个页面，页面的参数保持不变（不可用于 tab 页）

启动性能优化

代码包体积优化

合理使用分包

小程序中的某些场景（如广告页、活动页、支付页等），通常功能不是很复杂且相对独立，对启动性能有很高的要求。独立分包可以独立于主包和其他分包运行。从独立分包页面进入小程序时，不需要下载主包。建议开发者将部分对启动性能要求很高的页面放到特殊的独立分包中。

独立分包

独立分包是小程序中一种特殊类型的分包，可以独立于主包和其他分包运行。从独立分包中页面进入小程序时，不需要下载主包。当用户进入普通分包或主包内页面时，主包才会被下载。

注意：

• 独立分包中不能依赖主包和其他分包中的内容，包括 js 文件、模板、wxss、自定义组件等
• App 只能在主包内定义，独立分包中不能定义 App，会造成无法预期的行为
• 独立分包中暂时不支持使用插件

分包预下载

在使用「分包加载」后，虽然能够显著提升小程序的启动速度，但是当用户在使用小程序过程中跳转到分包内页面时，需要等待分包下载完成后才能进入页面，造成页面切换的延迟，影响小程序的使用体验。分包预下载便是为了解决首次进入分包页面时的延迟问题而设计的。

注意： 过度的预下载也会破坏分包按需使用的原则，过度的占用用户的存储空间，消耗数据流量。

分包异步化

分包异步化将小程序的分包从页面粒度细化到组件甚至文件粒度。这使得本来只能放在主包内页面的部分组件和代码逻辑可以剥离到分包中，并在运行时异步加载，从而进一步降低启动所需的包大小和代码量。

避免全局自定义组件和插件

• 如果自定义组件只在某个分包的页面中使用，应定义在页面的配置文件中
• 如果插件只在某个分包的中使用，请仅在分包中引用插件
• 全局引入的自定义组件会被认为是所有分包、所有页面都需要的，会影响「按需注入」的效果和小程序代码注入的耗时。

减小代码包内资源文件的大小

小程序代码包在下载时会使用 ZSTD 算法进行压缩，图片、音频、视频、字体等资源文件会占用较多代码包体积，并且通常难以进一步被压缩，对于下载耗时的影响比代码文件大得多。

建议开发者在代码包内的图片一般应只包含一些体积较小的图标，避免在代码包中包含或在 WXSS 中使用 base64 内联过多、过大的图片等资源文件。这类文件应尽可能部署到 CDN，并使用 URL 引入。

及时清理无用资源代码和资源

除了工具默认忽略或开发者明确声明忽略的文件外，小程序打包会将工程目录下所有文件都打入代码包内。意外引入的第三方库、版本迭代中被废弃的代码或依赖、产品环境不需要的测试代码、未使用的组件、插件、扩展库，这些没有被实际使用到的文件和资源也会被打入到代码包里，从而影响到代码包的大小。

建议使用微信开发者工具提供的「代码静态依赖分析」，不定期地分析代码包的文件构成和依赖关系，以此优化代码包大小和内容。对于仅用于本地开发调试，不应包含在小程序代码包的文件，可以使用工具设置的 packOptions.ignore 配置忽略规则。

在使用打包工具（如 Webpack、Rollup 等）对小程序代码进行预处理时，可以利用 tree-shaking 等特性去除冗余代码，也要注意防止打包时引入不需要的库和依赖。

代码注入优化

优化代码量

使用按需注入，尽量避免在全局声明中引入使用率低的自定义组件。

优化执行耗

使用用时注入，使一部分自定义组件不在启动时注入，而是在真正被渲染时才进行注入，进一步降低小程序的启动和首屏时间。

首屏渲染优化

启用初始渲染缓存

自基础库版本 2.11.1 起，小程序支持启用初始渲染缓存。开启后，可以在非首次启动时，使视图层不需要等待逻辑层初始化完毕，而直接提前将页面渲染结果展示给用户，这可以使「首页渲染完成」和页面对用户可见的时间大大提前。

缓存请求数据

小程序提供了wx.setStorage、wx.getStorage等读写本地缓存的能力，数据存储在本地，返回的会比网络请求快。如果开发者基于某些原因无法采用数据预拉取与周期性更新，我们推荐优先从缓存中获取数据来渲染视图，等待网络请求返回后进行更新。

骨架屏

骨架屏通常用于在页面完全渲染之前，通过一些灰色的区块大致勾勒出轮廓，待数据加载完成后，再替换成真实的内容。

建议开发者在页面数据未准备好时（例如需要通过网络获取），尽量避免展示空白页面，而是先通过骨架屏展示页面的大致结构，请求数据返回后再进行页面更新。以提升用户的等待意愿。

开发者工具提供了生成骨架屏的能力，帮助开发者更便捷的维护骨架屏。

小程序运行时性能

小程序运行环境

微信小程序运行在多种平台上：iOS/iPadOS 微信客户端、Android 微信客户端、Windows PC 微信客户端、Mac 微信客户端、小程序硬件框架和用于调试的微信开发者工具等。

不同运行环境下，脚本执行环境以及用于组件渲染的环境是不同的，性能表现也存在差异：

• 在 iOS、iPadOS 和 Mac OS 上，小程序逻辑层的 JavaScript 代码运行在 JavaScriptCore 中，视图层是由 WKWebView 来渲染的，环境有 iOS 14、iPad OS 14、Mac OS 11.4 等；
• 在 Android 上，小程序逻辑层的 JavaScript 代码运行在 V8 中，视图层是由基于 Mobile Chromium 内核的微信自研 XWeb 引擎来渲染的；
• 在 Windows 上，小程序逻辑层 JavaScript 和视图层都是用 Chromium 内核；
• 在 开发工具上，小程序逻辑层的 JavaScript 代码是运行在 NW.js 中，视图层是由 Chromium Webview 来渲染的。

JavaScriptCore 无法开启 JIT 编译 (Just-In-Time Compiler)，同等条件下的运行性能要明显低于其他平台。

平台差异

尽管各运行环境是十分相似的，但是还是有些许区别：

• JavaScript 语法和 API 支持不一致：语法上开发者可以通过开启 ES6 转 ES5 的功能来规避（详情）；此外，小程序基础库内置了必要的Polyfill，来弥补API的差异（详情)。
• WXSS 渲染表现不一致：尽管可以通过开启样式补全来规避大部分的问题，还是建议开发者需要在各端分别检查小程序的真实表现。

运行时性能优化

合理使用 setData

setData 的流程

setData 的过程，大致可以分成几个阶段：

• 逻辑层虚拟 DOM 树的遍历和更新，触发组件生命周期和 observer 等；
• 将 data 从逻辑层传输到视图层；
• 视图层虚拟 DOM 树的更新、真实 DOM 元素的更新并触发页面渲染更新。

数据通信

对于第 2 步，由于小程序的逻辑层和视图层是两个独立的运行环境、分属不同的线程或进程，不能直接进行数据共享，需要进行数据的序列化、跨线程/进程的数据传输、数据的反序列化，因此数据传输过程是异步的、非实时的。

iOS/iPadOS/MacOS 上，数据传输是通过 evaluateJavascript 实现的，还会有额外 JS 脚本解析和执行的耗时。

数据传输的耗时与数据量的大小正相关，如果对端线程处于繁忙状态，数据会在消息队列中等待。

使用建议

• ✅ 页面或组件的 data 字段，应用来存放和页面或组件渲染相关的数据（即直接在 wxml 中出现的字段）；
• ✅ 页面或组件渲染间接相关的数据可以设置为「纯数据字段」，可以使用 setData 设置并使用 observers 监听变化；
• ✅ 页面或组件渲染无关的数据，应挂在非 data 的字段下，如 this.userData = {userId: 'xxx'}；
• ✅ setData 应只传入发生变化的字段；
• ✅ 建议以[数据路径]
• ✅ 页面切后台后的更新操作，应尽量避免，或延迟到页面 onShow 后延迟进行；
• ✅ 对于需要频繁更新的页面元素（例如：秒杀倒计时），可以封装为独立的组件，在组件内进行 setData 操作。必要时可以使用 CSS contain 属性限制计算布局、样式和绘制等的范围。
• ✅ 仅在需要进行页面内容更新时调用 setData；
• ✅ 对连续的 setData 调用尽可能的进行合并；
• ❌ 避免在 data 中包含渲染无关的业务数据；
• ❌ 避免使用 data 在页面或组件方法间进行数据共享；
• ❌ 避免滥用 纯数据字段 来保存可以使用非 data 字段保存的数据。
• ❌ 避免不必要的 setData；
• ❌ 避免以过高的频率持续调用 setData，例如毫秒级的倒计时；
• ❌ 避免在 onPageScroll 回调中每次都调用 setData。 (developers.weixin.qq.com/miniprogram… this.setData({'array[2].message': 'newVal', 'a.b.c.d': 'newVal'})，而不是每次都更新整个对象或数组；
• ❌ 不要在 setData 中偷懒一次性传所有data：this.setData(this.data)。
• ❌ 避免在切后台后仍进行高频的 setData，例如倒计时更新。

页面切换优化

避免在 onHide/onUnload 执行耗时操作

页面切换时，会先调用前一个页面的 onHide 或 onUnload 生命周期，然后再进行新页面的创建和渲染。如果 onHide 和 onUnload 执行过久，可能导致页面切换的延迟。

• ✅ onHide/onUnload 中的逻辑应尽量简单，若必须要进行部分复杂逻辑，可以考虑用 setTimeout 延迟进行。
• ❌ 减少或避免在 onHide/onUnload 中执行耗时逻辑，如同步接口调用、setData 等。

提前发起数据请求

在一些对性能要求比较高的场景下，当使用 JSAPI 进行页面跳转时（例如 wx.navigateTo），可以提前为下一个页面做一些准备工作。页面之间可以通过 EventChannel 进行通信。

例如，在页面跳转时，可以同时发起下一个页面的数据请求，而不需要等到页面 onLoad 时再进行，从而可以让用户更早的看到页面内容。尤其是在跳转到分包页面时，从发起页面跳转到页面 onLoad 之间可能有较长的时间间隔，可以加以利用。

渲染性能优化

适当监听页面或组件的 scroll 事件

只要用户在 Page 构造时传入了 onPageScroll 监听，基础库就会认为开发者需要监听页面 scoll 事件。此时，当用户滑动页面时，事件会以很高的频率从视图层发送到逻辑层，存在一定的通信开销。

类似的，对于 <scroll-view>、<page-meta> 等可以通过 bindscroll 监听滑动事件的组件，也会存在这一情况。

正是由于 scroll 事件触发的频率很高，因此开发者很容易误用，在使用时需要注意：

• ✅ 非必要不监听 scroll 事件；
• ✅ 在实现与滚动相关的动画时，优先考虑滚动驱动动画（仅 <scroll-view>）或 WXS 响应事件
• ❌ 不需要监听事件时，Page 构造时应不传入 onPageScroll 函数，而不是留空函数；
• ❌ 避免在 scroll 事件监听函数中执行复杂逻辑；
• ❌ 避免在 scroll 事件监听中频繁调用 setData 或同步 API。

Page({
  onPageScroll () {} // ❌不要保留空函数
})

Page({ 
  // ✅ 应直接不传入
})

选择高性能的动画实现方式

开发者在开发界面动画时，应该选择高性能的动画实现方式。

• ✅ 优先使用 CSS 渐变、CSS 动画、或小程序框架提供的其他动画实现方式完成动画；
• ✅ 在一些复杂场景下，如果上述方式不能满足，可以使用 WXS 响应事件 动态调整节点的 style 属性做到动画效果。同时，这种方式也可以根据用户的触摸事件来动态地生成动画；
• ❌ 避免通过连续 setData 改变界面的形式来实现动画。虽然实现起来简单灵活，但是极易出现较大的延迟或卡顿，甚至导致小程序僵死；
• ✅ 如果不得不采用 setData 方式，应尽可能将页面的 setData 改为自定义组件中的 setData 来提升性能。

使用 IntersectionObserver 监听元素曝光

部分业务场景会需要监控元素曝光情况，用于进行一些页面状态的变更或上报分析。

• ✅ 建议使用节点布局相交状态监听 IntersectionObserver 推断某些节点是否可见、有多大比例可见；
• ❌ 避免通过监听 onPageScroll 事件，并在回调中通过持续查询节点信息 SelectQuery 来判断元素是否可见。

控制在 Page 构造时传入的自定义数据量

为了便于开发，开发者可以添加任意的函数或数据到 Page 构造传入的 Object 参数中，并在页面的函数内用 this 访问。例如：

Page({
  data: {}
  userInfo: {} // 自定义数据
  currentUser: 'Wechat' // 自定义数据
  onTap() { }
  onLoad() {
    console.log(this.currentUser)
  }
})

为了保证自定义数据在不同的页面实例中也是不同的实例，小程序框架会在页面创建时对这部分数据（函数类型字段除外）做一次深拷贝，如果自定义数据过多或过于复杂，可能带来很大的开销。

• ✅ 对于比较复杂的数据对象，建议在 Page onLoad 或 Component created 时手动赋值到 this 上，而不是通过 Page 构造时的参数传入。

// ❌ 使用复杂对象作为自定义数据
Page({
  onLoad() { }
  bigData: { /* A complex object */ },
  longList: [ /* A long complex array*/ ]
})

// ✅ 运行时手动赋值到 this。开发者可以根据需要选择进行深拷贝、浅拷贝或不拷贝。
Page({
  onLoad() {
    this.bigData = { /* A complex object */ },
    this.longList = [ /* A long complex array*/ ]
  }
})

资源加载优化

控制图片资源的大小

开发者应根据功能需要和实际显示区域的大小，选择合适的图片尺寸、图片格式和压缩比。

图片体积太大，可能导致下列后果

• 增加图片下载时间，导致用户看到图片时机延迟；
• 对用户造成非必要的流量消耗；
• 影响图片解码和绘制的耗时，可能更容易造成掉帧、卡顿或白屏，甚至无法正常进行滚动和页面切换（低端设备上会尤为明显）；
• 内存占用增长，尤其是大图片和长列表中的大量图片会导致内存占用急剧上升。

图片对内存的影响

iOS 系统内存紧张时，会主动回收掉一部分 WebView。大图片和长列表中的大量图片很容易引起系统对 WebView 的回收，导致小程序白屏，严重时会触发微信强制关闭小程序。

内存增长如果超过了限制，也会导致小程序出现白屏或黑屏，甚至整个小程序发生闪退。

避免滥用 image 组件的 widthFix/heightFix 模式

widthFix/heightFix 模式会在图片加载完成后，动态改变图片的高度或宽度。图片高度或宽度的动态改变，可能会引起页面内大范围的布局重排，导致页面发生抖动，并造成卡顿。

对于页面的背景图或 banner 图，应尽量预先指定图片的尺寸，避免图片加载完成后再进行二次的尺寸调整。

内存优化