收藏
回答

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

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

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

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

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

1 个回答

  • 小程序技术专员-LastLeaf
    小程序技术专员-LastLeaf
    2019-12-10

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

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

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

    2019-12-10
    赞同 1
    回复 2
    • panda
      panda
      01-02
      worker不能使用wx.request等wx API。如果使用worker代理网络请求,得自己写一套网络交互,这也许能做成,但是绕过小程序框架,实现起来时间开销大和兼容性也不能保障。如果想用worker和文件系统打交道,不知道有没有行得通的方法。如果worker能使用wx的API,那就很接近一个线程了。现在很多小程序功能都很丰富,有类似线程的支持能让此类小程序运行更流畅,真的就没有必要开发一个ios或者android的app了
      01-02
      回复
    • 小程序技术专员-LastLeaf
      小程序技术专员-LastLeaf
      01-02回复panda
      如果强行把网络请求放在 worker 中处理,那么,处理结果还是必须得传到主线程中(网络请求底层模块 -> worker -> 主线程),才能显示到界面上,整个链路的延时反而会变大(除非在接收到网络请求结果后有很复杂的数据处理逻辑)。文件系统接口总体上也类似。如果你有特殊场景,麻烦具体描述一下。
      01-02
      回复
登录 后发表内容
问题标签