性能优化

我们知道view部分是运行在webview上的，所以前端领域的大多数优化方式都有用。

我们知道view部分是运行在webview上的，所以前端领域的大多数优化方式都有用。

我们知道view部分是运行在webview上的，所以前端领域的大多数优化方式都有用。

加载优化

preload

代码包的大小是最直接影响小程序加载启动速度的因素。代码包越大不仅下载速度时间长，业务代码注入时间也会变长。所以最好的优化方式就是减少代码包的大小。

load-time-series

小程序加载的三个阶段的表示。

优化方式

  • 代码压缩。
  • 及时清理无用代码和资源文件。
  • 减少代码包中的图片等资源文件的大小和数量。
  • 分包加载。

首屏加载的体验优化建议

  • 提前请求: 异步数据请求不需要等待页面渲染完成。
  • 利用缓存: 利用 storage API 对异步请求数据进行缓存，二次启动时先利用缓存数据渲染页面，在进行后台更新。
  • 避免白屏：先展示页面骨架页和基础内容。
  • 及时反馈：即时地对需要用户等待的交互操作给出反馈，避免用户以为小程序无响应。

使用分包加载优化

sub-package

在构建小程序分包项目时，构建会输出一个或多个功能的分包，其中每个分包小程序必定含有一个主包，所谓的主包，即放置默认启动页面/TabBar 页面，以及一些所有分包都需用到公共资源/JS 脚本，而分包则是根据开发者的配置进行划分。

在小程序启动时，默认会下载主包并启动主包内页面，如果用户需要打开分包内某个页面，客户端会把对应分包下载下来，下载完成后再进行展示。

优点：

  • 对开发者而言，能使小程序有更大的代码体积，承载更多的功能与服务
  • 对用户而言，可以更快地打开小程序，同时在不影响启动速度前提下使用更多功能

限制：

  • 整个小程序所有分包大小不超过 8M
  • 单个分包/主包大小不能超过 2M

原生分包加载的配置假设支持分包的小程序目录结构如下：

  1. ├── app.js
  2. ├── app.json
  3. ├── app.wxss
  4. ├── packageA
  5. │   └── pages
  6. │       ├── cat
  7. │       └── dog
  8. ├── packageB
  9. │   └── pages
  10. │       ├── apple
  11. │       └── banana
  12. ├── pages
  13. │   ├── index
  14. │   └── logs
  15. └── utils

开发者通过在 app.json subPackages 字段声明项目分包结构：

  1. {
  2.   "pages":[
  3.     "pages/index",
  4.     "pages/logs"
  5.   ],
  6.   "subPackages": [
  7.     {
  8.       "root": "packageA",
  9.       "pages": [
  10.         "pages/cat",
  11.         "pages/dog"
  12.       ]
  13.     }, {
  14.       "root": "packageB",
  15.       "pages": [
  16.         "pages/apple",
  17.         "pages/banana"
  18.       ]
  19.     }
  20.   ]
  21. }

分包原则

  • 声明 subPackages 后，将按 subPackages 配置路径进行打包，subPackages 配置路径外的目录将被打包到 app（主包） 中
  • app（主包）也可以有自己的 pages（即最外层的 pages 字段
  • subPackage 的根目录不能是另外一个 subPackage 内的子目录
  • 首页的 TAB 页面必须在 app（主包）内

引用原则

  • packageA 无法 require packageB JS 文件，但可以 require app、自己 package 内的 JS 文件
  • packageA 无法 import packageB 的 template，但可以 require app、自己 package 内的 template
  • packageA 无法使用 packageB 的资源，但可以使用 app、自己 package 内的资源

官方即将推出分包预加载

preload-sub-package

独立分包

single-sub-package

渲染性能优化

render

  • 每次 setData 的调用都是一次进程间通信过程，通信开销与 setData 的数据量正相关。

  • setData 会引发视图层页面内容的更新，这一耗时操作一定时间中会阻塞用户交互。

  • setData 是小程序开发使用最频繁，也是最容易引发性能问题的。

避免不当使用 setData

  • 使用 data 在方法间共享数据，可能增加 setData 传输的数据量。data 应仅包括与页面渲染相关的数据。
  • 使用 setData 传输大量数据，通讯耗时与数据正相关，页面更新延迟可能造成页面更新开销增加。仅传输页面中发生变化的数据，使用 setData 的特殊 key 实现局部更新。
  • 短时间内频繁调用 setData，操作卡顿，交互延迟，阻塞通信，页面渲染延迟。避免不必要的 setData，对连续的setData调用进行合并。
  • 在后台页面进行 setData，抢占前台页面的渲染资源。页面切入后台后的 setData 调用，延迟到页面重新展示时执行。

one-context

避免不当使用onPageScroll

  • 只在有必要的时候监听 pageScroll 事件。不监听，则不会派发。
  • 避免在 onPageScroll 中执行复杂逻辑
  • 避免在 onPageScroll 中频繁调用 setData
  • 避免滑动时频繁查询节点信息（SelectQuery）用以判断是否显示，部分场景建议使用节点布局橡胶状态监听（inersectionObserver）替代

使用自定义组件

在需要频繁更新的场景下，自定义组件的更新只在组件内部进行，不受页面其他部分内容复杂性影响。