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

先说是不是，再问为什么。

我就知道有人会这么说，然而那样就成了一篇议论文了，而我只是想写一篇随笔。所以，不管事实是不是那样，反正我就是觉得Windows，MacOS，iOS都很流畅，而Linux，Android却很卡。当然了，这里说的是GUI，如果考量点换成是Web服务的吞吐和时延，那估计结论要反过来了，不过那是客户端程序感觉到的事，作为人，who cares！

我写这篇文章还有一个意思，那就是想牵引一个话题，如果我们想把Linux，Android(当然，Android内核也是Linux)优化到GUI不再卡顿，我们应该怎么做。

大概是去年，一个炎热的午后，吃过午饭我和同事们在公司附近晃悠，就讨论 “为什么苹果手机就不卡，安卓手机不管多贵都很卡。” 记得一位同事说，iOS在GUI方面做了很多的优化，而Android却没有。

这话说对了！不过更为重要的一点是， 不谈具体场景谈优化，都是瞎折腾！

Windows也好，iOS也好，都知道自己的应用场景，因此针对自己的应用场景做了优化之后，妥妥在自己拿手的场景下甩Linux在该场景下的表现几条街了。

下面开始正式的技术层面的分析之前，先声明几点。

• 本文并不是在说Linux系统总体上很卡顿，而只是说Linux系统桌面版的GUI程序相比Winddows很卡顿，如果真觉得本文是在喷Linux，那就当是喷Linux桌面的吧。

• 本文不准备讨论X window和Windows窗口子系统一个在用户态一个在内核之间的差异，这无关紧要。我的想法是，即便是你将X window扔进内核，现有的Linux内核处理GUI，该卡顿还是卡顿。

• 本文仅从调度算法的角度来评价为什么Windows/iOS不卡顿而Linux却卡顿，当然还有别的视角，但并不是本文主题。

• Windows内核调度的线程而不是进程，但是本文统一采用进程这个术语，没有别的原因，只是因为进程的概念是和现代操作系统概念相始终的，而线程是后来的概念。

先看服务对象，仅此就将Windows，MacOS/iOS和Linux的使用场景区分开来：

• Windows/MacOS/iOS系统，主要是被人操作，用来提供写文档，游戏，做报表，画图，上网浏览，视频播放等服务。

• Linux系统，主要提供网络服务，用来支撑各种远程的客户端，为其提供数据处理和查询，数据生成，数据存储等服务。

事实证明，Linux在其专业的领域已经做的足够好，但是问题是，为什么它在GUI处理方面却总是一直很糟糕呢？这就要看具体场景的差异了。

对于网络服务而言，其场景的行为是 可预期的 ，我们可以将这些场景简单归结为：

• 公平快速处理网络并发请求。

• 公平快速处理并发磁盘IO。

• 高吞吐CPU密集型数据处理与计算。

Linux优秀的O(1) O(1)O(1)调度器以及后来的CFS调度器可以非常完美的cover上述三个场景，至于说为什么，不必多说，简单归纳如下：

• 无论是O(1) O(1)O(1)的基于优先级的时间片轮转还是CFS的基于权重的时间配额，均可以既满足优先级的差别服务需求又保证高吞吐率，这些都来自于调度器本身而不是依靠频繁的切换。

• 额外的简单启发式奖惩机制可以让网络IO以及磁盘IO的响应度更高，同时又不影响CPU密集型计算服务的高吞吐。

上面的第二点是一个额外的辅助，照顾IO过程快速获得响应，这是一个非常棒的辅助，但是注意，再棒的启发式算法也总是辅助性的，提高响应度就是个辅助性的锦上添花的功能，以高吞吐为目标才是根本。

IO过程对于一台Linux服务器而言是与外界交互的唯一渠道，通过该渠道可以将处理好的数据送出到网络或者磁盘，同时从网络或者磁盘获取新的数据，换句话说， IO过程类似一道门。 但也仅仅是一道门。

照顾IO过程获得高响应度这件事是为了让门开得更大，通行效率更高！

熟悉Linux内核调度器变迁的都应该知道O(1) O(1)O(1)到CFS过渡的这段历史，即2.6.0内核开始一直到2.6.22为止的这些版本，采用Linux内核划时代的O(1) O(1)O(1)调度器，随后由于两个原因：

1、O(1) O(1)O(1)调度器动态范围太大或者太小。

2、IO补偿机制不到位，时间片分配不公平。

为了解决这些问题，Linux内核切换到了CFS调度器。

切换到了CFS调度器，事实上，人们更多指望的是CFS能够让进程时间片分配更加公平，多个进程运行更加平滑，如此一来，上GUI界面的话，岂不是就不卡顿了。

然而还是卡顿，本质原因是，场景根本就不对路子。

在Linux服务器的场景中，优先级和时间片是正相关的，无论是O(1) O(1)O(1)调度器的静态线性映射的时间片，还是CFS的动态时间配额，都是优先级越高的进程其每次运行的时间也就越久，但是实际上，这两者并不是一回事。

在更复杂的场景中，正确的做法应该是参考 时间管理的四象限法则 来设计进程调度器。其中：

• 优先级表示紧急性。

• 时间片表示重要性。

于是，如果不是因为Linux服务器场景过于单一简单，CPU的时间管理要复杂得多，比如调度器应该按照四象限法则设计成下面的样子：

1、处理重要且紧急事件的进程，需要赋予高优先级分配长时间片去抢占当前进程。

2、处理重要但是不紧急事件的进程，保持固有优先级分配长时间片就绪等待。

3、处理不重要但紧急事件的进程，提升优先级但不分配长时间片，处理完毕立即返回固有优先级。

4、既不重要也不紧急的后台进程，低优先级短时间片，系统闲了再调度。

后面我们会看到，Windows的调度器就是这般设计的。

我们先总体看看GUI系统的场景。

它的服务对象是人，和Linux的服务场景的行为可预期相反，人的操作是 不可预期 的！

Windows，MacOS/iOS这种Desktop系统的GUI进程，很多时候都是在等待人的进一步操作而睡眠，要么在等鼠标，要么在等键盘，要么在等声卡，显卡的输出，或者就是在将用户输入的信息往磁盘里写而等待IO完成，Desktop系统更多关注的是要对以上这些事件提供高效率的响应服务，而不是系统的数据吞吐。

Desktop在乎的是时延，而不是总吞吐，同时，这个时延还是区分对待的，有些时延的可容忍区间很大，比如网卡(网卡IO之所以优先级提升并不是很多，是因为首先网卡是有队列缓存的，而大多数的报文都是burst而来的，队列缓存可以平滑掉首包延迟，其次，由于光速极限，相比于网络延迟，主机调度延迟真的可以忽略不计。)，有些却很小，比如键盘鼠标。所以说，Windows之类的Desktop系统 必须能够区分一个进程当前的紧急性和重要性。

Linux内核能做到这种区分吗？

Linux可以通过计算一个进程的平均睡眠时间判定它是不是一个交互式IO进程，从而决定要不是给它一定的优先级提升，但是也仅能做到这个地步，因为Linux内核无法得到更进一步的信息。

Linux内核不知道一个进程到底是不是IO进程还是说仅仅在一个时间段内有IO行为的CPU密集型进程，Linux内核也不知道一个进程被唤醒是因为键盘的数据到了，还是无关紧要的信号到了，所以这一切，Linux内核只能 启发式预测。

Linux内核仅仅跟踪一个睡眠时间而且还是平均的睡眠时间，是区别不出进程当前的紧急性和重要性的。没有外界的信息输入，仅靠启发预测，当前的AI算法貌似还没有到这个境界吧。换句话说，启发算法是不准确的。你看看Linux内核O(1) O(1)O(1)调度器的sleep_avg是如何计算并如何参与动态优先级调整的，就会明白我上面说的意思。

既然Windows系统的GUI操作比Linux流畅，那么想必Windows肯定是做到了进程当前的紧急性和重要性的区分咯？那是当然。它是如何做到的呢？

虽然Windows的调度器也是基于优先级的，也是抢占式的，也是同优先级轮转的，这看起来和Linux并没有什么区别，甚至从4.3BSD开始，几乎所有的操作系统的调度器基本都是按这个思路设计出来的，仅仅从 如何选出下一个投入运行的进程 这个算法上看，几乎所有的操作系统调度器都是一样的。Windows与众不同的原因在于 其对优先级的不同处理方式。

自4.3BSD以来，所有的基于优先级的抢占式调度器的优先级计算都包括两部分因子，即固有优先级和动态优先级：

一直以来，

只是起到了 微调 的作用，而

才更具有参考意义，其比重更大。