[图片] https://v.qq.com/x/page/j079878zozx.html 在开发小程序的过程中，往往会遇到三个比较明显的问题，一是页面加载后的真机显示效果会在一瞬间（大约半秒）出现错乱，二是页面加载速度慢，尤其是页面需要请求接口的情况，三是全局管理数据，并且把数据同步到Page或者Component内显示麻烦。所以我们研发了一个叫做dataWorker的工具来解决真机显示效果出现错乱、提高页面加载和显示速度、并且做好全局数据管理。 我们在开发多个小程序的过程中，尤其是在解决用户数据上报丢失时发现，微信小程序的生命周期在真机中其实为伪周期。事实上，完全可以在生命周期外走逻辑，请求接口，唯一比较麻烦的把数据同步到页面内。这也就是为什么我们要用dataWorker（可以理解为浏览器内的service worker）来同步更新视图。我相信，市面上的大部分业务方往往是在页面的[代码]onLoad[代码]或者[代码]onShow[代码]的时候才开始加载并且渲染页面的，最终导致了体验上的卡顿，在数据上则常常出现业务PV点消失的情况。但是如果我们在页面还没有被打开之前就加载好了页面，那么打开的速度当然会快很多。 当然，有很多业务方已有的代码实际上是不需要有全局数据介入的，所以我们又添加了一个开关，叫做palindrome（可以理解为数据双向绑定把）。 然后在需要使用worker的Page或Component内添加palindrome: true，如下： Page({ [代码]palindrome: true, data: {...}, onLoad(){...} [代码] }) 那么比方说我现在想要设置该页面的数据，我依然可以使用原先微信提供的this.setData({…})，这和dataWorker不冲突，也不会改变dataWorker内的数据，但是我同时又可以用dataWorker.data = {…}或dataWorker.list = […]这种办法去修改页面的数据（会直接影响视图）。 dataWorker 代码片段，需要使用appId，并且申请《微盟RPRM测试版》插件（wx10692d472c83e02c）0.0.4或以上版本的使用权限。并且需要关闭安全域名检查（需要请求接口）。 代码片段：https://developers.weixin.qq.com/s/5f5PDMmv7O4J

在上一篇分享中，给大家分享了启动性能加载的相关实践，详情可戳右方链接：微盟小程序性能优化实践（上） 接下来和大家聊一聊首屏加载的体验建议和渲染性能优化。 二、首屏加载的体验建议 · 提前请求     异步数据请求不需要等待页面渲染完成。 · 利用缓存   利用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) 替代 使用自定义组件 在需要频繁更新的场景下，自定义组件的更新只在组件内部进行，不受页面部分内容的复杂性的影响。 使用体验评分功能 在开发过程中使用体验评分可以测试出代码中一些需要优化的点，准备定位到影响性能的原因，很大程序提高页面的性能。

原来一个小程序使用Wepy开发，但是上线后，小程序会越来越卡。 2.0版本又遥遥无期，而且，1.0切换2.0需要调整的代码也可能会很多。 索性就直接换回wx原始框架编码。 下面内容，是作者将小程序框架换完后，测试上线后的经验总结，给需要的朋友参考参考。 1. 原来使用async/await 方式编程，需要有相对应的支持，可以不需要修改逻辑； 2. 原有使用async/await方式封装wx下的异步方法，需要有对应的支持，这个可以自己实现，也可以找工具类； 3. 原有使用wepy的地方需要换成wx，但是在使用wepy异步方法时，需要使用特殊方法处理，参考第二点； 4. 原有页面使用类继承方式，需要换成App/Page方式，该步骤使用代码拷贝； 5. 原有事件绑定，wepy支持事件中，直接绑定参数，需要改成wx支持dataset方式，事件处理中，需要相应的修改； 6. 原有列表循环repeat方式，需要改成wx:for方式； 7. 原有request方式，可以使用拦截器，需要自己重新封装wx.request实现拦截器功能； 8. 原有组件方式，改动比较大，原来的组件与页面可以进行双向事件响应，wx不支持，只能组件版定方式，处理单向事件； 9. 原有使用apply方式修改数据，需要使用setData方式，这样的话就会对原来的封装造成比较大的影响，需要合理调整； 10. 切换框架后，可以使用这个库wxPromise，解决async/await 已经wx方法Promise化；