收藏
回答

setUpdatePerformanceListener 回调字段的具体含义?

小程序给出了 setUpdatePerformanceListener api 用来获取更新性能统计信息。

这个说明有点不够具体,毕竟对于开发者所谓的更新队列机制都是黑盒。有以下几个疑问:

  1. updateProcessId 是否是页面内自增的,不论是基本更新还是子更新,发生一个更新就自增?初始 data 算第一个 updateProcessId 么?
  2. parentUpdateProcessId 是否可以理解为某个 setData 导致的一些列同步 setData 更新,比如 observer 内部的 setData,其父更新就是导致 Observer 执行的 setData?还有其他场景么?
  3. isMergedUpdate 这个有场景示例么?
  4. pendingStartTimestamp 代表的是什么时刻:执行 setData 的那一刻,data 传递到渲染层那一刻还是指的其他时刻?
  5. updateStartTImestamp 代表的是什么时刻:DOM diff 开始那一刻?DOM diff 是在逻辑层还是渲染层呢?
  6. updateEndTImestamp 代表的是什么时刻:DOM diff 完成那一刻,还是 DOM render 那一刻?

烦请官方能够解答一下,也辛苦新出一个 api 以后,希望能从开发者的角度去丰富文档和示例,这样有助于这个 api 真正的落地和服务开发者,非常感谢。

ps: 既然出一个 api,应该是有场景驱动才对,想请问下官方推荐的使用场景是什么呀?

最后一次编辑于  02-04
回答关注问题邀请回答
收藏

1 个回答

  • 小程序技术专员-LastLeaf
    小程序技术专员-LastLeaf
    02-20
    1. 不建议将 updateProcessId 视为自增量,它就是个 ID 而已;若需要判断 setData 内容,使用 dataPaths 字段为宜。
    2. 可以这么理解,但是不只是 observer 的情况,还有些其他情况也会;关键在于,父更新的时间是包含有子更新的时间的,如果需要计算总时间,那不能将父更新的时长与其子更新的时长累加。
    3. 简单的观测到 isMergedUpdate 的方法:使用 数据监听器 并在其内部同步调用一次 this.setData 。
    4. pendingStartTimestamp 是进入更新队列的一刻,位于所有逻辑层和渲染层的逻辑处理之前(当然,是在传递到渲染层之前的,但是还要更早一点点)。
    5. updateStartTimestamp 是在渲染层开始执行更新逻辑的一刻,位于所有渲染层树结构更新逻辑处理之前(当然,是在 DOM diff 之前的)。
    6. updateEndTimestamp 位于所有渲染层树结构更新逻辑处理之后(当然,是在 DOM diff 之后的)。

    一般认为 updateStartTimestamp ~ updateEndTimestamp 的时间是渲染层最主要的计算开销,它会完全占用线程,并使得其他更新请求在队列中等待。 pendingStartTimestamp ~ updateStartTimestamp 是一次更新请求在队列里等待的时间,其中有一部分是跨线程通信,又有一部分是线程忙碌导致的等待,还有一部分是逻辑层的计算开销。

    这个接口设计上主要用于分析单个 setData 更新的性能问题,或者用于分析多个 setData 连续调用时相互之间的影响,也可以用于研究特殊时候(如冷启动时) setData 的延迟情况。

    02-20
    有用 2
    回复 1
    • 刘六
      刘六
      02-20
      非常感谢你的耐心解答~~~
      02-20
      回复
登录 后发表内容
问题标签