为什么Windows/iOS操作很流畅而Linux/Android却很卡顿呢

仔细看，你会注意到对于声卡而言，其IO完成时，优先级提升会很大，而磁盘，显卡这种却并不是很多，这充分体现了设计者的贴心。这充分考虑到了人耳的灵敏度和人眼的分辨率之间的对比，声音是作为流顺序输出的，耳朵很容易分辨出声音的卡顿，而对于图像而言，完全可以慢慢双缓冲刷层，人眼相比之下没有那么高的分辨率识别到，因此声卡事件必须优先处理。同时，对于磁盘，网卡之类的，人就更是感觉不到了。除了声卡之外，键盘鼠标操作的IO完成对于优先级提升的数值也很可观，因为键盘鼠标如果卡顿，人的输入会明显感觉到延迟，鼠标则显拖沓，这都是很容易识别的卡顿事件，所以Windows给予了进程更高的动态优先级来尽快处理这些事件。

对于窗口子系统而言，当一个窗口获得焦点时，对应的处理进程的优先级也会得到提升，这会给人一种 你操作的界面总是很流畅 的感觉，毕竟你操作的界面就是前台窗口，至于说此时后台窗口的处理进程，即便是僵死了你也不会有感觉，因为你并不操作它们呀，当你操作它们时，对应的处理进程的优先级就会提升。

所有的优先级提升都伴随着时间片的重新计算，但是和Linux不同的是，Windows并没有直接将进程优先级和时间片按照正相关关联起来，时间片是独立计算的，大多数时候，Windows对于所有的进程，不管优先级是多少，均采用同一个时间片。

如此看来，Windows虽然也是优先级调度的系统，但是其优先级却是 操作行为驱动的 ，这便是其与众不同之处。

Linux内核调度系统会精细区分磁盘事件的wakeup和键盘鼠标声卡事件的wakeup吗？不会。

说完了Windows为什么操作GUI会很流畅，该说点不好的了，Windows经常会死机，为什么呢？

这很大程度上也和上面描述的调度器有关。

仔细看这个操作行为驱动的动态优先级调度器，很大的一个问题就是容易饿死低优先级的进程，特别是Pbase P_{base}P 

base

 很低的进程。

Windows的解决方案是采用一个后台进程(学名叫做平衡集管理线程)轮询的方式，将超过秒级都没有被调度的进程的优先级拉升到很高的位置参与抢占。

这个机制有啥问题呢？问题在于Windows需要第三方线程来缓解饥饿，而不是靠调度器自身，这便增加了调解失败的可能：

• 第三方线程本身的问题没有按照预期工作。

• 饥饿进程过多。

• 饥饿进程优先级提升后又被抢占。

• …

除了死机问题之外，Windows系统对于服务器版本的调度器调整做的也不够优雅，Windows仅仅是调整了服务器版本的系统参数，而几乎没有对调度的算法做任何修改。对于服务器版本，Windows只是将时间片延长了而已，同时几乎不再动态计算时间片，而是选择始终使用相同的一个足够长的值，以减少进程切换提高吞吐率。显然这种方式并不妥当，因为动态优先级根据事件的提升，还是会造成进程间不断抢占，从而影响吞吐。

不过，毕竟Windows是一个Desktop系统，本身就不是为高吞吐而生的，这种针对服务器版本的策略调整便是无可厚非了。正如Linux服务器虽然可以很完美应对高吞吐场景，其Desktop版本比如Ubuntu，Suse不也是心有余而力不足吗？虽然Linux内核也有动态优先级提升这一说。

该简单总结一下了。

在人机关联上，Windows更加靠近人这一端，适应了人的操作行为，为操作该机器的人提供了良好的短时延体验，Linux相反，它靠近机器一端，让CPU可以尽可能开足马力跑task而不是频繁切换，从而为客户端提供最大的数据吞吐。

Windows的设计甚是精妙，考虑到了人的行为的每一个细节(除了对于死机的耐受力)，除了动态优先级和具体时间精确关联之外，对于待机恢复时间deadline在7秒内也是很值得拍案，这个7秒的阈值考虑到了人的短期记忆的极限，如果有人突然想到了一个点子，需要打开电脑将其记录下来，那么打开电脑的时间如果超过了7秒，那么可能这个点子就溜走了，所以待机恢复时间必须限制在7秒以内，哇塞不哇塞。