微盟小程序性能优化要分享的内容分为三部分，启动性能加载、首屏加载的体验建议和渲染性能优化。

先讲启动性能加载的性能优化实践，先看启动加载过程的流程：

· 公共库注入

· 资源准备（基础UI创建，代码包下载）

· 业务代码注入和渲染

· 渲染首屏

· 异步请求

优化方案

1、控制代码包大小

· 开启开发者工具中的 “ 上传代码时自动压缩 ”

· 及时清理无用代码和资源文件

· 减少代码包中的图片等资源文件的大小和数量

· 将图片等资源文件放到CND中

· 提取公共样式

· 代码压缩，图片格式，压缩，或者外联

· 公共组件提取，代码复用

2、 分包加载

分包加载过程流程

在开发小程序分包项目时，会有一个或者多个分包，其中没有分包小程序必须包含一个主包，即放置启动页面或者tabBar页面，以及一些分包都需要用到的公共资源脚本。

在小程序启动时，默认会下载主包并且启动主包内页面，如果用户打开分包内的页面，客户端会把分包下载下来，下载完之后再进行展示。

· 分包加载流程

使用分包加载的优点：

· 能够增加小程序更大的代码体积，开发更多的功能

· 对于用户，可以更快地打开小程序，同时不影响启动速度

使用分包加载有哪些限制：

· 整个小程序所有分包不能超过8M

· 单个主包/分包不能超过2M

3、 运行机制优化

· 代码中减少立即执行的代码数量

· 避免高开销和长时间阻塞代码

· 业务代码都写入页面的生命周期中

· 做好缓存策略

4、 数据管理优化

· 首屏请求数量尽量不能超过5个，超过的可以做接口合并（node层，服务端都可以处理）

· 对多次提交的数据可以做合并处理

接下来和大家聊一聊首屏加载的体验建议和渲染性能优化。

二、首屏加载的体验建议

· 提前请求  

  异步数据请求不需要等待页面渲染完成。

· 利用缓存

  利用storage API对异步请求数据进行缓存，二次渲染页面，再进行后台更新。

· 避免白屏

  先展示页面骨架和基础内容。

三、渲染性能优化

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

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

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

·  在页面列表中使用懒加载+动态移除非可视区域范围内的内容，让dom小下去

·  耗时比较长的js做到异步，不要阻塞进程（js属于单线程）

·  少使用scroll-view,这个组件对性能的影响太大，单纯的只是需要一块区域滚动，可以使用view+css的方式实现

·  在页面频繁滚动触发回调函数，会导致页面卡顿，这时必须和防抖动函数或者节流函数相结合做一些处理

·  页面中的图片可以使用懒加载的方式（添加lazy-load属性，只针对page与scroll-view下的image有效）

·  页面跳转要做一下限制，如果页面快速点击会出现跳转多次的情况

 避免不正当的使用setData

· 使用data在方法间共享数据，可能增加setData传输的数据量。data 应该仅仅包含与页面渲染相关的数据

· 使用setData 传输大量的数据，通讯耗时与数据量成正比，导致页面更新延迟 可能造成页面更新开销增加。所以setData 仅传输页面需要的数据,使用setData 的特殊Key 实现局部更新

· 短时间内频繁调用setData  (操作卡顿、交互延迟   阻塞通信、页面渲染延迟)，对连续的setData 调用进行合并

· 后台进行页面setData  (抢占前台页面的渲染资源) 例如 活动定时器 再页面切入后台时应该将关闭

避免不正当的使用onPageScroll

· 只在必要的时候监听pageScroll 事件

· 避免在onPageScroll 中执行复杂的逻辑

· 避免在onPageScroll 中频繁调用setData

· 避免频繁查询节点信息(SelectQuery) 部分场景建议使用节点布局相交状态

·  监听( IntersectionObserver) 替代

使用自定义组件

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