“协程”是一个大而空的筐，啥鸡蛋都往里装。Go 的 Goroutine 是 stackful 且在 Go 1.14 之后是基于 signal 的抢占式调度的，Kotlin 是 stackless 但是协作调度的，但是这俩都有人叫做协程。

实际上的“协程”，是一种用户调度抽象。有基本 OS 概念的人都知道，进程（ Process ）是负责资源隔离的，而真正的运行调度单元是线程（ OS Thread ）。线程不是免费的，这导致我们如果创建一大堆线程，必定涉及了资源的扩张，而实际上的很多 task 虽然对实时性、执行效率有要求，却不需要这么多资源（比如 IO 任务），我们该如何让这些任务能够更好地执行，而不每次都开一个线程呢？这就是协程的本来目的。

通俗来说，一个语言有没有协程，并不意味着这个语言没有这种抽象调度能力。Lisp 系的 call/cc 和 C 的 setjmp/longjmp 也可以实现某种程度上的协程，甚至更简单的，只要一个语言有能够将一个运行过程封装到一个内存结构上的能力（例如，C++ 有 operator() 的 struct ），基于这个能力写一个 scheduler ，你也发明了一个协程。

协程为何性能高？这也是一个网络迷思：如果你的 task 如上面描述的，是一个低资源占用但是高实时消耗的，那当然是显而易见的性能提升（线程内核态调度延迟一般是比协程用户态调度更慢的），但是这不是银弹，如果你的 task 需要独占资源，那么你的线程调度同样能做到跟协程一样快。

那么，我们该如何认识协程？实际上来说，这是一个异步计算结构的问题：
1. 抢占式调度（ preemptive ） vs 协作式调度（ cooperative ）
2. 有栈结构（ stackful ） vs 无栈结构（ stackless ）
3. 跟系统 Thread 的 mapping 关系：1:1, N:1 和 N:M
等等。这些关键词网络上都有非常优秀的资料，就轮不到我在这里扯淡了。认识协程最关键的部分，实际上还是看语言提供的能力（语言结构、标准库等），以及语言的目标领域。

楼主举得 NIO 的例子实际上跟这个话题相去甚远：NIO 用的是 kernel 提供的 IO Multiplexing 或者 Async IO 能力（ epoll/kqueue/io_uring/IOCP ），这个在内核态实现的调度反而还有点类似协程的味道。

育碧？

AC+ 就是个保险，一般来说预算足够可以直接上，因为 mac 维修成本确实高，这个沉没成本其实看个人接受程度

16，Max 24 核 GPU，32G RAM，2T SSD，写代码+全功能工作站

大学时用过一段时间 Elementary OS, 后面的主力是 Manjaro 。现在是 mac 了。

@qq316107934 老哥莫非是 shs ？

同国行首发，一般来说早上起床 wifi 开一个视频会议+蓝牙连耳机去公司，一个小时 15% 左右的电消耗，基本可以接受，在公司也是随时无线充电板上一放就行，系统小缺陷反正用过索尼的懂的都懂。
两个比较大的问题点是：
1. 充电的时候 888 很容易发热，然后过一会儿就可能会过热强降 60Hz，打游戏可以开 H.S.，对我这种习惯睡觉前充电看视频的有点影响；
2. 全面屏手势没有优化过，AOSP 有的 Bug 就原封不动搬过来，具体可以看 https://support.google.com/pixelphone/thread/71923225/android-11-issue-with-gesture-navigation-and-full-screen-apps?hl=en，横屏全屏游戏 or 视频会有一点问题。
就我个人来说，游戏都在三大主机平台上不玩手游，单纯听歌+IM+日常使用完全是足够的，续航和发热也基本能接受，索尼移动去年盈利不是没道理的。

@djyde 商店里可以筛选 `Optimized for Xbox X|S`

按 Github Status 的说法的确是发生了什么问题，https://www.githubstatus.com/incidents/2y6v4ltq26g7

感觉你可以去问问T4U的开发者，他们就是做到了ios上的一个透明代理后的twitter客户端