优化小程序测试网站-[微信小程序]性能优化

也想出现在这里？点击联系我~

立即下单

进入商城

进不了网站？换个网络试试！

对需要用户等待的交互操作及时反馈，避免用户认为小程序卡住、无响应

渲染性能优化一、小程序渲染原理

对于双线程下的界面渲染来说，小程序的逻辑层和渲染层是两个独立的线程。 在渲染层优化小程序测试网站，宿主环境会将WXML转换为相应的JS对象。 当逻辑层数据发生变化时，我们需要通过宿主环境提供的setData方法将数据从逻辑层传递到渲染层，然后比较前后的差异优化小程序测试网站，将差异应用到原来的Dom树上，并渲染正确的UI界面。

分析这个过程不难知道：页面初始化时间大致由两部分组成：页面初始数据通信时间和初始渲染时间。 其中，数据通信的时间是指从逻辑层数据组织到视图层完全接收的时间。 当数据量大于64KB时，总时长可控制在30ms以内。 传输时间一般与数据量正相关，过大数据的传输会显着减少这个时间。 因此，减少传输数据量是减少数据传输时间的有效途径。

2.避免setData使用不当

数据传输过程中，逻辑层会执行一次JSON.stringify，清除setData数据中不可传输的部分，然后将数据发送到viewport。 同时逻辑层会将setData设置的数据数组与data进行合并，以便开发者可以使用this.data读取变化后的数据。 因此，为了提高数据更新的性能，开发者在执行setData调用时应遵循以下原则：

2.1 不要过于频繁地调用setData，应考虑将多个setData合并为一个setData调用；

2.2 数据通信的性能与数据量正相关，因此如果有一些数据数组没有在界面中显示且数据结构复杂或包含长字符串，则不应该使用setData来设置此类数据；

2.3 data中最好不要设置与界面渲染无关的数据，可以考虑设置在页面对象的其他数组中

提高数据更新性能的代码示例表单

Page({
  onShow: function() {
    // 不要频繁调用setData
    this.setData({ a: 1 })
    this.setData({ b: 2 })
    // 绝大多数时候可优化为
    this.setData({ a: 1, b: 2 })
    // 不要设置不在界面渲染时使用的数据，并将界面无关的数据放在data外
    this.setData({
      myData: {
        a: '这个字符串在WXML中用到了',
        b: '这个字符串未在WXML中用到，而且它很长…………………………'
      }
    })
    // 可以优化为
    this.setData({
      'myData.a': '这个字符串在WXML中用到了'
    })
    this._myData = {
      b: '这个字符串未在WXML中用到，而且它很长…………………………'
    }
  }
})

一个列表中，有n条数据，需要更多的方法来拉取和加载。 如果此时你想点赞其中一项数据，就能及时看到点赞的疗效

1. SetData可以用来全局刷新。 点赞完成后，会重新获取数据，再次进行全局重新渲染。 这样做的好处是：方便、快捷！ 缺点是：用户体验很差。 当用户滑动超过100条数据时，重新渲染会话中会有一段空白期（不渲染）

2、说到重点了，就是借助setData进行部分刷新

> a.将点赞的`id`传过去，知道点的是那一条数据, 将点赞的`id`传过去，知道点的是那一条数据

<view wx:if="{{!item.status}}" class="btn" data-id="{{index}}" bindtap="couponTap">立即领取</view>

> b.重新获取数据，查找相对应id的那条数据的下标（`index`是不会改变的）
> c.用setData进行局部刷新

this.setData({
    list[index] = newList[index]
})

其实这个小操作对于刚接触陌陌小程序的人来说应该并不容易。 他们不明白setData还有这样的写法。

2.4 后台页面不要设置数据

某些操作会在某些页面上进行，页面跳转后，代码逻辑仍在执行。 此时多个webview共享一个js进程； 后台的setData操作会占用前台页面的渲染资源；

3、用户不当使用事件

视图层将风暴反馈给逻辑层时，也需要一个通信过程，通信的方向是从视图层到逻辑层。 由于这个通信过程是异步的，所以会形成一定的延迟。 延迟时间还与传输数据量呈正相关。 当数据量大于64KB时，在30ms以内。 有两种主要方法可以减少延迟。

1、去掉不必要的风暴绑定（WXML中的bind和catch），从而减少通信数据量和频率；

2、事件绑定时需要传输target和currentTarget的数据集，因此节点的data prefix属性中不要放置过大的数据。

4.视口渲染原理

4.1 第一次渲染

初始渲染发生在页面刚刚创建时。 在初始渲染期间，初始数据被应用到相应的WXML片段以生成节点树。 节点树是在开发者工具的WXML面板中看到的页面树形结构，其中包含页面中所有组件节点的名称、属性值、事件回调函数等信息。 最后根据节点树中包含的各个节点，在界面上依次创建各个组件。

在这整个过程中，所花费的时间大致与节点树中的节点总数成正比。 因此，减少WXML中的节点数量可以有效减少初始渲染和重新渲染所花费的时间，提高渲染性能。

简化 WXML 代码的反例

<view data-my-data="{{myData}}"> 
  <view class="my-class" data-my-data="{{myData}}" bindtap="onTap">
    <text> 
      {{myText}}
    </text>
  </view>
</view>

<view class="my-class" data-my-data="{{myData}}" bindtap="onTap">
  {{myText}}
</view>

4.2 重新渲染

初始渲染完成后，视图层可以多次应用数据setData。 每次应用setData数据时，都会进行重新渲染以更新界面。 初次渲染时获得的数据和当前节点树将被保留，以供重新渲染时使用。 每次重新渲染时，将 data 和 setData 应用到 WXML 片段以获取新的节点树。 然后将新的节点树与当前的节点树进行比较，这样就可以得到哪些节点的哪些属性需要更新，哪些节点需要添加或删除。 最后将setData数据合并为data，并用新的节点树替换旧的节点树，以供下次重新渲染。

当前节点树与新节点树进行比较时，会重点比较受setData数据影响的节点属性。 因此，去掉不必要的set数据，减少setData的数据量，也有助于提高这一步的性能。

5.使用自定义组件

自定义组件的更新只在组件内部进行，不受页面上其他不可分割内容的影响； 例如，可以将某些业务活动的计时模块单独提取出来，制作一个计时组件，并且计时组件的更新不会影响页面上的其他内容。 元素更新； 每个组件也会有自己独立的逻辑空间。 每个组件都有自己独立的数据，setData 调用。

6.避免onPageScroll使用不当

每次storm窃听都是一个视图到逻辑的通信过程，所以只有在必要的时候才在pageSrcoll上进行窃听

总结

小程序启动加载性能

小程序渲染性能

开机性能

小程序启动是小程序用户体验中极其重要的一环。 如果启动时间过长，会导致小程序用户流失，影响用户体验。

本章中的“启动”特指小程序的冷启动，不包括小程序从后台到前台的热启动。冷/热启动的定义请参考小程序的运行机制

1.小程序初创公司的定义

小程序的启动过程从“用户打开小程序”开始，到小程序“渲染小程序主页”结束。

“用户打开小程序”可能是用户点击访问触发的，也可能是扫码、小程序跳转到小程序、APP打开小程序触发的。 从扫码、APP等场景打开小程序时，可能会有一个后跳转和校准的过程优化小程序测试网站，这个过程不包含在小程序启动过程的讨论中。

小程序“首页渲染完成”的标志是由首页Page.onReady风暴触发的。 由于启动过程的差异，小程序定义的“首页渲染完成”并不等同于浏览器的DOMContentLoaded或加载风暴。

了解小程序启动的具体流程，请参考“小程序启动流程”章节的介绍。

2.打开率/到达率

小程序的“首页渲染完成”次数与“小程序启动”次数的比值也称为（PV）打开率或（PV）到达率。 对应的丢失率=1-打开率。

打开率受以下因素影响：

3.开始性能优化

小程序启动过程中，代码包规划、小程序代码注入、首页渲染的时长与小程序本身有关优化小程序测试网站，开发者可以进行一定的优化工作。 其他部分的时长由小程序框架方不断优化。

开发者可以从以下几个方面优化启动性能：

除了以上三部分之外，还有一些激励因素会影响小程序的启动时间。 可以参考“其他优化建议”

如果您想更好地了解和分析小程序的性能，可以参考“性能数据”章节。 平均而言，我们建议小程序的启动时长应控制在：

安卓系统 iOS系统

当需要下载或更新时

3.7秒

1.8秒

使用本机代码包时

2.6秒

0.9秒

盘面平均值

3.0秒

1.2秒

翻译由微信翻译提供，仅供参考。 若中文版本与英文版本有任何不一致或差异，以中文版本为准。 翻译错误。