徐汇区电脑维修培训学校,什么情况-为什么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的服务场景的行为可预期相反，人的操作是 不可预期 的！