javascript中没有原生协程，但可通过生成器和async/await模拟；1. 生成器（function*）使用yield实现显式暂停与恢复，通过next()方法驱动，支持双向通信，适用于自定义迭代器、状态机及复杂异步控制；2. async/await基于promise，用await暂停异步函数执行直至promise解决，自动恢复，简化异步代码，提升可读性；3. 两者不等价：生成器是底层控制原语，灵活但需手动驱动，async/await是异步场景的高级语法糖，自动与事件循环协作；4. 选择async/await处理常规异步操作，追求可读性和维护性，与promise生态集成；选择生成器实现自定义迭代、协作式多任务、状态机或需细粒度控制的异步框架；二者可结合使用，生成器驱动async/await流程，实现更强大的控制流管理。
JavaScript本身并没有传统意义上像Go语言或Python协程库那样的原生“协程”概念，因为它是一个单线程、基于事件循环的语言。但我们完全可以通过其提供的特性来模拟或实现类似协程的控制流，最核心的两种方式是使用生成器（Generators）和async/await
。它们都允许我们以一种“协作式”的方式暂停函数的执行，并在稍后恢复，从而管理复杂的异步或迭代逻辑。
解决方案
要实现JS中的协程控制，我们主要依赖两种强大的语言特性：生成器（Generators）和async/await
。
生成器提供了一种显式的、可暂停的函数执行机制。一个生成器函数通过
function*声明，并在其内部使用
yield关键字来暂停执行并返回一个值。当外部代码调用生成器的
next()方法时，函数会从上次
yield的地方继续执行，直到遇到下一个
yield或函数结束。这种“暂停-恢复”的能力，正是协程的核心特征之一。我们可以通过编写一个“协程运行器”来驱动生成器，使其能够处理异步操作，从而模拟出更接近传统协程的行为。
而
async/await则是ES2017引入的语法糖，它建立在Promise之上，旨在让异步代码看起来和写起来更像同步代码。
async函数内部的
await关键字会“暂停”当前
async函数的执行，直到它等待的Promise被解决（fulfilled或rejected）。一旦Promise解决，函数会从
await的地方继续执行。虽然它没有真正暂停JavaScript的主线程，而是将函数的剩余部分作为微任务（microtask）安排到事件队列中，但从代码逻辑上看，它确实实现了“等待”和“恢复”的效果，极大地简化了异步流程控制，使得异步代码的编写体验与协程非常相似。
JS中的生成器（Generators）如何实现协作式暂停与恢复？
说起生成器，我觉得它简直是JavaScript里一个被低估的宝藏。它提供了一种非常直接的方式来控制函数的执行流程，允许你在函数执行的任意点“暂停”下来，然后根据需要再“恢复”执行。这和传统意义上的协程（co-routine）概念非常契合，因为它们都是协作式的——函数主动让出控制权，而不是被动地被中断。
一个生成器函数通过在
function关键字后面加一个星号
*来定义，比如
function* myGenerator() { ... }。在生成器函数内部，你可以使用yield关键字。每当执行到
yield表达式时，生成器函数就会暂停执行，并把
yield后面的表达式的值返回给调用者。此时，函数的执行上下文（包括局部变量、执行位置等）会被保存下来。
当你调用一个生成器函数时，它并不会立即执行里面的代码，而是返回一个“生成器对象”（Generator Object），这个对象本身就是一个迭代器。通过调用这个生成器对象的
next()方法，你才能真正启动或恢复生成器函数的执行。
next()方法会返回一个对象，包含
value（
yield表达式的值）和
done（表示生成器是否已完成）两个属性。
来看个例子，感受一下这种“暂停与恢复”的魅力：
function* taskRunner() {
console.log('任务A：开始');
yield '等待外部指令1'; // 第一次暂停
console.log('任务B：进行中');
yield '等待外部指令2'; // 第二次暂停
console.log('任务C：完成');
return '所有任务完成'; // 生成器结束
}
const runner = taskRunner();
console.log(runner.next()); // { value: '等待外部指令1', done: false }
// 此时，taskRunner 在 '任务A：开始' 之后暂停了。
// 我们可以做一些其他事情...
console.log('外部世界：做点别的事情...');
console.log(runner.next()); // { value: '等待外部指令2', done: false }
// taskRunner 从上次暂停的地方继续，执行了 '任务B：进行中'，然后再次暂停。
console.log('外部世界：又做了一些事情...');
console.log(runner.next()); // { value: '所有任务完成', done: true }
// taskRunner 继续执行，直到结束，并返回了最终值。
console.log('外部世界：生成器已完成。');在这个例子里，
taskRunner就像一个可以随时“打盹”的工人，它执行一部分工作，然后
yield，把控制权交还给外部。外部世界可以决定什么时候叫醒它，让它继续工作。这不就是一种非常经典的协作式多任务处理吗？通过这种机制，我们甚至可以构建出复杂的异步流控制，比如著名的Redux Saga就是基于生成器来实现其副作用管理的。你可以通过
next()方法向生成器内部传递参数，实现双向通信，这让生成器在构建复杂状态机或迭代器时变得异常强大。
本文档主要讲述的是Android传感器编程；传感器是一种物理装置或生物器官,能够探测、感受外界的信号、物理条件（如光、热、湿度）或化学组成（如烟雾），并将探知的信息传递给其它装置或器官。同时也可以说传感器是一种检测装置，能感受被测量的信息，并能将检测的感受到的信息，按一定规律变换成为电信号或其它所需形式的信息输出，以满足信息的传输、处理、存储、显示、记录和控制等要求。它是实现自动检测和自动控制的首要环节。感兴趣的朋友可以过来看看
Async/Await与协程控制：它们是等价的吗？
这是一个经常被问到的问题，也是一个很容易产生误解的地方。在我看来，
async/await和生成器在实现“暂停与恢复”的效果上确实有相似之处，尤其是在处理异步操作时，它们都能让代码看起来更线性、更易读。但要说它们完全等价，那就不准确了。
async/await是基于Promise的语法糖，它的核心思想是简化异步代码的编写。当你在一个
async函数内部使用
await关键字时，它会等待一个Promise的解决。如果这个Promise还没有解决，
async函数就会“暂停”执行，把控制权交还给事件循环。一旦Promise解决，
async函数会作为微任务重新排队，并在合适的时机从
await的地方继续执行。
来看个
async/await的例子：
function simulateAsyncOperation(ms) {
return new Promise(resolve => setTimeout(resolve, ms));
}
async function fetchData() {
console.log('开始获取数据...');
await simulateAsyncOperation(1000); // 等待1秒
console.log('数据A获取完成。');
await simulateAsyncOperation(500); // 再等待0.5秒
console.log('数据B获取完成。');
return '所有数据已就绪';
}
fetchData().then(result => {
console.log(result);
});
console.log('主线程继续执行，不会被阻塞。');在这个例子中，
fetchData函数内部的
await看起来就像是“暂停”了函数的执行，直到模拟的异步操作完成。但实际上，它并没有阻塞主线程。JavaScript的事件循环依然在愉快地运行，处理其他任务。这种“暂停”是协作式的，而且是隐式的——你不需要像生成器那样手动调用
next()来驱动。Promise的解决机制会自动触发后续的执行。
所以，两者不等价。生成器提供的是更底层的、显式的、可编程的暂停/恢复机制，你可以用它来构建各种迭代器、状态机，甚至可以自己实现一个异步流程控制的库。而
async/await则是针对异步编程场景的一种高级抽象，它大大简化了Promise链，让异步代码的编写体验更接近同步代码，但它的“暂停”是与Promise和事件循环深度绑定的。你可以把
async/await看作是JavaScript官方为异步场景“量身定制”的、更易用的“协程”实现方式，而生成器则是更通用的、灵活的“暂停/恢复”原语。
何时选择生成器，何时选择Async/Await？
选择生成器还是
async/await，其实取决于你的具体需求和要解决的问题。它们虽然都能实现类似协程的控制流，但侧重点和应用场景还是有区别的。
选择async/await
的场景通常是：
-
处理绝大多数异步操作： 当你需要进行网络请求、文件读写、定时器等基于Promise或回调的异步操作时，
async/await
是首选。它让异步代码逻辑清晰，避免了回调地狱，可读性极高。 -
代码可读性和维护性优先： 如果你的主要目标是让异步代码看起来像同步代码一样直观，那么
async/await
无疑是最好的选择。它极大地简化了错误处理（使用try...catch
），使得异步流程的推理变得容易。 -
与现有Promise生态系统集成： 现代JavaScript的异步API几乎都返回Promise，
async/await
与它们无缝衔接。
选择生成器（Generators）的场景则相对特定，通常是：
- 实现自定义迭代器或无限序列： 如果你需要创建自定义的迭代行为，例如一个斐波那契数列生成器，或者一个能够按需生成数据流的管道，生成器是完美的选择。它允许你惰性地生成值，避免一次性计算所有结果。
-
构建复杂的异步流程控制框架： 就像前面提到的Redux Saga，它利用生成器的
yield
来暂停和控制副作用（如异步API调用），允许开发者以同步的方式编写复杂的异步逻辑。在这种场景下，生成器提供了比async/await
更细粒度的控制能力，你可以yield
出任何东西，而不仅仅是Promise。 -
模拟协作式多任务处理（非阻塞的同步计算）： 设想一个需要执行大量计算的函数，为了不阻塞UI，你希望它能定期“让出”控制权。你可以用生成器来实现，每次计算一小步，然后
yield
，让事件循环有机会处理UI更新或其他任务，等到下次next()
调用时再继续计算。这在某些客户端长任务处理中非常有用。 -
构建状态机： 生成器的
yield
机制使其非常适合实现状态机，每个yield
点可以看作是一个状态转换点，外部通过next()
驱动状态的迁移。
总而言之，
async/await是处理异步I/O和事件的“瑞士军刀”，它让你的异步代码变得优雅。而生成器则更像一个“乐高积木”，它提供的是更底层的、更灵活的“暂停与恢复”原语，让你能够构建出更复杂、更定制化的控制流模式，尤其是在需要精细控制迭代或异步副作用的场景。很多时候，你甚至会发现它们可以结合使用，比如在一些高级的异步库中，生成器可能会被用来驱动
async/await的执行，形成一个强大的组合。
