小程序redux性能优化，提升三倍渲染速度-加速度jsudo

小程序redux性能优化，提升三倍渲染速度

来源：加速度jsudo

作者

访问量 10009

本文摘要

很多使用小程序的用户会反馈，一些小程序会出现卡顿的情况，比如一些电商小程序在打开商品列表需要几秒的缓冲时间，那么微信小程序开发需要如何优化，下面是这篇小程序redux性能优化。首先了解小程序的工作原理和性能关键点。

很多使用小程序的用户会反馈，一些小程序会出现卡顿的情况，比如一些电商小程序在打开商品列表需要几秒的缓冲时间，那么微信小程序开发需要如何优化，下面是这篇小程序redux性能优化。

首先了解小程序的工作原理和性能关键点。

1
工作原理（官方说明）

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

2
性能关键点（官方说明）

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

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

每次 setData 都传递大量新数据
由setData的底层实现可知，我们的数据传输实际是一次 evaluateJavascript 脚本过程，当数据量过大时会增加脚本的编译执行时间，占用 WebView JS 线程，
后台态页面进行 setData
当页面进入后台态（用户不可见），不应该继续去进行setData，后台态页面的渲染用户是无法感受的，另外后台态页面去setData也会抢占前台页面的执行。

3
度量性能指标

我们在优化性能时，指标是非常重要的，没有指标，你没法知道优化的点是否有效。不能单凭感觉去优化，要根据指标反馈，明确优化的成果。同时，优化就像个无底洞，要注意投入产出比。
用户反馈的卡顿，要么就是js执行消耗资源过多导致处理器没响应，要么是UI渲染消耗资源过多，导致UI没法响应用户操作。
通过查看代码，我们并没有消耗大量计算资源的业务逻辑，但是出现了UI反复操作和抢占资源的现象。

4
如何度量

可以利用setData的第二个参数，传入callback函数，统计渲染时长。代码如下

let startTime = Date.now()
tShopfas.setData(data, () => {
let endTime = Data.now()
console.log(endTime - startTime, '渲染时长')
})

案例分析 1、检查点：是否频繁去setData 检查结果：存在产生原因：redux中监听的是整个store，只要store变化，就会执行setData操作，这就意味着页面无关的数据改变，也会触发该页面执行setData操作，但是这个操作是无意义的。问题代码：

// libs/redux-wechat/connect.js
// 对整个store进行subscribe。变化就执行handleChange
tShopfas.unsubscribe = tShopfas.store.subscribe(handleChange.bind(tShopfas, options));
function handleChange(options) {
...省略代码
const state = tShopfas.store.getState()
const mappedState = mapState(state, options);
tShopfas.setData(mappedState)
}

解决方案：

只监听当前页面用到的store中的部分数据，只有该部分数据变化，才setData。（store没提供单个数据的监听，如果自己修改redux实现，难度较大，同时修改太底层，容易出不可预料的异常。）判断页面数据与需要更新数据是否相同，如果相同，不做操作。（这个方案成本比较低，就用它吧）

代码实现：

// libs/redux-wechat/connect.js
// 如果更新的数据和页面数据相同，不做操作。
function handleChange(options) {
...省略代码
const state = tShopfas.store.getState()
const mappedState = mapState(state, options);
// 如果更新的数据和页面数据相同，不做操作。
if (mappedState === tShopfas.prevState) return // 新加入代码
tShopfas.setData(mappedState)
// 保存上一次数据
tShopfas.prevState = mappedState // 新加入代码
}

另外一个优化：如果store数据毫秒级变化怎么办，例如更新购物车的同时，还更新了购物数量，能不能把两次变化合并起来？因为store的数据是共享的，最后一次的更新就是最新的数据，可以采用节流器对请求进行合并。

clearTimeout(tShopfas.setDataTMO)
tShopfas.setDataTMO = setTimeout(() => {
tShopfas.setData(mappedState)
}, 50); // 时间可以看情况调整

2、检查点：每次 setData 都传递大量新数据检查结果：存在产生原因：

页面存在引用没用到的store数据。后端返回数据直接进入store，后端接口返回冗余字段。

问题代码：

/pages/user/index.js
connect(state => ({
member: state.member,
mycoupon: state.mycoupon,
guessLikeList: state.recommend.guessLikeList,
locationInfo: state.common && state.common.locationInfo, //可删除
selectedseller: state.home.selectedseller,//可删除
carts: state.carts.carts,//可删除
...state.common
}))

解决方案：

删除页面无用的connect （老业务在使用，修改存在风险，通过后续迭代优化）请求后端接口后，拿到数据进行优化处理再把数据传入store（成本较高）

3、检查点：后台态页面进行 setData 检查结果：存在产生原因：redux connect设计与小程序有差异问题代码：

// libs/redux-wechat/connect.js
function onLoad(options) {
...省略部分代码
if(shouldSubscribe){
tShopfas.unsubscribe = tShopfas.store.subscribe(handleChange.bind(tShopfas, options));
handleChange.call(tShopfas, options)
}
}
function onUnload() {
...省略部分代码
// 页面onUnload时，才解除监听
typeof tShopfas.unsubscribe === 'function' && tShopfas.unsubscribe()
}