收藏
回答

小程序什么时候能支持真正意义的多线程?

现在小程序的双线程结构(逻辑层+界面层)在频繁的网络交互场景中会引起页面响应的“抖动”。

一个想法是把这些与网络交互的逻辑放在一个单独的线程,这样逻辑层就能专注于服务界面层的响应,达到极速的用户体验。可惜,当下小程序的多线程(worker)并不是真正意义上的多线程:worker不能调用wx的API,非常鸡肋。

我想问官方是否有另一种方法或者计划支持创造一个真正意义的线程?为了控制滥用,可以限制一个小程序能创造此类线程的数量。

回答关注问题邀请回答
收藏

1 个回答

  • LastLeaf
    LastLeaf
    2019-12-10

    在频繁的网络交互场景中会引起页面响应的“抖动” —— 这个应该是因为网络请求先后到达,引起页面结构多次发生变化导致。请考虑等所有网络请求都到达之后再一次性改变页面,或者给页面暂时缺少网络数据的部分填充占位符来提升用户体验。

    Worker 主要用于大运算量的计算,如果有运算密集的逻辑,请考虑放在 worker 中。其他情况下一般不需要用到 worker 。

    在小程序中,和页面变更相关的逻辑不能分配到多个线程中。网络请求可以通过主线程代理到 worker 中,但对于这样的 io 操作,几乎没有优化。

    2019-12-10
    有用 1
    回复 5
    • 2020-01-02
      worker不能使用wx.request等wx API。如果使用worker代理网络请求,得自己写一套网络交互,这也许能做成,但是绕过小程序框架,实现起来时间开销大和兼容性也不能保障。如果想用worker和文件系统打交道,不知道有没有行得通的方法。如果worker能使用wx的API,那就很接近一个线程了。现在很多小程序功能都很丰富,有类似线程的支持能让此类小程序运行更流畅,真的就没有必要开发一个ios或者android的app了
      2020-01-02
      回复
    • LastLeaf
      LastLeaf
      2020-01-02回复
      如果强行把网络请求放在 worker 中处理,那么,处理结果还是必须得传到主线程中(网络请求底层模块 -> worker -> 主线程),才能显示到界面上,整个链路的延时反而会变大(除非在接收到网络请求结果后有很复杂的数据处理逻辑)。文件系统接口总体上也类似。如果你有特殊场景,麻烦具体描述一下。
      2020-01-02
      回复
    • 陆一珽
      陆一珽
      2020-07-09回复LastLeaf
      一个常见需求是后台保存文件,在数据改变时用writeFile保存,下次程序启动时读取。但好像无论什么时候调用writeFile都会导致界面停顿,也找不到好的替代办法。没有多线程,文件系统的可用性就差多了。
      2020-07-09
      回复
    • LastLeaf
      LastLeaf
      2020-07-13回复陆一珽
      理论上说渲染层不会受到逻辑层的 writeFile 调用影响(何况 writeFile 还是个异步调用)。“界面停顿”是什么表现呢?
      2020-07-13
      回复
    • 陆一珽
      陆一珽
      2020-07-14
      谢谢你的提醒,我重新检查了代码,发现耗时的部分确实不在writeFile,而是在一个叫sm3的签名函数,替换了这个函数卡顿的问题就解决了。Thanks a lot。
      2020-07-14
      回复
登录 后发表内容
问题标签