13518219792
这种情况，直接选择自动修复，看电脑系统能否自动修复问题。
在洛扎等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供网站制作、做网站 网站设计制作按需设计,公司网站建设,企业网站建设,成都品牌网站建设,成都营销网站建设,外贸网站建设,洛扎网站建设费用合理。
如果重启再次进入该界面，说明修复失败，直接选择正常启动，有时候也可以正常启动，反正我是遇到过多次，估计是系统误判。
如果仍然无法启动，送修理店重装系统吧，肯定可以解决。
多人都在抱怨安卓智能手机电池使用时间短，反应速度慢，上网速度慢。怎么办呢？不难！你可以试试下面的办法。先在你的手机系统文件里找到build.prop这个文件，这个文件在system文件夹下面。找到以后，打开，然后你可以把下面的你想使用的代码复制到build.prop文件下面，保存，推出。重启两次就OK了。
延迟电池使用寿命
ro.ril.disable.power.collapse=0 这个设置可以让你的手机在待机状态的时候，更深的睡眠。这可能会提高电池使用时间。
pm.sleep_mode=1 这个会使你的手机在待机的时候关闭电源。
wifi.supplicant_scan_interval=180 这个会使你的手机不在非常频繁的扫描WiFi信号，这也会节省一些电量。
加快手机反应速度
debug.performance.tuning=1 这个设置可以加快触屏的反应速度
video.accelerate.hw=1 加快触屏的反应速度
windowsmgr.max_events_per_sec=150 加快滑动反应速度
加快上网速度的设置：
net.tcp.buffersize.default=4096,87380,256960,4096, 16384,256960
net.tcp.buffersize.wifi=4096,87380,256960,4096,163 84,256960
net.tcp.buffersize.umts=4096,87380,256960,4096,163 84,256960
net.tcp.buffersize.gprs=4096,87380,256960,4096,163 84,256960
net.tcp.buffersize.edge=4096,87380,256960,4096,163 84,256960
一般用过这两种操作系统的朋友一定会感觉到 Android比iOS卡顿好几倍 可是为什么呢？ 安卓真的有那么烂吗？下面 我就给大家解释下 为什么安卓会比iOS卡顿 及解决方法
先来说原因之一(共仨) 就是因为iOS锁住了应用的后台 阻止其后台运行 但这是时候就有人问了 那为什么安卓在多任务管理器里清除后台应用没有用呢？因为安卓在任务管理器中清理掉后 某些流氓应用就又会自动运行 或者被其他应用唤醒 所以就算你划掉了 一些应用就又会重启 自然没有用 那安卓结束后台后就收不到其推送的消息了 比如QQ 比较吃运行内存 如果清除掉 有消息便收不到了
那为什么苹果可以在清掉后台的情况下保留消息推送呢？ 下面就来解释下 用过iOS的朋友 如果你细心 就会发现每当iOS安装一个新应用并打开时 会出现一个提示 大概内容就是询问你是否接收这个应用推送的消息通知 而现在 如果你选择了"是" 那么你的设备ID和这个APP的ID便会一同写入到苹果的云端服务器 而当这个应用发送推送消息时 不会发送到你手机上 而是发送到苹果的云端服务器上 再由苹果的服务器发送给你 这样 就算任务的后台被结束 也仍然能收到消息 且手机后台只需运行一个苹果服务器的消息接受端就可以了 这就是为什么iPhone5s的1g运行内存也可以运行如飞的原因 而国产2/3g运行内存仍有点吃力
再来说第二个原因 是因为iOS的"资源优先分配机制" 先来说iOS的应用打开方式 当你在iOS中点击一个应用时 它会第一时间跳出来 然后再准备其他的工作 这就是为什么iOS打开应用后还要等待比安卓长那么一点的时间 且在跳出来到准备的这个过程中 系统会先停下其他的活 将处理器及运行内存分配给这个过程 而安卓呢 则是平均分配cpu和ram 再来说安卓应用打开方式 安卓是先给你将什么的都准备好 再打开应用 因此你可以发现安卓打开应用后需要到等待的时间并不多 但是在你触摸屏幕的第一时间并不会太快的反馈 这也是导致用户感觉安卓卡顿的原因之一
再来说最后一个原因 过渡动画 如果你细心点的话 你会发现 虽然安卓在4.2版本后改进了动画 但仍比较生硬 而iOS在屏幕解锁 应用打开 和应用内动画做的略微夸张 流畅 舒缓让人感觉更快一些 但其实iOS与安卓的应用打开速度差的并不是很大
好了 原因说完了 总结下iOS流畅的原因
一、后台应用限制与云端推送服务
二、资源优先分配机制
三、过渡动画的优化
原因总结过后 再来说说安卓卡顿的解决方法 其实很简单 锁后台 但是我之前提到了 任务管理器相当于一个摆设 所以我们要借助第三方工具来结束后台 我推荐的一共有三个
一、绿色守护(root后使用更佳)
二、黑域(无法root用户的福音)
三、阻止运行(需xposed）
用了这几个后 你的安卓是不是飞了起来？ 如果要是还没飞 那就还剩俩原因了
一、手机配置有(ruo)点(bao)差(le)
二、系统优化不到位 或者说优化不适合你的手机 本人推荐小米的MIUI〈目前我使用〉或者华为的EMUI (不推荐低配机型)
好了 关于Android比iOS卡顿的问题解析就到这儿了 我是Jammy
首先来说，安卓手机最直接的原因还是由于手机内存不足导致的，因为安卓系统本身就非常耗费内存资源，一开机系统就会占用很大一部分内存，再加上开几个软件后，所剩内存也没有多少了，手机如果使用起来也会变得卡顿。所以我们也能看到很多安卓手机厂商都在加大运行内存，从之前的256MB逐渐上升到目前10GB，可以说安卓手机在内存上比有的电脑内存都大了。那么想要手机不卡可以选择内存大的手机，还有时常清理后台应用程序来增加可用内存。
还有一个原因也跟内存有关，那就是我们在使用手机的过程中软件会产生很多垃圾缓存文件，还有每次系统更新时也会让手机系统变得臃肿，很多时候用户都是更新系统后立马重置手机才可以让手机变得流畅些。对于这种情况我们就要做到时常清理手机垃圾文件，一般来说安卓手机中都有管家之类的软件，我们就可以通过里面的清理功能来清除垃圾文件。
最后还有一个重要的原因那就是手机处理器配置，高端处理器性能好手机当然很少会出现卡顿的情况，而处理器太过于低端，一开始用起来就不怎么流畅，那么随着手机使用时间越长，手机变得越来越卡顿也是情理之中的。因此，我们在选购手机的时候尽量要选择高配置处理器的手机，至少手机的性能有所保证。
现在移动设备的流行，很多人发现有些APP在IOS系统比在安卓系统上流畅，根据这一问题大家展开了激烈的讨论，IOS系统的严谨性自不用说，这篇文章总结了一些安卓卡顿的原因!
首先，根据所说的问题，我用iPad和小米Pad对比了，直观感受上明显感觉iOS要流畅、舒服。
在这件事情上，作为开发者的我认为主要有以下三个原因：
速度曲线。
当你滑动界面然后松手，这时界面会继续滑动，然后速度减小，直到速度为0时停止。iOS下速度减小的这个过程比较慢，尤其是快要停的时候是慢慢停的，视觉上有种很顺滑的感觉;Android下则从松手到停要快很多，相比之下有种戛然而止的感觉。
从数据/技术角度来看这个事情，我们滑动界面的最终目的不是为了“动”，而是为了“停”，因此只要平滑的到达目的地，似乎越快完成这个过程越好，所以Android的选择是理所当然的。但事实是，大家普遍更喜欢iOS的方式，这样做显得更顺滑、更优雅。
帧率。
绝大部分时间两者都能保持60FPS左右的满帧率。但都会有偶尔的掉帧。并且Android上要比iOS上严重很多。(好吧，比起前两年，已经好太多了。)我前前后后滑动了几十次，iOS在前面遇到1次掉帧，后面就很稳定了。而Android几乎每滑动一次都会伴随一次掉帧。这完全就是真真实实的卡顿，用户必然会感觉到那一刻的不流畅。Android掉帧的原因我后面再详细分析。
触摸响应速度。
从手指碰到触摸屏，到屏幕上显示处理这次触摸产生的画面，是需要时间的。时间越短感觉越跟手。据说iOS的触摸屏的处理时间要比一般的Android手机快，这不是我的专长，不知道怎么验证。但在软件系统层面，Android的显示机制是APP--SurfaceFlinger--Display，这比传统的APP--Display多了一步，主要基于这个原因，画面最终输出到屏幕要比传统的方式慢一帧(16.7ms)。
以上是个人分析的内容，如果有不对的地方，还请大家指正。作为APP开发者，系统的问题我们无可奈何，我们只有在APP的性能上下功夫，给用户一个好的体验。首先我们要做的就是预防，如何有效的进行预防?如何才能实时的检测卡顿现象的发生呢?就这一问题思考了很长时间，于是使用友盟+u-apm性能监测工具，这一工具在APP卡顿中起到哪些作用呢?
u-apm卡顿分析分析功能支持，卡顿趋势的查找、卡顿列表的筛选、卡顿模块的计算、卡顿分布的筛选、卡顿详情页面的展示，以上业务模块u-apm平台都以图表的形式直观的展示了实时数据，辅助开发者进行问题筛查。
卡顿分析功能可支持Android和iOS采集，Android支持5%采样率，iOS支持全量采集。提供卡顿趋势分析、卡顿列表及卡顿详情日志、支持分系统版本、运营商、APP版本、设备等6个纬度的查看卡顿分布;我们抽象了发生卡顿问题的堆栈信息构成卡顿模块，可通过倒序/正序聚合查看发现影响性能的最底层方法/核心原因。通过智能告警的方式推送到企业线上办公工具或邮件能力，便于团队内快速响应跟进问题。
总结
如今，事事都追求效率，快速，如果使用传统的检测方法，不仅耗费大量的时间不说，还会消耗大量的经费，u-apm的诞生，不仅能帮助开发者检测卡顿问题，还能检监测线上卡顿的产生，从而预防性能问题的发生。
先说是不是，再问为什么。
我就知道有人会这么说，然而那样就成了一篇议论文了，而我只是想写一篇随笔。所以，不管事实是不是那样，反正我就是觉得Windows，MacOS，iOS都很流畅，而Linux，Android却很卡。当然了，这里说的是GUI，如果考量点换成是Web服务的吞吐和时延，那估计结论要反过来了，不过那是客户端程序感觉到的事，作为人，who cares！
我写这篇文章还有一个意思，那就是想牵引一个话题，如果我们想把Linux，Android(当然，Android内核也是Linux)优化到GUI不再卡顿，我们应该怎么做。
大概是去年，一个炎热的午后，吃过午饭我和同事们在公司附近晃悠，就讨论 “为什么苹果手机就不卡，安卓手机不管多贵都很卡。” 记得一位同事说，iOS在GUI方面做了很多的优化，而Android却没有。
这话说对了！不过更为重要的一点是， 不谈具体场景谈优化，都是瞎折腾！
Windows也好，iOS也好，都知道自己的应用场景，因此针对自己的应用场景做了优化之后，妥妥在自己拿手的场景下甩Linux在该场景下的表现几条街了。
下面开始正式的技术层面的分析之前，先声明几点：
1.本文并不是在说Linux系统总体上很卡顿，而只是说Linux系统桌面版的GUI程序相比Winddows很卡顿，如果真觉得本文是在喷Linux，那就当是喷Linux桌面的吧。
2.本文不准备讨论X window和Windows窗口子系统一个在用户态一个在内核之间的差异，这无关紧要。我的想法是，即便是你将X window扔进内核，现有的Linux内核处理GUI，该卡顿还是卡顿。
3.本文仅从调度算法的角度来评价为什么Windows/iOS不卡顿而Linux却卡顿，当然还有别的视角，但并不是本文主题。
4.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以来，所有的基于优先级的抢占式调度器的优先级计算都包括两部分因子，即固有优先级和动态优先级：
一直以来，
只是起到了 微调 的作用，而
才更具有参考意义，其比重更大。
Windows与众不同，其弱化了进程(其实应该是线程，但是我就统一写成进程吧，为了照顾不懂Windows内核原理的读者)的初始基优先级
，而强化了动态优先级
，更重要的是，动态优先级的值并非来自预测，而是来自于 事件 ，事件本身的紧急性反馈到了动态优先级的值，而事件本身的重要性则反馈到了时间片：
可以看出，Windows对于不同的事件定义了不同的优先级提升的具体数值， 将动态优先级的值和具体的事件做了精确的关联。
这些数值的定义上，甚至精细而贴心，详细的数值参见ntddk.h：
//
// Priority increment definitions. The comment for each definition gives
// the names of the system services that use the definition when satisfying
// a wait.
//
//
// Priority increment used when satisfying a wait on an executive event
// (NtPulseEvent and NtSetEvent)
//
#define EVENT_INCREMENT 1
//
// Priority increment when no I/O has been done. This is used by device
// and file system drivers when completing an IRP (IoCompleteRequest).
//
#define IO_NO_INCREMENT 0
//
// Priority increment for completing CD-ROM I/O. This is used by CD-ROM device
// and file system drivers when completing an IRP (IoCompleteRequest)
//
#define IO_CD_ROM_INCREMENT 1
//
// Priority increment for completing disk I/O. This is used by disk device
// and file system drivers when completing an IRP (IoCompleteRequest)
//
#define IO_DISK_INCREMENT 1
//
// Priority increment for completing keyboard I/O. This is used by keyboard
// device drivers when completing an IRP (IoCompleteRequest)
//
#define IO_KEYBOARD_INCREMENT 6
//
// Priority increment for completing mailslot I/O. This is used by the mail-
// slot file system driver when completing an IRP (IoCompleteRequest).
//
#define IO_MAILSLOT_INCREMENT 2
//
// Priority increment for completing mouse I/O. This is used by mouse device
// drivers when completing an IRP (IoCompleteRequest)
//
#define IO_MOUSE_INCREMENT 6
//
// Priority increment for completing named pipe I/O. This is used by the
// named pipe file system driver when completing an IRP (IoCompleteRequest).
//
#define IO_NAMED_PIPE_INCREMENT 2
//
// Priority increment for completing network I/O. This is used by network
// device and network file system drivers when completing an IRP
// (IoCompleteRequest).
//
// 网卡IO之所以优先级提升并不是很多，是因为首先网卡是有队列缓存的，而大多数的报文都是burst而来的，队列缓存可以平滑掉首包延迟，其次，由于光速极限，相比于网络延迟，主机调度延迟真的可以忽略不计。
#define IO_NETWORK_INCREMENT 2
//
// Priority increment for completing parallel I/O. This is used by parallel
// device drivers when completing an IRP (IoCompleteRequest)
//
#define IO_PARALLEL_INCREMENT 1
//
// Priority increment for completing serial I/O. This is used by serial device
// drivers when completing an IRP (IoCompleteRequest)
//
#define IO_SERIAL_INCREMENT 2
//
// Priority increment for completing sound I/O. This is used by sound device
// drivers when completing an IRP (IoCompleteRequest)
//
#define IO_SOUND_INCREMENT 8
//
// Priority increment for completing video I/O. This is used by video device
// drivers when completing an IRP (IoCompleteRequest)
//
#define IO_VIDEO_INCREMENT 1
//
// Priority increment used when satisfying a wait on an executive semaphore
// (NtReleaseSemaphore)
//
#define SEMAPHORE_INCREMENT 1
---------------------
仔细看，你会注意到对于声卡而言，其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秒以内，哇塞不哇塞。
对于MacOS/iOS没有过多的研究，但是可以想见应该也如Windows这般了。因为它们都处在人机关联的人的这一端。随便看了下MacOS的开发手册，找到了下面的段落：
当我找和GUI和调度相关的东西时，就在上面这段的下面，有这个定义：
嗯，看来内核也是能看到所谓的前台窗口的。
不管怎么说，Windows，MacOS/iOS这些系统，共同的特点就是 大多数情况下，同时只有一个焦点窗口在前端接受输入输出。 毕竟把窗口缩小排满一屏幕的很少见。然后呢？然后这就是一个典型的场景啊！
你看看Win10，不就可以设置为平板模式吗？
倾其机器和操作系统内核所有资源和机制照顾这少数的，几乎是唯一的前台焦点窗口的处理进程，这几乎就是单进程处理啊！ 然后处理好用户的窗口切换即可，比如Windows的Ctrl-Tab。
Linux如若按照这个思路，单独再写一个调度器，替换掉CFS，而不是增加一个调度类，如此一来将系统中所有的进程统一按照 优先级和事件相关联 的方式对待，我想问题应该能优化不少。
已经快凌晨了，说点别的但是相关的吧。
Linux内核O(1) O(1)O(1)调度器的历史其实很短暂，2.6初始到2.6.22，但是非常经典的Linux内核方面的书，都是在描述这期间的Linux内核版本，这在当时就给了人们一个假象，O(1) O(1)O(1)调度器是无敌的，是划时代的，于是，当有了新的CFS调度器的时候，人们哇塞一声，O(1) O(1)O(1)只是银河系级别的，而CFS是宇宙级别的。
但其实，O(1) O(1)O(1)的意义只是优化了 如何快速找到下一个要运行的进程 ，虽然它也涉及了动态优先级的计算，但是这并不是它的重点。说实话，你若看看Windows的调度器，4.4BSD，SystemV4的调度器，基本上都是位图加优先级队列的形式，思路几乎是同一个，这么说来都是O(1) O(1)O(1)咯，而且人家这些调度器早在Linux还是O(n) O(n)O(n)调度器的时候就已经存在好几年了，却无人问津。
Windows内核的调度算法不为人知的原因除了其闭源之外，还有一个原因就是Windows内核方面的技术总体上推广的人太少，国内除了潘爱民一直在致力于这方面的推广之外，在没有别人了。估计是因为大家觉得Windows内核方面，Debug之外的东西，学了也没啥用吧。
你说Linux开源没错，BSD不也开源吗？怎么就没有人注意BSD的调度器实现呢？哈哈，开不开源无所谓，关键得能造势搞事情，而且获取方便，让大家用起来你的东西才真真的啊。Linux2.4版本说实话及其垃圾，但关键是很多人用起来了，这就是全部了。Solaris虽然设计完美优雅，可是有壁垒，没人用，最终也还是凉凉。同样的事情参考以太网。
通篇都在比较Windows和Linux的调度器如何影响人们的操作体验。最后说说iOS和Android吧，题外话，不涉及技术。
Android就是卡，不接受反驳。
再贵的Android机器也卡，三星的，华为的照卡不误，只是相比别的稍微好一点点而已。这意味着它们成不了街机。因为手机是买来用的，不是买来debug的，除了程序员没人在乎Android机慢的原因，即便是程序员也很少有折腾明白的，只是因为这份职业让他不用Android就不正确。不过现在互联网公司的程序员用iPhone的也多了，因为好用啊。再者说了，互联网公司程序员大概率以做业务逻辑为主，底层技术欠缺，无力debug，当然是什么好用用什么，iPhone贵，但是互联网程序员收入高啊。
最终，Android机的唯一优势就是价格，你让Android卖的和iPhone一样贵试试，分分钟被绞杀。要说还有唯一点五的，就是品牌，XX也不是吃素的，就算XX做的再烂，就凭它这牌子，也不缺市场，比如我就是XX用户，我并不是觉得XX的Android比小米的Android好，而是我喜欢XX这个公司，这个品牌，仅此而已
