微信小程序优化

setData

setData 是小程序开发中使用最频繁的接口，也是最容易引起性能问题的接口。在介绍常见的错误用法前，先简单介绍一下 setData 背后的工做原理。

工做原理

小程序的视图层目前使用 WebView 做为渲染载体，而逻辑层是由独立的 JavascriptCore 做为运行环境。在架构上，WebView 和 JavascriptCore 都是独立的模块，并不具有数据直接共享的通道。当前，视图层和逻辑层的数据传输，实际上经过两边提供的evaluateJavascript 所实现。即用户传输的数据，须要将其转换为字符串形式传递，同时把转换后的数据内容拼接成一份 JS 脚本，再经过执行 JS 脚本的形式传递到两边独立环境。

而 evaluateJavascript 的执行会受不少方面的影响，数据到达视图层并非实时的。

常见的 setData 操做错误

1. 频繁的去 setData

在咱们分析过的一些案例里，部分小程序会很是频繁（毫秒级）的去setData，其致使了两个后果：

• Android 下用户在滑动时会感受到卡顿，操做反馈延迟严重，由于 JS 线程一直在编译执行渲染，未能及时将用户操做事件传递到逻辑层，逻辑层亦没法及时将操做处理结果及时传递到视图层；
• 渲染有出现延时，因为 WebView 的 JS 线程一直处于忙碌状态，逻辑层到页面层的通讯耗时上升，视图层收到的数据消息时距离发出时间已通过去了几百毫秒，渲染的结果并不实时；

2. 每次 setData 都传递大量新数据

由setData的底层实现可知，咱们的数据传输实际是一次 evaluateJavascript 脚本过程，当数据量过大时会增长脚本的编译执行时间，占用 WebView JS 线程，

3. 后台态页面进行 setData

当页面进入后台态（用户不可见），不该该继续去进行setData，后台态页面的渲染用户是没法感觉的，另外后台态页面去setData也会抢占前台页面的执行。

图片资源

目前图片资源的主要性能问题在于大图片和长列表图片上，这两种状况都有可能致使 iOS 客户端内存占用上升，从而触发系统回收小程序页面。

图片对内存的影响

在 iOS 上，小程序的页面是由多个 WKWebView 组成的，在系统内存紧张时，会回收掉一部分 WKWebView。从过去咱们分析的案例来看，大图片和长列表图片的使用会引发 WKWebView 的回收。

图片对页面切换的影响

除了内存问题外，大图片也会形成页面切换的卡顿。咱们分析过的案例中，有一部分小程序会在页面中引用大图片，在页面后退切换中会出现掉帧卡顿的状况。

当前咱们建议开发者尽可能减小使用大图片资源。

代码包大小的优化

小程序一开始时代码包限制为 1MB，但咱们收到了不少反馈说代码包大小不够用，通过评估后咱们放开了这个限制，增长到 2MB 。代码包上限的增长对于开发者来讲，可以实现更丰富的功能，但对于用户来讲，也增长了下载流量和本地空间的占用。

开发者在实现业务逻辑同时也有必要尽可能减小代码包的大小，由于代码包大小直接影响到下载速度，从而影响用户的首次打开体验。除了代码自身的重构优化外，还能够从这两方面着手优化代码大小：

控制代码包内图片资源

小程序代码包通过编译后，会放在微信的 CDN 上供用户下载，CDN 开启了 GZIP 压缩，因此用户下载的是压缩后的 GZIP 包，其大小比代码包原体积会更小。 但咱们分析数据发现，不一样小程序之间的代码包压缩比差别也挺大的，部分能够达到 30%，而部分只有 80%，而形成这部分差别的一个缘由，就是图片资源的使用。GZIP 对基于文本资源的压缩效果最好，在压缩较大文件时每每可高达 70%-80% 的压缩率，而若是对已经压缩的资源（例如大多数的图片格式）则效果甚微。

及时清理没有使用到的代码和资源

在平常开发的时候，咱们可能引入了一些新的库文件，而过了一段时间后，因为各类缘由又再也不使用这个库了，咱们经常会只是去掉了代码里的引用，而忘记删掉这类库文件了。目前小程序打包是会将工程下全部文件都打入代码包内，也就是说，这些没有被实际使用到的库文件和资源也会被打入到代码包里，从而影响到总体代码包的大小。