OS 设计之性能设计

字数统计: 8.3k阅读时长: 28 min

 2023/08/21

本文是之前星球里 Yingyun 大佬的文章，由于星球已经关闭，所以把这个关于 OS 性能设计的系列文章发到博客上

Yingyun 是资深性能优化专家，他对于系统优化有非常深入的见解，本身在国内各个手机大厂都呆过，他本人的博客还在休整中，等休整好了我再发出来，目前他在我们的微信群里很活跃，对本文有什么建议或者意见，或者说想咨询问题的可以加我们的微信群（加我微信 553000664，备注博客加群，我会拉你进去）

1 缘起

新开系列文章，OS 架构设计中的各种考量因素。其实不止 OS，在设计任何大型软件都涉及到此类内容。

能力与知识面有限，而且还带了非常主观的看法，肯定有不足之处。希望听到不同的思路与观点，通过观点的碰撞进而达到更进一步的认知。

技术复核：2026-10-14。 本文保留 Yingyun 在 2023 年对架构取舍和开发者生态的个人观点。技术部分已修正内核、内存回收和后台执行的概念，并按具体版本补充；文中的平台评价和趋势预测不代表当前版本的对照测试结论。

我认为，Android 与 iOS 在 OS 角度看最核心的差异主要表现为:

应用与核心服务之间的 IPC 机制
平台开发环境，包括编程语言、IDE 工具、开发者生态建设
应用生命周期管理机制与策略
内核与核心服务的运行时组织结构

他们为什么会有不同的策略决策呢？这跟架构设计时的考量因素有关。一个软件架构设计决策是在当前一系列考虑因素中选择了对当前与可见的未来选择的最合适的决策，是一系列决策的集合。所以，架构的设计上没有绝对的对与错，或者说合理与不合理。因为不同项目、不同决策者所面临的的考虑因素、追求的侧重点是都不尽相同。如果架构师的水平差不多，把他们互换下情境，那大概率上所做出的决策是差不多的。这说明架构设计是一个工程，是一个技术手艺，它是可以被习得且有规律可循的。

架构设计中的挑战，可能更多的是在于准确理解组织所处的环境、当前与可见未来所要满足的考量因素，并从已有工程实践中找出最合适的方法论或者技术栈。考虑因素就起了重要作用，在软件架构设计里要考虑哪些因素呢？包括但不限于，可测试性、组件发布效率、组件开发效率、安全性、可靠性、性能、扩容性等等。有经验的架构师，特别是对类似业务有操盘经验，他更能把握好不同时期应该注重什么，哪些是必须坚持的，哪些是适当放开甚至舍弃的。考虑到边际收益递减，影响因素的考量与决策行为会贯穿整个生命周期，这又是另一个「决策艺术」了。

我们可以总结出:

不同阶段与不同考量因素的限制下，不同项目上软件架构设计可能是不同的。
软件产品迭代的整个周期内，这种设计决策是随时会发生。

有意思的是一个考量因素可能会与另外一个有冲突，会造成鱼和熊掌不可兼得局面。比如提高了组件开发效率但有可能会影响到程序性能。那针对一个移动 OS 的设计，当初 Android 与 iOS 的设计者们的考量因素是什么呢？为了回答这个问题，首先要解释 OS 与应用程序以及内核之间的关系。

2 机制与策略

OS 与应用共同构成硬件之上的软件栈。这里要区分内核与用户态系统服务：内核通常在 CPU 的特权模式下处理调度、内存和中断，许多系统服务仍运行在用户态，只是具有特定权限。不能把整个 OS 都理解为运行在内核态。应用通过系统调用、IPC 和框架 API 使用这些能力，例如播放音乐、存储数据。

再拔高一个层次，在用户体验角度来看，应用程序、OS 以及硬件，都是一回事情。当他们协作出现问题，普通消费者可能就觉得这台设备就不够理想。因此，这三方都有义务互相配合好、互相为彼此提供便利，只有把消费者伺候舒服了，这三家才有可持续的利润可赚。

当我们说到 OS，绝大部分现代 OS 是由内核（Kernel）跟系统服务组成。

macOS/iOS 的内核是 XNU，它结合 Mach、BSD 组件和 IOKit 等部分；Darwin 是包含 XNU 在内的底层操作系统基础，不能写成“Darwin 内核由 XNU 与 Mach 组成”。用户态还有众多 daemon 和框架服务。参见 Apple 的 XNU 说明。
Android 使用 Linux 内核。SurfaceFlinger 是 native 系统服务进程，system_server 则承载许多 Java 框架服务并使用 native 组件；两者都不是内核本身。

现在主流的操作系统有 macOS、Windows 以及基于 Linux 的各种衍生版本。显然，Android 是属于基于 Linux 的衍生版本，当然还有个在开发者圈子中更有名的延伸版本，那就是 Ubuntu。由于一个完整的 OS 的复杂性与路径依赖特性，往往会将一个延伸版本部署到不同的硬件与不同的应用场景上。有一阵子 Linux 就是以此为标榜，即它辐射到了多少台设备，应用场景有多广之类。能运行一个 OS 跟是否运行得好，即把硬件、应用程序连接起来，提供了最优的用户体验，完全是两码事情。

一个越来越普遍的认知是，不同的应用场景下，所需要的 OS 的机制与策略以及与之紧密配合的应用程序，是完全不一样的。

比如，即使是基于同一个 Linux 内核，用于嵌入式设备、智能手表以及智能手机、大型服务器甚至是智能汽车，它们使用 Linux 的方式与构建在它之上的系统服务均是不一样的，当然应用程序的运行策略也不尽相同。Linux 内核与设备驱动可以理解为硬件与系统服务之间的桥梁，是一个标准的桥梁，但是跑在它上面的车辆与行人，是完全不同的。

这就要引申出另一个非常经典的 OS 设计理念，机制与策略。

《UNIX 编程艺术》提出策略与机制分离、接口与引擎分离。机制提供能力，策略决定如何使用能力。

机制与策略的边界取决于讨论层次，不能把整个调度器或文件系统简单归为其中一类。例如，内核提供调度和 CPU 频率控制能力，系统服务提供前后台、负载等信息，调度策略和 governor 决定怎样分配资源；驱动再执行硬件支持的频率转换。DVFS 是电压/频率调节技术，预测负载和选择性能目标则属于策略。参见 Linux CPUFreq 的 governor 与驱动划分。

内存压缩是许多系统采用的机制，但不是现代 OS 的必备能力。Apple 在 WWDC 2018 的 iOS 内存说明中介绍，iOS 7 起使用内存压缩器处理暂时未访问的内存页；这不等于把整个进程压缩成一个对象。Android 常把 Linux zRAM 用作压缩内存中的交换设备。压缩页仍占用 RAM，压缩/解压也有 CPU 成本；具体策略和是否有额外后备存储，要看设备实现。

OS 的机制或许类似，但是策略千差万别，他们之间的差异有多大，取决于 OS 设计者对自身业务的理解。自身业务，指的是运行在 OS 之上的应用程序，到底要为用户提供什么样的体验与服务。这里把早期 Android 类比为桌面系统，是在形容我当时看到的后台执行自由度，并不是说 Android 原本就是桌面 OS。对厂商改造是否更适合移动设备的评价，也需要结合具体版本与场景。

智能手机、智能汽车的 OS，估计也是同样局面，不可生搬硬套。

策略还有个很有意思的特点，当你实施一个策略的时候会引申出另外一个问题，为此你要引入另一种策略。当一个策略弥补另外一个策略，逐渐会形成一个链条，你会发现你形成了一个闭环的机制。即，所有的策略同时生效，才能使你的系统发挥出最大的效益。当我们学习竞品 OS 的策略的时候，一定要记得这一点，否则只学会了皮毛，功能上线后会带来更大的「负优化」。

那具体到 Android 与 iOS，他们的策略设计是从何而来？

3 屁股决定脑袋

苹果的多个 OS 共享部分底层机制，但对后台执行、交互和资源分配采用不同策略。iOS 与 macOS 都有多任务能力；iOS 对普通第三方 App 的后台执行限制更多，不能把后台限制等同于缺少多任务能力。下面讨论的是这些产品策略的差异。

AOSP（Android Open Source Project）是 Android 的开源基础；具体设备上的 Android 产品还可能包含厂商组件和另行许可的服务。设备厂商拿到 AOSP 与硬件的相关的代码之后会在此基础上加入自己的各种服务，这是基于它们自身的商业模式、目标用户的理解，所创造出来的。苹果只有一个苹果，但是设备厂家就有很多，它们各自的盈利模式跟对目标用户理解不同，在 AOSP 基础上魔改了一遭，至于哪个好，就让市场先生来做判断吧。

AOSP 本身已有资源与生命周期策略，例如 JobScheduler、Android 6.0 起的 Doze/App Standby、lmkd 和 Android 11 起的 cached apps freezer，不能说策略都实现在 GMS 里。GMS 是不属于 AOSP、需另行许可的应用与云服务集合。厂商会在开源基础上继续调整产品策略；对这些策略的评价需要限定设备、版本和场景。

连谷歌自身的策略表现不尽人意，那就更为国内厂商发挥拳脚腾出了空间。中国大陆手机出货量累计合是全球最大的，而且竞争尤为激烈。因此它们会非常重视消费者的反馈，各种各样的需求与痛点挖掘，自然不在话下。简单总结就是，国内厂商更懂消费者的需求，这也是国内厂家对 AOSP 做各种魔改与优化成立的底层逻辑了。

所以当你再次见到有个老板说 “做手机很简单嘛，拿开源安卓跟厂商的方案整合一下就行了”，离他赶紧远一点，跟着他混简直就是枉费青春。

本文主要关注 iOS 与 Android 的策略差异；这不意味着两者底层机制相同。内核、IPC、运行时和框架组织都存在差异，不能将性能差别全部归因于策略。

这跟它两刚开始时不同的服务对象与发展目标，导致了技术选型上的巨大差异。

关于早期 iPhone 的开放策略，可以核实的时间线是：Apple 在 2007 年 6 月宣布支持第三方 Web 应用，在 2008 年 3 月发布原生 iPhone SDK 测试版并介绍 App Store。SDK 同时包含 Xcode、Interface Builder 和 Instruments。原文根据《乔布斯传》《成为乔布斯》讨论决策动机，但“因为 XNU 开销太大，所以硬件不能运行第三方应用”没有在本文中建立性能证据，不能当作技术结论。

对 UX 界面的优雅性，特别是图标与界面的一流体验是刻在苹果骨子里的基因。即使是开放出 API，他们也对整个应用运行机制做了修改，从此开始与 macOS 上的程序执行策略有差异了。

由于第一批应用都是苹果自己写的，因此他们积攒了大量在嵌入式设备上良好设计的应用应该是怎样的，也设计出了非常有效的 API 体系。在这种局面下，苹果有自己的 OS、自己的 IDE、自己的商店系统（当时还是跟 iTunes 共用），自然而然会设计出「最佳应用」应该长什么样。

这里头缺一不可，还记得前面提到过的观点吗？当你要实施一个策略的时候，可需要另一个策略来解决前一个策略带来的问题，当策略变多的时候就有可能形成了一个环路。

从这儿可看出，为了打造出一个完美的体验，从硬件到软件全部打通，是必然的结果。封闭本身不是目标，目标是把体验控制在同一套系统里。

反观 07 - 08 年的 Android 阵营，他们还在忙着如何让系统跑起来。

Chet Haase 的《Androids: The Team That Built the Android Operating System》记录了 Android 团队的早期历史。原文将创业压力、组件复用和开发者规模看作技术选型的重要背景，这是对架构取舍的理解。不过，不能据此说公开的早期 Android SDK 只有命令行工具：Google 在 2007 年 12 月的 SDK 更新说明中已经介绍 Eclipse 插件。

Android 选择 Java，有成熟语言生态和可移植性方面的考虑；“当时最多的开发者都使用 Java”需要明确统计口径，本文不据此给语言排名。早期 Android 使用 Dalvik，ART 是后续演进，Android 5.0（API 21）起成为默认运行时。不能把它们合称为 2007 年同时设计出的虚拟机，也不能只靠 CPU 进步解释两个平台的性能差异。

下面是我在 2023 年写下的工具使用感受。在安卓开发的早期，使用的是基于 Eclipse 的构建与开发工具，虽然谈不上非常优秀但是够用。但是痛苦的根源来源于对比，苹果很早之前开始构建自己的 IDE 工具，即 Xcode。这套工具里集成了大量的应用开发与调试以及分发功能，这极大的提高了应用开发工程师的效率。虽然安卓将开发环境切入到 AndroidStudio 之后相比之前进步了很多，但这主要还是得益于 IntelliJ 本身的优秀，单纯应用开发角度来看跟 Xcode 相比还是弱了一些。Xcode 提供了非常方便的编写与调试程序性能的工具，这会使开发者通过简单的学习就能快速找出程序上低性能的代码段，大大提高了程序的质量而且还使整个过程很愉快，这在安卓上可不是这么一回事了。

我认为苹果的开发者工具是其生态优势的一部分；这是我在 2023 年的使用感受，不是当前 Xcode 与 Android Studio 的功能或性能排名。还要区分工具来源：LLVM 起源于伊利诺伊大学的研究项目，Apple 后来持续参与，不能与 Swift、SwiftUI 一起写成完全由 Apple 起源的项目。参见伊利诺伊大学 LLVM 历史记录。

设计 OS 的目的是盈利，因此要想办法帮助应用开发者开发好程序。很多 OS 提供了能力之后，应用如何编写就不归他们管了，他们往往会把这个责任放到应用开发者身上，从苹果身上可以看到，这种做法可能不利于整个设备的最优体验，吃亏的还是消费者自己以及厂商，因为把消费者给磨没了。

所以当我看到苹果的强大时候，除了硬件的强大，在软件生态的建设上面的思路是非常值得借鉴的，简单总结就是:

构建 OS 是手段，提供完整且优秀的体验是目的，双方通力合作才能达到此目的。特别是 OS 与设备制造商，可能要做出更多的努力。
服务好应用开发者，努力帮助他们写好应用，甚至发现与诊断能出应用的问题，协助开发者改进应用程序。
提供更快更好用的 API，尽可能高效的满足应用开发者的需求。
通过优秀的 IDE 工具服务好开发者，让他们在此基础上开发更多更优秀的应用，OS 才能有更好的机会存活下去。

可以看到虽然苹果有绝对的话语权，但同时也提供了远超于行业平局水平的软件服务。再次强调，提供 OS 只是手段，要认识到与开发者建立怎样的关系、提供怎样的开发者服务（如 IDE），是在认知层面更为有意的事情。

4 策略之「过载保护」

移动设备的最大特性就是可移动，它是由电池供电实现了可移动性。除此之外，由于是手持设备因此散热基本靠被动散热，没有主动散热一说（奇葩的游戏手机与外挂式风扇另说）。现在有两个趋势，其一是晶体管的制作工艺越来越趋近于物理极限，其二是越来越多的功能直接封装在同一颗芯片上。实际发热取决于负载、电压、频率、制程和电源管理等因素，不能仅按晶体管数量或芯片面积推算。对于智能手机来说，现在更大的矛盾是，功耗与性能的平衡。

更多可运行线程可能争用 CPU，频繁唤醒也会增加能耗；但线程总数、实际运行时间和用户可见延迟不是同一指标。桌面和服务器同样有资源控制，移动设备只是更重视续航、温度和交互延迟之间的取舍。

Android 的 Java OutOfMemoryError、lmkd 因内存压力回收进程，以及 Linux 内核的 OOM killer 是不同层次。托管堆分配失败可能抛出 OOME；未处理的异常可导致崩溃，不是“堆超过某阈值就由系统直接杀进程”。lmkd 则结合系统内存压力和进程重要性选择回收目标，Android 10 支持 PSI 检测，Android 11 又调整了回收策略。

CPU 统计也不按 Java/native 语言划界。Android 13 的 AppProfiler 累加进程的用户态与内核态 CPU 时间；ActivityManagerService 再根据进程状态、观察窗口和阈值决定是否触发过量 CPU 使用处置。统计范围与具体终止策略要分开，不能说 native 线程不被统计。

iOS 的诊断也要按机制区分，而不是把所有超额行为都写成“必定终止”：

EXC_RESOURCE 可涉及 CPU、唤醒、内存或磁盘写入；报告若标有 NON-FATAL CONDITION，表示当次记录并没有终止进程。
Jetsam 报告说明内存压力等条件下的进程回收原因。vnode-limit 是系统级 vnode 资源不足，fc-thrashing 涉及文件缓存抖动；被回收的后台 App 不一定是制造压力的 App。
Watchdog 关注启动、响应和生命周期操作等超时；不能与资源异常混为同一阈值。
后台任务需要遵守对应 API 的完成与到期约定，过热也可能触发系统保护。但设备温度升高不意味着每个 App 都会立即被终止。

判断具体退出原因，应读该次诊断报告及设备、系统版本；不要把示例阈值当作所有 iOS 版本和设备的固定配额。

厂商加入资源保护策略，本意是保护用户体验。但如果策略没写清楚，App 为什么被终止也查不到，开发者要怎么改？这才是我想批评的地方。

需要补充的是，Android 11（API 30）起的 ApplicationExitInfo 已向 App 提供历史进程退出原因等信息。覆盖范围依设备而异：并非所有设备都能报告 REASON_LOW_MEMORY，trace 也不保证存在。厂商策略仍可能缺乏细节，但“开发者完全拿不到退出信息”不成立。

这导致的结果是，应用开发者不得不想出各种各样的所谓黑科技来使自己保活、绕过系统的各种检测机制。本应该由开发者一起共建的生态，现在变成了两家的攻防战了。到最后，是两败俱伤，而其中最受伤的就是消费者。

理想中的世界:

明文化资源过载保护机制，写在应用开发文档上。
当系统进行过载保护时将上下文调试信息保存下来，开发者可以查阅此类信息（具体权限、范围、有效期可以另定。总之要有方法，可以由开发者拿到此类调试信息）。
厂商提供方便好用的调试工具，可以由开发者在本地进行开发时修复问题使用。
当超出厂商制定的质量标准水位线，责令开发者进行修复，若不修复则下架应用。

厂商跟开发者应当是合作关系，可能厂商要做更多的事情用于帮助开发者，因为很多能力只有厂家才有。只是一味地责怪质量差是开发者的问题，这种厂商我觉得不太会有竞争力。

在认知维度上，就已经错了。

5 策略之「生命周期管理」

不同设备形态会采用不同的生命周期策略。桌面 App 通常有较大的持续运行空间，但生命周期也受用户退出、崩溃、内存压力、系统关机和管理策略影响；桌面、服务器和笔记本同样受功耗、散热与资源容量约束，不能说完全由应用自己掌控。

而在智能手机上却是另一种情况，原因是它有功耗跟发热的限制。与此类似，智能手表上也有功耗与散热的限制，但是它比手机设备更为严苛。谁都不希望手腕里戴着一个会发热的表，而且续航一天都撑不了。除此之外，由于它的性能跟内存受限，不能驻留太多的程序在后台，因此需要有一个集中式管理的模块来统一实现绝大部分常见应用的服务，即所谓的托管式架构。智能汽车也有算力、供电、散热和待机能耗约束；不同域控制器会有各自的休眠、唤醒与可靠性要求，不能把整车系统视为只要未断电就一直运行。长期服务的资源泄漏和恢复能力仍值得关注。

iOS 通常会在 App 退到后台后暂停普通执行；暂停时进程不再执行代码，但不等于已经终止。原文的“5 秒”来自 applicationDidEnterBackground 的返回时限，不能当作所有后台 API 的统一运行额度。有特定后台模式或任务授权的 App，要按对应机制处理。

原文对厂商冻结策略优劣的评价属于 2023 年的观察，不能据此预测后续两三年的效果。AOSP 并非不支持冻结：Android 11（API 30）起已有 cached apps freezer，通过内核 cgroup freezer 暂停符合条件的缓存进程，保留内存而停止 CPU 执行。Android 14 又调整了缓存进程与广播等相关行为。是否启用、豁免条件和时序依版本、内核及设备配置而定；有后台任务或前台服务的进程不一定处于可冻结的 cached 状态。

那 App 在后台被暂停了，需要继续计算的任务怎么办？iOS 提供了几种不同机制，不能统称为一个 BackgroundTask 权限：

UIKit beginBackgroundTask 为前台已开始的重要工作申请有限的收尾时间，需要及时 endBackgroundTask 并处理到期；不是定时调度器。
iOS 13 起的 BGAppRefreshTask 用于短时刷新，系统安排运行时机，文档说明最多约 30 秒。
同为 iOS 13 起的 BGProcessingTask 可执行较长处理，可能运行数分钟，也可能被中断；没有通用的固定 30 秒额度。
iOS/iPadOS 26 新增 BGContinuedProcessingTask，支持从前台开始、继续到后台的用户可见工作，需要报告进度，用户可取消，系统也可因资源限制而终止。

参见后台策略选择、BGProcessingTask 和 BGContinuedProcessingTask。执行时机和预算由系统决定，没有面向所有 App 的固定每日次数，也不保证每隔若干分钟运行；任务必须处理到期、保存进度并报告完成。

后台需求还不止计算。播放音乐、定位、传文件怎么办？这些场景有各自的能力声明、用户授权和 API 约束。App Store 的审核属于分发治理，运行时是否调度、暂停或回收进程由设备上的系统机制决定，不能把商店当成后台调度器。内存压力可以使暂停的进程被终止，但内存回收也有缓存丢弃、压缩等手段，不是只有杀进程这一种方法。

那 App 连进程都被终止了，又怎么执行任务、接收消息？系统终止后，符合条件的任务有机会让 App 再次在后台启动，但不是无条件保证；用户强制退出后的行为也不能等同于系统回收，见 Apple 后台执行限制说明。通知至少还要分清：系统展示的可见通知、用于后台更新的静默通知，以及真实来电场景的 VoIP Push。

后台通知的投递和唤醒不保证及时，也可能被节流；不能说只有点击通知或 VoIP 才能触发后台工作。PushKit 的 VoIP 通知用于来电，使用 iOS 13 SDK 及以后的 App 需按文档与 CallKit 配合，不能当作通用保活通道。

Android 的后台调度与推送也要分开。JobScheduler 从 API 21 起提供平台任务调度，WorkManager 不要求 Google Play services。它们不能简单归入 GMS，也不是通用常驻进程许可。

FCM 的标准 Android 客户端依赖相应 Google 服务环境，厂商也有自己的通道，例如 HUAWEI Push Kit。各通道的设备覆盖、投递与后台执行约束需要分别适配。因此，“没有 GMS 就只能常驻”“厂商只能靠加内存解决”都不是技术上的必然结论。我的主张还是：厂商要和应用开发者一起把生态做好，不能只在各自的边界内解决问题。

纵观 iOS 的设计，相比于 macOS，限制了应用的自由度，但也提供了各种「窗口期」或者「统一的解决方案」，以满足开发者的不同需求。目的是让开发者在合理范围内做事情，避免榨干用户的电量与性能。

总结下技术之上的设计原则

移动设备受限因素多，因此要对应用「自由度」给予限制但不能一刀切，需要给予对应的解决方案。
应用之间的共性任务要由系统统一提供，可节省系统整体负担，这对限制因素较多设备尤为重要。
程序最终执行权交由系统而定，由他综合各类信息之后统一调度，这有利于保护最终的用户体验。

写到此处，似乎是两个体制的碰撞，一个崇尚自由，个体优先、一个崇尚统一安排与调度。无论是哪种体制，要看最终目的是什么，如果是要提供最佳的设备用户体验，显然后者体制被市场证明是正确的。

6 设计之上

专用加速器可以提高特定工作负载的效率，GPU、媒体编解码器和机器学习加速器就是例子，但这不意味着通用 CPU 已停止进步，也不意味着所有软件都能获得同样收益。DSA（Domain-Specific Architecture）强调按领域需求设计硬件与软件接口。“下一个十年的大飞跃主要来自 DSA”是作者在 2023 年的趋势判断，保留作讨论，不当作已验证的预测。

以 2020 年的 M1 为例，它同时包含 CPU、GPU、Neural Engine 和媒体编解码引擎。专用引擎的收益取决于任务、格式和软件是否调用硬件加速，不能用一句“超过 Intel 芯片”概括不同代际、功耗与负载的比较。本文没有提供同条件基准测试，因此这里只说明架构分工，不给出跨平台性能排名。

但这不代表基于 CPU 的性能提升已经走到尽头，随着单靠 CPU 升级获取性能收益变得不够，通过对需求的准确理解，优化矩阵与架构设计来实现在已有 CPU 上的性能提升，变得更为紧迫。对硬件、编译器、算法以及操作系统（框架与内核）的理解，变得越来越重要。因为当你优化到一定层度的业务代码之后，注意力必然会往底层走。

只有相当多的失败的经验，才能未雨绸缪，以高屋建瓴的方式设计出最佳的架构与优化矩阵。优化矩阵是指为了提供一个极佳的体验，并不是由一个 OS 就能搞定，他要有相配套的其他技术一起支撑才能做好。比如 IDE、比如云端配合、以及正确的认知。想要提供一个极致的体验，是非常难的事情，但也正因为如此，你会发现了解越多可做的事情就越多。同样道理，也有别样的说法 → 使自己始终处于「知道自己不知道」的状态。

不过以上成立的前提，是设计者的认知要跟得上。

查理芒格说过，投资不是看看财报，看看走势图就能做好的。除经济学与金融学外，心理学、社会学、政治学、甚至生物学都有关系。只有当你踏平学科间的隔阂，不设边界地把多个学科内容融合在一起之后，才能看到别人看不到的世界。我当然也没达到这种境界，芒格给世人的经验是我们值得学习的宝贵经验。努力跨学科、跨领域的刻意练习，如果能在此基础上做到思考输出，那对学习更有帮助。