main-thread-scheduling

<br> <br> <div align="center"> <img width="288px" src="https://yellow-cdn.veclightyear.com/835a84d5/49be4fbd-acee-478c-bd7b-c0c7a599f7dd.png"> </div> <h3 align="center"> <b>主线程调度</b> </h3> <p align="center"> 通过单一函数调用实现快速且持续响应的应用 </p> <p align="center"> <a href="https://bundlephobia.com/result?p=main-thread-scheduling"> <img src="https://img.shields.io/bundlephobia/minzip/main-thread-scheduling" alt="Gzip压缩大小" /> </a> <a href="https://github.com/astoilkov/main-thread-scheduling/actions/workflows/main.yml"> <img src="https://img.shields.io/github/actions/workflow/status/astoilkov/main-thread-scheduling/main.yml?branch=main" alt="构建状态" /> </a> <p> <br>

安装

npm install main-thread-scheduling

概述

该库允许您在主线程上运行计算密集型任务，同时确保：

您的应用界面不会冻结。
用户的电脑风扇不会高速运转。
您的INP（交互到下一次绘制）保持绿色状态。
易于集成到现有代码库中。

这里有一个真实世界的展示：在包含10k个笔记、200k+行文本、占用50MB磁盘空间的文件夹中搜索，并立即获得结果。

使用场景

您想将同步函数转换为非阻塞的异步函数。避免UI冻结。
您想先渲染重要元素，后渲染不太紧急的元素。提高感知性能。
您想运行长时间的后台任务，但不希望一段时间后风扇开始高速运转。避免声誉受损。
您想运行多个后台任务，但不希望随时间推移降低应用性能。防止千刀万剐式的性能下降。

工作原理

使用requestIdleCallback()和requestAfterFrame()进行调度。
当用户与UI交互时停止任务执行（如果navigator.scheduling.isInputPending()API可用）。
全局队列。多个任务按顺序执行，因此增加任务数量不会线性降低性能。
按重要性对任务排序。根据策略排序，并优先处理后请求的任务。
考虑到您现有的代码。使用idle策略的任务最后执行，以避免在后台任务完成后出现意外工作拖慢主线程。

为什么选择它

简单。 90%的情况下，您只需要使用yieldOrContinue(strategy)函数。API还有两个函数用于更高级的场景。
不是周末项目。 已积极维护三年 — 查看贡献者页面。我在自己的产品中使用它已超过四年 — Nota和iBar。Flux.ai也在他们的产品中使用它（使用Web技术设计硬件电路的软件）。
这是未来。 一些浏览器已经实现了对主线程任务调度的支持。这个库更进一步，努力提高用户感知性能 — 详见解释。
高质量。 遵循我的开源原则，致力于高质量。

示例

您可以在这个CodeSandbox中看到该库的实际应用。尝试移除对yieldToContinue()的调用，然后在输入框中输入内容，观察区别。

API

`yieldOrContinue(strategy: 'interactive' | 'smooth' | 'idle', signal?: AbortSignal)`

整个库的复杂性都隐藏在这个方法背后。通过调用单个方法，您就可以获得出色的应用性能。

async function findInFiles(query: string) {  
    for (const file of files) {
        await yieldOrContinue('interactive')
        
        for (const line of file.lines) {
            fuzzySearchLine(line, query)
        }
    }
}

`scheduleTask(callback: () => T, { strategy, signal }): T`

这模仿了scheduler.postTask()的API风格，同时提供了main-thread-scheduling的额外优势。

const controller = new AbortController()
const result = await scheduleTask(() => {
    return computeHeavyCalculation()
}, {
    strategy: 'smooth',
    signal: controller.signal,
})

更复杂的场景

该库还提供了两个额外的函数：

yieldControl(strategy: 'interactive' | 'smooth' | 'idle', signal?: AbortSignal)
isTimeToYield(strategy: 'interactive' | 'smooth' | 'idle', signal?: AbortSignal)

这两个函数一起使用，用于处理更高级的用例。一个需要使用这两个函数的简单用例是当你想在将控制权交还给浏览器继续工作之前渲染你的视图时：

async function doHeavyWork() {
    for (const value of values) {
        if (isTimeToYield('interactive')) {
            render()
            await yieldControl('interactive')
        }
        
        computeHeavyWorkOnValue(value)
    }
}

调度策略

有三种可用的调度策略。你可以通过用三个词之一完成这个句子来更容易地理解它们："调度任务保持页面'交互性'/'流畅'/'空闲'"。

interactive - 用于需要尽快向用户显示的内容。每个interactive任务运行83毫秒 - 这给你一个很好的周期来执行繁重的工作并让浏览器渲染待处理的更改。
smooth - 用于你想快速显示给用户但仍希望动画能流畅运行的内容。smooth运行13毫秒，然后给予大约3毫秒来渲染帧。
idle - 用于后台任务。每个空闲任务运行5毫秒。

替代方案

Web Workers

Web Workers非常适合以下情况：1) 复杂算法（例如图像处理），2) 繁重的进程（运行时间长，是应用生命周期的重要部分）。然而，在现实中，很少看到人们使用它们。这是因为无论使用何种编程语言，在处理CPU线程时都无法避免复杂性，因此需要投入大量时间。这个库可以作为过渡到Web Workers之前的一个入口。在大多数情况下，你会发现在主线程上执行已经足够好了。

`scheduler.postTask()`

scheduler.postTask()目前在一些浏览器中可用。postTask()和main-thread-scheduling做类似的事情。你可以将postTask()视为一个低级API - 在特定场景下可能是正确的选择。库的作者可能会对两者之间的细微差异感兴趣。对于大多数情况，main-thread-scheduling提供了一个scheduleTask()方法，模仿postTask()的API，同时提供库的额外好处。