共计 2997 个字符，预计需要花费 8 分钟才能阅读完成。
小程序从发布到现在也已经有将近两年的时间，越来越来多的公司开始重视小程序生态带来的流量，今年也由于小程序平台对外能力的越来越多的开放以及小程序平台的自身优化，越来越多的开发者也自主的投入到小程序的开发当中，现在，作为前端如果会写小程序，绝对是一个不折不扣的面试加分项。相信不少人刚接触小程序时的感觉大都是小程序很简单，开发只要是会写 html、css、js 就可以了，但是当自己的第一个小程序开发完成上线时，却发现小程序体验非常糟糕，接下来就让我们一窥小程序优化之道。
加载流程
要想给小程序做优化，对小程序的加载流程一定要有一定的了解，小程序是怎么加载的，让我们先来看一个图片：
这三个图片大家一定都不陌生，当你打开一个小程序的时候就会经历这三个过程：
资源准备，这个过程就是小程序在下载你的代码包的过程
业务代码注入和渲染，这个过程就是小程序将的业务代码分别注入视图层和逻辑层，并在视图层做视图的渲染
异步数据的请求，显示加载中的时候，其实就是在到达首页时，如果首页有异步数据请求，这个时候小程序就会执行异步数据请求
上述就是对小程序的启动过程的一个简单概述，让我们再来看一个更加具体一点的图片，可能会更好理解小程序启动过程：
从这个图片可以看到，小程序在启动加载的时候，其实分为两部分，一部分是逻辑层的启动启动，另一部分是视图层的启动，逻辑层的启动就是加载小程序的 js 代码，视图层的启动 webview 对页面进行加载和渲染，那预加载又是什么时候执行的呢？其实在微信动的时候，小程序平台就开始静默执行与加载的过程，包括 JS 引擎初始化和 WebView 的初始化，然后会注入小程序自带的公共库，例如自带 api、组件等，后面的小程序启动，就是上面说过的打开一个小程序具体的启动加载过程了，下载代码包，分别注入逻辑层和视图层，然后共同完成首屏渲染。
启动性能优化
讲完小程序的启动过程，就可以开始介绍具体的性能优化方案了，让我们一起看看影响小程序性能的因素以及具体的解决办法
代码包大小
代码包大小会直接影响小程序的启动速度，代码包越大，小程序的启动时间就越长，在小程序启动时，下载代码包和代码注入的时间和小程序代码包大小是成正比的，一般小程序的平均启动时间是 2s 左右，可以看看你的小程序有没有拖后腿，那么如何控制包大小呢？
资源控制
开启开发工具”上传代码时自动压缩”，小程序开发工具有一个上传代码时自动压缩的功能，当开启时，会在你上传代码时为你做代码压缩，除了这个，我们也可以通过使用第三方打包工具做代码压缩，如 webpack、grunt、grulp。
及时清理无用代码和资源文件，无用的代码和资源也会占用一定的包大小。
减少代码包中的资源文件，将资源存放在 cdn 上，小程序开发工具对资源文件的压缩比率非常低，资源有条件的可以尽量放在 CDN 上，因为小程序开发工具对资源文件的压缩比率非常低，只有 10% 左右，或者也可以用第三编译工具对资源文件自己进行压缩处理
分包加载
分包加载是小程序提高加载启动性能的一个重要方法，如果有人还不了解，可以点开链接看官方介绍，那么如何做好分包加载呢？将小程序中不常用的代码放在分包中，主包内只保留用户最常访问的页面，但是由于官方规定 tab 页面只能放在主包中，因为小程序启动时只会加载主包，使用时按需下载分包，不会在加载时一次将整个代码包下载，这样就能有效减少启动加载的时间。但是分包加载也有它的局限性，用户首次打开分包页面时，需要先进行分包代码的加载和注入，会造成页面切换时产生一定的延时，因此在此基础上，官方又推出了分包预加载和独立分包。
分包预加载
先来看一下之前分包加载时的流程是怎样的：
那么分包预加载是怎么干的呢？分包预下载：提前配置可能会跳到哪些分包，框架在进入页面后根据配置进行预下载，分包预加载会在你进入主包页面后，为你静默开启分包代码的下载和注入，这个过程是无感的，来看一下分包预加载的流程是怎样的：
分包预加载需要注意的是：同一个分包中的页面享有共同的预下载大小限额 2M，限额会在工具中打包时校验，因此不能把所有的分包页面都配置到分包预加载的配置中，只配置主包页面会跳转的页面即可。
独立分包
独立分包又是什么呢？由于从分包页面启动是，必须要依赖于主包的下载和注入，启动速度会受到主包大小的制约，因此这就有了独立分包，独立分包在启动分包页面时，可以独立启动而不需要依赖主包，这样就可以减少主包下载和注入的时间，通常情况下我们会将活动、广告一类的具有独立逻辑的功能代码标记为一个独立分包，在分包页面启动时，可以不依赖于主包启动，只下载分包代码进行注入。让我们来看一下独立分包的加载流程是怎样的：
首屏加载性能优化
首屏加载的体验对小程序来说十分重要，那么如何提升首屏加载性能呢？
提前请求：异步数据数据请求不需要等待页面渲染完成
利用缓存：利用 storage API 对异步请求数据进行缓存，二次启动时先利用缓存数据渲染页面，再进行后台更新
避免白屏：先展示页面骨架和基础内容
及时反馈：及时地对需要用户等待的交互操作给出反馈，避免用户以为小程序没有响应
渲染性能优化
要想提高渲染性能，就需要知道小程序如何做页面渲染的，让我们先来看一个页面渲染的流程图：
js 引擎和 native 都可以过 js 的计算或者 data 修改来对 Webview 发起绘制操作，但是对开发者来说最重要的就是 js 引擎和 Webview 之间的通信，这通信过程是一个跨进程通信，是非常耗时的一个过程，我们要提高渲染的性能，也就是减少这个跨进程通信的时间，那么怎么去减少跨进程通信的时间呢？
避免不当使用 setData
使用 data 在方法间共享数据，会增加 setData 传输的数据量，同时会增加页面重绘的概率
data 仅包括与页面相关的数据
使用 setData 传输大量数据，通讯耗时与数据量正相关，页面更新延迟可能造成更新开销增加
仅传输页面中发生变化的数据，使用 setData 的特殊 key 实现局部更新
后台页面进行 setData 抢占前台页面的资源
页面切入后台后的 setData 调用，延迟到页面重新展示的时候执行
总结来说就是在 data 中只定义与页面渲染相关的数据，其他与页面渲染无关的数据都定义成普通变量，在做 setData 操作时，尽量只传输页面渲染需要的数据，当页面切换时，将后台执行的 setData 操作销毁，等到页面重新展示的时候再执行。
避免不当使用 onPageScroll
只在必要的时候监听 pageScroll 事件
避免在 onPageScroll 中执行复杂逻辑
避免在 onPageSroll 中频繁调用 setData
避免频繁查询节点信息 (SelectQuery), 部分场景使用节点布局相交状态监听(IntersectionObserver) 替代
由于 onPageSroll 事件监听在处理 js 引擎和 webview 之间的通信时也是一个跨进程通信，因此在使用 onPageScroll 事件时，要注意以上的几点内容，来进行相关的优化
使用自定义事件
在需要频繁更新的场景下，自定组件的更新只在组件内部更新，不受页面其他部分内容复杂性影响，这样也可以在一定程度优化渲染性能
总结
这篇文章简单的介绍了微信小程序性能优化的一些方法，还有很多我没有介绍到方法就需要大家自己去探索总结了。希望大家看完这篇文章能对小程序性能优化有一定的认识，如果有错误或不严谨的地方，欢迎批评指正，如果喜欢，欢迎点赞收藏。
