我写了两篇《为什么 Mac OS X 先进》( 一、二 ) 。主要讨论什么样的文化经历了什么样的历史如何沉淀到技术中去。不过，文化有时候就保持为文化，不是所有的文化都有机会或者有必要沉淀为某种具体的技术。
前不久有一阵关于 Android 和 iOS 用户体验差异的讨论，始于《Why is Adnroid laggy, while iOS, Windows Phone 7, QNX, and WebOS are fluid》。这篇文章的作者认为原因在于两个操作系统调度线程 (thread scheduling) 的方式不同，在 iOS 上 UI 由一个有 realtime 优先级的专用线程处理，而在 Android 上只由普通线程处理。但是马上有人指出其实 iOS 和 Android 线程调度方式的差异并无文中猜测的那么巨大。
文章的作者承认自己的结论属于「猜测」。他说明自己并无特权接触iOS 底层（如果真有「特权」接触，也就不太可能被允许讨论），只是根据观察两个操作系统的外部行为大胆推测。他的观察是准确的，iOS 上大多数 app 界面渲染的优先级高于其它任务的优先级的程度，要比 Android 上类似的差异大。不过我推测这种最终处理效果的优先级差异并非源自操作系统的线程调度机制。
第一，虽然大多数 app 需要对用户的操作作出及时反应，但并不要求这种反应很快地提供最终计算结果。所以很多计算并不要求在后台和 UI 渲染同步进行（或者说，在单核系统上，和 UI 渲染以 preemptive 的方式分时进行），相反，只是要求 UI 渲染能比较快地打断计算即可。这种「打断」一般是利用 timer 等协作式多任务机制来完成。因为相对操作系统本身的 preemptive 多任务，协作式多任务对数据结构一致性的处理更为简单。此类多任务并不受操作系统的调度，而是 timer 本身的实现和 timer 的调度库（比如 Cocoa，Cocoa Touch）负责的。其中又以前者的影响为大。
第二，现代操作系统的线程调度一般基于动态反馈优先级 (dynamic feedback priority) 。在这种策略中，如果一个线程总是用尽分配给自己的时间 (time slice) 而必须由操作系统强制收回 CPU，它的优先级就会降低。而一个线程如果总是由于等待鼠标、键盘、或者磁盘主动让出 CPU，它的优先级就会提升。这种策略只考虑收回 CPU 的方式，而不考虑线程本身运行和休眠 (sleep) 的历史情况。在此基础上，有些操作系统，如 FreeBSD 和 Linux，会统计线程运行和休眠状况的历史，并且根据二者的关系推测该线程是否为 interactive 类型，即上文的 UI 线程。不过这种基于统计的推测做不到 100% 准确。Interactive 线程从休眠状态恢复到可运行状态时，会放入运行队列直接等待 CPU 调度。而 non-interactive 线程从休眠状态恢复到可运行状态时，会放到比运行队列低一级的「next 队列」。CPU 调度线程时不会考虑 next 队列，只有当运行队列清空之后（其中线程都已经调度过，并且其间没有 interactive 线程被重新唤醒），next 队列和运行队列的角色才会对调。值得注意的是 OS X 的 XNU kernel 中的 Mach scheduler 并没有采用这种「运行/next」队列的概念，也没有 interactive/non-interactive 类型，它只为每个 CPU core 创建和维护唯一的基于动态反馈优先级的运行队列。我猜测同样基于 Mach 的 iOS 和基于 Linux kernel 的 Android，其 scheduler 也与各自的源头基本相同。所以，现代操作系统中为提高用户体验的最重大的努力之一并没有应用到 OS X / iOS 中，而结果是似乎后者的用户体验并未受到什么伤害。
在 time-sharing 系统中，虽然 scheduler 是一个关键角色，但是因为它没有上层应用的 knowledge，scheduler 根据统计 (statistic) 和启发式 (heuristic) 算法所作的优化并不如上层应用根据自身逻辑进行的优化效果更明显。OS X 和 iOS 上 app 顺畅的操作感来自于 app 开发者本身对高质量界面文化的认同，而不是操作系统提供的「免费午餐」。OS X 没有采纳「运行/next」队列是不完美的，我希望这点最终能改变，不过目前看来其它操作系统和 OS X / iOS 在质量文化方面的差距差距抵消了后者技术上的不完美，亦或是，把有限的资源用在提高 app 质量本身而非效果甚微的底层方案才是正确的。
技术奇异点 
发表评论