这是我搭建个人笔记体系的一套理论，目前也还在探索中，未来或许还会持续迭代。

当然，我主要目前有两个工具，

• Heptabase，主要用于记录知识点和学习笔记，不会记录用于发表和发布的文章，它的使用更像卡片笔记法的思路。
• Craft，主要记录最终的文章，而这些文章的论据和内容大部分都是记录在 Heptabase，它的使用更像写一个比较严谨，且有逻辑性文章的思路。

虽然有两个软件，但这两个软件的背后，其实包含着一套相同的方法论，只不过在使用上因为不同阶段有不同的诉求，所以需要两个工具载体！

这也就是我今天要说的这套 INK 方法论！

含义

• I：Inbox（收集箱），用来收集任何时刻、任何方式得到的零碎资讯，用关键词记下，放在 Inbox 下随便一个页面里。称为关键词笔记。

• N：Note（条目），用来存放 Inbox 中经过整理的完整笔记。每一则笔记都有完整的时间、标题及脉络。称为参考笔记。

• K：Knowledge （知识），这是重点。用来将 Note 里面储存的笔记主题化。称为主题笔记。

核心

• 就是将 Note 中的笔记，按照某一个主题，或者某一种用途，有组织地放到一起。

执行流程

收集 —— 完善 —— 整理 ——（应用）—— 归档

收集

任何时刻，看到任何觉得有价值的资讯，用手机和平板（视哪个更方便而定）记下来。结合文字、画图、拍照等方式，记在印象笔记里，自动同步。

回到电脑前，打开印象笔记电脑端，同步，将之前记下来的关键词转移到Inbox里。

完善

定期进行，一般1-3天一次。将所有Inbox里的每一个关键词，通过搜索，扩充成一则有价值的详细笔记，存放在Note里面。如果在Inbox里记下的是一篇文章的链接，则进行通读，整理出要点，同样存放在Note里面。然后将Inbox清空。

例如，我在Inbox里记下一个关键词，叫做「长尾效应」，那么，我就会通过搜索，整理出：长尾效应是什么意思？谁提出的？得到了怎样的印证？业界对其态度如何？存在怎样的问题？等等。然后把这部分内容，在Note里新建一页，放进去。

整理

我会经常翻阅Note笔记，并且一边翻阅一边思考，当突然想到「诶，这个内容似乎可以用」的时候，就会进行思维整理。比如，我看到「长尾效应」时，可能会想到它也许可以解释某个案例，或者与某个理论之间存在矛盾，就会在Knowledge中另开一页，把这个思考写上去，并且附上「长尾效应」这一页的链接，以便查阅。

怎么附上链接呢？这里要提到 Craft 和 Heptabase 特别优秀的一个功能：在这两个软件里面，任何一个 Block（它可以是一页笔记、一段话、甚至一行字），都可以生成一个内部链接，只需要选中，右键，选择「复制指向页/段落的链接」即可。

这个功能可以大大提高思维整理的效率。比如，在一页Knowledge里面，我可能会引用到10页Note的内容，但我并不需要把它们的内容全部复制进去，我贴10个链接就可以了。

应用

定时翻看自己的笔记，尤其是主题笔记，有灵感了，就将其输出。 写一篇文章，在知乎回答一个问题，或者告诉别人，都可以。 关键是要去用。将笔记和思考转化成为实实在在的实践，把思想落实成为行动，这才是笔记的本来目的。

归档

对于完全物尽其用的笔记，或者已经记得滚瓜烂熟的笔记，删掉，为今后的输入腾出空间。

注意点

• Inbox 里使用关键字作为标题存放相关内容

• Notes 里存放着经过阅读，整理，完善，扩充后的笔记

• Knowledge 里存放 Notes 里的具体链接，看起来更像一个目录

相关链接：

1. https://www.zhihu.com/question/23427617

2. http://www.wenjukong.com/forum.php?mod=viewthread&tid=2098

3. https://www.douban.com/note/462721812/

感想

基于之前 《现代 Web 开发的现状与未来（JSDC 2019 演讲全文）》的演讲，去深入了解了一下 Design Token 的相关内容，说一下我学习后的感想：

Design Token 是啥？

首先设计系统这个概念现在已经很火了。提出原子设计理念的 Brad Frost 曾说过：

在一个公司内，设计系统可以提高团队间的协作效率。目前设计师和工程师遇到的一个普遍问题是，如何共享产品的品牌和界面信息。在开发过程中需要尽可能地按照设计产出还原，但是我们都知道这件事没那么简单。我们需要保持产品的品牌一致性，而设计规范和设计系统可以帮我们达成这个目标。

让我们先看一下 Nachos —— Trello 的设计系统。在大部分设计系统中，我们总能找到一个定义"核心样式"的章节。我所指的"核心样式"是指那些界面中不可拆分的部分，比如说颜色、字号、间隔、动画、阴影、层级、响应式断点等等。这些集中在一起的不可拆分的样式信息将会被应用于不同平台的产品设计中，它们就是——Design Token。

这个概念出自 Salesforce，Jina Anne 给其命名

Design Token 可以让产品设计团队更好地协作，同时保持产品跨平台的一致性。

可以想象，上图中这些颜色将被用在 Trello 不同平台的界面中，不同的是每一种平台都有其自己的格式和要求：

• 在 Web 中是一个写满了 RGB 颜色的 CSS 文件

• 在 iOS 中是一个写满 RGBA 颜色的 JSON 文件

• 在 Android 中是写满 8 位十六进制色值的 XML 文件

当然，这些文件中的色值会随着时间不断变化，这也是为什么需要集中管理的原因，否则每次更新我们都需要到处寻找它们并修改，太浪费时间了。

现状

作为一个大前端，我假设设计师想要更换一些样式，比如说替换颜色，修改字号，或者其他一些样式。理想的状态是，他们更新之后在各个平台都可以立即看到修改后的效果，可事实并不是这样。

举个例子，假如现在我们需要替换一个颜色，现在的工作流程是这样的：

• 设计师在设计工具中更新颜色

• 设计师将设计更新提供给开发

• 开发依据设计稿更改对应的代码

• 设计师可以在开发环境中看到最新的结果

这个流程不好的地方在于：

• 设计师想要看到最终实际效果如何，需要等待开发完成所有工作。这会阻碍设计流程，让设计师很难受

• 在代码中更改一处色值不需要太多时间，但是如果把这个时间用在其他更有意义的事情上会更好。如果经常这样更改，开发也会很难过

• 由于我们通常会把它记在任务管理工具中，这件「小事」会给人造成一定心理压力

• 从一个更加普遍的视角来看，这些变更会推迟产品走向市场的时间

这个流程其实是可以被优化的

让 Design Token 来拯救你 现在闭上眼睛，想象你正在使用一个带有 Design Token 生成器的设计工具，理想的设计流程就像下面这样子：

• 设计师在设计工具中更改颜色。

• 设计工具自动将 Design Token 文件更新到指定平台。

• 开发只需要拉取或更新这个文件到自己的项目中即可。

这将会给设计和开发节省大量时间，并保证产品整体一致性，无论是设计师还是开发或者产品负责人都会很开心

不过，正如我上面所说，这是一个理想的工作流程。如果要实现它，需要在设计工具和开发工具之间架起桥梁。目前据我所知可以生成 Design Token 的工具只有一个 Theo，这是由 Salesforce 开发的。Theo 做的事情很简单，它把一些原始的 JSON、YML 文件转换为适用于各个平台的代码文件，比如适用于 Web 的 Less 文件。

Theo 如果能在设计工具中使用的话，那么这个流程就有可能实现，尤其是自从 Sketch 可以导出 JSON 文件之后

想得更深远一些的话，这种中间工具应该可以直接让设计师在设计工具中生成 Design Token，接着这些变更被自动同步到设计系统中。

在这个例子中，Design Token 是颜色，其它属性诸如字号、投影或间隔都是一样的道理。

适合开发的相关工具

• 24ways 的设计规范就是使用一个叫做 Fractal 的工具生成的。它的维护者 Paul Robert Lloyd 在构建规范的过程中就使用了 Design Token，这些 JSON 文件中的 Token 会被 postcss-map 插件导入到 CSS 中去。

• EightShape 做了一个静态站点生成器，用来生成设计系统文档。他们通过一个 Gulp 任务来将 JSON 或 YAML 文件中的 Design Token 生成为一个叫 tokens.scss 的文件。

• 还有一个叫做 Dragoman 的项目，它是一个 Gulp 插件，也可以帮助你将 Design Token 转换为不同平台的样式文件，可惜它现在已不再更新了。

总结一下

Design Token 是一些集中存储的 UI 元素信息，比如颜色、字体、间隔、动画等等。他们可以根据需要被转换为不同平台的代码，比如 Android、iOS 或 Web。

Design Token 让团队间的协作更加流畅，并且保证了不同平台间的品牌一致性。

然而，目前 Design Token 似乎只能在开发那边发挥作用，在设计工具内目前还没法直接和这些 Design Token 生成器产生联系，但目前 Sketch 可以导出 JSON 的数据了。另外 Figma 通过其开放 API 可以将 Design Token 导出，有一个插件叫做 CSSGen 甚至可以直接生成 Web 样式变量

设计产出后的那些事，大概可以分为 Design Review, UI Testing, Design Lint 三个环节。

Design Review

设计评审，应该是设计师最熟悉和参与度最高的一个环节。不过对于大部分设计师来说，关注的重点和经验主要集中在前期需求分析和完成设计稿，对于设计评审往往没有太多的经验，不知道如何表达，这篇文章很好地讲解了设计评审的流程：如何在會議中有效表達設計

UI Testing

UI 测试，通常是在通过前端框架自动化测试设计界面中存在的潜在问题，比如国外知名的 Chromatic 2.0，网易的 Airtest，阿里也有自己家的测试工具。

本文不讨论前面两个环节，主要说说 Design Lint 这件事。我们姑且把它翻译成设计审查吧。

Design Lint

Lint，这个在代码世界非常普及的事情，如今在设计工具里也渐渐流行了。

很早以前我就在想，为什么设计工具里一直没有 Lint 这类功能？我想可能有两个主要原因：

1.设计工具的最终产出和设计源文件没有直接关系。不像是代码，不符合规范会报错，语法错误根本无法运行。而设计过程中图层和命名等基本操作全凭设计师自觉，除非是团队制定规范，强制执行，通常也只能人工审核。但就算不遵守，也不会影响最终生产，老板更不关心。

2.历史遗留问题。早期的互联网设计和开发还是相对独立的两个环节，设计也没有组件，设计系统这些概念，和开发的联系没那么紧密，也就不需要语义化的命名规则，更不需要检查太多逻辑上的问题。

同样的设计产出，表面看起来完全一样，但对组件和样式的运用、图层的命名却有天壤之别。

目前市面上已经出现很多 Design Lint 工具了，其中最广为人知使用最广泛的就是 color contrast 这类工具，比如：

Cluse

免费的 Sketch 插件，相当于把 Chrome DevTools 内置的 color contrast 功能拿到了软件里，可以实时查看修改结果。

Contrast

大概是目前设计和口碑最好的一款 Mac 小工具，由知名的 @mds 大神出品。

ontraste

前苹果设计师做的另一个免费小工具。

同类的颜色对比度工具还有很多很多，因为标准已经比较完善成熟，不管是原生桌面软件，在线网站工具，还是设计软件里面的插件，甚至浏览器开发工具，都有不少非常不错的产品。

随着 Figma 这种基于 Web API 的设计工具的普及，越来越多更专业功能更全面的 Lint 工具也都出现了。

Design Lint

前段时间 Discord 产品设计师做的一个 Figma 插件，受限于官方 API 的能力，虽然功能不算强大，但可以说很好的展示了这类工具的雏形和未来发展方向。

基于现在设计系统的思想，通常我们需要定义好一套颜色、描边、阴影等基础样式，以便在图层中方便地引用，它可以检测出设计稿中没有用到定义的样式的所有图层，统计并报错。尽管不是完全自动化的，需要你点一下插件执行，但好在是全局的。

然后就可以逐条点击并跳转到错误的图层进行修复，并且提供了简单的提示。

Roller

TOYBOX 团队也开发的另一款类似的 Figma 插件。

这个插件和上面那个大同小异，同样也是检查颜色、文字、描边、样式和圆角等基本属性，但是界面的设计更加合理一些，把不同的分类整合在一起显示了，并且还可以直接添加没有样式的部分。

同时它还提供了可以直接在插件里修改的界面，这样就不需要不停地跳转到对应图层了，比 Design Lint 更高级一些，唯一的缺点是免费版只能检查颜色和文字两个属性。

Sketch-lin

Sketch Lint 是一个比较早期的 Sketch 插件，应该是目前功能最强大的，但也是作为一个试验性项目，已经一年多没更新了。因为是基于 Sketch 和 Mac 系统原生的 API，它除了可以做到上述基本属性，还可以检查拼写和边距（Padding）。

Sleuth

最近才发布的另一个 Sketch 插件，基于 Sketch 的组件 Library 系统来检测组件的使用情况。

分析结果界面：有点像 Figma 企业版里面才有的那个设计系统分析工具。

Fix Your Mess

这个插件可以检测出所有被解组的 instances 子组件，对它们进行清理或再次编辑等操作。严格来说这个其实不算 Lint 工具，只是对设计稿比较有洁癖的人来说很有用。比如还有的插件可以检查隐藏的图层，没有使用的图层等等。

Modulz

之前在 未来的 UI 设计工具要来了吗？介绍过的全新设计工具 Modulz，也提供了一个 Lint 功能，看如下截图是不是联想到了基于 Chrome 浏览器的网站性能测试工具 Lighthouse？其实如果把浏览器看作是一个设计工具的话，Lighthouse 确实是最完美的 Lint 工具了。

Sketch Beta

Sketch 官方最近也在做一个叫做 Sketch Assistants 的功能，提供类似 Lint 的功能，相信官方自己做这件事，功能特性和使用体验上应该好很多吧。

总结 所以可以看到，现阶段的 Design Lint 工具，能做到的事情还非常有限，主要包括：

• 颜色：检查图层的颜色是否使用了色板（或 design token ）中定义的颜色。

• 字体：检查字体大小、颜色、字体、行高等样式。

• 样式：包括圆角、描边、阴影等等。

• 拼写：检查文字图层中文字的拼写，只能通过苹果系统自带的字典 API 来做。

• 内边距（Padding）：只能检查图层和元素之间的垂直间距。

• 对比度（Contrast）：检查两个图层或文字图层的颜色对比度，显示 accessibility 评分。

而暂时还不能做到，个人非常希望将来可以实现的事情大概有：

• 图层和图层组的命名：想象一下这个应该不难做到，在插件的设置里定义好一份命名规范，如果不符合规范就会报错。

• 组件和样式的命名：检查颜色等样式的命名方式是否符合前端规范，组件的命名是否采用了 name / name 这样的命名方式，语义是否符合前端规范。

• 像素对齐：检查矢量图的像素对齐问题。

• 网格系统和元素位置：检查画布上的元素是否正确地使用了定义好的网格系统。还可以检查元素间的位置，比如基于 8pt 的原则，是否有元素不小心使用了奇数的间距等等。

• 图片处理：检查设计稿中载入的图片是否太大而影响文件性能，是否采用 Fill 的方式而不是其他方式载入的。

• 布局和响应式设计：对于需要做响应式设计的元素，你可能经常忘了设置 constraints 或使用 autolayout，如果可以智能地检查出来就很省心了。

综上所述，目前 Design Lint 这件事，还处于不太成熟的早期阶段，没有大厂推动，设计软件本身也都没有做太多相关功能，也没有更开放的 API，即使个人开发者有一些小的尝试，也很难做到很完善。设计不是艺术，如今的互联网设计是高度工程化的一个环节，希望借助新的设计工具大潮的推进，会有更多的厂商意识到这件事并积极做出一些改变吧。

References

• 如何在會議中有效表達設計: https://medium.com/uxeastmeetswest/如何在會議中有效表達設計-how-to-present-your-design-in-design-review-6e192e5dd4b3

• Chromatic 2.0: https://www.chromatic.com/

• Airtest: https://airtest.netease.com/

• Cluse: https://cluse.cc/

• Contrast: https://usecontrast.com/

• Contraste: https://contrasteapp.com/

• Design Lint: https://lintyour.design/

• Roller: https://www.trytoybox.com/roller

• Sketch-lint: https://github.com/saranshsolanki/sketch-lint

• Sleuth: https://sleuth.keap.design/

• Fix Your Mess: https://www.figma.com/community/plugin/817773666528183444

• Modulz: https://www.modulz.app/

• Sketch Beta: https://www.sketch.com/beta/

BFF，SFF 到底是什么？

• BFF: Backend For Frontend

• SFF: Serverless For Frontend

关于 BFF 可以参考我的这篇笔记: 《微服务设计》中关于 BFF 内容的读后感

文章核心内容的总结：

至于 SFF，则是阿里 Egg 团队提出的一个新概念，那么为什么要提出 SFF 呢？这就要说说 SFF 的前任，也就是 BFF，它出了什么问题，Egg 团队认为 BFF 存在下面 3 个问题：

• 专业人才储备

  • 远远低估了前端的缺人程度，一将难求，无人可招。

  • 全栈人才的培养成本不低，包括前端需要学习后端 DevOps，后端需要学习前端的用户交互。

• 基建墙，各种流程太重

  • 不同的基建服务需要去不同的后台走申请流程，N 多个工单需等待审批。

  • 像 DRM 的配置、Mobilegw 的配置，需要在每种环境中单独配置一遍。

• 资源浪费

  • 在 BFF 场景下，服务器水位较低（10% ~ 30%），基于微服务的高可用诉求导致了服务器资源的浪费。

  • 譬如在蚂蚁容灾要求下，至少需要 11 台 4C8G 的容器。据此估算，支撑内部上千个中台应用，则就至少需要约 2000 台 32 核物理机！！！

而 SFF 的目标是 提升前端的研发效能，以一当百。

主要思路为：专业的人做专业的事，让业务开发者专注于业务本身的研发。

• 场景化：根据不同业务场景做垂直领域定制，减少不必要的干扰，专注于业务逻辑的开发。

• 轻流程化：打破基建墙，一站式的接入三方服务，减少各种不必要的流程和工单，以代码为中心，声明即接入。

• Serverless 化：让应用能利用云平台实现资源的按需分配和弹性伸缩，从而减少资源浪费。

• 自动化运维：DevOps → noops，减少研发对基础措施和运维的关注，交给我们这些专业的框架维护者。

一句话阐述：让纯前端开发者，只需写几个 Function 即可使用到后端相关的能力。

研发的角色将变为

一些思考与疑问：

回看 SFF 的整体概念，似乎 Egg 团队想表达的核心观点是： 将 BFF 这个层级做成 Serverless 的，这样做也有几个明显的好处：

• 在SFF的模式下，原先 BFF 层里的前端开发在获取后端业务信息时，借助 Serverless 的能力，只需要写一些函数（FaaS）或者直接调用一些基础服务（SaaS）就 ok 了

• 原先的 BFF 层里的服务器维护工作还是相对较重的，一旦 BFF 层级变成 Serverless 的形式，维护将变得更加容易

那么这些 SFF 这个概念对于 我们的 MBC 有一定指导意义么？

我觉得有，而且肯定有！

首先，SFF 提出的三个矛盾，我相信明眼人都可以看到，这就是未来 MBC 会遇到的问题，完全没毛病，但这些问题是现在还不是痛点或者痒点，但等体量大起来，这些问题就会暴露出来。

其次，试想一下在前端 Serverless 化的一个典型网站 CodePen ，如果说它是未来中台控制台的终极形态，也不为过，我们完全可以做到在 CodePen 上直接写几个简单函数，就实现了业务开发，而不再关注一切跟服务器相关的内容，那会多爽啊。这个模式没毛病，除非你非要折腾那些和业务没什么关系的代码。

最后，技术在发展，BFF 是 2015 年的概念了，这个架构关注的核心点是不同端上的差异问题（比如像 b 站 Android 和 iOS 的 app 设计体系是完全不同的两套，长得不一样，所以需要的 API 数据是极有可能不同的 ）和快速开发的问题（摆脱后端的发版依赖，将数据的控制权掌握在前端手里，后端只作为物料的供给方），而这些点已经不全是美团 app 所需要解决的核心问题了（例如美团 app 在 Android 和 iOS 上的样式是完全一致的，其实一套 API 就可以），MBC 在某种程度上将前端的主动权拿回到了自己的手里，也就是灵活性有了，所以研发效率会有一定的提升，那么未来到底怎么再提升研发效率，我想降低开发的门槛会是一个方向(在纯UI 方面，我们已经有了 MTFlexbox，好比你不会 iOS ，不会 Android 都可以，只要会 MTFlexbox 就行，从某种程度上就是降低了开发门槛), 也就是所谓的 Serveless，毕竟这样开发者不用懂太多的服务端知识，就可以马上开发。相信当我们的架构在灵活性和可操作性上都有了很好的平衡，整体的研发效率又会有一个提升。

GraphQL 到底是什么？

一句话来定义 GraphQL：GraphQL 是一种描述请求数据方法的语法，通常用于客户端从服务端加载数据。

它有 3 个显著的特征：

它允许客户端指定具体所需的数据。

它让从多个数据源汇总取数据变得更简单。

它使用了类型系统来描述数据。

历史背景

GraphQL 是由 Facebook 开发的，用于解决他们巨大、老旧的架构的数据请求问题。但是即使是比 Facebook 小很多的 app，也同样会碰上一些传统 REST API 的局限性问题。

例如，假设你要展示一个文章（posts）列表，在每篇文章的下面显示喜欢这篇文章的用户列表（likes），其中包括用户名和用户头像。这个需求很容易解决，你只需要调整你的 posts API 请求，在其中嵌入包括用户对象的 likes 列表，如下所示：

但是现在你是在开发移动 app，加载所有的数据明显会降低 app 的速度。所以你得请求两个接口（API），一个包含了 likes 的信息，另一个不含这些信息（只含有文章信息）。

现在我们再掺入另一种情况：posts 数据是由 MySQL 数据库存储的，而 likes 数据却是由 Redis 存储的。现在你该怎么办？

按着这个剧本想一想 Facebook 的客户端有多少个数据源和 API 需要管理，你就知道为什么现在评价很好的 REST API 所体现出的局限性了。

解决的方案

Facebook 提出了一个概念很简单的解决方案：不再使用多个“愚蠢”的节点，而是换成用一个“聪明”的节点来进行复杂的查询，将数据按照客户端的要求传回。

实际上，GraphQL 层处于客户端与一个或多个数据源之间，它接收客户端的请求然后根据你的设定取出需要的数据。还是不明白吗？让我们打个比方吧！

之前的 REST 模型就好像你预定了一块披萨，然后又要叫便利店送一些日用品上门，接着打电话给干洗店去取衣服。这有三个商店，你就得打三次电话。

GraphQL 从某方面来说就像是一个私人助理：你只需要给它这三个店的地址，然后简单地告诉它你需要什么 （“把我放在干洗店的衣服拿来，然后带一块大号披萨，顺便带两个鸡蛋”），然后坐着等他回来就行了。

换句话说，为了让你能和这个神奇的私人助手沟通，GraphQL 建立了一套标准的语言。

一个例子

设想我们使用 GraphQL 查询数据，你只需要写出下面的代码即可

query { 
client(id: 1) { 
    id
    name 
  } 
}

你的第一印象：“这个不是JSON？”。

还真不是！就如我们之前说的，GraphQL设计的中心是为客户端服务。

GraphQL的设计者希望可以写一个和期待的返回数据schema差不多的查询。

那么后端会返回什么呢？

{
  "data": {
    "client": {
      "id": "1",
      "name": "Uncle Charlie"
    }
  }
}

就如我们期望的，server会返回一个JSON串。这个JSON的schema和查询的基本一致。

Serverless 到底是什么 ？FaaS 和 BaaS 又是什么？

一种比较通俗的说法：你部署代码的时候再也不用关心服务器之类的问题。

一段相对严谨的说法：无服务器架构（Serverless architectures）是指一个应用大量依赖第三方服务（后端即服务，Backend as a Service，简称“BaaS”），或者把代码交由托管的、短生命周期的容器中执行（函数即服务，Function as a Service，简称“FaaS”）。现在最知名的 FaaS 平台是 AWS Lambda。把这些技术和单页应用等相关概念相结合，这样的架构无需维护传统应用中永远保持在线的系统组件。Serverless 架构的长处是显著减少运维成本、复杂度、以及项目起步时间，劣势则在于更加依赖平台供应商和现阶段仍有待成熟的支持环境。

后一种说法里提到了 BaaS 和 FaaS，这两个名词到底是什么意思呢？

• BaaS: Backend as a Service，这里的Backend可以指代任何第三方提供的应用和服务，比如提供云数据库服务的Firebase和Parse，提供统一用户身份验证服务的Auth0和Amazon Cognito等。

• FaaS: Functions as a Service，应用以函数的形式存在，并由第三方云平台托管运行，比如之前提到的AWS Lambda，Google Cloud Functions等。

相比于 Baas ，FaaS 还是比较抽象，下面有一个例子来说明

函数，往大了说可以是一个应用的main函数，往小了说也可以是一个简单的加法函数，那到底该如何理解FaaS中的函数呢？先来看张图。

左侧的Monolith即我们常说的单体应用，中间是微服务，右侧就是FaaS中的函数。

如同一个单体应用可以按业务模块拆分成多个微服务，一个微服务也可以按使用场景拆分成多个函数。

比如一个广告微服务，至少可以拆分出实时竞价、展示计数、报表查询等多个函数。

也就是说，FaaS中的函数和微服务中的API是同一粒度的。

但不同于API，在Serverless架构下，每个函数都是独立部署，按需执行。

在解释了 BaaS 和 FaaS 后，我们回过头来在用一个例子来解释 Serverless

举一个实际的例子，假设我要部署一个小系统，它的作用是从一个数据库中检索一个列表，并以 JSON 格式呈现出来。（因为我自己比较熟悉 Node，我们来写一个具体的实现）

var express = require('express');
var app = express();

app.get('/cats', (req, res) => {
    //go get my cats
    let cats = ["Luna","Robin","Cracker","Pig"];
    res.json(cats);
});

app.set('port', process.env.PORT || 3000);

app.listen(app.get('port'), () => {
    console.log('Express running on http://localhost:' + app.get('port'));
});

整个代码是基于 Express 框架来实现的，所以为了实现这个 API，我必须加载 Express，但重点在下面：

• 首先，我需要一种设置和处理路由的方法，以便我知道何时显示路由 cats。换句话说，我要知道 /cats 是否被请求，而不是别的请求。

• 我必须启动一个 Web 服务器才能响应这些 API 调用。 虽然 Express 使这个变得很容易，但是我还是要做这一步。

• 我要处理一个请求和一个响应来处理客户端 API 调用。Express 再次简化了这个流程，但是现在我的逻辑和 HTTP 有着密切的联系。

所以总的来说还不错。我可以在几分钟内运行起来。但是我需要部署它。

• 首先我找到一个主机。例如美团云，哈哈，在这些主机上能够部署我的 Node 代码，并在几分钟内启动并运行。

• 作为这个过程的一部分，我必须考虑应用程序的使用情况，并对 CPU，内存等进行一些选择。

那么云服务带来的改变是什么呢？我可以几秒钟内在云服务上的机器里部署好 Node 环境。这里还是涉及到了服务器。我们还是需要设置它（不管容易与否）。

所以在这些场景下，不管怎样你都需要设置服务器。

现在让我们回过头来看看 serverless。使用相同的用例，下面是我的代码：

function main(args) {
    //go get my cats
    let cats = ["Luna", "Robin", "Cracker", "Pig"];
    return { cats: cats};
}

就这样。实现业务逻辑的代码是我唯一需要关心的。

部署这些只需要运行命令行将其添加到 OpenWhisk 中，类似的程序可以用于其他 serverless 平台。所以最后…

我只关心业务逻辑（获取 /cats）

我不关心路由，我的平台会告诉我 cats 是可用的

我没有绑定到 HTTP 模型了。我可以使用这个例子作为 serverless 平台每天运行的计划任务，甚至不考虑网络。

最后，我仍然在做同样的事情 — 使我的业务逻辑可用。但是我并不关心与网络访问相关的其它事情。

换句话说，我不关心服务器。

laaS，Paas，SaaS 到底是什么？

在理解之前，先弄清这几个词儿的定义

• IaaS：基础设施服务，Infrastructure-as-a-service

• PaaS：平台服务，Platform-as-a-service

• SaaS：软件服务，Software-as-a-service

老外有一个比较形象的解释来说明这个问题，假设你是一个餐饮从业者，打算做披萨生意

你可以从头到尾，自己生产披萨，但是这样比较麻烦，需要准备的东西多，因此你决定外包一部分工作，采用他人的服务。你有三个方案。

• 方案一：IaaS：他人提供厨房、炉子、煤气，你使用这些基础设施，来烤你的披萨。

• 方案二：PaaS：除了基础设施，他人还提供披萨饼皮。你只要把自己的配料洒在饼皮上，让他帮你烤出来就行了。也就是说，你要做的就是设计披萨的味道（海鲜披萨或者鸡肉披萨），他人提供平台服务，让你把自己的设计实现。

• 方案三：SaaS：他人直接做好了披萨，不用你的介入，到手的就是一个成品。你要做的就是把它卖出去，最多再包装一下，印上你自己的 Logo。

从左到右，自己承担的工作量（上图蓝色部分）越来越少，IaaS > PaaS > SaaS。

对应软件开发，则是下面这张图（同理上一张图，蓝色部分为需要自己承担的工作量）

SaaS 是软件的开发、管理、部署都交给第三方，不需要关心技术问题，可以拿来即用。普通用户接触到的互联网服务，几乎都是 SaaS，下面是一些例子。

• 客户管理服务 Salesforce

• 团队协同服务 Google Apps

• 储存服务 Box

• 储存服务 Dropbox

• 社交服务 Facebook / Twitter / Instagram

PaaS 提供软件部署平台（runtime），抽象掉了硬件和操作系统细节，可以无缝地扩展（scaling）。开发者只需要关注自己的业务逻辑，不需要关注底层。下面这些都属于 PaaS。

• Heroku

• Google App Engine

• OpenShift

IaaS 是云服务的最底层，主要提供一些基础资源。它与 PaaS 的区别是，用户需要自己控制底层，实现基础设施的使用逻辑。下面这些都属于 IaaS。

• Amazon EC2

• Digital Ocean

• RackSpace Cloud

起因是因为 Epic 和 Apple 的官司结案了，突然想起来之前看过的一些材料，就顺手整理了这份杂文，里面的很多内容在时效性上已经比较落后了，不一定与当下完全一致，不过当个奇闻轶事读读也好啦！

一份被忽视的资料

对于外界而言，Apple 的 App Review 团队一直都显得十分神秘，直到 2019 年 CNBC 的一篇名为《Inside Apple’s team that greenlights iPhone apps for the App Store》的文章发布后，大家才对其有了一定的了解。

其中有不少特别有意思的冷知识，例如审核人员会通过 Mac 电脑访问一个叫 App Claim 的 Web 网站，批量审核应用，然后他们通常会在 iPad 上审核应用，即使这是一款 iPhone 应用。（Reviewers “claim” a batch of apps through a web portal on a Mac desktop, called App Claim. They often examine the app on an attached iPad, even if it’s an iPhone app.）

所以，我突然明白了为什么早年间，即使我们提交的是 iPhone 应用，但在拒审邮件的截图附件中，总是能看到 iPad 屏幕截图的身影，现在看来，原来如此~

不过，去年 Epic 和 Apple 的官司 又一次把 App Review 团队带到了大众的视野中。

关于这件事，IGN 上有一篇文章叫做 Epic vs. Apple Shows the Courts Were Not Prepared for the Games Industry's Obsessive Secrecy，里面提到了不少在法庭上辩论的细节，一开始我还好奇媒体是如何知道这些细节的，后来仔细阅读，才发现法庭里的很多内容其实是对外公开的，还好 IGN 的这篇文章里提供了信息的出处，好奇的我怎能错过！

• 美国政府机构在公开网站上的存档 - Epic Games, Inc. v. Apple Inc.，
• 热心网友在 box 上提供的存档 - exhibits，

其中一篇文档成功的吸引到了我，那就是 App Store 审核团队高级总监 Trystan Kosmynka 在 Epic Games vs Apple 诉讼大战时提供的关于 App Store 审核团队的证词文件。

在这些文件中，我们可以发现许多有意思的信息，首先是在开庭当天（May 3 2021 Apple Opening），Apple 提供了一些关于审核团队的数据！

来，我们看看这篇 slide 都讲了啥？

• 在 2020 年，App Store 在全球有 180W 的 App
• 一共有 15W+ 的 App 因为违反隐私规定被拒审。
• 一共有 100W+ 的 App 因为不良或者非法内容被删除或者下架。
• 一共有 200W+ 的 App 因为没有及时更新或者适配新系统而下架。
• 一共有 10W+ 的 App 因为滥用或者不必要地使用用户信息而遭到拒审。
• 一共有 50W+ 的开发者账户因为欺诈和传播非法内容被吊销。
• 一共有 500个审核专家，它们每周平均要审核 100W+ 的 App

说真，第一次看到这份数据的时候，大家还是蛮震惊的，一方面是每年拒审下架的 app 数量之多，一方面是审核团队的人数又是如此之少！

现在想想，我们被拒审好像也不足为奇了.......

上面的数据来自 May 6 2021 里 Trystan Kosmynka 的证词，这个图里我们可以看到 2019 年 16 号左右的 SLA 指数，SLA 是 Apple 内部用来衡量 App 审核效率的一个指标（如果一个 App 从审核开始发起到结束的耗时控制在 1天/2天，那么就认为达标）。

从公开的数据来看，11 月 16 日那一周，1 Day SLA 指标在 89.8%， 2 Day SLA 指标在 96.6%。

而从上面图表的下半部分来看，Apple 似乎对 1 Day SLA 的指标是要求在 50% 以上，而 2 Day SLA 的指标是控制在 90% 以上，而且你要注意到，这里是不区分工作日和周末的哦！

上面的这张图来自 May 7 2021 里 Trystan Kosmynka 的证词，从图里可以看出，应用审核团队的人员分工有很多，常规审核、新发布功能审核等；有涉及到对内容的理解，比如说版权，法律等；涉及到用户利益，比如说付费，IAP，隐私；还有开发者账户等。

关于 App Review 的审核流程

先说说广义上的审核流程，结合 May 7 2021 里 Trystan Kosmynka 的证词，我们可以看到 App Review 的审核流程会有如下 5 个阶段：

但对于开发者而言，第二部分的 Review 环节是大家更关心的部分，因为它就是大家所说的狭义上的审核流程，但是关于这个部分的细节，Apple 似乎从来没有公开过。

不过同样在 May 7 2021 里 Trystan Kosmynka 的证词中，我们终于对这个黑盒系统有了更多的了解，让我们先看一下 App Review Process 的相关 Slide。

所以从这些资料里，我们可以看到 App Store 的审核流程总共分为静态分析（Static Analysis）、动态分析（Dynamic Analysis）、MOZART 以及人工审核（Magellan）。

静态分析，包括了：

• DT App Analyer（DT应用分析器）
• App Similarity（应用相似度）
• Z Strings（Z 字符串）
• App Transparency（应用透明度）

动态分析，包括了：

• App Transparency（应用透明度）
• Mercury

至于这些东西的具体作用，在 Trystan Kosmynka 的证词里都做了一些简单的说明，感兴趣的朋友可以自行查看，我们在这里就不展开了。

除了这些，我们还可以从公开资料中了解到，Apple 还会使用一个名为 Columbus 的审核系统，通过它的介入，让 App 的审核流程变得更加高效。

在这些资料中，还介绍了如何对新旧二进制文件进行审核，以及审核后台的样子。

简单来说，在每次的审核过程中，系统都会把二进制文件的静态检查签名和动态检查签名信息合并成一个 App 特定的版本签名信息，通过对比新旧 App 的版本签名信息，来判断 App 的状态是否符合预期。

关于 App Review Guideline 的解读

在这些公开资料中，最让我涨姿势的还是 Apple 对其 App Review Guideline 的许多解读和背景故事，其中一篇资料是他们内部对于用户隐私数据（地理定位）的讨论，非常有启发性，从这点来说，我认为 Apple 确实是在真正的关心用户体验。

App Review Guideline 是 Apple 审核所有 App 的统一基准，在审核过程中的任何问题都可以在这里得到解释。它的重要性，我想不用多说，大家都是明白的。

在公开的资料中，有一份名为 《11/22/2019 iOS App Review（ERB）》特别值得反复阅读，为什么这么说？

因为这份材料是面向 ERB 的！可能有的读者还不了解 ERB 是什么意思，ERB 的全称是 Executive Review Board，即执行审核委员会，那可能又有读者在问，这个组织是干嘛的呢？

如果应用被拒绝审核，开发者可以向上申诉，申诉的审核委员会（ERB），也是对 App 是否可以上架 App Store 或被拒绝进行最后决定的机构。

如果你仔细阅读这份包含了 57 个 App 的审核资料（如下图所示），结合之前提到的 App Review Guideline，我想肯定会有不少新的启发和感悟。

拒审后的解决方案

拒审对于大多数开发者而言，都不是什么陌生的事情，而且在公开的资料中（May 6, 2021 Trystan Kosmynka），我们可以看到了 2019 年 Nov 16 这一周的相关应用审核数据，其中包含了 iOS，watchOS，tvOS，macOS 和 Testflight 这五个渠道的 Top 10 拒审原因。

除了 Apple 提供的这份数据外，我们还可以在第三方服务商的网站上查到类似的信息，比如 七麦数据 提供的这个统计列表。

总的来看，2.1 Performance: App Completeness, 2.3 Performance: Accurate Metadata，5.1.1 Legal: Data Collection & Stroge ，4.3 Design: Spam 等几个条款是开发者在审核过程中最常被拒的原因。

总结

这篇文章虽然揭开了审核团队的冰山一角，但可能也没什么重量级的干货，就当个奇闻趣事看看吧。

总之，关于应用审核，就不要想什么歪门邪道了，答应我，还是做遵纪守法的好公民吧！

这一部分的文章是我早年间参与iOS和macOS性能优化这本书翻译时的原稿, 当时的水平有限, 翻译的可能会有一些纰漏, 还请多多指教. 将文章同步到个人博客主要是为了同步和备份.

本章将通过两个具体示例来详述如何优化大型应用程序：一款以图像为核心的天气应用和 Wunderlist 3 任务管理器（译者注：一款生活实用类软件）。

优美的天气应用

几年之前，我与一家刚刚成立的柏林创业公司进行了接触，迄今为止主要业务是开发益智类应用程序，并且取得了相当优秀的成绩。他们的目标是构建一款最优美的天气应用，现在已经基本完成了 UI 设计（参见图 17.1），但是同时遇到了一些阻碍，延缓了项目的交付。

这款应用程序依赖大量图片资源，以致于经常因为内存错误而引发崩溃。此外性能问题也令人堪忧。我已经在前面几章中讲述了一些经验教训，但是最明显的一点仍然是内存警告与线程之间恼人的交互：若主线程运行内存消耗大的程序，进程会收到内存警告并处理，这将阻塞当前进程，甚至可能会被销毁，即使原则上你可以做些事情来挽救它。另一方面，如果后台线程上运行内存消耗大的程序，那么即使主线程尝试处理内存警告，但是后台线程可能仍会继续占用内存，从而导致进程被销毁。

解决方案如下：通过间断性发送消息的方式，后台线程向主线程“登记”申请内存，然后等待主线程返回的结果，特别是在分配大量内存之前。这样做的结果就是让主线程有时间对所有内存警告作出回应，并且在必要的时候停止后台线程。

更新

然而，本章所述的主要任务是对应用进行相应的更新。截至目前，iOS 设备的屏幕尺寸和分辨率数目又有所增加，并且为了同时兼容旧设备与新设备，我们需要处理新设备与旧设备之间存在的巨大功能差异。当然，设计团队可能还需要更多的动画、更逼真的图像以及更强的视差效果。

当我介入这个项目的时候，可能需要花费几分钟的时间才能够启动应用，单单高分辨率版本的图像资源本身就占用了 491 MB，并且这还不是全部的资源。为每个设备添加优化过的资源以及所缺少的图像，很容易就能让应用大小超过 1 GB，但是 Apple 仅允许 100 MB 以下的应用程序使用空中下载技术进行购买与更新（译者注：OTA Over-The-Aire 的简称，是通过移动通信（GSM或CDMA）的空中接口对SIM卡数据及应用进行远程管理的技术，可以简单理解为2G 3G 4G网络）。

所以当务之急是将资源的容量减少五分之四以上，并且还要在不增加资源的基础上支持当前所有 iOS 设备，此外还得大大缩短加载时间。我不得不承认，这似乎是个不可能完成的任务。

探索 PNG

应用初始版本使用的是 PNG 图像，尽管这些图像有着媲美照片的真实画质。我当时对这个选择已经有所质疑，但是在版本发布的前一夜再来做任何事情就真的太晚了，而且这个团队似乎也知道他们在做什么。

此外，虽然这些图像看起来与真实照片无异，但实际上是通过合成得到，而且 PNG 通常认为比 JPEG 更适合进行图像合成。因为 PNG 进行了充分的优化，它使用了 8 位 / 256 色的调色板图像来进行有损压缩，甚至可以将调色板颜色减少到 8 位以下，以为了空间分辨率而牺牲色彩分辨率。

原则上来说，牺牲色彩分辨率是一个好主意，因为人类视觉对于亮度变化的分辨要远远强于对色彩变化的分辨，但是这种做法可能会有所偏差：使用某种交互工具将原始尺寸的图像进行多次压缩，并调整相应的参数，直到图像达到最小尺寸，也就是实现一种“看起来还行”的效果。这种方法的问题在于，由于图像将会被放大显示，空间上的缺陷将会超过色彩上的缺陷。解决方案是同时“增加”颜色分辨率，但是我不知道该如何实现。

原型应用试图避免为每个设备配置多个版本的资源，这种方式也是有问题的——它对某些特定出现问题的设备保存了优化过的资源版本（实际上，这是为了将其降低到适当的分辨率上）。为了不影响现有的渲染代码，这种二次采样和保存操作是在正常加载代码之前完成的（参见图 17.2），这导致第一次启动的用户体验非常糟糕：应用会在加载屏幕停留好几分钟，不停的转圈圈，无法进行交互，并且设备会变得很烫手。

此外，iOS 的 PNG 写入代码不像外部工具那样具备相应的优化机制，因此图像将被保存为 32 位的 RGBA，显然会比原始文件要大很多，尽管图像的分辨率很低。

头脑风暴

就我而言，很显然，“至少” PNG 格式需要重新考虑是否继续使用。我的第一个想法是围绕类似金字塔 (pyramidal) 编码方案进行，或者直接使用诸如 JPEG 2000 之类的小波 (wavelet) 编码。金字塔编码方案的优点是，它通过不停提取图像的较低分辨率版本来压缩图像，并且只存储这些版本之间的差距。这意味着解压缩操作将会自动提取较低分辨率的版本，因此可以仅仅只提供一个图像文件，就可以实现多个分辨率。

不过，iOS 和 Mac OS X 对 JPEG 2000 的支持相当慢，所以使用 JPEG 2000 并不是一个好选择。还有相当多的证据表明，这种性能上的缺陷并不是没有人尝试去修复，而是被现有的格式和技术手段所制约住了。所以这种方法似乎相当令人生畏，尽管我们的需求允许使用较少层次的金字塔简单实现，也可以使用其他的压缩机制来编码这些基本图像。

我们还研究了 PNG 当中所使用的 flate 压缩的替代方法。flate 压缩是一个非常好用的通用无损压缩器，但是我们的需求并不是很广泛，而是非常具体的。例如，我们只需要压缩图像，并且比起压缩速度而言，我们更关注解压缩速度（flate 有时会平衡两者的速度）。我们看到的一个替代方案是 LZ4，它的解压缩速度比起最差压缩比的 flate 速度至少要快 10 倍。

此外，我们其实还有其他神奇的选择，比如说 Apple 的移动芯片组直接支持的预压缩 PVRTC 结构格式。该数据格式不需要 CPU 解码；它可以直接馈送到 GPU，从而得到最佳的性能。另一方面，它的压缩率和质量都很一般。我还尝试使用 MPEG 影片格式，它也有一个硬件解码器，但是在 iOS 上一次只能存在一个 MPEG，而且它很难与场景中的其他对象组合在一起。

JPEG 数据点

直至最后，我们的面前仍然摆放了很多选择，而且依旧不清楚什么是正确的选择。我们需要相关的数据，所以我开始进行试验，从最普通的 JPEG 和 PNG 图像格式开始。

毫无疑问，JPEG 格式的文件在尺寸大小方面遥遥领先，对于 491 MB 的资源来说，使用非常保守的 0.7 质量设置就能够压缩到 87 MB，并且图片质量没有明显的损失。更令人惊讶的是，Apple 推荐将 Xcode “优化过的” PNG 作为默认格式，但是 JPEG 压缩文件的解码速度明显更快，至少在我运行测试的 Mac 上是这样的。

我们决定更加深入研究 JPEG 解码，得到了更多的好消息——使用 TurboJPEG 库能够将速度额外提升 20% 到 200%。更重要的是，对于我们在第 16 章“为何绝对不要绘制缩略图”一节中提到的需求而言，CGImageSourceCreateThumbnailAtIndex() 函数变得完全无用，也就是从 JPEG 2000 当中快速提取低分辨率图像！

测量时的小错误

当然，这里我犯了一个严重错误，没有实际在设备上运行这些测试，真正运行测试的时候就出现了一个巨大的断层：性能变得更加糟糕，特别是相对于 PNG 而言，而 PNG 格式现在竟然变得更加迅速了！这种性能差异对我来说没有任何意义，因为 CPU 是非常相似的，即便设备上的速度要稍微慢一些，但是两个解编码器之间的性能差异也不应该像我们测量的那么大才对。随后我对 Independent JPEG Group 的 libjpeg 软件的其中一个版本，也就是 JPEG 的官方参考实现，发现得到了比 Apple 标准库更好的结果，事情变得棘手起来。

其原因在于，Apple 实际上在 iPhone 系统集成芯片 (SOC) 中包含了一个 JPEG 解码硬件。这个解码硬件的工作效率实际上可能比软件还要慢，但是所使用的功率要更少一些，所以即便它的工作效率较慢，Apple 仍然更加偏好它。此外使用 Mach IPC 接口与硬件通信也会产生一些性能开销。

幸运的是，事实证明这些性能开销是固定的，因为我对一些小图像进行了测量。图 17.3 至 17.5 展示了一组更具代表性的测量结果，我们对不同的尺寸和不同的二次采样设置的图像进行了测量。

对于较大的图像而言，在对更多数据进行解码的时候，固定的性能消耗将会被摊销，此时 Apple JPEG 轻松地击败了 TurboJPEG，这个替代品的性能位于第二位，而 PNG 的速度依旧慢得让人难以接受，因为 JPEG 解码器确实能够只进行部分解码来获得性能的大幅度提升。

最后，尽管小图像相对性能的下降非常显著，但是由于图像很小，绝对性能的下降并没有那么大。一个中等大小的 JPEG 所“耗费”的性能抵得上将近一百个小图像，并且如果有一个非常大的图像，那么结果就显而易见了。此外，硬件性能的下降因模型而异，我所测试的是最慢的设备之一。

所以实际上，这个结果比我们一开始用设备测试后得出的结果要好，如果其他的方案都失败了，那么我们就可以回到 libjpeg 或者使用 TurboJPEG。因此，看起来我们似乎不需要那种高精尖的技术，JPEG 能够满足我们所需的一切。

JPNG 与 JPJP

现在只剩最后一道障碍了：我们需要将许多资源组合在一起，从而形成最终的场景，并且还是用了大量的透明度设置，然而 JPEG 不支持透明度设置。幸运之神再次眷顾了我们，有人曾经遇到并解决了这个特殊问题：Nick Lockwood 提出了 JPNG 文件格式，也就是将 JPEG 和 PNG 组合成一个单独的文件，JPEG 提供颜色信息，PNG 提供 alpha 遮罩。

首先，使用 PNG 来提供 alpha 通道似乎听起来有些矛盾。没错，PNG 支持 alpha，但是我们并不会使用 alpha 值来编码图像，我们只需要编码出一个简单的灰度图，这样就与对另一个图像应用 alpha 通道的表现类似。另一方面，alpha 通道通常比图像更具备块状特性，因此 flate 压缩的效果应该也会很不错。尽管如此，实际上并没有一个很好的理由让 alpha 通道以 PNG 的形式提供，对于我们来说这同样是一个严重的限制，因为这意味着对于最高分辨率而言，必须要砍掉四分之一的数据。

相反，我们决定更新 JPNG 格式，以便它也可以使用（灰度）JPEG 图像来作为 Alpha 通道。此外，我们还会修改库的 API，以允许指定图像的分辨率/大小，并且还可以使用 CGImageSourceCreateThumbnailAtIndex() 来提取较低分辨率的图像。

优美的启动

最后，我们实现了这个看似不可能完成的任务。让这个应用保持在 100 MB 的限制之内，并且还可以支持所有的新设备，设计师对于他们可以添加新图形和动画感到十分满意。用户呢？他们非常喜欢，应用在美国和德国的 App Store 上都获得了 4.5+ 的评分，并且很多评论表示早上打开这个应用还能够驱赶瞌睡。

使用 JPEG 子集化机制的一个好处就是：即便是在非常老旧的设备上，我们仍然可以非常快速地加载这些分辨率显著降低的图像（分辨率只有之前的四分之一甚至八分之一），以便在高分辨率图片正在加载的过程中，用户仍然能够看到最终的场景。

我们能做的还有很多。首先我们并没有集成 JPEG 软解码，所有的解码都要通过硬件解码器完成。显然，从 CPU Profile 中可以看到，CPU 的利用率显著低于 100%。虽然硬件通常要更快一些，但是添加两个软件解码器似乎可以让解码吞吐量至少增加一倍，特别是如果我们还设法对图像进行排序，以便让硬件解码器优先解码较大的图像，软件解码器优先解码较小的图像。我们还可以添加一些 PVRTC 格式的图像，使用这种压缩还能够进一步提升性能，此外或许还可以从 MPEG 视频中解码某些动画序列。这种想法是尽可能多地利用可用的硬件资源，只要它们不会互相干扰即可。

但是这是之后的优化目标了。

Wunderlist 3

2013 年底，Wunderkinder 团队请我去帮忙推出 Wunderlist 3，在这期间，我们一起推出了名为 Objectice-C 客户端：Mac 和 iOS 的架构（译者注：没搞明白），它的表现格外突出，至今仍然无与伦比。这个团队以及参与的这款产品给我留下了深刻印象，。

一年半后，微软对这个团队和他们所构建的产品表现出了浓厚的兴趣，与此同时收购了这个公司，这意味着忠实的 Apple 程序员现在已被邪恶的 Redmond 帝国所雇佣了。并且还深深喜爱上了它！

Wunderlist 2

Wunderlist 2.0 版本就许多方面而言是一款非常优异的产品，大部分用户都非常喜欢，但是它的性能和稳定性仍然亟待改善。当我首次下载并启动应用的时候竟然直接闪崩了，直至最后版本稳定下来之前，依旧连续崩溃了好几次。

Mac 和 iOS 客户端的数据模型使用 Core Data 来构建，此外也用来关联 UI 组件。正如我们在第 12 章所看到的那样，对于少量数据和简单用例而言，Core Data 的表现还行，毕竟性能的要求并不高。但是在处理中等或者大量数据的时候，保持高性能就变成了极大的挑战，开发团队发现他们得创建更复杂、同时也更加脆弱的权衡措施，才能够保证 Core Data 不会由于 I/O 而阻塞主线程。

整体架构

Wunderlist 3 Objective-C 客户端的整体架构如图 17.6 所示。这个架构并没有什么特别的地方。其中包含了一个内存模型 (in-memory model)，它会在启动的时候从持久化（硬盘）存储中进行初始化。内存模型将会与 UI （双向）和后端（也是双向）保持同步。我们还会让磁盘存储与内存模型保持同步，但是由于磁盘存储对于应用而言是无法直接看见的，因此这个同步是单向访问。

然而，正是这种简单的架构才可能成就优秀的性能：通过明确界定不同子系统之间的界限，使得责任分工清晰明了。例如，模型对象和内存中数据库都不需要知道存储或者网络 I/O 中的任何内容，这样就不会有出人意料的数据交互发生。它们最多知道如何将自身转换成字典，也就是让外部代码可以将其序列化为某种持久化的数据格式。

我们用另一种方法来表示该架构，如示例 17.1 所示，这次是用代码的形式来表示的。|= 和 =|= 运算符（类似图 17.6 当中的实线箭头）表示数据流约束 (dataflow constraints)，其行为与 Excel 公式非常类似，并且可以视作永久分配 (permanent assignment)，因此它的行为与正常分配类似，只不过系统会维护它们之间的关系。

memory-model := persistence.
persistence  |= memory-model.
ui          =|= memory-model.
backend     =|= memory-model.

URI 与进程中 REST

内存模型和持久化存储的基础架构模型是 In-Process REST，这是一种适用于应用当中的 REST 架构风格。所有的实体都由标识符对象所引用，这些标识符对象则是发挥 URI (通用资源标识符，Uniform Resource Identifier) 的作用；在 Wunderlist 中，指的是 WLObjectReference 类的实例，它会将实体类型 (entity type)、容器 ID (container id) 和对象 ID (object id) 进行编码。容器 ID 是封闭对象 (enclosing object) 的 ID，比如说任务所属列表的列表 ID。并非所有对象都有明确的容器；例如，列表或者已登入用户是直接位于 URI 根结构下面的。示例 17.2 展示了用字符串 URI 表示的 WLObjectReferences 实例：

task://container/2/id/3
list://id/2/
task://container/2/
task://id/3

URI 是结构化的。例如，示例 17.2 中的第一个 URI 引用了 id 2 列表中的 id 3 对象所表示的任务。第二个 URI 表示 id 2 列表对象。第三个 URI 是一个数组，表示包含在 id 2 列表当中的所有任务。最后一个 URI 指示表示 id 为 3 的一个任务，并没有提供任何列表 id。在我们目前的实现中，这会在所有列表中搜索满足此条件的任务。

数据存储被组织成一系列对象，其行为类似于 Web 服务器，只是它们不会使用 HTTP 协议来进行通信，不过这与示例 17.3 所示的标准 Objective-C 消息协议类似。如你所见，消息会一一与 GET、PUT 和 DELETE 这几个动词相对应，唯一的区别是，我们通常传入对象数组，而非单个对象。

@protocol WLStorage <NSObject>

- (NSArray*)objectsForReference:(WLObjectReference*)ref;
- (void)removeObjectsForReference:(WLObjectReference*)ref;
- (void)setObjects:(NSArray*)new forReference:(WLObjectReference*)ref;

@end

内存存储、硬盘存储和表示 REST 后端的对象都遵循相同的协议，因此大部分的存储操作都是可以互相替换的。为了进行测试，我们可以将第二个内存存储替换为磁盘存储，或者替换为后端同步，也可以同时实现两者的功能，这样就加快了测试的速度。事实上，这个协议非常简单，这同样意味着可以相互组合。例如，我们将计算实体 (computed entities) 的匹配器 (filter) 添加到存储层次结构中，这样就可以使用相同的方式来对其进行访问了，或者也可以针对某个特定的实体，将其放到多种持久化存储当中。

我们可以独立于 WLObjectReferences 所引用的对象来执行相关的计算。例如，我们可以确定磁盘路径和后端 URL。正如我们在示例 17.2 当中所看到的那样，我们还可以剔除 URI 的最后一个部分来确定对象所属的组。

最终一致的异步数据存储

回想我们之前使用 Core Data 的经验，让数据存储保持简洁、快速是初期设计中的优先考虑事项之一。我认为我们成功做到了这一点：我们的 CTO 很喜欢在讲座中震惊听众，他这样说：我们将数据以单独的 JSON 文件形式存储在磁盘上。这种做法其实非常有效——如果您回想一下第 12 章的内容，使用 Foundation 方法来对 JSON 格式进行编码和解码是最快的，恰好 JSON 也是我们与后端通信的数据格式，因此让存储格式和后端通讯格式保持相同，已经证明对于调试而言是非常不错的方法。

我们已经证明，这种简单的机制所带来的性能提升是非常惊人的。我们的其它客户端使用了数据库，或者其他复杂的序列化格式，但是 Objective-C 客户端在性能上始终遥遥领先，特别是在处理压力测试的时候，考虑到一个理智的——呃，不，一个不理智的用户很有可能会创建很多个列表和任务。尽管从事实上来说，使用这种格式就很多方面而言存在很多不足。例如，我们可能会写入太多的小文件。然而，每当我以为某个问题需要换用更复杂的方法才能解决时（否则会很伤脑筋），但实际上最后我会发现这个问题是由一个简单的错误所引起的，并且解决起来非常简单。

数据存储之所以如此简单，完全要归功于我们的后端，它由一个松散的微服务集合所组成，可以保证不同的实体之间最终能够保持一致。这意味着我们的一致性需求并不只满足于存储的规范，因此将 YES 传递给 NSData 的 writeToFile:atomically: 方法来保证独立文件的一致性，这个做法非常有效。

所有写入到磁盘的操作都是与主线程异步的；不过，这些操作都是在一个负责写入磁盘的后台线程中同步循环执行的。主线程只会将需要保存到后台写入线程的 对象 URI，通过队列发送出去。当后台写入线程在队列中获取到特定的 URI 后，就会从内存存储中获取当前的最新条目，然后将其序列化到磁盘当中。

由于磁盘写入器总是保存当前最新版本，所以可以简单地剔除队列中重复的写入请求 URI，以合并多个写入请求。这有助于减少磁盘子系统的负载。

RESTOperation 队列

在上一节中，我提到写入请求将通过队列发送到文件写入模块当中。这个队列就是 WLRESTOperationQueue，这个实例我们在整个系统中用来异步连接代理实体 (acting entities)。可以这么说，这是让 Wunderlist 在处理网络交互和管理持久化的同时，仍然可以响应用户操作的秘密武器。

顾名思义，WLRESTOperationQueue 由一个 REST 操作队列组成，而每个操作又由一个 WLObjectReference 和一个 REST 动词（GET、PUT、DELETE）组成，该动词用于告知目标应该对引用执行何种操作。操作的含义取决于具体的目标。对于磁盘存储而言，如果收到了 PUT 就意味着要将这个由 URI 指定的对象存储到磁盘；对于 Web 接口而言，则是意味着发送 HTTP PUT 请求给后端。

可以从任意线程中来添加队列，并且队列可以维护子集的工作线程，以便为条目进行服务。队列可以选择将结果传递给指定的目标线程，这个线程与服务线程不同；比如说主线程。与 GCD 相比，让每个队列都具备单独的工作线程，可以大大减少线程的数量，以及相应的资源消耗。

WLRESTOperationQueue 对象通过自动拒绝重复条目 (entry)，来支持合并操作。要实现这个功能，最关键的一点取决于：队列当中的条目只能是引用。我们花了很多时间来证明这一点，因此 WLRESTOperationQueue 目前的版本历经了大约一年左右的完善才得以出现。

如果我们尝试使用实际对象指针的任意一种变体，都会出现不合意的结果（比如说以这个写入磁盘的示例应用为例）。

• 将可变对象写入到队列当中，并在写入之后对其进行修改，因此这种对象在保存的时候仍有可能会被修改。这是一个很糟糕的想法，如果要解决这个问题，那么就需要添加数不胜数的锁，即便如此仍可能允许进行有冲突的修改。
• 将副本发在队列当中可能意味着：每当对其进行修改，那么所有相同对象都会执行一次写入。这在高负载的情况下会导致性能严重下降，特别是您需要保证性能良好的时候。
• 清除最新添加的对象（通过 URI 的方式）意味着：只有第一条更新操作会被写入；后面执行的所有更新都会丢失，直到对象再次执行更改。
• 清除最老添加的对象，很容易导致所修改的对象永远无法写入到磁盘的情况出现。

借助 URI 队列，即便是在高负载的情况下也仅仅只意味着会有多余的更改操作累积下来，但是磁盘子系统仍会尽可能保持最高的吞吐量。到目前为止，我们已经很少遇见磁盘写入速率跟不上系统写入速率的情况，而这些由小错误引起的问题也很容易进行修复。

流畅、反应灵敏的 UI

对于 UI 而言（图 17.7），实际上我们使用了一种经典的 MVC 方法，在 Wunderlist 的架构中可以表示为 ui =|= model。在经典的 MVC 中，当 UI 准备好进行更新并需要数据时，UI 便会去模型中拉取数据，对应到 Apple 的 MVC，其特征是控制器负责将数据从模型推送到 UI 中。

让 UI 在准备就绪后，就自行完成更新其实才是 MVC 的基本准则，而这在目前流行的大部分 ViewController 编程实践中往往会被忽略，但是当在动画运行的时候，需要通过异步操作来为其添加更多数据，从而协调动画的运行，因此这个准则变得至关重要，因为尝试依赖模型推送来协调几乎是不可能实现这一点的，并且还可能会导致各种复杂解决方案的出现，例如说 FRP 和 React，但是传统的 MVC 对此就有解决方案：我们只需要通知用户界面（无需推送数据），并让其决定何时该自行更新即可。

在我们的示例中，UI 元素将由 URI 进行参数化，URI 当中包含了 UI 元素所应该展示的对象。之后，可以使用这个 URI 来发送 objectsForReference: 消息，从内存存储中获取最新的对象版本。

这个 URI 同样也可以用在更新通知当中。我们可以使用 Cocoa 最基本的 NSNotificationCenter 方法，将对应的 URI 与其一同进行参数化。随后，UI 元素可以将此 URI 与其内部维护的 URI 进行比较，以确定是否需要更新自身。

如前所述，URI 还会互相关联，因此假设有一个 URI 为 task://container/2/id/3 的任务被修改了，那么展示该列表 task://container/2 的列表视图同样也会进行更新。

我们可以使用 WLRESTOperationQueue 对象分离 UI 线程和任何可能会发生模型修改的线程。当模型对某个特定对象进行修改后，它会将该对象的 URI 发布到队列当中，并将配置为表示“模型已更改”的 NSNotification 传递到 UI 线程上的默认 NSNotificationCenter 当中。

队列的合并行为巧妙地解决了这样一个问题：我们尽可能降低每个单独更新的等待时间，同时避免在发生大量连续更改时频繁重载 UI 。此外，这种行为同样也不会丢失任何更新。

对于 UI 而言，我们实际上还需要添加一项功能：自动组合。在正常操作下，我们希望每个单独元素会立即独立进行更新。然而，随着负载的增加，这种做法变得越来越无意义。当您将数百条新列表任务发送给设备时，让每个列表都执行一遍动画效果不仅毫无意义，并且还会让用户感到非常烦人、感觉非常混乱。

自动合并的工作方法就是监视队列的深度。对于进入到队列当中的 URI 而言，随着队列越来越长，合并级别也将逐步增加，URI 后面的元素移除得也越来越多。如果将合并级别设置为默认值，那么诸如 task://container/2/id/3 之类的 URI 将原样进入到队列当中，并且合并只会影响到特定任务的更改。

如果将自动合并的合并级别设置为 1，那么就会从 URI 后面移除一个元素，仅仅只留下前面的容器：task://container/2。这会造成两种影响：一方面，当前 UI 中的整个列表会全部刷新，而不是针对某个特定任务进行更新；另一方面，这还会将列表当中所有独立的项目更新给合并在一起。因此，这就不会对列表当中的项目进行多次更新，因为我们对整个列表执行了更新。

最后，如果更新的频率仍然超出了用户界面展示的能力，那么合并级别 2 将会移除 URI 末尾的所有内容，只留下一个通用的 “UI 需要更新”的消息，并且还会将所有的 UI 更新请求合并成一个，以让 UI 自行进行刷新。

通过这种机制，我们就再也不用担心 UI 在大量更新的过程中跟不上变化，或者出现无响应的情况。除非我们引入了新的 BUG。

简评 Wunderlist

这里所展现的架构元素显然不是 Wunderlist 3 之所以性能如此强劲的全部原因。我们还有一个庞大的后端团队，为我们提供快速的 HTTP 和 WebSocket 接口，此外整个团队还进行了深入、详细的性能调查，并根据需求适当进行调整。不过，架构元素会确保审查的次数并不会很多，并且目的也十分明确，因此所做的调整都是非常微小、简单的，而不是时刻都在奋战性能问题。

我的意思是，这并不是实现高性能的唯一途径，换句话说：那些我们没有使用的技术并不是不能实现高性能。我认为，应用这些技术和基本原则，不仅可以在使用其他技术的同时实现高性能，并且还可以任意使用我们所提供的工具来直接获得出人意料的性能。优秀的性能是应用每月获取 500 万活跃用户，并且在 App Store 中获取 4.5 到 5 星评价的关键因素。

总结

在本章中，我们讨论了两个示例，通过将所有调优手段“结合在一起”，从而开发出优秀的、高性能的应用。优美天气应用是一个很极端的例子，因为它将调优目标推动到了一个非常具体的调优方向（即加载并显示大型图像集），此外还要实现一些看起来完全不可能的功能，最后还得为应用预留充足的空间。我们需要仔细分析硬件和软件的功能，并恰当调整需求，并根据需求作出适当调整，此外还需要一些来自外界的支持……我们自定义一种图像文件格式，它是另一种自定义图像格式的改版。

Wunderlist 是当代移动应用的一个典型示例，其中混杂了数据存储、实时网络访问以及 UI 的频繁更新等功能。我们将之前章节中所学到经验教训结合在了一起——例如，都要尽可能在内存中处理大部分工作，避免使用数据库引擎，无论性能是否与之相关，都尽可能使用简单、快速的存储机制。我们将第 16 章当中所述的更新机制进行了概括，将 UI 更新限制在某个架构元素当中，从而用于协调和简化应用的所有部分：网络层、数据存储、内存模型和 UI。

这两个示例都展示了如今手机的无限可能，并且最后，我们还是需要将硬件的能力推向极致，从而才能实现非凡的性能。

这一部分的文章是我早年间参与iOS和macOS性能优化这本书翻译时的原稿, 当时的水平有限, 翻译的可能会有一些纰漏, 还请多多指教. 将文章同步到个人博客主要是为了同步和备份.

实际上，图形程序设计本身就是一个完整成熟的领域，有许多值得一读的书籍，网上资料也非常丰富，所以本书不可能涵盖并详述所有知识点。比如，我们会粗略了解下 OpenGL，学习非游戏、用户端应用程序中常见的图形技巧，仅此而已。

陷阱

响应性方面，最大的陷阱之一是在主线程中执行较长或不可预测的操作。所有 I/O 都存在该问题，我们从之前章节中了解到，即使是最小的 I/O 操作也可能耗费很长时间。另一方面，单纯将这些操作放到后台线程执行，而不想办法提升 I/O 响应性，这只会更加糟糕，关于这点我们之前也见过不少了：用户可以操作所有界面，但没有任何反应，并且也没有显示旋转光标（译者：系统卡主时出现的进度指示器，俗称“风火轮”）。在这种情况下，操作放置在主线程执行更合适一些，至少主线程操作会触发系统繁忙的旋转光标，告知用户发生了什么。

对于图形来说，预先渲染所有图形资源并以位图格式进行传递是提供图形最普遍的技术之一，同时这也是最大和最明显的错误。最极端的例子就是 iPad 上一些杂志类应用程序，用 Adobe 发布工具直接发布到应用里，杂志的每一页都是预先渲染好的整页位图，同时适配横屏和竖屏。由于 I/O 是现代计算机体验中最慢的一部分，不管是使用（蜂窝数据）无线数据还是直接从硬盘读取，哪怕是固态硬盘，用户体验都差强人意。视网膜高清屏出来以后，预先渲染的位图在高清屏上看起来就会非常模糊，效果更差了。

随着高分辨率视网膜显示屏的出现，让一切都看起来像是艺术品，任何数字生成的东西都应该可以直接作为矢量图使用，除去那些直接用代码绘制的部分。而位图问题显而易见：本身太大了而且无法缩放，必须适配每个分辨率版本，不过 “像素完美” 的理念依然会经久不衰。

这个理念将一直延续下去。

iPhone 6 Plus 有 1,920×1,080 个面板，但是实际渲染是分辨率的 3 倍，即 2,208×1,242 像素，由于两个分辨率不匹配，因此像素对显示的分辨率下采样 1.15 倍。无论是通过下采样的手法（Quartz 和合适的设备会自动处理）还是单独一个步骤专门对整个渲染帧缓冲区进行下采样并不（很）重要，不管采取哪种方式，都不符合 “像素完美” 的预渲染设计理念。其中这也不重要 —— 400 dpi 的屏幕分辨率，也没人会在单个像素点上较真，用户十分喜爱 6 Plus 的屏幕。

如果必须要使用位图格式的图形，也存在多种优化技术供我们选择。即使是 Xcode 生成的 “优化过” 的 PNG 文件，也能借助这些优化技术减少文件大小以及文件加载的时间。我们将在第 17 章中详细讨论这些。

在绘图方面，最大的问题往往是过度绘制（多次绘制相同的像素）和重绘没有变化的屏幕区域。幸运的是，第 15 章介绍的那些工具将助你诊断和解决这些问题，请使用这些工具！

技巧

要获得良好的图形性能，通常意味着要从需要展示的屏幕和像素入手，进行逆向操作，而不是从更改模型作为开始并将其展示在屏幕上。

一方面，绘制过程涉及到 AppKit、UIKit 提供的脏矩形，另一方面，每当 UI 层收到改动通知都需要设置这些矩形。“过多通信导致安装缓慢” 一节包含了一个庞大的示例，展示为了实现较好的效果，在项目中需要克服的一些障碍，以及如何将性能从难以忍受的缓慢提升到几乎无法测量的快速。

大型复杂的路径一直是 Quartz 的巨大难题，由于需要计算自相交以实现抗锯齿效果，所使用的几何图形算法是分段数的二次项（检查每段上的相交点，对比其他的段）。底层算法已经改进了不少，所以这也不再是一个大问题了，但是还是要考虑路径的长度，最好是使用中等长度的路径。

不再重复绘制形状，使用 Quartz 图样设备。对渐变来说都是一样的：使用内置的内容。在绘制性能方面，CGLayer 并没有太大的帮助。自 NextStep 起图像绘制问题就没有得到改善，而 CGImage 重写了基本图形绘制部分，尽可能加快了绘制速度。不过，CGLayer 在生成 PDF 时仍具有优势，得益于保留了重复元素的向量信息。如果你打算打印或者生成 PDF 里有重复的元素，那么 CGLayer 是个好东西。

考虑到 15 章里介绍的 OpenGL 潜在的性能优势，以及现在的游戏在高帧率下呈现的超级复杂场景，使用 OpenGL 加速绘制绝对是无脑行为。虽然概念上讲得通，实际上实现类似加速绘制的行为绝对是无脑行为。苹果公司曾多次尝试在系统级上将 OpenGL 的加速机制融入 Quartz 中，据我所知，所有的尝试都以失败告终。额外的执行操作将会吃掉图形加速所获的所有好处。还有一个问题非常明显，Quartz API 的调用/返回性质，能很好的映射到 OpenGL API 上，但是不能很好的映射到实际的硬件接口上（参见第 14 章 Metal 章节里的 OpenGL 和 Metal 的讨论。）

另外一个原因是图形原语不同：Quartz 使用填充和描边的贝塞尔路径，这些路径必须经过昂贵的细分，将其转换成阴影三角形供图形硬件使用，同时开放应用程序接口暴露给外部调用。 如果形状被重复使用，那么转换成本可以被其他使用者均摊，不过接口并未真正提供该功能。

过多通信导致安装缓慢

一项调查结果出乎意料：Mac OS X 新版本下，某个安装程序按照预期的步骤执行安装数千个小文件，竟然出现了进度减慢的神秘现象。在新版本下，安装程序速度减缓了几倍，几乎降了一个数量级。I/O 速率比磁盘子系统慢了很多，CPU 的使用率可以忽略不计，所以看起来好像没什么瓶颈可以用来解释这种性能下降的情形。

节流显示

在使用了大量工具和抓耳挠腮之后，终于发现安装器提供显示了状态更新信息。它正在显示每个安装文件名称，为了确保用户有机会看到每一个文件名，每次都会刷新屏幕上的内容。这样能满足用户了解过程进度的渴望，却与 Mac OS X 图形子系统的节流机制相冲突，限制图形的更新频率，现在设置成了大约 60 Hz。试着更频繁的刷新屏幕，就能轻而易举地阻塞你的程序，正如示例 16.1 所示。

示例 16.1 在 60 Hz 下运行

import Cocoa
 class AppController: NSObject, NSApplicationDelegate {
   var mainWindow: NSWindow?
   func applicationDidFinishLaunching(n: NSNotification) {
      let window = NSWindow(contentRect: NSMakeRect(0, 0, 320, 200),
                             styleMask: NSTitledWindowMask,
                             backing: NSBackingStoreType.Buffered,
                             defer: false)
      window.orderFrontRegardless()
      self.mainWindow = window
      NSApp.activateIgnoringOtherApps(true)
      dispatch_async(dispatch_get_main_queue()) {
         for i in 1...60 {
           self.drawSomething(i)
         }
       NSApp.terminate(true)
    }
 }

func drawSomething( i:Int ) {
      let window=self.mainWindow!
      window.contentView?.lockFocus()
      NSColor.redColor().set()
      NSBezierPath.fillRect( NSMakeRect( 10,10,200,120 ))
      let labels=String(i)
      let label:NSString=labels
      NSColor.blackColor().set()
      label.drawAtPoint( CGPoint(x:20,y:20),  withAttributes:nil)
      window.contentView?.unlockFocus()
      window.flushWindow()
} }
NSApplication.sharedApplication()
let controller = AppController()
NSApp.delegate = controller
NSApp.run()

在 8 核 的 Mac Pro 上执行这段代码 600 次只花费了 10.0 秒，MacBook Pro 同样如此 ，两个系统 CPU 的空闲超过了 90%。

注意一下，Quartz 足够聪明可以分辨是否有任何绘图行为，因此只要在循环中调用 flushWindow() 就会立即得到返回结果，因为在这种情况下实际并未产生刷新行为。我们需要实际地绘制一些东西，但绘制内容并非总是不同。

使用节流显示

虽然节流显示的使用方式有很多，例如游戏里使用 OpenGL 来获得更高的刷新频率，请牢记以下要点：实际状态更新的频次可能比用户知悉的要多得多。比如，我通过 NSURLSession DataTask 的代理方法进行测试，在家用 6-MBit/s 的 DSL 光缆条件下，显示状态更新次数为每秒 273 次。

我相信用户并不关心，也不想知道每秒进行了 273 次状态更新 —— 换做我也是如此 —— 实际上我们也无法读取刷新如此频繁的字节数。就字节计数文本而言，每秒一次足矣，当然如果加快更新速率会使得进度条更加平滑，例如每秒钟刷新10次。

至此，我已经使用了三种技术来避免过高的 UI 刷新频率，其中有两种是有效的。第一种技术适合用在连续的进度监视上，比如下载或磁盘进度。使用了大约 10 Hz 的计时器来查询进度并更新显示。除了解决进度显示的平滑问题以及一些限制，该技术避免了模型→视图通信，从架构角度而言是可取的。 定时器技术的缺点是它必须独立于底层操作启动和停止。

第二种技术是批量处理更新请求，避免引入显示计时器，但不能避免 模型→视图 通信。实现批量处理更新请求的一种方式是预先缓存，然后发送更新消息，在某个点比如 0.1 秒之后及时地传递该更新消息，如在下章节示例 16.4 中展示了这种操作。

第三种技术我本以为会有效的，结果还是图样图森破了，performSelector:afterDelay: 取消了之前的请求，实际上我曾多次见过该项技术，哎，实际上没起作用，至少如果有足够的负载使间隔时间短于延迟，这样的话，能一直取消更新信息的发送直到更新停止为止。

今日安装程序和进度报告

考虑到这个特定问题是如此糟糕，你可能认为该情况很少见，甚至根本不可能发生。那你就错了—— 在 2016 年 1 月，据报道，当呈现进度条时，节点包管理器 npm 速度减慢了 50% 到 200%，微软的自动更新仍然占用了 150% 的 CPU 资源（这是在双核机器上使用 top 命令测量得到的结果），归结原因是在更新过程中开启了进度显示条。

在 OS X 10.9 和 iOS 7 中，苹果引入了 NSProgress 类和 NSProgressReporting 协议，明确支持长时间运行任务的报告进度。基本实现思路如下：让对象汇报每个活动的进度，然后将这些单独的进度汇总在一起，组成总的进度。在上世纪 90 年代末期就实现了相似的系统，干得好！

哎，谈及进度报告，苹果实际上完全失误了，或许就是熟视无睹。指示 UI 进度的推荐方法实际上就是监听 NSProgress 对象的 percentCompleted 属性。这并不能解决我们遇到的问题，还会引入 KVO 通知的问题，KVO 传递通知的线程和改变进度条状态使用的线程是同一个。

实际上，苹果公司警告过：“不要在紧密循环中更新 completedUnitCount”，看来苹果公司知悉该问题，意识到了实际上并没有解决问题。

iPhone 无法承受之重(Overwhelming an iPhone)

几年前，有人请我帮忙开发一款新闻类应用程序，管理一些类似 RSS 里的 Feed 条目，使用常见的 UITableView 进行展示。每个条目对其所处的不同状态都显示不同的 UI：尚未下载，下载了一些元数据，缩略图已接收，有无音频。另外，在下载音频数据时需要展示下载进度，这些文件可能要很久才能下载完毕。

只要我们使用一个 feed 且条目数量小于 10，就不会出现什么问题。但是一旦超过 10 个 feed 或者 30 个条目，应用程序就会遇到明显的性能问题。我们尝试了很多常见的优化措施，比如，将长时间运行的操作（如生成缩略图）放到后台线程上，避免不必要的工作，例如为每个条目的状态更改都同步到数据库中，这些措施都无济于事。

具体的症状表现为：UI 界面可能会很长一段时间僵住不动，然后才会恢复使用。应用程序第一次启动时最容易发生，因为此时正在读取、更新 feed 下的所有条目。之后启动应用程序就不太会遇到该问题了，因为数据已经缓存在应用里了。即便如此，也给用户的第一印象造成了不好的影响。

分析表明，UI 界面僵住主要是 UIKit 花时间在执行绘制代码（绘制文本、table 布局），Cell 的复用机制如期运行，创建 Cell 没有什么额外的消耗。这里也没有什么可优化的对吧？

不对！实际上问题出现在示例 16.2 的这段代码里。

示例 16.2 模型改变时通知视图代码

-(void)notifyChanged
{
    [[NSNotificationCenter defaultCenter]
               postNotificationName: @"UserStatusChanged"
               object:nil];
}

尽管这段代码看起来没什么问题，和很多 NSNotificationCenter 示例代码都相似，实际上会产生两个问题。首先，缺少之前章节讨论的更新节流（update-throttling），其次未给出具体细节：只说有些东西改变了，却没有明确指出是什么。缺少这么重要的上下文信息，UI 元素（这个例子中的 table view）收到通知后，无奈只能更新所有的 UI 元素。不仅要更新可见的元素，还要更新不可见的元素，有些甚至不在当前的界面里！

有个非常简单的方法可以解决该问题，就是在通知中指明当前的对象，幸运的是 NSNotification 可以实现该需求。示例 16.3 显示了实现的代码：

示例 16.3 模型改变时通知视图，并传递上下文

-(void)notifyChanged
{
   [[NSNotificationCenter defaultCenter]
               postNotificationName: @"UserStatusChanged"
               object:self];
}

接收通知的代码能够从通知中获取有问题的对象，看一下是否相关（属于当前的 table），接着只更新这一行。示例 16.4 的代码在之前章节所说的批量更新中，将根据上下文内容进行了单独的更新。假设 table view 只能显示一屏的 “条目”，客户端调用 -refreshItemsFromBackground:，例如，通过 NSNotification 确定该条目的索引值，然后使用该值。

示例 16.4 批量更新 table view 条目

@property (retain)  NSMutableSet  *indexesToRefresh;
-(void)refreshAccumulatedItems
{
    NSSet *items=nil;
    @synchronized(self) {
      itemIndexes=[self indexesToRefresh];
      [self setIndexesToRefresh:nil];
    }
    [tableview reloadRowsAtIndexPaths:[itemIndexes allObjects]
                        withRowAnimation:UITableViewRowAnimationNone];
}
-(void)triggerRefresh
{
  [self performSelector:@selector(refreshAccumulatedItems)
           withObject:nil afterDelay:0.2];
}
-(void)refreshItemFromBackground:item
{
  NSIndexPath* index=[self indexPathForItem:item];
  if ( index ) {
    @synchronized(self) {
      if ( !indexesToRefresh ) {
        [self setIndexesToRefresh:[NSMutableSet setWithObject:index]];
        [self performSelectorOnMainThread:@selector(triggerRefresh)
                   withObject:nil waitUntilDone:NO];
      } else {
        [indexesToRefresh addObject:index];
        } 
    }
   } 
}

批量更新代码基本上按照如下步骤执行：如果没有可供刷新的批量集合，则新建一个然后再安排刷新；如果存在，则只需要将结果添加到批量操作的队列中。启动过程也很简单 —— 获得需要更新的批量集合，清除并刷新 table view。请注意，如果发生任何事情导致这些索引失效，你将要清除当前更新批次。

一切都是假象

关于处理 UI 性能问题，我学到最重要的技巧之一就是伪造，如果你要做的事情执行速度实在太慢，你可以向用户展示一个旋转图标，告知用户你正在努力完成剩下的工作，提示用户完成进度。或者用动画效果表达。

使用动画效果掩饰延迟是非常聪明的办法，让 iPhone 看起来运行速度非常快，反应迅速。尽管硬件性能相对有限，且竞争对手推出了更高性能的硬件，更好的硬件加速处理，动画效果仍让 iPhone 保持了领先地位。

例如，打开 PDF 文件渲染第一页（或头两页）会花一些时间，然而，借助动画效果将文件从缩略图大小切换成全屏的这个过程，用户的注意力被动画效果所吸引，同时系统忙于处理打开 PDF 的工作。动画可以由 GPU 处理，所以不会占据 CPU 的资源。

图像的缩放和剪切

在上世纪 90 年代，我开发了多款 NeXT 软件，以输出设备的驱动为主，从 NeXT 彩色打印机到成本高达数万美元的高端彩色激光复印机，都可以使用我开发的软件。其中一个软件是 eXTRASLIDE（见图 16.1），可驱动宝丽来 CI-5000S 数字调色板录像机。

从工程师的角度来说，程序的核心部分是底层驱动，使用 SCSI 端口将由 Display PostScript 渲染的高清分辨率位图传送到设备上，设备往往使用自定义且缺乏文档说明的协议。

良好的性能对上面这些软件来说至关重要。就拿宝丽来录像机来说，有 4000 行分辨率，图像大小 48 M，对传送图像有实时性要求。1 GB 内存的手机看起来貌似有点不够用，但是当时我们最高端的盒子是佳能 object.station 41，32 MB 的 DRAM，100 MHz 的 486 处理器。频率钟显示此设备的 CPU 和现代 CPU 之间的差异是 10 到 20 倍，基准测试显示是 100 倍，简而言之，该设备比当今中等配置的手机要慢得多。那时候，我们还认为它“超级快”呢。

就 eXTRASLIDE 而言，还有另外一个问题：需要前端界面对原材料进行定位、缩放、剪切（见图 16.1）。小菜一碟，除了需要硬件需要花费大量的时间重绘原素材，实时重绘是无法实现的。于是，标准做法是绘制矩形轮廓辅助定位，定位后重新一次性绘制整张图片。

这时候 NSImage 就派上用场了。不管你的原素材是什么，它都能为不同的屏幕分辨率自动创建并缓存预览界面以及渲染。这样会导致一些问题，尽管类名称已经暗示和图片有关（NSBitmapImageRep 是处理位图的类），有时候人们依旧会忘记正在处理一个包装器，而不是一张图片，但在这种情况下正是我们所需要的。eXTRASLIDE 的预览图片足够小一遍满足界面交互的所需性能。不管原始图片有多大，从截图中也可能看出，预览图片非常小。

最后一个问题就是 NSImage 只会考虑屏幕的有效缓存，如果分辨率和屏幕正好匹配的话。否则，就会从原始的展示中生成缓存。哎，在缩放的时候的确会发生这样的事情，每次缩放都会导致分辨率不再匹配屏幕，因而触发重绘机制。这本是 “正确” 行为，然而反复采样缩略图会引发严重的质量问题，也意味着不可能实时缩放。

关键的技巧如图 16.2 所示，只用最初的 NSImage 缓存创建新的 NSImage 实例，在这里，NSImage 没得选，只能缩放低分辨率位图，因此可以实现实时缩放。缩放低质量缩略图没什么问题，图片在移动的时候，人眼无法分辨细节，一旦实施缩放结束（按钮松开），就切回原来的 NSImage，重新缓存新的屏幕位图。

我得到的经验教训就是，凡是交互形式的程序，只要不被抓住，就可以作弊。在这里的例子中，只要能缩放就行，哪怕是只能缩放低分辨率的位图。虽然不如缩放源文件效果好，图片在运动过程中，这两者之间的区别不是很大，也不会引人注意，客户还是很喜欢这个特性的。

缩略图绘制

在开发获奖软件 Livescribe Desktop 时，图片，特别是缩略图，再次使用了作弊手段未被发现，结果证明这样的处理是合理的。Livescribe Smartpen 使用红外摄像机精准地捕捉位置，正如你在纸上书写不规则的点图案一样。桌面应用展示并整理这些捕捉到的手写或绘制页面。

每个笔记的预览模式，应该展示缩略图，展示捕捉到的纸张背景的向量笔触，很明显这不是笔捕捉的图像。这些背景有两个问题，意识高分辨率的 PNG 图像渲染速度非常慢，包含笔触的文件格式在读取时需要执行很多初始化的工作。

如何不绘制缩略图

绘制缩略图的第一个方案，如图 16.3 所示，以 “缩略图” 为主。一张缩略图实际上就是一张从源文件中生成的小图片，我们的 Windows 客户端直接为每个页面创建了缩略图图片，保存在硬盘里。

Mac 团队认为他们应该也这样做，不过效果更好，因为 OS X 支持高质量的 PDF，苹果也引入了 CGImageSource CreateThumbnailAtIndex() 方法，专门用于从硬盘中加载缩略图。那么最可能出什么纰漏呢？

额怎么说呢，使用该方法后所有东西都出错了：因为 PDF 是一种与分辨率无关的格式，每个 PDF “缩略图” 包含了全分辨率的 PNG，绘制到 PDF 需要解压 PNG，生成 PDF 后再重新压缩。这些 PDF 由于包含了太多细节信息，因此 “缩略图” 渲染速度也很慢，为每个 PDF 生成新的线程解决进程自身执行缓慢的问题。

要尝试这个办法，需要重启机器，因为 200 个线程对 CPU 和内存的消耗会产生大量持续的交换。

如何真的不画缩略图

把 PDF 写到硬盘后再去渲染明显就是一个典型的 烂注意 TM，我们仍然坚持认为一张缩略图就是一个特定的图像，我们刚刚接受了位图在低分辨率下够用的想法。苹果公司的 ImageKit （新出的）和 IKImageBrowser View 提供了答案：快速（OpenGL 加速！）、可用的图片视图。很完美吧？

应用程序接口也非常简单，我们需要做的就是提供数据源，然后 API 返回给我们任何图片格式的图片。

哎！可惜结果和理想效果差距甚远，如图 16.4 所示：缩略图生成后，速度就会变的超级快。但是初始的加载却非常缓慢，一张一张渲染缩略图的过程简直辣眼睛。更糟糕的是，打开过程中发生的延迟导致我们无法绘制任何东西。

这也导致我们收到了亚马逊客户无爱的评论：

基本上和之前遇到的问题一样：无法获得 IKImageBrowserView 想要展示的缩略图。我们使用的是大尺寸、共享且渲染缓慢的背景图和每个数据源里的向量数据，必须要将这两者用 IKImageBrowserView 结合在一起，这自然拖慢了进程速度。

如何绘制非缩略图

庆幸的是，导致问题发生的架构给出了解决方案。不再作为原子单元和实际图片传递每张缩略图，而是使用古老的 Quartz/AppKit 绘制所有的屏幕元素，使用 ThumbView 类里的 -drawRect: 方法。

与 eXTRASLIDE 图片缩放相似，NSImage 可用于缓存已优化的、屏幕大小分辨率的 PNG 格式背景图片，每台笔记本仅需缓存一次，之后为每张缩略图绘制 NSImage 背景图。这使得绘制背景操作瞬间完成成为可能。

然而，我们还遗留一个问题需要解决：从文件格式中提取笔触数据略微有些耗时。解决方案还是有点取巧嫌疑：不再像过去那样等到所有的笔触数据都可用时才操作，而是在渲染完背景图后立即绘制所有的缩略图，就可以看见需要绘制的一些东西，即便不是最终的图片。

结果如图 16.5 所示，首先绘制所有背景图，同时检索笔触数据。在下一步中，所有的笔触数据都会在同一时间出现。

在屏幕的效果非常动态：缩略图似乎是立即出现了，感觉像是活的可以触摸的对象。原因就是缩略图立即出现然后缓慢的改变，比一个接连一个出现最终完整的缩略图的效果要好得多。该解决方案给用户一种立即响应的感觉，感觉像是正在直接操作屏幕上的项目，而不是等待计算机响应操作。

这种技术类似于苹果要求 iOS 应用程序的启动页快速响应，看似响应及时，“实则因为它出现在界面后，立即被第一个屏幕置换掉了“。

想要达到这种效果的关键在于不要将缩略图当做一个独立的单位，活用缩略图（背景图+笔触数据）的结构优势：首先，考虑到背景图绘制缓慢，所以我们一次只绘制一页，不要每个页面都绘制，然后，在等待解码笔触数据的时候可以显示这些背景图。效果对比如图 16.6 所示。

实际上我们不需要更快的图形程序或借助 OpenGL 图形程序接口。事实证明，使用 OpenGL 内部的方法（IKImageBrowserView）实现该需求时速度不增反降，不如使用 Quartz 和 AppKit 进行绘制。通常情况下，数据结构优势远远超过了 API 的消耗。

iPhone 上绘制直线

本章 “一切都是假象”一节中讨论的 Livescribe 软件还使用了另外一个方案：称之为“Paper Replay”：可以用笔记录音频和笔画，播放这段音频时，笔画的动画效果会和音频同步浮现。更具体地说，所谓的未来墨迹 (即尚未书写的笔记) 呈现灰色，随着音频播放书写过的墨迹显示绿色。该效果可以从手写文本（或图片）处找到，看起来就好像是第一次书写时那样。

对于 Mac 客户端来说，这真的是小菜一碟。直接使用 Quartz 代码绘制笔触，调用 PageView’s drawRect: 方法。对于 Paper Replay 功能，只需添加 time-from 和 time-to 参数（每一笔都有自己的时间戳），然后绘制笔触两遍：设置笔触颜色为灰色，设置 time-to 为录音中的当前时间后，绘制一遍；设置笔触颜色为绿色，设置 time-from 为录音中的当前时间后，再绘制一遍。

当我们把这段代码移植到 iPhone 上后，我们决定使用 Core Animation，也是苹果推荐使用的高效应用程序接口，毕竟我们用了动画效果。具体来说，用 CATiledLayer 支持缩放功能，CATiledLayer 内部甚至支持多线程，所以速度应该会更快。只可惜凡事都有意外：在复杂的图形上，Instruments 显示每秒只有 3-4 帧，CPU 使用率已达 100%。在动画工程中还要实现重绘，重绘命令也会占用 CPU，使得应用程序彻底瘫痪。Paper Replay 功能没法用了，更别提还会有更复杂的页面内容。

到底做错了什么？我们并非忽略了性能问题，实际上，我们所做的一切都是为了提升性能。为了提高速度，我们甚至研究了笔触的最佳长度，可是不管长度如何，性能上只提升了 10% - 20% ，实在是微不足道。于是我们查看 OpenGL，问题依然萦绕我的思绪，这个问题本不应该这么难解决的。

当然了，问题的确不难解决，我们只是被技术细节蒙蔽了双眼，却没有真正地思考问题。图 16.7 显示了 Paper Replay 的两帧，学习飞行课程的笔记——两种不同的方式输入空白区。该区域实际上需要重绘，才能让第一张图的矩形所示区域变成第二张图的样子。

笔是由手控制的实体物品，在一定的时间内移动速度是有限的，六十分之一秒内，一帧所移动的距离不可能很远。所以只有屏幕的一小部分需要在两帧之间做出改变，也只有这一小部分需要重绘。

之前一味地关注 Core Animation，从而忽视了这点。Core Animation 只允许一次替换整个 layer 的位图。AppKit 和 UIkit 的视图机制，换句话说，都允许使用 drawRect: 方法只绘制一部分区域（或多个矩形子区域），用 setNeedsDisplayInRect: 让视图中一部分矩形无效。在 iOS 中，这些矩形最终绘制写入作为整个 layer 的位图。

在了解到应该使用 UIKit 而不是 Core Animation 后，我们立即修改了代码。添加了 PageView，放到绘制代码这里，在设置时间的代码里，添加了一些程序，从一组时间中获取更改后的矩形，接着针对特定的几帧让一部分矩形无效。效果非常明显：之前只能每秒处理 3-4 帧，就到达了 CPU 的极限，现在每秒可以处理 60 帧，而 CPU 的使用率只有 2% - 3%，很大程度上独立于页面内容的复杂度。更棒的是，UI 的动画直接从 UI 界面程序，没有了被音频推出来的感觉，所以永远都不会出现音频和动画不同步的情况了。

总结

在本章，我们了解了图形性能和响应性。尽管底层绘制性能更容易测量，一直是开发者热衷讨论的话题，我觉得架构模式和特定领域的优化有更深远的影响。实际上，阻止高级优化的底层的技术限制，常常比单纯的低级优化有更深远的影响，在 model-view-controller 通信机制中更为明显，也和我们网络连接的设备更息息相关，因为我们可以快速更改 model 无需用户输入。我们会在下一章中寻找一种更容易理解的解决方案。

这一部分的文章是我早年间参与iOS和macOS性能优化这本书翻译时的原稿, 当时的水平有限, 翻译的可能会有一些纰漏, 还请多多指教. 将文章同步到个人博客主要是为了同步和备份.

正如其他领域的性能一样，如果不清楚导致缓慢的原因，优化图形通常是毫无意义的，更为重要的是你不知道刚才所做的优化对性能是有益还是有害。

在各方面而言，测量图形性能和响应性会比测量其他类型的性能更加困难。一般来说，相关的操作会涉及到一些完全封闭的系统库，未必有权限接触的进程，甚至可能是完全无法感知的硬件。

更重要的是，涉及到图像性能，你需要真正的关心单个事件的时间，而这个时间的数量级会降低到几十毫秒的水平上。在之前的章节中，我们通过测量大量的单个事件，然后进行分割以获得单个事件的的“时长”。这其实并不完全正确，因为获取的实际上是 平均 时长。

正如在第 14 章中所见的，平均数在测量图像时长中的作用非常有限：例如现在有两组数据，第一组数据中，在 1 秒的时间内，每一帧都能在保证在 16.6 ms 后刷新，第二组数据中，同样是在 1 秒的时间内，前 50 帧在 1ms 内完成刷新，而后 10 帧以每帧 90ms 的速度刷新，虽然第二组数据的平均数比第一组数据要好，但是在视觉上很难接受这样的效果，还是第一种方法在视觉上更平滑一些。

幸运的是，我们还是有解决办法的：系统和相应的工具给出了更好的解决方案，可以让开发者直观地观察到是否高效达成了目标。例如，如果你正用同样的值重绘一个像素，这个无效的操作指令就会被标注。

本章将会介绍这些特定的工具以及它们报告出来的信息在整个图形管线（graphics pipeline）中的意义，我们还会说说如何将这些工具和之前介绍的通用工具结合起来使用。

CPU 分析仪

在之前的章节中，主要介绍了基于 CPU 绘制图像的 Quartz 框架和基于硬件绘制图像 OpenGL 框架，以及这两个框架在性能上的区别。图 15.1 展示了时间分析仪（time profile）在 Quartz 示例下表现。

时间分析仪里的前 11 个条目包含了开发者自己编写的代码，但可以看到，这些代码只占用了总时间的 3.3%，最后一个开发者编写的代码条目是个闭包，这个闭包在 -[GLBenchView drawOn:inRect:] 中定义，被 -[MPWAbstractContext ingsave:] 方法调用。剩下 96.7% 的运行时间都花在了 Quartz 的函数 CGContextDrawPath() 上。这个看起来很有意思，其中 50% 都花费在了 CGSColorMaskSover ARGB8888() 里，而且很显然支持 SSE 的函数 CGSColor MaskSoverARGB8888_sse() 在这里并没起到什么作用。

事实上，你花了大量的时间绘制路径，也许算是有用的信息，但是它并没有告诉你为什么会这样。是路径太复杂了吗？还是进行了多余的绘制？或者你正在尝试的操作对系统来说太复杂了？如何是后者的话，那我们可以肯定这是不应该发生的，因为即便是 Quartz 也能在理论上以动画帧速率（animation frame rate）填充屏幕上的每个像素点。

当使用硬件加速时，问题更严重，因为现在 CPU 几乎处于闲置状态，只是在等 GPU 的结果，图 15.2 显示了基准程序在同样时间下的数据图，不过这次用的是 OpenGL 代码，用 CPU 进行绘制。

鉴于 Quartz 示例下，CPU 花费了 2176 ms，而在 OpenGL 示例下，CPU 仅仅花费了6 ms，而这6 ms 中真正用于绘图的代码只占用了 16% 的时间。

当使用硬件协助绘图时，CPU 的分析结果不会告诉你的应用程序瓶颈在哪里。

Quartz 调试

在 Mac OS X 上，有个专门用来调试图形性能的工具，叫做 Quartz Debug。图 15.3 显示了其主要菜单选项和帧率表盘。Quartz Debug 可以调试 Mac OS X 图形堆栈中的全局元素。它不仅会检测你的程序，还会检测所有正在运行的程序，包括 Quartz Debug 本身，最好在测试之前关闭或者隐藏其他正在运行的程序。

我个人觉得最有用的选项是 Flash identical screen updates，差不多在菜单的中间位置，开启该选项后，Quartz 会用红色矩形块标注屏幕中重复刷新相同内容的区域，这表示红色区块的绘制操作是多余的，应该被删除。很显然我们没有必要绘制同样的内容。

下一步是 Flash screen updates 设置，这个设置和前面说的选项的很像，不过它会在有更新的界面上闪动一个黄色矩形框。该选项能让你区分出那些刷新次数过于频繁的地方。打开该选项可能会产生一些干扰数据。

Autoflush drewing 选项会关闭合并内存的访问模式（coalescing），所以每个绘制操作都会直接展示在屏幕上（如果开启前面所说的两个选项，可能会造成闪烁），这会产生更多干扰信息，但是这样会将绘制过程划分的更细，展示的矩形越多，就越能让开发者了解是系统是如何绘制的、以及绘制过程发生了哪些改变。

最后，应该注意随着 Quartz Debug 的运行，应用程序与平常的运行状态有一点区别，绘制这些额外的矩形会造成不小的开销，你甚至可以感觉到屏幕刷新的过程中有一些延迟。开启一个 Flash 选项，然后尝试拖拽窗口，这时不仅能看到有很多的闪烁效果，拖拽的过程也会变得迟钝。关闭延迟能让性能恢复正常，但闪烁会导致肉眼难以识别屏幕上的情况。

Core Animation 工具

iOS 有一个更高级的调试工具，这也许是因为 iOS 上的图像架构更复杂，但手机的硬件性能不够强大，所以这就要求调试更加严格和精准。总之，在 iOS 上你需要这些高级调试工具！

最主要的调试工具是 Core Animation，它属于 Instruments 一部分，并非像 Quartz Debug 那样的独立工具。它和 Instruments 集成在一起非常有用，你可以将多种工具结合起来调试，并由此寻找问题的根源。

图 15.4 显示了在开发 Wunderlist 3 时，我们遇到的一个动画性能问题。

测试针对的 iPhone 5s，但在 iPhone 4s 上动画性能下降地更为明显。通过关注性能下降区域，然后切换到 CUP 调试工具上，我们可以弄清楚发生了什么 —— 一段程序反复调用 valueForKeyPath:：进行计算。回顾下第 3 章提到的，使用键值访问比直接访问或发送信息要慢得多。

简单的解决方案是日常工作不再使用 valueForKeyPath:方法，而使用循环和发送消息，这样计算速度更快。如果此路不通，还有一个办法，就是延迟计算操作，稍等片刻再计算，在后台线程上执行，而不是主线程上，或者逐步计算。

当 CPU 不再是问题

在之前的几个例子中，我们足够幸运，发现问题都出现在 CPU 上，当然这是使用了第 2 章所说的分析工具确定了问题所在。不过要是问题不在 CPU 上怎么办？iOS 的 Core Animation instrument 有一组和 Quartz Debug 工具类似的选项，除了应用广泛，也适用于一些特殊的 iPhone / iPad 环境。

正如在第 14 章中解释的那样，iOS 将最为笨重且低效的位图作为标准，虽然这样通过充分利用 GPU 来抵消性能上的文档，但这也意味着，在遇到大量数据时，数据读取效率低的缺点会格外明显。图 15.5 Core Animation 的选项表里列举出了一些虽然看起来不显眼，但有可能造成性能问题的情况，这些选项的显示结果和 Quartz Debug 的显示结果相似。

具体来说，这个调试工具支持以下功能：

• Color Blended Layers——将目标色和来源色混合意味着需要同时读取目标色值和源色值，不混合就意味着能少读取一次数据，工具会将进行混合的图层层用红色标注，不需要混合的图层用绿色标注。

• Color Hits Green and Misses Red——这里指的是支持 shouldRasterize 标识的系统缓存。通常状况下 Core Animation 会在每次更新后复制/混合整个视图层级树，当视图设置了 shouldRasterize 标识时，这就意味着它告诉 Core Animation 去缓存该整个视图的栅格图像。然而，系统并不会保留所有视图的栅格图，它是一个全局缓存，在有限的时间内缓存有限数量的位图。
• Color Copied Images——用于标注图像是否能直接被 GPU 使用，或者图像是否需要通过 CPU进行一次 复制/转换（开启选项后，系统会为需要转换的情况标注颜色）。
• Color Misaligned Image——该标记用于优化内存的访问模式。当图像边界以字（word）的方式对齐时，所有的内存只需要访问一个完整的字。当图像没有对齐时，需要读取多个字里的内容进行计算，之后 GPU 会根据计算结果对原始数据进行一些必要的处理。根据 GPU 的智能程度，额外的内存访问可能发生在每个字或者图像的边缘上。不管哪种方式，最好避免不对齐的图像，开启这个选项会标注出没有对齐的图像。
• Flash Updated Regions——这个功能与名为 Quartz Debug 的功能相似：当屏幕上的某个区域改变后，该区域会以独特的颜色进行闪烁。目前我还没有在 iOS 的调试工具中找到与 Quartz Debug 里 “flash identical regions” 功能相似的选项。
• Color OpenGL Fast Path Blue——开启改功能后，调试工具会标注出屏幕上哪些区域需要避免合成，应该直接使用 OpenGL 进行渲染。
• Color Offscreen Rendered Yellow——开启该功能后，调试工具会显示哪些区域是先进行离屏渲染，再将渲染内容复制到屏幕上的，很明显额外的复制操作会存在潜在的性能问题。

和 Quartz Debug 需要注意的一样，这些选项会全局影响设备的渲染，而不是仅仅影响正在使用 Instruments 的应用。

为了更形象的描述这些选项，让我们看一下 iPad 的 PostScript/PDF 预览界面的缩略图。图 15.6 显示了看起来正常的缩略图，没有开启颜色标识。滚动的时候会有一点延迟的感觉，所以在这里我们使用刚才所说 debug 选项来找找里面的问题。

图 15.7 显示了开启了 Color Blended Layers 选项后的缩略图。每个单独的缩略图都被 Instruments 工具标红了（受纸质书籍的打印问题，这些红色区域在书中会显示为深灰色），意味着这里使用了混合功能。由于这里完全不需要显示缩略图后的背景，所以这里不应该有 blending 才对。

首当其冲的想法就是 UIImageView 没有被设置成不透明色，所以才有了阴影，阴影需要混合。然而，将视图设置成不透明色、并移除阴影后，结果还是没什么变化，由于使用了混合，所有的缩略图仍然是红色的。

经过检查，问题的原因是缩略图本身包含一个 alpha 通道。 从视觉角度上来说，这个 alpha 通道是不需要的，因为所有的像素都是不透明的，但这并不是 GPU 或者 API 可以理解的，所以它们还是会进行混合（blending）操作，这样就会重新计算目标对象的像素。

这些缩略图是参考 PDF 文件并通过 Core Graphics 位图上下文创建的，所以解决方案是在 CGBitmapContextCreate() 方法中，使用 kCGImageAlphaNoneSkipLast，而不是 kCGImageAlphaPremultiplied Last。使用 kCGImageAlphaNone 似乎是一个显而易见的去掉透明图层的办法，但是它并会不起任何作用，如果这样设置的话，函数在运行时返回了一个错误信息。

图 15.8 显示了解决方案的结果：现在屏幕上所有的东西都成了绿色（这些颜色在纸质书中显示为浅灰色），现在没有图层混合的问题了。但是你会惊奇的发现，性能几乎没有什么提升，不过这就是争取到的最好结果了，毕竟你也没费多少精力，但是优化仍然是值得的。

最后，我还查看了没有对齐的图像（如图 15.9），在图 15.9 显示 app 中没有对齐的缩略图。由于这些图片应该居中且宽度没法控制，所以不太好解决图像对齐的问题，所以就目前来讲，该问题仍未得到优化解决。

如果图像未对齐真的会造成明显的性能问题，那么我们可以修改缩略图的生成过程，让图片的宽度取整，让其接近一个几乎 “对齐安全” 的数值，接着居中绘制实际文档的大号缩略图。然而，这需要让图片的边缘透明才能保证精准还原图片，但这又会导致图层混合问题，从而增大计算开销。当然另外一种选择是在图片还原度上妥协，用小的白色边框绘制缩略图或将其缩放到略微不同的尺寸。

我在测量什么？

我们在考虑是使用静态的图像资源，还是使用代码绘制图像。其中一个考量因素就是不同技术的性能表现如何。示例 15.10 是绘制的渐变色效果。

在示例 15.1 的代码中，想绘制渐变效果，要么用 CoreGraphics，要么加载一张预渲染渐变效果的 PNG 或 JPEG 图片文件，并测量一下每种方法的时间。

示例 15.1 尝试记录加载图像的时间和生成图像的时间

-(void)timeImageDrawingAndLoading {
    CGFloat drawnTime, PNGTime, JPGTime;
    CFTimeInterval startTime, endTime;
    startTime = CACurrentMediaTime();
    self.drawnImageView.image = [self drawnImage];
    endTime = CACurrentMediaTime();
    drawnTime += 1000*(endTime - startTime);

    //What Am I Measuring? 321
    startTime = CACurrentMediaTime();
    self.PNGImageView.image = [UIImage imageNamed:@"Image.png"];
    endTime = CACurrentMediaTime();

    PNGTime += 1000*(endTime - startTime);
    SEL flusher = NSSelectorFromString(@"_flushSharedImageCache");
    [[UIImage class] performSelector:flusher];

    startTime = CACurrentMediaTime();
    self.JPGImageView.image = [UIImage imageNamed:@"Image.jpg"];
    endTime = CACurrentMediaTime();

    JPGTime += 1000*(endTime - startTime);
    [[UIImage class] performSelector:flusher];
    NSLog(@"Drawing %f, PNG %f, JPG %f", drawnTime, PNGTime, JPGTime);
}

测量出来的时间是：绘制用了 11.1 毫秒，PNG 3.89 毫秒，JPG 0.51 毫秒，所以这是一个能够说明问题的例子，不是么？我们可以粗略地解释这些数字：正如在第 14 章中见到的，Core Animation 基于位图，所以绘制是一个额外步骤，然而图片的加载或存储可以简单的理解为是直接从后备存储器（backing storage）中获取的。

先别急着下结论！

因为这些时长是模拟器的测量结果（数值可疑），另外，JPG 的读取时间比 PNG 快了 8 倍？这有点奇怪啊。

首先，打开 Instruments，了解一下大体发生了什么，timeImageDrawing AndLoading 方法中没有图片解码，相反稍后在实际绘制这些视图时，会看到一些 PNG 的解码操作。我没有看到 JPEG 的解码过程，整个过程发生的太快了。这验证了我们对 iOS 中图片加载和解码的理解：它是一种懒加载的模式，只在万不得已才会加载/解码，比如绘图时。

一些书籍声称，当为 UIImageView 的 image 属性赋值或者 CALayer 的 image 属性赋值时，解码是会被强制执行的，不过我在实践中并没有发现这点。

在真机上运行代码得到以下结果：绘制 3.26 毫秒，PMG 67.2 毫秒，JPG 49.1 毫秒。这次，结果反转了，绘制比 PNG 解码快 20 倍，比 JPG 解码快 15 倍。然而，对该结果也令人困惑——因为在这里 iOS 实际上并没有解码图片（通过 Instrument 工具可以确认这点），那么，到底发生了什么？

如果仔细观察一下 Instruments，可以在当前的例子中，JPG、PNG 的“解码”时长是包含了各自解码器的初始时间成本，所以“加载”图片的副本可能会快很多倍：绘制 3.50 毫秒，PNG 2.54 毫秒，JPG 1.91 毫秒。但是这些并不是解码图片的真正时长，现在得到的时长只是从硬盘中读取图片元数据并用于将来解码用。

为了将在视图中绘制图像与解码过程区分出来（当然这很难区分），我们需要在位图上下文中“绘制”图像，使用此方法获得以下时长：绘制 3.41 毫秒，PNG 7.91 毫秒，JPG 8.39 毫秒。这是目前最接近的真实时间，尽管很有点小误差，我们不得不把解码和绘制时间合在了一起。尽管苹果公司声称该操作与纯解码基本上是一样的，但我们还是不能百分之百确定。

另一个异常现象是，尽管现在可以清楚地在 CPU 调试工具中追踪到 PNG 的解码时间，但还是没法追踪 JPEG 的解码时间。运行 CPU Profile Instrument 工具，打开 “Record Waiting Threads” 选项，我们可以看到 JPEG 解码位于 mach_msg_trap() 中，这意味着它在等待一个不会被 CPU 调试工具显示任何信息的进程完成任务。答案很显然是 iPhone 有一个 JPEG 的硬件解码器，使用该解码器时，不会在 CPU 上显示任何信息。

硬件解码器在处理大图片时非常快，但对于小图片而言，这个开销就比较大了，即便针对 PNG 使用相对缓慢的 zlib/flate 解压器，总体速度依然很快，而且类似 TurboJPEG 这样专门的 JPEG 库甚至可以快好几倍。

总结

本章展示了在衡量图形性能过程中会遇到各种错综复杂的情况，除了要考虑其他子系统的影响外，实际操作中的延迟也会影响测量结果。获取这些操作的平均值是无法得到有意义的结果。

然而，还是有一些测量的途径的——比如，Mark 1 eyeball 是个非常好的测量装置，特别是当它配备一个性能良好的电子秒表（带有机械按钮的那种大秒表，不是 iPhone 上的那种）时，效果更佳。当我们使用手动测量结果作为性能评估的关键指标是，我们只花费了十分之一秒就诊断出问题所在。

在下一章中，我们将关注如何解决发现的问题。

这一部分的文章是我早年间参与iOS和macOS性能优化这本书翻译时的原稿, 当时的水平有限, 翻译的可能会有一些纰漏, 还请多多指教. 将文章同步到个人博客主要是为了同步和备份.

在之前的章节中，我们已经学习了不少底层系统性能方面的知识，例如 CPU、内存和 I/O ，现在我们可以将学到的知识应用到搭建一个高性能的用户界面中。这意味着应用程序既能快速绘制用户界面，又能高效响应用户请求。

响应能力

当提及高性能的用户界面（high-performance user interface）时，通常也意味着它是一个响应式的界面，也就是说它能快速响应用户的操作。这里的快速响应到底得多快呢？一般说来，就是能多快就多快，不过我们还是设定了一些阈值来区分用户的感知程度。具体的数值请见表 14.1。

下表中最值得关注的两个阈值分别为响应用户操作的 100 毫秒和保证动画流畅所需的 60 Hz/16（2/3）毫秒，如果你不想让用户在向计算机发出指令后等待一段时间才获得反馈，而是希望让用户有一种在屏幕直接操控物体的感觉，那么这两个阈值就显得及其重要。下表提及的 25 Hz（也有说是 30 Hz）也是一个常见的阈值，举个例子来说，它可以应用在模拟电影（analog film，用模拟胶片拍摄的电影，需要进行数字化后才能在电子设备上播放）的重制过程中，如果想让整个电影画面平稳过渡的话，它还依赖模拟媒介提供的集成效果，例如运动模糊等。而对于数字屏幕上的动画，60 Hz 将成为我们的目标。

表 14.1 响应时间阈值表

请见http://www.youtube.com/watch?v=vOvQCPLkPt4. 。

相比之前看到的阈值而言，60-Hz，即 16.67 毫秒，可不是一个多么长的时间。对于一些基本的计算密集型（CPU-bound）操作来说，这个时间是没问题的，但如果你还需要在磁盘搜索上花费 7ms，那你就不得不考虑下花费如何使用剩下的时间来做点其他的事儿，更何况图形系统还要占用一些剩余的时间。

所以 60 HZ 是一个极限值了么？尽管表 14.1 的最后一项不是 60 Hz，但受限于当前的软硬件水平，60 HZ 的确是极限了。虽然 60 HZ 能够保证动画非常流畅，但实际上仍然有提升的可能性。我们举个例子，当你用光笔（pen or stylus）在屏幕上进行绘制或者写作的时候，假设笔尖移动的速度大约是 5 cm/s（大约 2 英寸/每秒），而屏幕在 60 HZ 的刷新率下，暂且认为它会以每 16.7 ms 移动 1 mm 的速度延伸，屏幕渲染出来的“印记”和光笔的笔尖之间有着明显的距离差，这会产生一种“滞后”的感觉。当你在屏幕上拖拽物体的时候，也会产生同样的效果。假如你快速地移动指针设备（手指，鼠标等设备），系统实际上是无法做到精准追踪的效果。

幸运的是，对于鼠标的光标这一类物体实在是太小了，小到以至于它快速移动时，人眼根本无法精准定位，因此它带来的滞后感不易被察觉。但是要拖拽一个比较大的物体时，人眼就能察觉到这种滞后感。在当下科技水平无法从本质上解决这一实际问题时，充分利用人类感知的极限是一种保持响应能力的常见技术手段。

软件和 API

在 Mac OS X 和 iOS 中，大部分的人机交互都由高层级的框架完成，如 iOS 上的 UIKit，Mac OS X 上的 AppKit。这些框架读取用户的输入并将其转换成事件传递到程序中，同时它们还负责绘制用户界面。图 14.1 从一个较高的视角对图形相关的 API 进行了分层。

这些高层级框架提供了大量现成的控件，如按钮（buttons）、复选框(checkboxes)、表格(tables)和文本编辑器(text editors)。除个别控件外，它们中的绝大多数不光完备性强，还拥有快速响应的能力，所以它们的性能并没有什么问题。

这些控件基于 OS X 的 NSView 类和 iOS 的 UIView，它允许用户扩展视图的层次结构。一个视图（view）表示屏幕上的一个矩形区域，可用drawRect:方法渲染，可处理用户的输入事件。这些高层级框架主要通过 Core Graphic 的 API 进行绘制方面的工作，Core Graphic 有时候也被叫做 Quartz。

另外一个与图形相关的主要 API 是 OpenGL，它主要用于 3D 图形应用中，例如一些 3D 游戏，由于这套 API 拥有对图形加速硬件的访问权限，也常常被其他的 API 所使用。除此之外，还有一些处理图片或者视频的 API，如 Core Image 和 Core Video，以及视频播放相关的 AVFoundation 或 Quick Time X，最新的框架还包括了用于 2D 游戏开发的框架 SpriteKit 和用于处理 3D 图形的高级框架 SceneKit。

在显示列表（display list）被图像系统持有且直接驱动显像管（CRT）成像的时代，保留模式（retained-mode）和即时模式（immediate-mode）的意义在于它们区分了两种不同风格的图形 API。在即时模式中，程序通过主动调用绘图 API 的方式进行渲染。而在保留模式中，程序不会主动调用绘图相关的 API ，而是通过更新 API 创建的对象这种方式来实现渲染的效果。

图 14.2 以三个几何图形为例来阐述二者之间的不同。图表上方是保留模式风格的 API，程序首先生成三个图形，这些图形会以某种数据结构或着数据库的形式被 API 所持有。如果想要改变粉色矩形的坐标，程序必须要记住该矩形，并且告诉 API 要移动该矩形。接着 API 就会担负起刷新屏幕并渲染该矩形到新的位置上的工作。图表下方是即时模式风格的 API，它没有保留模式那么复杂，它只需绘制两遍场景（scence）即可，粉色矩形一次是在旧的坐标上，一次是新的坐标上。

Quartz 和 OpenGL 这两个重要的图形 API 都是即时模式风格的 API，绘图命令可以直接发起并立即执行。虽然 OpenGL 将自己内部的 API 划分为了即时模式和保留模式，但从广义上来说，OpenGL 的 API 应该都是即时模式风格的 API。SceneKit 和 SpriteKit 属于保留模式风格的 API；你需要创建 nodes（节点）并将其添加到场景中，之后的过程中，我们只需要对节点进行操作即可。

乍一看，保留模式风格的 API 似乎更简单一些，尤其在图形对象的层级关系满足应用需求的时候。因此在许多场景中，一个简易的图形编辑器可以是这些 API 轻度封装后的产物。然而，现实中的大多数应用都有特定的应用场景和特定的数据模型，这也就是说通过业务对象模型（domain-model）和相关算法得到的图元也会缺乏共性。在这种情况下，我们可以选择继续抽象相关算法以便它能够处理不同类型的数据模型，也可以选择放弃保留模式，而投入到即时模式的怀抱中。

UIKIt/AppKit 是个混合体：视图本身是保留模式风格的 API，但是绘制的时候使用的是即时模式风格的 API， 想想 drawRect: 方法。在这种混合模式下，你可以定义视图的相关特性并在发出重新绘制视图的命令后，把视图的移动，缩放和相关变换的工作交给系统来完成，但你同样保留了灵活修改视图内容的能力。图 14.2 中的三个几何图形，既可以用三个独立的视图对象表示（保留模式），也可以用 drawRect: 方法统一绘制（即时模式）。

Core Animation 和上面的情况有点相似，我们会在后面用另外一种方式来讨论它。

Quartz 和 PostScript 图像模型

Quartz 看起来很像当今计算机环境下的产物，但它的前身可以追溯到施乐公司 Palo Alto 研究中心（PARC）的 Bravo 系统，后来面向打字机的 PostScript 页面描述语言（page description language）和 Quartz 走的很近，借助 NeXT 公司开发的视窗和绘图系统( windowing and drawing system) ，Adobe 公司的 PDF，以及阉割掉编程功能的 PostScript，Quartz 最终演变成了 Mac OS X 的 Quartz 框架。

PDF 和 Quartz 是基于 PostScript 的产物，而 PostScript 这门页面描述语言的一个特性就是它拥有精确定义的图像模型。PostScript 语言操作的对象会被定义成栅格图像（raster image），我们根据其来源将这些被操作的对象分成三种类型的图元：

1. 栅格图像
2. 路径（path），filled 类型或 stroked 类型
3. 文本

这三种图元可以进行仿射变换，任意裁剪以及着色，在之后的版本中，还可以使用渐变色或其他非常量类型的着色方式。早期图像模型的构成方式决定了在栅格化之后用画家算法（Painter’s Algorithm）着色的结果，这意味着对于某个具体的像素点而言，后添加的图像模型会最终决定其着色方式，不论这个像素上之前的图像模型是什么样子的。Quartz 和当前版本下的 PDF 使用了新的图像构成方式，这种方式具备了 alpha 混合（alpha-blending）的能力，这意味着先添加的图像模型和后添加的图像模型会共同影响最终的生成结果。抗锯齿（anti-aliasing）技术可以看做是 alpha 混合的一种变体，它是将原始图像模型的边缘和其相对应的背景色进行了混合，从而产生抗锯齿的效果。

最重要的是在这种设计模式下，每个像素的信息都可以通过图像模型获取，而不依赖具体的实现方式，苹果公司非常认同并坚持这种方式。

在图像模型中，所有的对象都会被转换为 filled 类型的路径。文本字符通过编码映射转换成字形（glyph），然后再通过字体程序变成 filled 类型的路径。stroked 类型的路径可以理解为由自身轮廓线围成的 filled 类型的路径；路径的顶点样式（cap）和拐点样式（line）也会以几何图形的形式添加进路径中。所有曲线在高分辨率下会被转换成一个个连接着的直线段，之后就是栅格处理了。

平整的栅格图像是由矩形网格组成的，所以栅格图像本身也可以像其他矩形一样进行缩放和旋转。举个例子，我们可以绘制一个编号从 0 到 255 号， 256 像素宽、1 像素高的栅格图形，它的效果与我们绘制一个灰度值介于 0 到 1 之间，共有 256 个矩形的效果一样。事实上，将图像进行栅格化就是一个渐变过程，这种渐变和我们常说的渐变有一些不同：用一个路径（clip path）描绘出需要绘制的形状，将对应的图像绘制到这个形状中。

图 14.3 用 Times Roman 字体的小写字母 a 来演示上面的内容。

注意这个转换步骤的每一步都会导致数据量的增加，有时候增长的非常显著。字母本身可以用一个字节表示，例如 ASCII 码中 97 就代表小写字母 a。字形也可以是表明某个特定字体的数字或名称。然而，字母 a 的轮廓有 3 个直线段和 34 个曲线段组成，总计 210 个浮点坐标，将曲线拟合成直线会成倍地增加坐标数量，当然这主要取决于分辨率（在当前的测试环境下会生成 484 个坐标点）。最终，网格化后的字形有 24 point 的尺寸，在 retina 屏幕下会产生大约 2 KB 的黑白栅格数据，或者带有 alpha 信息的 8 KB 的全彩色栅格数据。如果你还想使用 super-sampling 技术进行抗锯齿处理，那么栅格属性还会继续增大。

在现实生活中我们完全可以不这样做，也不应该这样做，否则文本和光栅图形的处理会非常慢。虽然精准的图像模型能够更好的还原图像本身，但这也意味着我们需要能够保存更多信息的图像模型。

OpenGL

Mac OS X 平台上的第二个基础图形 API 就是 3D OpenGL API（iOS 上也叫 OpenGL ES）。OpenGL 最早是由 Silicon Graphics 开发出来的，它是一种与语言无关的、跨平台的 3D 图形 API，但是在后来它变成了一个开源标准。远远超越了现在的 PHIGS 开源标准，而其中的原因就是 OpenGL 与 Postscript，Quartz 一样，都是即时模式风格的图形框架，相比较与 PHIGS 这种保留模式风格的图形框架，OpenGL 的使用更加简单。

OpenGL 和 Quartz 支持的图形模式和图元大不相同，OpenGL 可以通过顶点数组（vertex array）实现对多边形(polygon meshe)、折线(polyline)或点云（point cloud）使用。在 OpenGL 中，不能直接使用图像（image）进行渲染，但可以通过在物体表面覆盖纹理贴图（texture）的方式达到同样的效果。另外 OpenGL 不支持文本类型，所以它会将文本转换成多边形或者位图。

尽管绘制图像本身是即时模式的，但 OpenGL 也可以将纹理贴图或顶点数组上传到图形硬件中，以便图形硬件在之后可以多次使用。在 OpenGL 的领域内，这就是保留模式。这将保留模式与另外一种数据被逐步指定的模式区分开来。

OpenGL 有这样一个问题，它自身提供的是一种过程式（procedural）/返回式（call return）的 API，这使得 OpenGL 与更加面向批量处理的现代化图形硬件格格不入。这种格格不入体现在，看起来非常“自然”的 API 并不高效，而高效的 API 看起来非常别扭且容易出错。

Metal

针对 OpenGL 与现代化图形硬件格格不入的情况，苹果公司给出了自己的解决方案。那就是 Metal API。与 Khronos 组织的 Vulcan API 非常相似， Metal 是一个面向底层的 API。

在 Metal 的世界中，应用程序不仅管理着命令缓冲区（comman buffer），也负责将缓冲区中的指令发送到 GPU 中，这与让程序直接调用 API 中去更新状态或者绘制视图的方式不太一样。

图形硬件加速

尽管计算机图形学中的一些术语，如 “Display List（显示列表）”会让我们回想曾经还使用过向量显示器（vector display）（光束在 CRT 的作用下可以绘制出特定的线段），但事实上，现在所有的显示器都是栅格显示器。栅格显示器定义由图像元素（像素）组成的矩形网格，这就像栅格图像和原始图像的关系。

虽然现代固态显示器经历了诸如 LCD、OLED、等离子屏幕等技术的发展，但最终显示的像素矩阵仍然是由硬件预设：这也就是说在硬件上的每一个独立元素会对应着帧缓冲区（frame buffer）的每一个元素。

针对前面所说的情况，即使考虑到视网膜（retina）屏幕的存在。我们需要提供的像素数量也可以说是相对稳定的，iPhone 屏幕的像素数量在七十万到二百万之间，iPad 屏幕需要的像素数量接近三百万，iPad Pro 或者笔记本电脑的像素数量接近五百万。因此无论应用程序多么复杂，只要在每次刷新的过程中能够处理这么多的像素数，就代表你可以改变整个屏幕的内容。在大 O 表示法中，它的复杂度是 O(k)。

虽然像素的数量是一个常量，我们从算法复杂度的角度上来说可以忽略它的存在，但由于像素的数量非常大，在实际的计算过程中我们还是无法完全忽视它。大多数情况下，绘制图形是当今非服务器型（non-server）计算机中计算量最大的任务。

随着时间的推移，市面上出现了许多能够增强图形计算的硬件架构，最常见的几种如图 14.4 所示。架构（1）中没有任何额外的硬件支持，CPU 在内存中进行绘制，而且内存还会被当做用于刷新屏幕的帧缓冲器。

CPU 绘图模型（CPU-drawing model）的优点是简单通用。从 Xerox Alto 到 Apple II，以及早期的 Macintosh 和 NeXT 机器，都使用了这个模型。Quartz 就是使用 CPU 绘图模型的一个例子 ，即 Quartz 操作 CPU 在内存中进行绘制。

从几何计算到绘制像素中,图形处理器（graphics processing units, GPUs）可以在绘图的各个过程中发挥作用。在架构（2）中，独立出来的 GPU 和 CPU 一样，都可以直接访问内存，这种架构在二十世纪八九十年代的家用电脑中非常普遍，不过现在已被弃用。

如今，图形硬件的架构大体可以分为两类，一种是架构（3）中的独立显卡模式，GPU 配有独立的显存（VRAM）；另一种是架构（4）中的集成显卡模式，GPU 和 CPU 在同一个芯片上，通过公用总接线口访问同样的 RAM。

特定硬件协助通用硬件更好的完成工作，这种模式似乎看起来有点像历史的重演，但随着这种特定硬件的普及，现在的 GPU 还可以用在 OpenCL 的计算中。例如英特尔的 “Larrabee” 显卡由大量的通用 x86 内核组成。最终，集成显卡的架构会越来越像最初的 CPU 配置，可以看做是前者的一种变体。

尽管这些架构看起来大同小异，但在性能上还是存在不小的差异。举个例子，如图 14.5 所示，我在 2D 平面下绘制了许多三角形进行测试，测试设备是一台 13 英寸、拥有视网膜显示屏、英特尔 HD Graphics 4000 集成显卡的 MacBook Pro。

首先我尝试用 OpenGL 进行实验，显而易见，我们将用到图形硬件，详情见示例 14.1

示例 14.1 用 OpenGL 进行三角形绘制的基准测试代码

-(void)drawRect:(NSRect)dirtyRect
{
    int iterations=10000;
    glClearColor(1.0, 0.5, 0.5, 0.5);
    glEnable (GL_BLEND);
    glBlendFunc (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
    glPushMatrix();
    glScalef(0.4, 0.4, 1.0);
    for (int i=0;i<iterations;i++) {
        float a = -0.5 + (float)i / (float)iterations;
        glColor4f(1.0f, 0.85f, 0.35f + a,0.4);
        glBegin(GL_POLYGON);
        {
            a*=2;
            glVertex3f(  0.0 + a,  0.6, 0.0);
            glVertex3f( -0.2 + a, -0.3, 0.0);
            glVertex3f(  0.2 + a , -0.3 ,0.0);
            glVertex3f(  0.0 + a,  0.6, 0.0);
}
glEnd(); }
    glPopMatrix();
    glFinish();
}

在执行效率上，示例 14.1 里 OpenGL 的代码比示例 14.2 里 Quartz 的代码快了十多倍，我在一台 2007 年产，拥有独立显卡的 Mac Pro 上看到了明显的对比结果。

示例 14.2 用 Quartz 进行三角形绘制的基准测试代码

-(void)drawRect:(NSRect)dirtyRect
{
  int iterations=10000;
  CGContextRef context=[[NSGraphicsContext currentContext]
  graphicsPort];
  CGContextSetRGBFillColor(context, 1.0,0.5,0.5,1.0 );
  CGContextAddRect( context, dirtyRect);
  CGContextFillPath( context );
  CGContextScaleCTM( context, [self frame].size.width,
  [self frame].size.height );
  CGContextTranslateCTM( context, 0.25 , 0.5);
  CGContextScaleCTM( context,0.2, 0.2);
  
  for (int i=0;i<iterations;i++) {
    float a =  (float)i / (float)iterations;
    CGContextSetRGBFillColor(context, 1.0f, 0.85f, 0.35f + a,0.4);
    a*=2;
    CGContextMoveToPoint( context, 0.0 + a,  0.6);
    CGContextAddLineToPoint( context, -0.2 + a, -0.3);
    CGContextAddLineToPoint( context, 0.2 + a , -0.3);
    CGContextClosePath(context);
    CGContextFillPath( context );
    } 
}

在使用 Quartz 时，CPU 已经达到了百分之百的利用率，而在使用 OpenGL 时，将对 GPU 操作的指令传递到命令缓冲器（command buffer）后，CPU 就空闲下来，等待这些命令执行完毕。上面两种情况都符合低功耗 CPU 的标准。

GPU 不仅在架构上拥有一定的优势，它还可以在图形计算中充分发挥自身并行计算的能力，这是以芯片上有大量的晶体管为前提做保障的。虽然 CPU 也有相似的晶体管数量，但是 CPU 却并不具备相同的并行能力。

所以，相比于 CPU 设计者需要采取更加精密的方案才能让 CPU 在执行大量串性指令的时候得到小幅的性能提升，而利用额外的硬件资源就会让整体性能的提升近似于线性增长，例如让 GPU 分担一部分的计算量。GPU 和 CPU 在处理串行指令上的区别是造成它两性能差距的主要原因之一（在适当的计算负载下），但是 GPU 的性能提升曲线更为陡峭，意味着 CPU 和 GPU 的性能差距每年都会扩大。

从 Quartz 到 Core Animation

Mac OS X 和 iOS 的图像 API 最开始只有基于 CPU 渲染的 Quartz，随后 Quartz Extreme，Quartz GL，以及 Core Animation 等图像框架逐渐加入到这个大家庭中。驱动这些 API 演变的不只是基于 OpenGL 的游戏，还有充分利用现代 GPU 潜能进行系统级别图形渲染的目标。

让 Quartz 利用 GPU 进行绘制的最直接方式就是将 Quartz 的图元映射为 GPU 的命令。这个方案的问题在于图形硬件实现了与 OpenGL 兼容的图元，而 OpenGL 的图元与 Quartz 的图元并不兼容。OpenGL 并没有 filled path 类型的图元；它只有三角形或四边形组成的多边形网络，并没有曲线的概念，与 stroke path 类型的图元相对应的是折线。尽管这种映射是可行的，例如我们将 filled path 转换为多边形，但这种转换的代价相当大。另外，OpenGL 对渲染模型的定义非常松散（loosely），也就是说，这意味着硬件在解释命令方面有很大的回旋余地。这种松散的特性不仅与 Quartz 严格定义的成像模型冲突，也和苹果公司对图形质量的要求相冲突。

然而，有一个图元可以很容易的进行转换，那就是栅格图像（raster image）。有一个名为窗口管理者（Window Mnanager）的隐藏子系统会处理栅格图像，它允许不同进程所拥有的窗口对象可以与单个物理屏幕进行映射，这样每个进程可以只关注自己的窗口对象，无需关注其他进程的操作。

由于窗口管理者的存在，不管是即时模式还是保留模式，Mac OS X 上的每个图形 API 最后都变成了保留模式的 API，具有窗口位图和保留状态，具备保留模式 API 的所有优势：窗口可以随意移动，移动的过程可视化，完全由 Window Manager 控制。这和之前的视窗系统（windowing systems）不同，也不像是 AppKit 或 UIKit 中的视图层级结构，无需客户端代码来重绘显示的部分，因此即使进程不响应，窗口的操作总是非常平滑的。

在 Mac OS X 10.2 引入了 Quartz Extreme 库，这个库为系统添加了一些图形硬件加速的能力。系统中的每个窗口都变成了 OpenGL 里的矩形，窗口的内容（由 Quartz 或其他图形 API 提供）都变成了 OpenGL 的纹理，这些纹理被映射到了相应的矩形中。每个窗口的内容都由合适的 API 进行绘制，然后再使用 OpenGL 和图形硬件将内容整合到位图窗口（bitmap window）中。

这种改变不仅更好地利用了显卡的性能，对于许多操作而言，也完全消除了 CPU 的负载：为了移动窗口，视窗管理者（window server）只需改变矩形的坐标，想要将窗口置前或置后，只需调整矩形的 z 值。

Core Animation 将这种架构从 Window Server 引入到客户端程序中，每个 CALayer 不再是绘制到一个共享的后台存储(shared backing store)里，而是维护自己的栅格图像，然后通过硬件支持的单独进程（iOS 上的渲染服务器）将这些图像组合在一起。其实，每个 CALayer 就像是 Quartz Extreme 中的窗口，我们可以改变 CALayer 的位置、透明度和旋转等属性，通过操作 CALayer 映射的 OpenGL 图元的几何形状，我们也可以将实际的位图组合加载到图形硬件中。

图 14.6 展示了从 Window Server，扩展了 Quartz Extreme 的 Window Server，到 Core Animation 的发展过程。如您所见，硬件加速的增长和图形架构中后置缓冲区（backing buffer）的增长相对应。在图形资源极端的情况下，除了解码这些资源外，根本就没有软件渲染；整个管道的其余部分都是硬件加速的。所谓的开销就是内存，资源的分辨率，以及图片资源解码所需的时间，这可能也是最重要的。

就像独立 Window Server 进程能够让窗口的操作平滑过渡一样，这种架构也可以在任意的客户端达到动画运行平滑的效果。一旦设置完所有的图层，动画就会独立于调用程序而运行，它会在一个单独的进程中执行，并且能够得到硬件的支持。

这是一种极其不明显的性能优化方法，因为该方法的基础是处理最宝贵的图元，即栅格图像。栅格图像使用了大量的内存和内存带宽，并用于最后的图像合成。在其他条件相同的情况下，Core Animation 的架构会导致速度变慢，但是实际上其他的条件不可能相同，因为这些操作可以从图形硬件中获得不少好处。

另外，我们在简单性和相应的可预测性上获得了收益，使得操作可以单独执行，只需给图形硬件发送指令流即可。

大大减少了 CPU 的工作，将不同的层复合在一起，为这些组合创建动画空间。实际上动画由独立的进程控制，在高性能的 GPU 上执行，这意味着比起客户端程序，该系统可以保证更高的平滑度和性能。

性能保证了动画可以成为用户体验的核心，除了能够让用户体验更加“立体”和真实之外，动画还能极大地提高感知响应性。

如果用户的操作触发了一个动画，即使系统没有给出最终的结果，用户也会认为这个应用是具有响应性的。只要找到合适的动画效果，这个动画所花费的时间都可用于处理用户的操作。

总结

在本章中，我们主要了解了应用程序响应用户操作的基本心理学，学习了图形编程的特点和需要权衡的问题，接着我们还了解了图形硬件和 Mac OS X 以及之后 iOS 的图像 API 的协同进化史。

这种协同进化给我们留下了许多的关于图形编程的方法和需要权衡的地方，我们将在后面的章节进行详细的探讨。

这篇文章是我早年在美团技术博客上发布的一篇文章, 部分内容可能已经过时, 请开发者注意. 将文章同步到个人博客主要是为了同步和备份.

TL;DR

文章涉及面广，篇幅长，阅读完需要耗费一定的时间与精力，如果你带有较为明确的阅读目的，可以参考以下建议完成阅读：

• 如果你对预编译的理论知识已经了解，可以直接从【原来它是这样的】的章节开始进行阅读，这会让你对预编译有一个更直观的了解。
• 如果你对 search path 的工作机制感兴趣，可以直接【关于第一个问题】的章节阅读，这会让你更深刻，更全面的了解到它们的运作机制，
• 如果您对 Xcode Phases 里的 Header 的设置感到迷惑，可以直接从【揭开 Public，Private，Project 的真实面目】阅读，这会让你理解为什么说 Private 并不是真正的私有头文件
• 如果你想了解如何通过 hmap 技术提升编译速度，可以从关于【基于 hmap 优化 Search Path 的策略】的章节开始阅读，这会给你提供一种新的编译加速思路。
• 如果你想了解如何通过 VFS 技术进行 Swift 产物的构建，可以从 【关于第二个问题】开始阅读，这会让你理解如何用另外一种提升构建 Swift 产物的效率。
• 如果你想了解 Swift 和 Objective-C 是如何找寻方法声明的，可以从 【Swift 来了】的章节阅读，这会让你从原理上理解混编的核心思路和解决方案。

概述

随着 Swift 的发展，国内的技术社区出现了一些关于如何实现 Swift 与 Objective-C 混编的文章，这些文章的主要内容还是围绕着指导开发者进行各种操作来实现混编的效果，例如在 Build Setting 中开启某个选项，在 podspec 中增加某个字段，鲜有文章对这些操作背后的工作机制做剖析，大部分核心概念也都是一笔带过。

正是因为这种现状，很多开发者在面对与预期不符的行为时，又或者各种奇怪报错时，会无从下手，而这也是由于对其工作原理不够了解所导致的。

笔者自身在美团平台负责 CI/CD 相关的工作，这其中也包含了 Objective-C 与 Swift 混编的内容，出于让更多开发者能够进一步理解混编工作机制的目的，笔者编写了这篇技术文章。

该文章从预编译的基础知识入手，由浅至深的介绍了 Objective-C 和 Swift 的工作机制，并通过这些机制来解释混编项目中使用到的技术和各种参数的作用，由此来指导开发者如何进行混编。

好了废话不多说，我们开始吧！

预编译知识指北

#import 的机制和缺点

在我们使用某些系统组件的时候，我们通常会写出如下形式的代码：

#import <UIKit/UIKit.h>

#import 其实是 #include 语法的微小创新，它们在本质上还是十分接近的。#include 做的事情其实就是简单的复制粘贴，将目标 .h 文件中的内容一字不落地拷贝到当前文件中，并替换掉这句 #include，而 #import 实质上做的事情和 #include 是一样的，只不过它还多了一个能够避免头文件重复引用的能力而已。

为了更好的理解后面的内容，我们这里需要展开说一下它到底是如何运行的？

从最直观的角度来看：

假设在 MyApp.m 文件中，我们 #import 了 iAd.h 文件，编译器解析此文件后，开始寻找 iAd 包含的内容（ADInterstitialAd.h，ADBannerView.h），及这些内容包含的子内容（UIKit.h，UIController.h，UIView.h，UIResponder.h），并依次递归下去，最后，你会发现 #import <iAd/iAd.h> 这段代码变成了对不同 SDK 的头文件依赖。

如果你觉得听起来有点费劲，或者似懂非懂，我们这里可以举一个更加详细的例子，不过请记住，对于 C 语言的预处理器而言， #import 就是一种特殊的复制粘贴。

结合前面提到的内容，在 AppDelegate 中添加 iAd.h：

#import <iAd/iAd.h>
@implementation AppDelegate
//...
@end

然后编译器会开始查找 iAd/iAd.h 到底是哪个文件且包含何种内容，假设它的内容如下：

/* iAd/iAd.h */
#import <iAd/ADBannerView.h>
#import <iAd/ADBannerView_Deprecated.h>
#import <iAd/ADInterstitialAd.h>

在找到上面的内容后，编译器将其复制粘贴到 AppDelegate 中：

#import <iAd/ADBannerView.h>
#import <iAd/ADBannerView_Deprecated.h>
#import <iAd/ADInterstitialAd.h>

@implementation AppDelegate
//...
@end

现在，编译器发现文件里有 3 个 #import 语句 了，那么就需要继续寻找这些文件及其相应的内容，假设 ADBannerView.h 的内容如下：

/* iAd/ADBannerView.h */
@interface ADBannerView : UIView
@property (nonatomic, readonly) ADAdType adType;

- (id)initWithAdType:(ADAdType)type

/* ... */
@end

那么编译器会继续将其内容复制粘贴到 AppDelegate 中，最终变成如下的样子：

@interface ADBannerView : UIView
@property (nonatomic, readonly) ADAdType adType;

- (id)initWithAdType:(ADAdType)type

/* ... */
@end
#import <iAd/ADBannerView_Deprecated.h>
#import <iAd/ADInterstitialAd.h>

@implementation AppDelegate
//...
@end

这样的操作会一直持续到整个文件中所有 #import 指向的内容被替换掉，这也意味着 .m 文件最终将变得极其的冗长。

虽然这种机制看起来是可行的，但它有两个比较明显的问题：健壮性和拓展性。

健壮性

首先这种编译模型会导致代码的健壮性变差！

这里我们继续采用之前的例子，在 AppDelegate 中定义 readonly 为 0x01，而且这个定义的声明在 #import 语句之前，那么此时又会发生什么事情呢？

编译器同样会进行刚才的那些复制粘贴操作，但可怕的是，你会发现那些在属性声明中的 readonly 也变成了 0x01，而这会触发编译器报错！

@interface ADBannerView : UIView
@property (nonatomic, 0x01) ADAdType adType;

- (id)initWithAdType:(ADAdType)type

/* ... */
@end

@implementation AppDelegate
//...
@end

面对这种错误，你可能会说它是开发者自己的问题。

确实，通常我们都会在声明宏的时候带上固定的前缀来进行区分。但生活里总是有一些意外，不是么？

假设某个人没有遵守这种规则，那么在不同的引入顺序下，你可能会得到不同的结果，对于这种错误的排查，还是挺闹心的，不过这还不是最闹心的，因为还有动态宏的存在，心塞 ing。

所以这种靠遵守约定来规避问题的解决方案，并不能从根本上解决问题，这也从侧面反应了编译模型的健壮性是相对较差的。

拓展性

说完了健壮性的问题，我们来看看拓展性的问题。

Apple 公司对它们的 Mail App 做过一个分析，下图是 Mail 这个项目里所有 .m 文件的排序，横轴是文件编号排序，纵轴是文件大小。

可以看到这些由业务代码构成的文件大小的分布区间很广泛，最小可能有几 kb，最大的能有 200+ kb，但总的来说，可能 90% 的代码都在 50kb 这个数量级之下，甚至更少。

如果我们往该项目的某个核心文件（核心文件是指其他文件可能都需要依赖的文件）里添加了一个对 iAd.h 文件的引用，对其他文件意味着什么呢？

这意味着其他文件也会把 iAd.h 里包含的东西纳入进来，当然，好消息是，iAd 这个 SDK 自身只有 25KB 左右的大小。

但你得知道 iAd 还会依赖 UIKit 这样的组件，这可是个 400KB+ 的大家伙

所以，怎么说呢？

在 Mail App 里的所有代码都需要先涵盖这将近 425KB 的头文件内容，即使你的代码只有一行 hello world。

如果你认为这已经让人很沮丧的话，那还有更打击你的消息，因为 UIKit 相比于 macOS 上的 Cocoa 系列大礼包，真的小太多了，Cocoa 系列大礼包可是 UIKit 的 29 倍……

所以如果将这个数据放到上面的图表中，你会发现真正的业务代码在 file size 轴上的比重真的太微不足道了。

所以这就是拓展性差带来的问题之一！

很明显，我们不可能用这样的方式引入代码，假设你有 M 个源文件且每个文件会引入 N 个头文件，按照刚才的解释，编译它们的时间就会是 M * N，这是非常可怕的！

PCH(PreCompiled Header)是一把双刃剑

为了优化前面提到的问题，一种折中的技术方案诞生了，它就是 PreCompiled Header。

我们经常可以看到某些组件的头文件会频繁的出现，例如 UIKit，而这很容易让人联想到一个优化点，我们是不是可以通过某种手段，避免重复编译相同的内容呢？

而这就是 PCH 为预编译流程带来的改进点！

它的大体原理就是，在我们编译任意 .m 文件前, 编译器会先对 PCH 里的内容进行预编译，将其变为一种二进制的中间格式缓存起来，便于后续的使用。当开始编译 .m 文件时，如果需要 PCH 里已经编译过的内容，直接读取即可，无须再次编译。

虽然这种技术有一定的优势，但实际应用起来，还存在不少的问题。

首先，它的维护是有一定的成本的，对于大部分历史包袱沉重的组件来说，将项目中的引用关系梳理清楚就十分麻烦，而要在此基础上梳理出合理的 PCH 内容就更加麻烦，同时随着版本的不断迭代，哪些头文件需要移出 PCH，哪些头文件需要移进 PCH 将会变得越来越麻烦。

其次，PCH 会引发命名空间被污染的问题，因为 PCH 引入的头文件会出现在你代码中的每一处，而这可能会是多于的操作，比如 iAd 应当出现在一些与广告相关的代码中，它完全没必要出现在帮助相关的代码中（也就是与广告无关的逻辑），可是当你把它放到 PCH 中，就意味组件里的所有地方都会引入 iAd 的代码，包括帮助页面，这可能并不是我们想要的结果！

所以 PCH 并不是一个完美的解决方案，它能在某些场景下提升编译速度，但也有缺陷！

Clang Module 的来临

为了解决前面提到的问题，Clang 提出了 module 的概念，关于它的介绍可以在 Clang 官网 上找到。

简单来说，你可以把它理解为一种对组件的描述，包含了对接口（API）和实现（dylib/a）的描述，同时 module 的产物是被独立编译出来的，不同的 module 之间是不会影响的。

在实际编译之时，编译器会创建一个全新的空间，用它来存放已经编译过的 module 产物。如果在编译的文件中引用到某个 module 的话，系统将优先在这个列表内查找是否存在对应的中间产物，如果能找到，则说明该文件已经被编译过，则直接使用该中间产物，如果没找到，则把引用到的头文件进行编译，并将产物添加到相应的空间中以备重复使用。

在这种编译模型下，被引用到的 module 只会被编译一次，且在运行过程中不会相互影响，这从根本上解决了健壮性和拓展性的问题。

module 的使用并不麻烦，同样是引用 iAd 这个组件，你只需要这样写即可。

@import iAd;

在使用层面上，这将等价于以前的 #import <iAd/iAd.h> 语句，但是会使用 clang module 的特性加载整个 iAd 组件。如果只想引入特定文件（比如 ADBannerView.h），原先的写法是 #import <iAd/ADBannerView.h.h>，现在可以写成：

@import iAd.ADBannerView;

通过这种写法会将 iAd 这个组件的 API 导入到我们的应用中，同时这种写法也更符合语义化（semanitc import）。

虽然这种引入方式和之前的写法区别不大，但它们在本质上还是有很大程度的不同，Module 不会“复制粘贴”头文件里的内容，也不会让 @import 所暴露的 API 被开发者本地的上下文篡改，例如前面提到的 #define readonly 0x01。

此时，如果你觉得前面关于 clang module 的描述还是太抽象，我们可以再进一步去探究它工作原理， 而这就会引入一个新的概念 – modulemap。

不论怎样，module 只是一个对组件的抽象描述罢了，而 modulemap 则是这个描述的具体呈现，它对框架内的所有文件进行了结构化的描述，下面是 UIKit 的 modulemap 文件

framework module UIKit {
  umbrella header "UIKit.h"
  module * {export *}
  link framework "UIKit"
}

这个 module 定义了组件的 umbrella header 文件（UIKit.h），需要导出的子 module（所有），以及需要 link 的框架名称（UIKit），正是通过这个文件，让编译器了解到 Module 的逻辑结构与头文件结构的关联方式！

可能又有人会好奇，为什么我从来没看到过 @import 的写法呢?

这是因为 Xcode 的编译器能够将符合某种格式的 #import 语句自动转换成 module 识别的 @import 语句，从而避免了开发者的手动修改。

唯一需要开发者完成的就是开启相关的编译选项。

对于上面的编译选项，需要开发者注意的是:

Apple Clang - Language - Modules 里 Enable Module 选项是指引用系统库的的时候，是否采用 module 的形式。

而 Packaing 里的 Defines Module 是指开发者编写的组件是否采用 module 的形式。

说了这么多，我想你应该对 #import， pch， @import 有了一定的概念。当然，如果我们深究下去，可能还会有如下的疑问：

• 对于未开启 clang module 特性的组件，clang 是通过怎样的机制查找到头文件的呢？在查找系统头文件和非系统头文件的过程中，有什么区别么？
• 对于已开启 clang module 特性的组件，clang 是如何决定编译当下组件的 module 呢？另外构建的细节又是怎样的，以及如何查找这些 module 的？还有查找系统的 module 和非系统的 module 有什么区别么？

为了解答这些问题，我们不妨先动手实践一下，看看上面的理论知识在现实中的样子。

原来它是这样的

在前面的章节中，我们将重点放在了原理上的介绍，而在在这个章节中，我们将动手看看这些预编译环节的实际样子。

#import 的样子

假设我们的源码样式如下：

#import "SQViewController.h"
#import <SQPod/ClassA.h>

@interface SQViewController ()
@end

@implementation SQViewController
- (void)viewDidLoad {
    [super viewDidLoad];
    ClassA *a = [ClassA new];
    NSLog(@"%@", a);
}

- (void)didReceiveMemoryWarning {
    [super didReceiveMemoryWarning];
}
@end

想要查看代码预编译后的样子，我们可以在 Navigate to Related Items 按钮中找到 Preprocess 选项

既然知道了如何查看预编译后的样子，我们不妨看看代码在使用 #import, PCH 和 @import 后，到底会变成什么样子？

这里我们假设被引入的头文件，即 ClassA 中的内如如下：

@interface ClassA : NSObject
@property (nonatomic, strong) NSString *name;
- (void)sayHello;
@end

通过 preprocess 可以看到代码大致如下，这里为了方便展示，将无用代码进行了删除。这里记得要将 Build Setting 中 Packaging 的 Define Module 设置为 NO，因为其默认值为 YES，而这会导致我们开启 clang module 特性。

@import UIKit;
@interface SQViewController : UIViewController
@end

@interface ClassA : NSObject
@property (nonatomic, strong) NSString *name;
- (void)sayHello;
@end

@interface SQViewController ()
@end

@implementation SQViewController
- (void)viewDidLoad {
    [super viewDidLoad];
    ClassA *a = [ClassA new];
    NSLog(@"%@", a);
}

- (void)didReceiveMemoryWarning {
    [super didReceiveMemoryWarning];
}
@end

这么一看，#import 的作用还就真的是个 copy & write。

pch 的真容

对于 CocoaPods 默认创建的组件，一般都会关闭 PCH 的相关功能，例如笔者创建的 SQPod 组件，它的 Precompile Prefix Header 功能默认值为 NO。

为了查看预编译的效果，我们将 Precompile Prefix Header 的值改为 YES，并编译整个项目，通过查看 build log，我们可以发现相比于 NO 的状态，在编译的过程中，增加了一个步骤，即 Precompile SQPod-Prefix.pch 的步骤。

通过查看这个命令的 -o 参数，我们可以知道其产物是名为 SQPod-Prefix.pch.gch 的文件

这个文件就是 PCH 预编译后的产物，同时在编译真正的代码时，会通过 -include 参数将其引入

又见 clang module

在开启 Define Module 后，系统会为我们自动创建相应的 modulemap 文件，这一点可以在 Build Log 中查找到

它的内容如下：

framework module SQPod {
  umbrella header "SQPod-umbrella.h"

  export *
  module * { export * }
}

当然，如果系统自动生成的 modulemap 并不能满足你的诉求，我们也可以使用自己创建的文件，此时只需要在 Build Setting 的 Module Map File 选项中填写好文件路径，相应的 clang 命令参数是 -fmodule-map-file。

最后让我们看看 module 编译后的产物形态。

这里我们构建一个名为 SQPod 的 module ，将它提供给名为 Example 的工程使用，通过查看 -fmodule-cache-path 的参数，我们可以找到 module 的缓存路径

进入对应的路径后，我们可以看到如下的文件

其中后缀名为 pcm 的文件就是构建出来的二进制中间产物。

现在，我们不仅知道了预编译的基础理论知识，也动手查看了预编译环节在真实环境下的产物，现在我们要开始解答之前提到的两个问题了！

打破砂锅问到底

关于第一个问题

在早期的 clang 编译过程中，头文件的查找机制还是基于 header search path 的，这也是大多数人所熟知的工作机制，所以我们不做赘述，只做一个简单的回顾。

header seach path 是构建系统提供给编译器的一个重要参数，它的作用是在编译代码的时候，为编译器提供了查找相应头文件路径的信息，通过查阅 Xcode 的 Build System 信息，我们可以知道相关的设置有三处 header search path，system header search path，user header search path。

它们的区别也很简单，system header search path 是针对系统头文件的设置，通常代指 <> 方式引入的文件，user header search path 则是针对非系统头文件的设置，通常代指 "" 方式引入的文件，而 header search path 并不会有任何限制，它普适于任何方式的头文件引用。

听起来好像很复杂，但关于引入的方式，无非是以下四种形式:

#import <A/A.h>
#import "A/A.h"
#import <A.h>
#import "A.h"

我们可以两个维度去理解这个问题，一个是引入的符号形式，另一个是引入的内容形式

• 引入的符号形式：通常来说，双引号的引入方式(“A.h” 或者 "A/A.h")是用于查找本地的头文件，需要指定相对路径，尖括号的引入方式(<A.h> 或者 <A/A.h>)是全局的引用，其路径由编译器提供，如引用系统的库，但随着 header search path 的加入，让这种区别已经被淡化了。
• 引入的内容形式：对于 X/X.h 和 X.h 这两种引入的内容形式，前者是说在对应的 search path 中，找到目录 A 并在 A 目录下查找 A.h，而后者是说在 search path 下查找 A.h 文件，而不一定局限在 A 目录中，至于是否递归的寻找则取决于对目录的选项是否开启了 recursive 模式

在很多工程中，尤其是基于 CocoaPods 开发的项目，我们已经不会区分 system header search path 和 user header search path，而是一股脑的将所有头文件路径添加到 header search path 中，这就导致我们在引用某个头文件时，不会再局限于前面提到的约定，甚至在某些情况下，前面提到的四种方式都可以做到引入某个指定头文件。

header maps

随着项目的迭代和发展，原有的头文件索引机制还是受到了一些挑战，为此，Clang 官方也提出了自己的解决方案。

为了理解这个东西，我们首先要在 build setting 中开启 Use Header Map 选项。

然后在 build log 里获取相应组件里对应文件的编译命令，并在最后加上 -v 参数，来查看其运行的秘密：

clang <list of arguments> -c SQViewController.m -o SQViewcontroller.o -v

在 console 的输出内容中，我们会发现一段有意思的内容：

通过上面的图，我们可以看到编译器将寻找头文件的顺序和对应路径展示出来了，而在这些路径中，我们看到了一些陌生的东西，即后缀名为 .hmap 的文件。

那 hmap 到底这是个什么东西呢？

当我们开启 Build Setting 中的 Use Header Map 选项后，会自动生成的一份头文件名和头文件路径的映射表，而这个映射表就是 hmap 文件，不过它是一种二进制格式的文件，也有人叫它为 header map，总之，它的核心功能就是让编译器能够找到相应头文件的位置。

为了更好的理解它，我们可以通过 milend 编写的小工具 hmap 来查其内容。

在执行相关命令（即 hmap print）后，我们可以发现这些 hmap 里保存的信息结构大致如下：

需要注意，映射表的键值并不是简单的文件名和绝对路径，它的内容会随着使用场景产生不同的变化，例如头文件引用是在 "..." 的形式，还是 <...> 的形式，又或是在 Build Phase 里 Header 的配置情况。

至此我想你应该明白了，一旦开启 Use Header Map 选项后，Xcode 会优先去 hmap 映射表里寻找头文件的路径，只有在找不到的情况下，才会去 header search path 中提供的路径遍历搜索。

当然这种技术也不是一个什么新鲜事儿，在 Facebook 的 buck 工具中也提供了类似的东西，只不过文件类型变成了 HeaderMap.java 的样子。

查找系统库的头文件

上面的过程让我们理解了在 header map 技术下，编译器是如何寻找相应的头文件的，那针对系统库的文件又是如何索引的呢？例如 #import <Foundation/Foundation.h>

回想一下上一节 console 的输出内容，它的形式大概如下：

#include "..." search starts here:
XXX-generated-files.hmap (headermap)
XXX-project-headers.hmap (headermap)

#include <...> search starts here:
XXX-own-target-headers.hmap (headermap)
XXX-all-target-headers.hmap (headermap) 
Header Search Path 
DerivedSources
Build/Products/Debug (framework directory)
$(SDKROOT)/usr/include 
$(SDKROOT)/System/Library/Frameworks(framework directory)

我们会发现，这些路径大部分是用于查找非系统库文件的，也就是开发者自己引入的头文件，而与系统库相关的路径只有以下两个：

#include <...> search starts here:
$(SDKROOT)/usr/include 
$(SDKROOT)/System/Library/Frameworks.(framework directory)

当我们查找 Foundation/Foundation.h 这个文件的时候，我们会首先判断是否存在 Foundation 这个 framework。

$SDKROOT/System/Library/Frameworks/Foundation.framework

接着，我们会进入 framework 的 Headers 文件夹里寻找对应的头文件

$SDKROOT/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h

如果没有找到对应的文件，索引过程会在此中断，并结束查找。

以上便是系统库的头文件搜索逻辑。

framework search path

到底为止，我们已经解释了如何依赖 header search path，hmap 等技术寻找头文件的工作机制，也介绍了寻找系统库（system framework）头文件的工作机制。

那这是全部头文件的搜索机制么？答案是否定的，其实我们还有一种头文件搜索机制，它是基于 Framework 这种文件结构进行的。

对于开发者自己的 Framework，可能会存在 “private” 头文件，例如在 podspec 里用 private_header_files 的描述文件，这些文件在构建的时候，会被放在 Framework 文件结构中的 PrivateHeaders 目录。

所以针对有 PrivateHeaders 目录的 Framework 而言，clang 在检查 Headers 目录后，会去 PrivateHeaders 目录中寻找是否存在匹配的头文件，如果这两个目录都没有，才会结束查找。

$SDKROOT/System/Library/Frameworks/Foundation.framework/PrivateHeaders/SecretClass.h

不过也正是因为这个工作机制，会产生一个特别有意思的问题，那就是当我们使用 Framework 的方式引入某个带有 “private” 头文件的组件时，我们总是可以以下面的方式引入这个头文件！

怎么样，是不是很神奇，这个被描述为 “private” 的头文件怎么就不私有了？

究其原因，还是由于 clang 的工作机制，那为什么 clang 要设计出来这种看似很奇怪的工作机制呢？

揭开 Public，Private，Project 的真实面目

其实你也看到我在上一段的写作中，将所有 private 单词标上了双引号，其实就是在暗示，我们曲解了 private 的含义。

那么这个 “private” 到底是什么意思呢？

在 Apple 官方的 Xcode Help - What are build phases? 文档中，我们可以看到如下的一段解释：

总的来说，我们可以知道一点，就是 Build Phases - Headers 中提到 Public 和 Private 是指可以供外界使用的头文件，且分别放在最终产物的 Headers 和 PrivateHeaders 目录中，而 Project 中的头文件是不对外使用的，也不会放在最终的产物中。

如果你继续翻阅一些资料，例如 StackOverflow - Xcode: Copy Headers: Public vs. Private vs. Project? 和 StackOverflow - Understanding Xcode’s Copy Headers phase，你会发现在早期 Xcode Help 的 Project Editor 章节里，有一段名为 Setting the Role of a Header File 的段落，里面详细记载了三个类型的区别。

至此我们应该彻底了解了 Public，Private，Project 的区别，简而言之，Public 还是通常意义上的 Public，Private 则代表 In Progress 的含义，至于 Project 才是通常意义上的 Private 含义。

那么 CocoaPods 中 Podspec 的 Syntax 里还有 public_header_files 和 private_header_files 两个字段，它们的真实含义是否和 Xcode 里的概念冲突呢？

这里我们仔细阅读一下官方文档的解释，尤其是 private_header_files 字段。

我们可以看到，private_header_files 在这里的含义是说，它本身是相对于 public 而言的，这些头文件本义是不希望暴露给用户使用的，而且也不会产生相关文档，但是在构建的时候，会出现在最终产物中，只有既没有被 public 和 private 标注的头文件，才会被认为是真正的私有头文件，且不出现在最终的产物里。

其实这么看来，CocoaPods 对于 public 和 private 的理解是和 Xcode 中的描述一致的，两处的 Private 并非我们通常理解的 Private，它的本意更应该是开发者准备对外开放，但又没完全 ready 的头文件，更像一个 In Progress 的含义。

所以，如果你真的不想对外暴露某些头文件，请不要再使用 Headers 里的 Private 或者 podspec 里的 private_header_files 了。

至此，我想你应该彻底理解了 Search Path 的搜索机制和略显奇怪的 Public，Private，Project 设定了！

基于 hmap 优化 Search Path 的策略

在查找系统库的头文件的章节中，我们通过 -v 参数看到了寻找头文件的搜索顺序：

#include "..." search starts here:
XXX-generated-files.hmap (headermap)
XXX-project-headers.hmap (headermap)

#include <...> search starts here:
XXX-own-target-headers.hmap (headermap)
XXX-all-target-headers.hmap (headermap) 
Header Search Path 
DerivedSources
Build/Products/Debug (framework directory)
$(SDKROOT)/usr/include 
$(SDKROOT)/System/Library/Frameworks(framework directory)

假设，我们没有开启 hmap 的话，所有的搜索都会依赖 header search path 或者 framework search path，那这就会出现 3 种问题：

• 第一个问题，在一些巨型项目中，假设依赖的组件有 400+，那此时的索引路径就会达到 800+ 个（一份 public 路径，一份 private 路径），同时搜索操作可以看做是一种 IO 操作，而我们知道 IO 操作通常也是一种耗时操作，那么，这种大量的耗时操作必然会导致编译耗时增加。
• 第二个问题，在打包的过程中，如果 header search path 过多过长，会触发命令行过长的错误，进而导致命令执行失败的情况。
• 第三个问题，在引入系统库的头文件时，clang 会将前面提到的目录遍历完才进入搜索系统库的路径，也就是 $(SDKROOT)/System/Library/Frameworks(framework directory)，即前面的 header search 路径越多，耗时也会越长，这是相当不划算的。

那如果我们开启 hmap 后，是否就能解决掉所有的问题呢？

实际上并不能，而且在基于 CocoaPods 管理项目的状况下，又会带来新的问题。下面是一个基于 CocoaPods 构建的全源码工程项目，它的整体结构如下：

首先，Host 和 Pod 是我们的两个 Project，Pods 下的 target 的产物类型为 static library。

其次，Host 底下会有一个同名的 Target，而 Pods 目录下会有 n+1 个 target，其中 n 取决于你依赖的组件数量，而 1 是一个名为 Pods-XXX 的 target，最后，Pods-XXX 这个 target 的产物会被 Host 里的 target 所依赖。

整个结构看起来如下所示。

此时我们将 PodA 里的文件全部放在 Header 的 Project 类型中。

在基于 Framework 的搜索机制下，我们是无法以任何方式引入到 ClassB 的，因为它既不在 Headers 目录，也不在 PrivateHeader 目录中。

可是如果我们开启了 Use Header Map 后，由于 PodA 和 PodB 都在 Pods 这个 Project 下，满足了 Header 的 Project 定义，通过 Xcode 自动生成的 hmap 文件会带上这个路径，所以我们还可以在 PodB 中以 #import "ClassB.h" 的方式引入。

而这种行为，我想应该是大多数人并不想要的结果，所以一旦开启了 Use Header Map，再结合 CocoaPods 管理工程项目的模式，我们极有可能会产生一些误用私有头文件的情况，而这个问题的本质是 Xcode 和 CocoaPods 在工程和头文件上的理念冲突造成的。

除此之外，CocoaPods 在处理头文件的问题上还有一些让人迷惑的地方，它在创建头文件产物这块的逻辑大致如下：

• 在构建产物为 Framework 的情况下:
  • 根据 podspec 里的 public_header_files 字段的内容，将相应头文件设置为 Public 类型，并放在 Headers 中
  • 根据 podspec 里的 private_header_files 字段的内容，将相应文件设置为 Private 类型，并放在 PrivateHeader 中
  • 将其余未描述的头文件设置为 Project 类型，且不放入最终的产物中
  • 如果 podspec 里未标注 public 和 private 的时候，会将所有文件设置为 public 类型，并放在 Header 中
• 在构建产物为 Static Library 的情况下:
  • 不论 podspec 里如何设置 public_header_files 和 private_header_files，相应的头文件都会被设置为 Project 类型
  • 在 Pods/Headers/Public 中会保存所有被声明为 public_header_files 的头文件
  • 在 Pods/Headers/Private 中会保存所有头文件，不论是 public_header_files 或者 private_header_files 描述到，还是那些未被描述的，这个目录下是当前组件的所有头文件全集
  • 如果 podspec 里未标注 public 和 private 的时候，Pods/Headers/Public 和 Pods/Headers/Private 的内容一样且会包含所有头文件。

正是由于这种机制，还导致了另外一种有意思的问题。

在 Static Library 的状况下，一旦我们开启了 Use Header Map，结合组件里所有头文件的类型为 Project 的情况，这个 hmap 里只会包含 #import "A.h" 的键值引用，也就是说只有 #import "A.h" 的方式才会命中 hmap 的策略，否则都将通过 header search path 寻找其相关路径。

而我们也知道，在引用其他组件的时候，通常都会采用 #import <A/A.h> 的方式引入。至于为什么会用这种方式，一方面是这种写法会明确头文件的由来，避免问题，另一方面也是这种方式可以让我们在是否开启 clang module 中随意切换，当然还有一点就是，Apple 在 WWDC 里曾经不止一次的建议开发者使用这种方式引入头文件。

接着上面的话题来说，所以说在 Static Library 的情况下且以 #import <A/A.h> 这种标准方式引入头文件时，开启 Use Header Map 并不会提升编译速度，而这同样是 Xcode 和 CocoaPods 在工程和头文件上的理念冲突造成的。

这样来看的话，虽然 hmap 有种种优势，但是在 CocoaPods 的世界里显得格格不入，也无法发挥自身的优势。

那这就真的没有办法解决了么？

当然，问题是有办法解决的，我们完全可以自己动手做一个基于 CocoaPods 规则下的 hmap 文件。

举一个简单的例子，通过遍历 PODS 目录里的内容去构建索引表内容，借助 hmap 工具生成 header map 文件，然后将 Cocoapods 在 header search path 中生成的路径删除，只添加一条指向我们自己生成的 hmap 文件路径，最后关闭 Xcode 的 Ues Header Map 功能，也就是 Xcode 自动生成 hmap 的功能，如此这般，我们就实现了一个简单的，基于 CocoaPods 的 header map 功能。

同时在这个基础上，我们还可以借助这个功能实现不少管控手段，例如

• 从根本上杜绝私有文件被暴露的可能性。
• 统一头文件的引用形式
• …

目前我们已经自研了一套基于上述原理的 cocoapods 插件，它的名字叫做 cocoapods-hmap-prebuilt，是由笔者与同事 @宋旭陶 共同开发的，

说了这么多，让我们看看它在实际工程中的使用效果！

经过全源码编译的测试，我们可以看到该技术在提速上的收益较为明显，以美团和点评 App 为例，全链路时长能够提升 45% 以上，其中 Xcode 打包时间能提升 50%。

关于第二个问题

首先，我们来明确一个问题， clang 是如何决定编译当下组件的 module 呢

以 #import <Foundation/NSString.h> 为例，当我们遇到这个头文件的时候：

首先会去 Framework 的 Headers 目录下寻找相应的头文件是否存在，然后就会到 Modules 目录下查找 modulemap 文件

此时，Clang 会去查阅 modulemap 里的内容，看看 NSString 是否为 Foundation 这个 Module 里的一部分，

// Module Map - Foundation.framework/Modules/module.modulemap
framework module Foundation [extern_c] [system] {
    umbrella header "Foundation.h"
    export *
    module * {
        export *
    }

    explicit module NSDebug {
        header "NSDebug.h"
        export *
    }
}

很显然，这里通过 umbrella header，我们是可以在 Foundation.h 中找到 NSString.h 的。

// Foundation.h
…
#import <Foundation/NSStream.h>
#import <Foundation/NSString.h>
#import <Foundation/NSTextCheckingResult.h>
…

至此，clang 会判定 NSString.h 是 Foundation 这个 module 的一部分并进行相应的编译工作，此时也就意味着 #import <Foundation/NSString.h> 会从之前的 textual import 变为 module import

Module 的构建细节

上面的内容解决了是否构建 module，而这一块我们会详细阐述构建 module 的过程！

在构建开始前，clang 会创建一个完全独立的空间来构建 module，在这个空间里会包含 module 涉及的所有文件，除此之外不会带入其他任何文件的信息，而这也是 module 健壮性好的关键因素之一。

不过，这并不意味着我们无法影响到 module 的唯一性，真正能影响到其唯一性的是其构建的参数，也就是 clang 命令后面的内容，关于这一点后面还会继续展开，这里我们先点到为止。

当我们在构建 Foundation 的时候，我们会发现 Foundation 自身要依赖一些组件，这意味着我们也需要构建被依赖组件的 module

但很明显的是，我们会发现这些被依赖组件也有自己的依赖关系，在它们的这些依赖关系中，极有可能会存在重复的引用。

此时 module 的复用机制就体现出来优势了，我们可以复用先前构建出来的 module，而不必一次次的创建或者引用，例如 Drawin 组件，而保存这些缓存文件的位置就是前面章节里提到的保存 pcm 类型文件的地方。

先前我们提到了 clang 命令的参数会真正影响到 module 的唯一性，那具体的原理又是怎样的？

clang 会将相应的编译参数进行一次 hash，将获得的 hash 值作为 module 缓存文件夹的名称，这里需要注意的是，不同的参数和值会导致文件夹不同，所以想要尽可能的利用 module 缓存，就必须保证参数不发生变化。

$ clang -fmodules —DENABLE_FEATURE=1 …
## 生成的目录如下
98XN8P5QH5OQ/
  CoreFoundation-2A5I5R2968COJ.pcm
  Security-1A229VWPAK67R.pcm
  Foundation-1RDF848B47PF4.pcm
  
$ clang -fmodules —DENABLE_FEATURE=2 …
## 生成的目录如下
1GYDULU5XJRF/
  CoreFoundation-2A5I5R2968COJ.pcm
  Security-1A229VWPAK67R.pcm
  Foundation-1RDF848B47PF4.pcm

这里我们大概了解了系统组件的 module 构建机制，这也是开启 Enable Modules(C and Objective-C) 的核心工作原理。

神秘的 Virtual File System（VFS）

对于系统组件，我们可以在 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.2.sdk/System/Library/Frameworks 目录里找到它的身影，它的目录结构大概是这样的

也就是说，对于系统组件而言，构建 module 的整个过程是建立在这样一个完备的文件结构上，即在 Framework 的 Modules 目录中查找 modulemap，在 Headers 目录中加载头文件。

那对于用户自己创建的组件，clang 又是如何构建 module 的呢？

通常我们的开发目录大概是下面的样子，它并没有 modules 目录，也没有 headers 目录，更没有 modulemap 文件，看起来和 framework 的文件结构也有着极大的区别。

在这种情况下，clang 是没法按照前面所说的机制去构建 module 的，因为在这种文件结构中，压根就没有 Modules 和 Headers 目录。

为了解决这个问题，clang 又提出了一个新的解决方案，叫做 Virtual File System（VFS）。

简单来说，通过这个技术，clang 可以在现有的文件结构上虚拟出来一个 Framework 文件结构，进而让 clang 遵守前面提到的构建准则，顺利完成 module 的编译，同时 VFS 也会记录文件的真实位置，以便在出现问题的时候，将文件的真实信息暴露给用户。

为了进一步了解 VFS，我们还是从 Build Log 中查找一些细节！

在上面的编译参数里，我们可以找到一个 -ivfsoverlay 的参数，查看 help 说明，可以知道其作用就是向编译器传递一个 VFS 描述文件并覆盖掉真实的文件结构信息。

-ivfsoverlay <value>    Overlay the virtual filesystem described by file over the real file system

顺着这个线索，我们去看看这个参数指向的文件，它是一个 yaml 格式的文件，在将内容进行了一些裁剪后，它的核心内容如下，：

{
  "case-sensitive": "false",
  "version": 0,
  "roots": [
    {
      "name": "XXX/Debug-iphonesimulator/PodA/PodA.framework/Headers",
      "type": "directory",
      "contents": [
        { "name": "ClassA.h", "type": "file",
          "external-contents": "XXX/PodA/PodA/Classes/ClassA.h"
        },
        ......
        { "name": "PodA-umbrella.h", "type": "file",
          "external-contents": "XXX/Target Support Files/PodA/PodA-umbrella.h"
        }
      ]
    },
    {
      "contents": [
        "name": "XXX/Products/Debug-iphonesimulator/PodA/PodA.framework/Modules",
        "type": "directory"
        { "name": "module.modulemap", "type": "file",
          "external-contents": "XXX/Debug-iphonesimulator/PodA.build/module.modulemap"
        }
      ]
    }
  ]
}

结合前面提到的内容，我们不难看出它在描述这样一个文件结构：

借用一个真实存在的文件夹来模拟 framework 里的 Headers 文件夹，在这个 Headers 文件夹里有名为 PodA-umbrella.h 和 ClassA.h 等的文件，不过这几个虚拟文件与 external-contents 指向的真实文件相关联，同理还有 Modules 文件夹和它里面的 module.modulemap 文件。

通过这样的形式，一个虚拟的 framework 目录结构诞生了！此时 clang 终于能按照前面的构建机制为用户创建 module 了！

Swift 来了

没有头文件的 Swift

前面的章节我们聊了很多 C 语言系的预编译知识，在这个体系下，文件的编译是分开的，当我们想引用其他文件里的内容时，就必须引入相应的头文件。

而对于 Swift 这门语言来说，它并没有头文件的概念，对于开发者而言，这确实省去了写头文件的重复工作，但这也意味着，编译器会进行额外的操作来查找接口定义并需要持续关注接口的变化！

为了更好的解释 Swift 和 Objective-C 是如何寻找到彼此的方法声明的，我们这里引入一个例子，在这个例子由三个部分组成：

• 第一部分是一个 ViewController 的代码，它里面包含了一个 view，其中 PetViewController 和 PetView 都是 Swift 代码。
• 第二部分是一个 App 的代理，它是 Objective-C 代码。
• 第三个部分是一段单测代码，用来测试第一个部分中的 ViewController，它是 Swift 代码。

import UIKit
class PetViewController: UIViewController {
  var view = PetView(name: "Fido", frame: frame)
  …
}
#import "PetWall-Swift.h"
@implementation AppDelegate
…
@end
@testable import PetWall
class TestPetViewController: XCTestCase {
}

它们的关系大致如下所示：

为了能让这些代码编译成功，编译器会面对如下 4 个场景：

首先是寻找声明，这包括寻找当前 target 内的方法声明（PetView），也包括来自 Objective-C 组件里的声明（UIViewController 或者 PetKit）。

然后是生成接口，这包括被 Objective—C 使用的接口，也包括被其他 target (Unit Test）使用的 Swift 接口。

第一步 - 如何寻找 Target 内部的 Swift 方法声明

在编译 PetViewController.swift 时，编译器需要知道 PetView 的初始化构造器的类型，才能检查调用是否正确。

此时编译器会加载 PetView.swift 文件并解析其中的内容, 这么做的目的就是确保初始化构造器真的存在，并拿到相关的类型信息，以便 PetViewController.swift 进行验证。

编译器并不会对初始化构造器的内部做检查，但它仍然会进行一些额外的操作，这是什么意思呢？

与 clang 编译器不同的是，swiftc 编译的时候，会将相同 target 里的其他 swift 文件进行一次解析，用来检查其中与被编译文件关联的接口部分是否符合预期。

同时我们也知道，每个文件的编译是独立的，且不同文件的编译是可以并行开展的，所以这就意味着每编译一个文件，就需要将当前 target 里的其余文件当做接口，重新编译一次。 等于任意一个文件，在整个编译过程中，只有 1 次被作为生产 .o 产物的输入，其余时间会被作为接口文件反复解析。

不过在 Xcode 10 以后，Apple 对这种编译流程进行了优化！

在尽可能保证并行的同时，将文件进行了分组编译，这样就避免了 group 内的文件重复解析，只有不同 group 之间的文件会有重复解析文件的情况。

而这个分组操作的逻辑，就是刚才提到的一些额外操作。

至此，我们应该了解了 Target 内部是如何寻找 Swift 方法声明的了。

第二步 - 如何找到 Objective-C 组件里的方法声明

回到第一段代码中，我们可以看到 PetViewController 是继承自 UIViewController，而这也意味着我们的代码会与 Objective-C 代码进行交互，因为大部分系统库，例如 UIKit 等，还是使用 Objective-C 编写的。

在这个问题上，Swift 采用了和其他语言不一样的方案！

通常来说，两种不同的语言在混编时需要提供一个接口映射表，例如 JavaScript 和 TypeScript 混编时候的 .d.ts 文件，这样 TypeScript 就能够知道 JavaScript 方法在 TS 世界中的样子。

然而，Swift 不需要提供这样的接口映射表, 免去了开发者为每个 Objective-C API 声明其在 Swift 世界里样子，那它是怎么做到的呢?

很简单，Swift 编译器将 clang 的大部分功能包含在其自身的代码中，这就使得我们能够以 module 的形式，直接引用 Objective-C 的代码。

既然是通过 module 的形式引入 Objective-C，那么 framework 的文件结构则是最好的选择，此时编译器寻找方法声明的方式就会有下面三种场景：

• 对于大部分的 target 而言，当导入的是一个 Objective-C 类型的 framework 时，编译器会通过 modulemap 里的 header 信息寻找方法声明
• 对于一个既有 Objective-C，又有 Swift 代码的 framework 而言，编译器会从当前 framework 的 umbrella header 中寻找方法声明，从而解决自身的编译问题，这是因为通常情况下 modulemap 会将 umbrella header 作为自身的 header 值。
• 对于 App 或者 Unit Test 类型的 target，开发者可以通过为 target 创建 briding header 来导入需要的 Objective-C 头文件，进而找到需要的方法声明。

不过我们应该知道 Swift 编译器在获取 Objective-C 代码过程中，并不是原原本本的将 Objective—C 的 API 暴露给 Swift，而是会做一些 “Swift 化” 的改动，例如下面的 Objective-C API 就会被转换成更简约的形式。

这个转换过程并不是什么高深的技术，它只是在编译器上的硬编码，如果感兴趣，可以在 Swift 的开源库中的找到相应的代码 - PartsOfSpeech.def

当然，编译器也给与了开发者自行定义 “API 外貌” 的权利，如果你对这一块感兴趣，不妨阅读我的另一篇文章 - WWDC20 10680 - Refine Objective-C frameworks for Swift，那里面包含了很多重塑 Objective-C API 的技巧。

不过这里还是要提一句，如果你对生成的接口有困惑，可以通过下面的方式查看编译器为 Objective-C 生成的 Swift 接口。

第三步 - Target 内的 Swift 代码是如何为 Objective-C 提供接口的

前面讲了 Swift 代码是如何引用 Objective-C 的 API，那么 Objective-C 又是如何引用 Swift 的 API 呢？

从使用层面来说，我们都知道 Swift 编译器会帮我们自动生成一个头文件，以便 Objective-C 引入相应的代码，就像第二段代码里引入的 PetWall-Swift.h 文件，这种头文件通常是编译器自动生成的，名字的构成是 组件名-Swift 的形式。

但它到底是怎么产生的呢？

在 Swift 中，如果某个类继承了 NSObject 类且 API 被 @objc 关键字标注，就意味着它将暴露给 Objective-C 代码使用。

不过对于 App 和 Unit Test 类型的 target 而言，这个自动生成的 header 会包含访问级别为 public 和 internal 的 API，这使得同一 target 内的 Objective-C 代码也能访问 Swift 里 internal 类型的 API，这也是所有 Swift 代码的默认访问级别。

但对于 framework 类型的 target 而言，Swift 自动生成的头文件只会包含 public 类型的 API，因为这个头文件会被作为构建产物对外使用，所以像 internal 类型的 API 是不会包含在这个文件中。

那么编译器自动生成的 API 到底是什么样子，有什么特点呢？

上面是截取了一段自动生成的头文件代码，左侧是原始的 Swift 代码，右侧是自动生成的 Objective-C 代码，我们可以看到在 Objective-C 的类中，有一个名为 SWIFT_CLASS 的宏，将 Swift 与 Objective-C 中的两个类进行了关联。

如果你稍加注意，就会发现关联的一段乱码中还绑定了当前的组件名（PetWall），这样做的目的是避免两个组件的同名类在运行时发生冲突。

当然，你也可以通过向 @objc(Name) 关键字传递一个标识符，借由这个标识符来控制其在 Objective-C 中的名称，如果这样做的话，需要开发者确保转换后的类名不与其他类名出现冲突。

这大体上就是 Swift 如何像 Objective-C 暴露接口的机理了，如果你想更深入的了解这个文件的由来，就需要看看第四步。

第四步 - Swift Target 如何生成供外部 Swift 使用的接口

Swift 采用了 Clang Module 的理念，并结合自身的语言特性进行了一系列的改进。

在 Swift 中，module 是方法声明的分发单位，如果你想引用相应的方法，就必须引入对应的 module，之前我们也提到了 swift 的编译器包含了 clang 的大部分内容，所以它也是兼容 clang module 的。

所以我们可以引入 Objective-C 的 module，例如 XCTest，也可以引入 Swift Target 生成的 module，例如 PetWall

import XCTest
@testable import PetWall
class TestPetViewController: XCTestCase {
  func testInitialPet() {
    let controller = PetViewController()
    XCTAssertEqual(controller.view.name, "Fido")
  }
}

在引入 swift 的 module 后，编译器会反序列化一个后缀名为 .swiftmodule 的文件，并通过这种文件里的内容来了解相关接口的信息。

例如，以下图为例，在这个单元测试中，编译器会加载 PetWall 的 module，并在其中找寻 PetViewController 的方法声明，由此确保其创建行为是符合预期的。

这看起来很像第一步中 target 寻找内部 Swift 方法声明的样子，只不过这里将解析 swift 文件的步骤，换成了解析 swiftmodule 文件而已。

不过需要注意的是，这个 swfitmodule 文件并不是文本文件，它是一个二进制格式的内容，通常我们可以在构建产物的 Modules 文件夹里寻找到它的身影。

在 target 的编译的过程中，面向整个 target 的 swiftmodule 文件并不是一下产生的，每一个 swift 文件都会生成一个 swiftmodule 文件，编译器会将这些文件进行汇总，最后再生成一个完整的，代表整个 target 的 swiftmodule，也正是基于这个文件，编译器构造出了用于给外部使用的 Objective-C 头文件，也就是第三步里提到的头文件

不过随着 Swift 的发展，这一部分的工作机制也发生了些许变化。

我们前面提到的 swiftmodule 文件是一种二进制格式的文件，而这个文件格式会包含一些编译器内部的数据结构，不同编译器产生的 swiftmodule 文件是互相不兼容的，这也就导致了不同 Xcode 构建出的产物是无法通用的，如果对这方面的细节感兴趣，可以阅读 Swift 社区里的两篇官方 Blog：Evolving Swift On Apple Platforms After ABI Stability 和 ABI Stability and More，这里就不展开讨论了。

为了解决这一问题，Apple 在 Xcode 11 的 Build Setting 中提供了一个新的编译参数 Build Libraries for Distribution，正如这个编译参数的名称一样，当我们开启它后，构建出来的产物不会再受编译器版本的影响，那它是怎么做到这一点的呢？

为了解决这种对编译器的版本依赖，Xcode 在构建产物上提供了一个新的产物，swiftinterface 文件。

这个文件里的内容和 swiftmodule 很相似，都是当前 module 里的 API 信息，不过 swiftinterface 是以文本的方式记录，而非 swiftmodule 的二进制方式。

这就使得 swiftinterface 的行为和源代码一样，后续版本的 swift 编译器也能导入之前编译器创建的 swiftinterface 文件，像使用源码的方式一样使用它。

为了更进一步了解它，我们来看看 swiftinterface 的真实样子，下面是一个 .swift 文件和 .swiftinterface 文件的比对图。

在 swiftinterface 文件中，有以下点需要注意

• 文件会包含一些元信息，例如文件格式版本，编译器信息，和 Swift 编译器将其作为模块导入所需的命令行子集。
• 文件只会包含 public 的接口，而不会包含 private 的接口，例如 currentLocation
• 文件只会包含方法声明，而不会包含方法实现，例如 Spacesship 的 init，fly 等方法
• 文件会包含所有隐式声明的方法，例如 Spacesship 的 deinit 方法 ，Speed 的 Hashable 协议

总的来说，swiftinterface 文件会在编译器的各个版本中保持稳定，主要原因就是这个接口文件会包含接口层面的一切信息，不需要编译器再做任何的推断或者假设。

好了，至此我们应该了解了 Swift Target 是如何生成供外部 Swift 使用的接口了。

这四步意味着什么？

此 module 非彼 module

通过上面的例子，我想大家应该能清楚的感受到 swift module 和 clang module 不完全是一个东西，虽然它们有很多相似的地方。

clang module 是面向 C 语言家族的一种技术，通过 modulemap 文件来组织 .h 文件中的接口信息，中间产物是二进制格式的 pcm 文件。

swift module 是面向 Swift 语言的一种技术，通过 swiftinterface 文件来组织 .swift 文件中的接口信息，中间产物二进制格式的 swiftmodule 文件。

所以说理清楚这些概念和关系后，我们在构建 Swift 组件的产物时，就会知道哪些文件和参数不是必须的了。

例如当你的 Swift 组件不想暴露自身的 API 给外部的 Objective-C 代码使用的话，可以将 Build Setting 中 Swift Compiler - General 里的 Install Objective-C Compatiblity Header 参数设置为 NO，其编译参数为 SWIFT_INSTALL_OBJC_HEADER，此时不会生成 <ProductModuleName>-Swift.h 类型的文件，也就意味着外部组件无法以 Objective-C 的方式引用组件内 Swift 代码的 API。

而当你的组件里如果压根就没有 Objective-C 代码的时候，你可以将 Build Setting 中 Packaging 里 Defines Module 参数设置为 NO，其编译参数为 DEFINES_MODULE, 此时不会生成 <ProductModuleName>.modulemap 类型的文件。

Swift 和 Objective-C 混编的三个“套路”

基于刚才的例子，我们应该理解了 swift 在编译时是如何找到其他 API 的，以及它又是如何暴露自身 API 的，而这些知识就是解决混编过程中的基础知识，为了加深影响，我们可以将其绘制成 3 个流程图

当 Swift 和 Objective-C 文件同时在一个 App 或者 Unit Test 类型的 target 中，不同类型文件的 API 寻找机制如下

当 Swift 和 Objective-C 文件在不同 target 中，例如不同 Framework 中，不同类型文件的 API 寻找机制如下

当 Swift 和 Objective-C 文件同时在一个target 中，例如同一 Framework 中，不同类型文件的 API 寻找机制如下

对于第三个流程图，需要做以下补充说明

• 由于 swiftc，也就是 swift 的编译器，包含了大部分的 clang 功能，其中就包含了 clang module，借由组件内已有的 modulemap 文件，swift 编译器就可以轻松找到相应的 Objective-C 代码。
• 相比于第二个流程而言，第三个流程中的 modulemap 是组件内部的，而第二个流程中，如果想引用其他组件里的 Objective-C 代码，需要引入其他组件里的 modulemap 文件才可以
• 所以基于这个考虑，并未在流程 3 中标注 modulemap。

构建 Swift 产物的新思路

在前面的章节里，我们提到了 Swift 找寻 Objective-C 的方式，其中提到了，除了 App 或者 Unit Test 类型的 target 外，其余的情况下都是通过 framework 的 module map 来寻找 Objective-C 的 API，那么如果我们不想使用 framework 的形式呢？

目前来看，这个在 Xcode 中是无法直接实现的，原因很简单，Build Setting 中 Search Path 选项里并没有 modulemap 的 search path 配置参数。

为什么一定需要 modulemap 的 search path 呢？

基于前面了解到的内容，swiftc 包含了 clang 的大部分逻辑，在预编译方面，swiftc 只包含了 clang module 的模式，而没有其他模式，所以 Objective-C 想要暴露自己的 API 就必须通过 modulemap 来完成。

而对于 Framework 这种标准的文件夹结构，modulemap 文件的相对路径是固定的，它就在 Modules 目录中，所以 Xcode 基于这种标准结构，直接内置了相关的逻辑，而不需要将这些配置再暴露出来。

从组件的开发者角度来看，他只需要关心 modulemap 的内容是否符合预期，以及路径是否符合规范。

从组件的使用者角度来看，他只需要正确的引入相应的 Framework 就可以使用到相应的 API。

这种只需要配置 Framework 的方式，避免了配置 header search path，也避免了配置 static library path，可以说是一种很友好的方式，如果再将 modulemap 的配置开放出来，反而显得多此一举。

那如果我们抛开 Xcode，抛开 Framework 的限制，还有别的办法构建 Swift 产物么？

答案是肯定有的，这就需要借助前面所说的 VFS 技术！

假设我们的文件结构如下所示：

├── LaunchPoint.swift
├── README.md
├── build
├── repo
│   └── MyObjcPod
│       └── UsefulClass.h
└── tmp
    ├── module.modulemap
    └── vfs-overlay.yaml

其中 LaunchPoint.swift 引用了 UsefulClass.h 中的一个公开 API，并产生了依赖关系。

另外，vfs-overlay.yaml 文件重新映射了现有的文件目录结构，其内容如下：

{
  'version': 0,
  'roots': [
    { 'name': '/MyObjcPod', 'type': 'directory',
      'contents': [
        { 'name': 'module.modulemap', 'type': 'file',
          'external-contents': 'tmp/module.modulemap'
        },
        { 'name': 'UsefulClass.h', 'type': 'file',
          'external-contents': 'repo/MyObjcPod/UsefulClass.h'
        }
      ]
    }
  ]
}

至此，我们通过如下的命令，便可以获得 LaunchPoint 的 swiftmodule，swiftinterface 等文件，具体的示例可以查看我在 github 上的链接 - manually-expose-objective-c-API-to-swift-example

swiftc -c LaunchPoint.swift -emit-module -emit-module-path build/LaunchPoint.swiftmodule -module-name index -whole-module-optimization -parse-as-library -o build/LaunchPoint.o -Xcc -ivfsoverlay -Xcc tmp/vfs-overlay.yaml -I /MyObjcPod

那这意味着什么呢？

这就意味着，只提供相应的 .h 文件和 .modulemap 文件就可以完成 Swift 二进制产物的构建，而不再依赖 Framework 的实体。同时，对于 CI 系统来说，在构建产物时，可以避免下载无用的二进制产物（.a 文件），这从某种程度上会提升编译效率。

如果你没太理解上面的意思，我们可以展开说说。

例如，对于 PodA 组件而言，它自身依赖 PodB 组件，在使用原先的构建方式时，我们需要拉取 PodB 组件的完整 Framework 产物，这会包含 Headers 目录，Modules 目录里的必要内容，当然还会包含一个二进制文件（PodB），但在实际编译 PodA 组件的过程中，我们并不需要 B 组件里的二进制文件，而这让拉取完整的 Framework 文件显得多余了。

而借助 VFS 技术，我们就能避免拉取多余的二进制文件，进一步提升 CI 系统的编译效率。

总结

感谢你的耐心阅读，至此，整篇文章终于结束了，通过这篇文章，我想你应该：

• 理解 Objective-C 的三种预编译的工作机制，其中 clang module 做到了真正意义上的语义引入，提升了编译的健壮性和扩展性。
• 在 Xcode 的 search path 的各种技术细节使用到了 hmap 技术，通过加载映射表的方式避免了大量重复的 IO 操作，可以提升编译效率。
• 在处理 Framework 的头文件索引时，总是会先搜索 Headers 目录，再搜索 PrivateHeader 目录
• 理解 Xcode Phases 构建系统中，Public 代表公开头文件，Private 代表不需要使用者感知，但物理存在的文件， 而 Project 代表不应让使用者感知，且物理不存在的文件。
• 不使用 Framework 的情况下且以 #import <A/A.h> 这种标准方式引入头文件时，在 CocoaPods 上使用 hmap 并不会提升编译速度。
• 通过 cocoapods-hmap-built 插件，可以将大型项目的全链路时长节省 45% 以上，Xcode 打包环节的时长节省 50% 以上。
• clang module 的构建机制确保了其不受上下文影响（独立编译空间），复用效率高（依赖决议），唯一性（参数哈希化）
• 系统组件通过已有的 Framework 文件结构实现了构建 module 的基本条件 ，而非系统组件通过 VFS 虚拟出相似的 Framework 文件 结构，进而具备了编译的条件。
• 可以粗浅的将 Clang Module 里的 .h/m，.moduelmap，.pch 的概念对应为 Swift Module 里的 .swift，.swiftinterface，.swiftmodule 的概念
• 理解三种具有普适性的 Swift 与 Objective-C 混编方法
  • 同一 target 内（App 或者 Unit 类型），基于 <PorductModuleName>-Swift.h 和 <PorductModuleName>-Bridging-Swift.h
  • 同一 target 内，基于 <PorductModuleName>-Swift.h 和 clang 自身的能力
  • 不同 target 内，基于 <PorductModuleName>-Swift.h 和 module.modulemap
• 利用 VFS 机制构建，可以在构建 Swift 产物的过程中避免下载无用的二进制产物，进一步提升编译效率

最后，在编写这篇文章的过程中，我的同事 @叶樉 和 @宋旭陶 给与了我许多指导与帮助，也正是在大家的共同努力下，才有了这篇文章，希望它能对亲爱的读者您，有所帮助！

参考文档

• Apple - WWDC 2013 Advances in Objective-C
• Apple - WWDC 2018 Behind the Scenes of the Xcode Build Process
• Apple - WWDC 2019 Binary Frameworks in Swift
• Apple - WWDC 2020 Distribute binary frameworks as Swift packages
• Swift org - Evolving Swift On Apple Platforms After ABI Stability
• Swift org - ABI Stability and More
• StackOverflow - #import using angle brackets < > and quote marks “ ”
• StackOverflow - Xcode: Copy Headers: Public vs. Private vs. Project?
• StackOverflow - Understanding Xcode’s Copy Headers phase
• Xcode Help - What are build phases?
• Xcode Build Settings
• Big Nerd Ranch - Manual Swift: Understanding the Swift/Objective-C Build Pipeline
• Big Nerd Ranch - Build Log Groveling for Fun and Profit: Manual Swift Continued
• Big Nerd Ranch - Build Log Groveling for Fun and Profit, Part 2: Even More Manual Swift
• Quality Coding - 4 Ways Precompiled Headers Cripple Your Code
• try! Swift Tokyo 2018 - Exploring Clang Modules

这篇文章是我早年在美团技术博客上发布的一篇文章, 部分内容可能已经过时, 请开发者注意. 将文章同步到个人博客主要是为了同步和备份.

cocoapods-hmap-prebuilt 是什么？

cocoapods-hmap-prebuilt 是美团平台迭代组自研的一款 cocoapods 插件，以 Header Map 技术 为基础，进一步提升代码的编译速度，完善头文件的搜索机制。

虽然以二进制组件的方式构建 App 是 HPX (公司移动端统一持续集成/交付平台)的主流解决方案，但在某些场景下（Profile、Address/Thread/UB/Coverage Sanitizer、App 级别静态检查、ObjC 方法调用兼容性检查等等等等），我们的构建工作还是需要以全源码编译的方式进行；再结合实际开发过程中，大多是以源码的方式开发，所以我们将实验对象设置为基于全源码编译的流程。

废话不多说，我们来看看它的实际使用效果！

总的来说，以美团和大众点评的全源码编译流程为实验对象的前提下，cocoapods-hmap-prebuilt 插件能将总链路提升 45% 以上的速度，在 Xcode 打包环节上能提升 50% 以上的速度，是不是有点动心了？

为了更好的理解这个插件的价值和功能，我们不妨先理解一下当前的工程中存在的问题！

为什么现有的项目不够好？

目前公司内的 App 都是基于 CocoaPods 做包管理方面的工作，所以在实际的开发过程中，CocoaPods 会在 Pods/Header/ 目录下添加组件名目录和头文件软链，类似于下面的形式:

/Users/sketchk/Desktop/MyApp/Pods
└── Headers
    ├── Private
    │   └── AFNetworking
    │       ├── AFHTTPRequestOperation.h -> ./XXX/AFHTTPRequestOperation.h
    │       ├── AFHTTPRequestOperationManager.h -> ./XXX/AFHTTPRequestOperationManager.h
    │       ├── ...
    │       └── UIRefreshControl+AFNetworking.h -> ./XXX/UIRefreshControl+AFNetworking.h
    └── Public
        └── AFNetworking
            ├── AFHTTPRequestOperation.h -> ./XXX/AFHTTPRequestOperation.h
            ├── AFHTTPRequestOperationManager.h -> ./XXX/AFHTTPRequestOperationManager.h
            ├── ...
            └── UIRefreshControl+AFNetworking.h -> ./XXX/UIRefreshControl+AFNetworking.h

也正是通过这样的目录结构和软链，CocoaPods 得以在 Header Search Path 中添加如下的参数，使得预编译环节顺利进行。

$(inherited)
${PODS_ROOT}/Headers/Private
${PODS_ROOT}/Headers/Private/AFNetworking
${PODS_ROOT}/Headers/Public
${PODS_ROOT}/Headers/Public/AFNetworking

虽然这种构建 search path 的方式解决了预编译的问题，但在某些项目中，例如多达 400+ 组件的巨型项目中，会造成以下几点问题：

1. 大量的 header search path 路径，会造成编译参数中的 -I 选项极速膨胀，在达到一定长度后，甚至会造成无法编译的情况
2. 目前美团的工程中，已经有近 5W 个头文件，这意味着不论是头文件的搜索过程，还是软链的创建过程，都会引起大量的文件 IO 操作，进而会产生一些耗时操作。
3. 编译时间会随着组件数量急剧增长，以美团和大众点评有 400+ 个组件的体量为参考，全源码打包耗时均为 1 小时以上。
4. 基于路径顺序查找头文件的方式有潜在的风险，例如重名头文件的情况，排在后面的头文件永远无法参与编译
5. 由于 ${PODS_ROOT}/Headers/Private 路径的存在，让引用其他组件的私有头文件变为了可能。

上面的问题，好一点的不过是浪费了 1 个小时而已，而不好的情况则是让有风险的代码上线了，你说开发者头疼不头疼？

Header Map 是个啥？

还好 cocoapods-hmap-prebuilt 的出现，让这些问题变成了历史，不过要想理解它为什么能解决这些问题，我们得先理解一下什么是 Header Map！

Header Map 其实是一组头文件信息映射表！

为了更直观的理解 Header Map，我们可以在 build setting 中开启 Use Header Map 选项，真实的体验一下它。

然后在 build log 里获取相应组件里对应文件的编译命令，并在最后加上 -v 参数，来查看其运行的秘密：

clang <list of arguments> -c some-file.m -o some-file.o -v

在 console 的输出内容中，我们会发现一段有意思的内容：

通过上面的图，我们可以看到编译器将寻找头文件的顺序和对应路径展示出来了，而在这些路径中，我们看到了一些陌生的东西，即后缀名为 .hmap 的文件，后面还有个括号写着 headermap。

没错！它就是 Header Map 的实体。

此时 clang 已经在刚才提到的 hmap 文件里塞入了一份头文件名和头文件路径的映射表，不过它是一种二进制格式的文件，为了验证这个的说法，我们可以通过 milend 编写的hmap 工具来查其内容。

在执行相关命令（即 hmap print）后，我们可以发现这些 hmap 里保存的信息结构大致如下, 类似于一个 key-value 的形式，key 值是头文件的名称，value 是头文件的实际物理路径：

需要注意，映射表的键值内容会随着使用场景产生不同的变化，例如头文件引用是在 "..." 的形式下，还是 <...> 的形式下，又或是在 Build Phase 里 Header 的配置情况。例如，你将头文件设置为 public 的时候，在某些 hmap 中，它的 key 值就为 PodA/ClassA，而将其设置为 project 的时候，它的 key 值可能就是 ClassA，而配置这些信息的地方，如下图所示：

至此我想你应该了解到 Header Map 到底是个什么东西了。

当然这种技术也不是一个什么新鲜事儿，在 Facebook 的 buck 工具中也提供了类似的东西，只不过文件类型变成了 HeaderMap.java 的样子。

此时，我估计你可能并不会对 buck 产生太多的兴趣，而是开始思考上一张图中 Headers 的 public，private，project 到底代表着什么意思，好像我从来没怎么关注过，以及为什么它会影响 hmap 里的内容？

Public，Private，Project 是个啥？

在 Apple 官方的 Xcode Help - What are build phases? 文档中，我们可以看到如下的一段解释：

总的来说，我们可以知道一点，就是 Build Phases - Headers 中提到 Public 和 Private 是指可以供外界使用的头文件，而 Project 中的头文件是不对外使用的，也不会放在最终的产物中。

如果你继续翻阅一些资料，例如 StackOverflow - Xcode: Copy Headers: Public vs. Private vs. Project? 和 StackOverflow - Understanding Xcode’s Copy Headers phase，你会发现在早期 Xcode Help 的 Project Editor 章节里，有一段名为 Setting the Role of a Header File 的段落，里面详细记载了三个类型的区别。

至此我们应该彻底了解了 Public，Private，Project 的区别，简而言之，Public 还是通常意义上的 Public，Private 则代表 In Progress 的含义，至于 Project 才是通常意义上的 Private 含义。

此时，你会不会联想到 CocoaPods 中 Podspec 的 Syntax 里还有 public_header_files 和 private_header_files 两个字段，它们的真实含义是否和 Xcode 里的概念冲突呢？

这里我们仔细阅读一下官方文档的解释，尤其是 private_header_files 字段。

我们可以看到，private_header_files 在这里的含义是说，它本身是相对于 public 而言的，这些头文件本义是不希望暴露给用户使用的，而且也不会产生相关文档，但是在构建的时候，会出现在最终产物中，只有既没有被 public 和 private 标注的头文件，才会被认为是真正的私有头文件，且不出现在最终的产物里。

其实看起来，CocoaPods 对于 public 和 private 的官方解释是和 Xcode 中的描述一致的，两处的 Private 并非我们通常理解的 Private，它的本意更应该是开发者准备对外开放，但又没完全 Ready 的头文件，更像一个 In Progress 的含义。

这一块是不是有点让人大跌眼镜，那么，在现实世界中，我们是否正确的使用了它们呢？

为什么用原生的 hmap 不能改善编译速度？

前面我们介绍了 hmap 是什么，以及怎么开启它（启用 Build Setting 中的 Use Header Map 选项），也介绍了一些影响生成 hmap 的因素（Public，Private，Project）

那是不是我只要开启 Xcode 提供的 Use Header Map 就可以提升编译速度了呢?

很可惜，答案是不行的！

至于原因，我们就从下面的例子开始说起，假设我们有一个基于 CocoaPods 构建的全源码工程项目，它的整体结构如下：

• 首先，Host 和 Pod 是我们的两个 Project，Pods 下的 target 的产物类型为 static library。
• 其次，Host 底下会有一个同名的 Target，而 Pods 目录下会有 n+1 个 target，其中 n 取决于你依赖的组件数量，而 1 是一个名为 Pods-XXX 的 target，最后，Pods-XXX 这个 target 的产物会被 Host 里的 target 所依赖。

整个结构看起来如下所示。

当构建的产物类型为 Static Library 的时候，CocoaPods 在创建头文件产物过程中，它的逻辑大致如下:

• 不论 podspec 里如何设置 public_header_files 和 private_header_files，相应的头文件都会被设置为 Project 类型
• 在 Pods/Headers/Public 中会保存所有被声明为 public_header_files 的头文件
• 在 Pods/Headers/Private 中会保存所有头文件，不论是 public_header_files 或者 private_header_files 描述到，还是那些未被描述的，这个目录下是当前组件的所有头文件全集
• 如果 podspec 里未标注 public 和 private 的时候，Pods/Headers/Public 和 Pods/Headers/Private 的内容一样且会包含所有头文件。

正是由于这种机制，会导致一些有意思的问题发生。

• 首先，由于所有头文件都被当做最终产物保留下来，在结合 header search path 里 Pods/Headers/Private 路径的存在，我们完全可以引用到其他组件里的私有头文件，例如我只要使用 #import <SomePod/Private_Header.h> 的方式，就会命中私有文件的匹配路径。
• 其次，就是在 Static Library 的状况下，一旦我们开启了 Use Header Map，结合组件里所有头文件的类型为 Project 的情况，这个 hmap 里只会包含 #import "ClassA.h" 的键值引用，也就是说只有 #import "ClassA.h" 的方式才会命中 hmap 的策略，否则都将通过 header search path 寻找其相关路径，例如下图中的 PodB，在其 build 的过程中，Xcode 会为 PodB 生成 5 个 hmap 文件，也就是说这 5 个文件只会在编译 PodB 中使用，其中 PodB 会依赖 PodA 的一些头文件，但由于 PodA 中的头文件都是 Project 类型的，所以其在 hmap 里的 key 全部为 ClassA.h ，也就是说我们只能以 #import "ClassA.h" 的方式引入。

而我们也知道，在引用其他组件的时候，通常都会采用 #import <A/A.h> 的方式引入。至于为什么会用这种方式，一方面是这种写法会明确头文件的由来，避免问题，另一方面也是这种方式可以让我们在是否开启 clang module 中随意切换，当然还有一点就是，Apple 在 WWDC 里曾经不止一次的建议开发者使用这种方式引入头文件。

接着上面的话题来说，所以说在 Static Library 的情况下且以 #import <A/A.h> 这种标准方式引入头文件时，开启 Use Header Map 选项并不会帮我们提升编译速度。

但真的就没有办法使用 Header Map 了么？

cocoapods-hmap-prebuilt 诞生了

当然，总是有办法解决的，我们完全可以自己动手做一个基于 CocoaPods 规则下的 hmap 文件，正是基于这个想法，美团自研的 cocoapods-hmap-prebuilt 插件诞生了！

它的核心功能并不多，大概有以下几点：

• 借助 CocodPods 处理 Header Search Path 和创建头文件 soft link 的时机，构建了头文件索引表并以此生成 n+1 个 hmap 文件（n 是每个组件自己的 private header 信息，1 是所有组件公共的 public header 信息）
• 重写 xcconfig 文件里的 header search path 到对应的 hmap 文件上，一条指向组件自己的 private hmap，一条指向所有组件共用的 public hmap。
• 针对 public hmap 里的重名头文件进行了特殊处理，只允许保存组件名/头文件名方式的 key-value，排查重名头文件带来的异常行为。
• 将组件自身的 Ues Header Map 功能关闭，减少不必要的文件创建和读取

听起来可能有点绕，内容也有点多，不过这些你都不用关心，你只需要通过以下 2 个步骤就能将其使用起来：

1. 在 Gemfile 里声明插件
2. 在 Podfile 里使用插件

// this is part of Gemfile
source 'http://sakgems.sankuai.com/' do
  gem 'cocoapods-hmap-prebuilt'
  gem 'XXX'
  ...
end

// this is part of Podfile
target 'XXX' do
  plugin 'cocoapods-hmap-prebuilt'
  pod 'XXX'
  ...
end

除此之外，为了拓展其实用性，我们还提供了头文件补丁（解决重名头文件的定向选取）和环境变量注入（无侵入的在其他系统中使用）的能力，便于其在不同场景下的使用。

总结

至此，关于 cocoapods-hmap-prebuilt 的介绍就要结束了。

回看整个故事的开始，Header Map 是我在研究 Swift 和 Objective-C 混编过程中发现的一个很小的知识点，而且 Xcode 自身就实现了一套基于 Header Map 的功能，在实际的使用过程中，它的表现并不理想。

但幸运的是，在后续的探索的过程中，我们发现了为什么 Xcode 的 Header Map 没有生效，以及为什么它与 CocoaPods 出现了不兼容的情况，虽然它的原理并不复杂，核心点就是将文件查找和读取等 IO 操作编变成了内存读取操作，但结合实际的业务场景，我们发现它的收益是十分可观的。

或许这是在提醒我们，要永远对技术保持一颗好奇的心！

最后，非常感谢 @宋旭陶 同学在工作之余，和我一起完成了 cocoapods-hmap-prebuilt 插件的开发工作，也非常感谢 @叶樉 同学，在我困惑的时候给出很多富有建设性的指导和意见。

参考文档

• Apple - WWDC 2018 Behind the Scenes of the Xcode Build Process
• Apple 的 HeaderMap.cpp 源码
• 美团技术学院- 从预编译的角度理解 Swift 与 Objective-C 及混编机制

这篇文章是我早年在美团技术博客上发布的一篇文章, 部分内容可能已经过时, 请开发者注意. 将文章同步到个人博客主要是为了同步和备份.

背景

目前，开源社区和业界内已经存在一些 iOS 导航栏转场的解决方案，但对于历史包袱沉重的美团 App 而言，这些解决方案并不完美。有的方案不能满足复杂的页面跳转场景，有的方案迁移成本较大，为此我们提出了一套解决方案并开发了相应的转场库，目前该转场库已经成为美团点评多个 App 的基础组件之一。

在美团 App 开发的早期，涉及到导航栏样式改变的需求时，经常会遇到转场效果不佳或者与预期样式不符的“小问题”。在业务体量较小的情况下，为了满足快速的业务迭代，通常会使用硬编码的方式来解决这一类“小问题”。但随着美团 App 业务的高速发展，这种硬编码的方式遇到了以下的挑战：

1. 业务模块的不断增加，导致使用硬编码方式编写的代码维护成本增加，代码质量迅速下降。
2. 大型 App 的路由系统使得页面间的跳转变得更加自由和灵活，也使得导航栏相关的问题激增，不但增加了问题的排查难度，还降低了整体的开发效率。
3. App 中的导航栏属于各个业务方的公用资源，由于缺乏相应的约束机制和最佳实践，导致业务方之间的代码耦合程度不断增加。

从各个角度来看，硬编码的方式已经不能很好的解决此类问题，美团 App 需要一个更加合理、更加持久、更加简单易行的解决方案来处理导航栏转场问题。

本文将从导航栏的概念入手，通过讲解转场过程中的状态管理、转换时机和样式变化等内容，引出了在大型应用中导航栏转场的三种常见解决方案，并对美团点评的解决方案进行剖析。

重新认识导航栏

导航栏里的 MVC

在 iOS 系统中， 苹果公司不仅建议开发者遵循 MVC 开发框架，在它们的代码里也可以看到 MVC 的影子，导航栏组件的构成就是一个类似 MVC 的结构，让我们先看看下面这张图：

在这张图里，我们可以将 UINavigationController 看做是 C，UINavigationBar 看做是 V，而 UIViewController 和 UINavigationItem 组成的 Stack 可以看做是 M。这里要说明的是，每个 UIViewController 都有一个属于自己的 UINavigationItem，也就是说它们是一一对应的。

UINavigationController 通过驱动 Stack 中的 UIViewController 的变化来实现 View 层级的变化，也就是 UINavigationBar 的改变。而 UINavigationBar 样式的数据就存储在 UIViewController 的 UINavigationItem 中。这也就是为什么我们在代码里只要设置 self.navigationItem 的相关属性就可以改变 UINavigationBar 的样式。

很多时候，国内的开发者会将 UINavigationBar 和 UINavigationController 混在一起叫导航栏，这样的做法不仅增加了开发者之间的沟通成本，也容易导致误解。毕竟它们是两个完全不一样的东西。

所以本文为了更好的阐明问题，会采用英文区分不同的概念，当需要描述笼统的导航栏概念时，会使用导航栏组件一词。

通过这一节的回顾，我们应该明确了 NavigationItem、ViewController、NavigationBar 和 NavigationController 在 MVC 框架下的角色。下面我们会重新梳理一下导航栏的生命周期和各个相关方法的调用顺序。

导航栏组件的生命周期

大家可以通过下图获得更为直观的感受，进而了解到导航栏组件在 push 过程中各个方法的调用顺序。

值得注意的地方有两点：

第一个是 UINavigationController 作为 UINavigationBar 的代理，在没有特殊需求的情况下，不应该修改其代理方法，这里是通过符号断点获取它们的调用顺序。如果我们创建了一个自定义的导航栏组件系统，它的调用顺序可能会与此不同。

第二个是用虚线圈起来的方法，它们也有可能不被调用，这与 ViewController 里的布局代码相关，假设跳转到新页面后，新旧页面中的控件位置会发生变化，或者由于数据改变驱动了控件之间的约束关系发生变化，这就会带来新一轮的布局，进而触发 viewWillLayoutSubview 和 viewDidLayoutSubview 这两个方法。当然，具体的调用顺序会与业务代码紧密相关，如果我们发现顺序有所不同，也不必惊慌。

下面这张图展示了导航栏在 pop 过程中各个方法的调用顺序：

除了上面说到的两点，pop 过程中还需要注意一点，那就是从 B 返回到 A 的过程中，A 视图控制器的 viewDidLoad 方法并不会被调用。关于这个问题，只要提醒一下，大多数人都会反应过来是为什么。不过在实际开发过程中，总会有人忘记这一点。

通过这两个图，我们已经基本了解了导航栏组件的生命周期和相关方法的调用顺序，这也是后面章节的理论基础。

导航栏组件的改变与革新

导航栏组件在 iOS 11 发布时，获得了重大更新，这个更新可不是增加了一个大标题样式（Large Title Display Mode）那么简单，需要注意的地方大概有两点：

1. 导航栏全面支持 Auto Layout 且 NavigationBar 的层级发生了明显的改变，关于这一点可以阅读 UIBarButtonItem 在 iOS 11 上的改变及应对方案 。
2. 由于引进了 Safe Area 等概念，topLayoutGuide 和 bottomLayoutGuide 等属性会逐渐废弃，虽然变化不大，但如果我们的导航栏在转场过程中总是出现视图上下移动的现象，不妨从这个方面思考一下，如果想深究可以查看 WWDC 2017 Session 412。

导航栏组件到底怎么了？

经常有人说 iOS 的原生导航栏组件不好使用，抱怨主要集中在导航栏组件的状态管理和控件的布局问题上。

控件的布局问题随着 iOS 11 的到来已经变得相对容易处理了不少，但导航栏组件的状态管理仍然让开发者头疼不已。

可能已经有朋友在思考导航栏组件的状态管理到底是什么东西？不要着急，下面的章节就会做相关的介绍。

导航栏的状态管理

虽然导航栏组件的 push 和 pop 动画给人一种每次操作后都会创建一遍导航栏组件的错觉，但实际上这些 ViewController 都是由一个 NavigationController 所管理，所以你看到的 NavigationBar 是唯一的。

在 NavigationController 的 Stack 存储结构下，每当 Stack 中的 ViewController 修改了导航栏，势必会影响其他 ViewController 展示的效果。

例如下图所示的场景，如果 NavigationBar 原先的颜色是绿色，但之后进入 Stack 里的 ViewController 将 NavigationBar 颜色修改为紫色后，在此之后 push 的 ViewController 会从默认的绿色变为紫色，直到有新的 ViewController 修改导航栏颜色才会发生变化。

虽然在 push 过程中，NavigationBar 的变化听起来合情合理，但如果你在 NavigationBar 为绿色的 ViewController 里设置不当的话，那么当你 pop 回这个 ViewController 时，NavigationBar 可就不一定是绿色了，它还会保持为紫色的状态。

通过这个例子，我们大概会意识到在导航栏里的 Stack 中，每个 ViewController 都可以永久的影响导航栏样式，这种全局性的变化要求我们在实际开发中必须坚持“谁修改，谁复原”的原则，否则就会造成导航栏状态的混乱。这不仅仅是样式上的混乱，在一些极端状况下，还有可能会引起 Stack 混乱，进而造成 Crash 的情况。

导航栏样式转换的时机

我们刚才提到了“谁修改，谁复原”的原则，但何时修改，何时复原呢？

对于那些存储在 Stack 中的 ViewController 而言，它其实就是在不断的经历 appear 和 disappear 的过程，结合 ViewController 的生命周期来看，viewWillAppear: 和 viewWillDisappear: 是两个完美的时间节点，但很多人却对这两个方法的调用存在疑惑。

苹果公司在它的 API 文档中专门用了一段文字来解答大家的疑惑，这段文字的标题为《Handling View-Related Notifications》，在这里我们直接引用原文：

这里很好的解释了所有的 will 系列方法和 did 系列方法的对应关系，同时也给我们吃了一个定心丸，那就是在 appearing 和 disappearing 状态之间会由 will 系列方法进行衔接，避免了状态中断。这对于连续 push 或者连续 pop 的情况是及其重要的，否则我们无法做到 “谁修改，谁复原”的原则。

通常来说，如果只是一个简单的导航栏样式变化，我们的代码结构大体会如下所示：

- (void)viewWillAppear:(BOOL)animated{
    [super viewWillAppear:animated];
    // MARK: change the navigationbar style 
}

- (void)viewWillDisappear:(BOOL)animated{
    [super viewWillDisappear:animated];
    // MARK: restore the navigationbar style
}

现在，我们明确了修改时机，接下来要明确的就是导航栏的样式会进行怎样的变化。

导航栏的样式变化

对于不同 ViewController 之间的导航栏样式变化，大多可以总结为两种情况：

1. 导航栏的显示与否
2. 导航栏的颜色变化

导航栏的显示与否

对于显示与否的问题，可以在上一节提到的两个方法里调用 setNavigationBarHidden:animated: 方法，这里需要提醒的有两点：

1. 在导航栏转场的过程中，不要天真的以为 setNavigationBarHidden: 和 setNavigationBarHidden:animated: 的效果是一样的，直接使用 setNavigationBarHidden: 会造成导航栏转场过程中的闪现、背景错乱等问题，这一现象在使用手势驱动转场的场景中十分常见，所以正确的方式是使用带有 animated 参数的 API。
2. 在 push 和 pop 的方法里也会带有 animated 参数，尽量保证与 setNavigationBarHidden:animated: 中的 animated 参数一致。

导航栏的颜色变化

颜色变化的问题就稍微复杂一些，在 iOS 7 后，导航栏增加了 translucent 效果，这使得导航栏背景色的变化出现了两种情况：

1. translucent 属性值为 YES 的前提下，更改导航栏的背景色。
2. translucent 属性值为 NO 的前提下，更改导航栏的背景色。

对于第一种情况，我们需要调用 UINavigationBar 的 setBackgroundColor: 方法。

对于第二种情况我们需要调用 UINavigationBar 的 setBackgroundImage:forBarMetrics: 方法。

对于第二种情况，这里有三点需要提示：

1. 在设置透明效果时，我们通常可以直接设置一个 [UIImage new] 创建的对象，无须创建一个颜色为透明色的图片。
2. 在使用 setBackgroundImage:forBarMetrics: 方法的过程中，如果图像里存在 alpha 值小于 1.0 的像素点，则 translucent 的值为 YES，反之为 NO。也就是说，如果我们真的想让导航栏变成纯色且没有 translucent 效果，请保证所有像素点的 alpha 值等于 1。
3. 如果设置了一个完全不透明的图片且强行将 NavigationBar 的 translucent 属性设置为 YES 的话，系统会自动修正这个图片并为它添加一个透明度，用于模拟 translucent 效果。
4. 如果我们使用了一个带有透明效果的图片且导航栏的 translucent 效果为 NO 的话，那么系统会在这个带有透明效果的图片背后，添加一个不透明的纯色图片用于整体效果的合成。这个纯色图片的颜色取决于 barStyle 属性，当属性为 UIBarStyleBlack 时为黑色，当属性为 UIBarStyleDefault 时为白色，如果我们设置了 barTintColor，则以设置的颜色为基准。

分清楚 transparent，translucent，opaque，alpha 和 opacity 也挺重要

在刚接触导航栏 API 时，许多人经常会把文档里的这些英文词搞混，也不太明白带有这些词的变量为什么有的是布尔型，有的是浮点型，总之一切都让人很困惑。

在这里将做了一个总结，这对于理解 Apple 的 API 设计原则十分有帮助。

transparent， translucent， opaque 三个词经常会用在一起，它用于描述物体的透光强度，为了让大家更好的理解这三个词，这里做了三个比喻：

• transparent 是指透明，就好比我们可以透过一面干净的玻璃清楚的看到外面的风景。
• translucent 是指半透明，就好比我们可以透过一面有点磨砂效果的塑料墙看外面的风景，不能说看不见，但我们肯定看不清。
• opaque 是指不透明，就好比我们透过一个堵石墙是看不见任何外面的东西，眼前看到的只有这面墙。

这三个词更多的是用来表述一种状态，不需要量化，所以这与这三个词相关的属性，一般都是 BOOL 类型。

alpha 和 opacity 经常会在一起使用，它要表示的就是透明度，在 Web 端这两个属性有着明显的区别。

在 Web 端里，opacity 是设定整个元素的透明值，而 alpha 一般是放在颜色设置里面，所以我们可以做到对特定对元素的某个属性设定 alpha，比如背景、边框、文字等。

div {
  width: 100px;
  height: 100px;
  background: rgba(0,0,0,0.5);
  border: 1px solid #000000;
  opacity: 0.5;
}

这一概念同样适用于 iOS 里的概念，比如我们可以通过 alpha 通道单独的去设置 backgroudColor、borderColor，它们互不影响，且有着独立的 alpha 通道，我们也可以通过 opacity 统一设置整个 view 的透明度。

但与 Web 端不一致的是，iOS 里面的 view 不光拥有独立的 alpha 属性，同时也是基于 CALayer，所以我们可以看到任意 UIView 对象下面都会有一个 layer 的属性，用于表明 CALayer 对象。view 的 alpha 属性与 layer 里面的 opacity 属性是一个相等的关系，需要注意的是 view 上的 alpha 属性是 Web 端并不具备的一个能力，所以笔者认为：在 iOS 中去说 alpha 时，要区分是在说 view 上的属性，还是在说颜色通道里的 alpha。

由于这两个词都是在描述程度，所以我们看到它们都是 CGFloat 类型：

转场过程中需要注意的问题和细节

说完了导航栏的转场时机和转场方式，其实大体上你已经能处理好不同样式间的转换，但还有一些细节需要你去考虑，下面我们来说说其中需要你关注的两点。

translucent 属性带来的布局改变

translucent 会影响导航栏组件里 ViewController 的 View 布局，这里需要大家理清 5 个 API 的使用场景：

1. edgesForExtendedLayout
2. extendedLayoutIncluedsOpaqueBars
3. automaticallyAdjustScrollViewInsets
4. contentInsetAdjustmentBehavior
5. additionalSafeAreaInsets

前三个 API 是 iOS 11 之前的 API，它们之间的区别和联系在 Stack Overflow 上有一个比较精彩的回答 - Explaining difference between automaticallyAdjustsScrollViewInsets, extendedLayoutIncludesOpaqueBars, edgesForExtendedLayout in iOS7，我在这里就不做详细阐述，总结一下它的观点就是:

如果我们先定义一个 UINavigationController，它里面包含了多个 UIViewController，每个 UIViewController 里面包含一个 UIView 对象：

• 那么 edgesForExtendedLayout 是为了解决 UIViewController 与 UINavigationController 的对齐问题，它会影响 UIViewController 的实际大小，例如 edgesForExtendedLayout 的值为 UIRectEdgeAll 时，UIViewController 会占据整个屏幕的大小。
• 当 UIView 是一个 UIScrollView 类或者子类时，automaticallyAdjustsScrollViewInsets 是为了调整这个 UIScrollView 与 UINavigationController 的对齐问题，这个属性并不会调整 UIViewController 的大小。
• 对于 UIView 是一个 UIScrollView 类或者子类且导航栏的背景色是不透明的状态时，我们会发现使用 edgesForExtendedLayout 来调整 UIViewController 的大小是无效的，这时候你必须使用 extendedLayoutIncludesOpaqueBars 来调整 UIViewController 的大小，可以认为 extendedLayoutIncludesOpaqueBars 是基于 automaticallyAdjustsScrollViewInsets 诞生的，这也是为什么经常会看到这两个 API 会同时使用。

这些调整布局的 API 背后是一套基于 topLayoutGuide 和 bottomLayoutGuide 的计算而已，在 iOS 11 后，Apple 提出了 Safe Area 的概念，将原先分裂开来的 topLayoutGuide 和 bottomLayoutGuide 整合到一个统一的 LayoutGuide 中，也就是所谓的 Safe Area，这个改变看起来似乎不是很大，但它的出现确实方便了开发者。

如果想对 Safe Area 带来的改变有更全面的认识，十分推荐阅读 Rosberry 的工程师 Evgeny Mikhaylov 在 Medium 上的文章 iOS Safe Area，这篇文章基本涵盖了 iOS 11 中所有与 Safe Area 相关的 API 并给出了真正合理的解释。

这里只说一下 contentInsetAdjustmentBehavior 和 additionalSafeAreaInsets 两个 API。

对于 contentInsetAdjustmentBehavior 属性而言，它的诞生也意味着 automaticallyAdjustsScrollViewInsets 属性的失效，所以我们在那些已经适配了 iOS 11 的工程里能看到如下类似的代码：

if (@available(iOS 11.0, *)) {
    self.tableView.contentInsetAdjustmentBehavior = UIScrollViewContentInsetAdjustmentNever;
} else {
    self.automaticallyAdjustsScrollViewInsets = NO;
}

此处的代码片段只是一个示例，并不适用所有的业务场景，这里需要着重说明几个问题：

1. 关于 contentInsetAdjustmentBehavior 中的 UIScrollViewContentInsetAdjustmentAutomatic 的说明一直很“模糊”，通过 Evgeny Mikhaylov 的文章，我们可以了解到他在大多数情况下会与 UIScrollViewContentInsetAdjustmentScrollableAxes 一致，当且仅当满足以下所有条件时才会与 UIScrollViewContentInsetAdjustmentAlways 相似：
   • UIScrollView 类型的视图在水平轴方向是可滚动的，垂直轴是不可滚动的。
   • ViewController 视图里的第一个子控件是 UIScrollView 类型的视图。
   • ViewController 是 navigation 或者 tab 类型控制器的子视图控制器。
   • 启用 automaticallyAdjustsScrollViewInsets。
2. iOS 11 后，通过 contentInset 属性获取的偏移量与 iOS 10 之前的表现形式并不一致，需要获取 adjustedContentInset 属性才能保证与之前的 contentInset 属性一致，这样的改变需要我们在代码里对不同的版本进行适配。

对于 additionalSafeAreaInsets 而言，如果系统提供的这几种行为并不能满足我们的布局要求，开发者还可以考虑使用 additionalSafeAreaInsets 属性做调整，这样的设定使得开发者可以更加灵活，更加自由的调整视图的布局。

backIndicator 上的动画

苹果提供了许多修改导航栏组件样式的 API，有关于布局的，有关于样式的，也有关于动画的。backIndicatorImage 和 backIndicatorTransitionMaskImage 就是其中的两个 API。

backIndicatorImage 和 backIndicatorTransitionMaskImage 操作的是 NavigationBar 里返回按钮的图片，也就是下图红色圆圈所标注的区域。

想要成功的自定义返回按钮的图标样式，我们需要同时设置这两个 API ，从字面上来看，它们一个是返回图片本身，另一个是返回图片在转场时用到的 mask 图片，看起来不怎么难，我们写一段代码试试效果：

self.navigationController.navigationBar.backIndicatorImage = [UIImage imageNamed:@"backArrow"];
self.navigationController.navigationBar.backIndicatorTransitionMaskImage = [UIImage imageNamed:@"backArrowMask"];

代码里的图片如下所示：

也许大多数人在这里会都认为，mask 图片会遮挡住文字使其在遇到返回按钮右边缘的时候就消失。但实际的运行效果是怎么样子的呢？我们来看一下：

在上面的图片中，我们可以看到返回按钮的文字从返回按钮的图片下面穿过并且文字被图片所遮挡，这种动画看起来十分奇怪，这是无法接受的。我们需要做点修改：

self.navigationController.navigationBar.backIndicatorImage = [UIImage imageNamed:@"backArrow"];
self.navigationController.navigationBar.backIndicatorTransitionMaskImage = [UIImage imageNamed:@"backArrow"];

这一次我们将 backIndicatorTransitionMaskImage 改为 indicatorImage 所用的图片。

到这里，可能大多数人都会好奇，这代码也能行？让我们看下它实际的效果：

在上面的图中，我们看到文字在到达图片的右边缘时就从下方穿过并被完全遮盖住了，这种动画效果虽然比上面好一些，但仍然有改进的空间，不过这里我们先不继续优化了，我们先来讨论一下它们背后的运作原理。

iOS 系统会将 indicatorImage 中不透明的颜色绘制成返回按钮的图标， indicatorTransitionMaskImage 与 indicatorImage 的作用不同。indicatorTransitionMaskImage 将自身不透明的区域像 mask 一样作用在 indicatorImage 上，这样就保证了返回按钮中的文字像左移动时，文字只出现在被 mask 的区域，也就是 indicatorTransitionMaskImage 中不透明的区域。

掌握了原理，我们来解释下刚才的两种现象：

在第一种实现中，我们提供的 indicatorTransitionMaskImage 覆盖了整个返回按钮的图标，所以我们在转场过程中可以清晰的看到返回按钮的文字。

在第二种实现中，我们使用 indicatorImage 作为 indicatorTransitionMaskImage，记住文字是只能出现在 indicatorTransitionMaskImage 里不透明的区域，所以显然返回按钮中的文字会在图标的最右边就已经被遮挡住了，因为那片区域是透明的。

那么前面提到的进一步优化指的是什么呢？

让我们来看一下下面这个示例图，为了更好的区分，我们将 indicatorTransitionMaskImage 用红色进行标注。黑色仍然是 indicatorImage。

按照刚才介绍的原理，我们应该可以理解，现在文字只会出现在红色区域，那么它的实际效果是什么样子的呢，我们可以看下图：

现在，一个完美的返回动画，诞生啦！

导航栏的跳转或许可以这么玩儿

前两章的铺垫就是为了这一章的内容，所以现在让我们开始今天的大餐吧。

这样真的好么？

刚才我们说了两个页面间 NavigationBar 的样式变化需要在各自的 viewWillAppear: 和 viewWillDisappear: 中进行设置。那么问题就来了：这样的设置会带来什么问题呢？

试想一下，当我们的页面会跳到不同的地方时，我们是不是要在 viewWillAppear: 和 viewWillDisappear: 方法里面写上一堆的判断呢？如果应用里还有 router 系统的话，那么页面间的跳转将变得更加不可预知，这时候又该如何在 viewWillAppear: 和 viewWillDisappear: 里做判断呢？

现在我们的问题就来了，如何让导航栏的转场更加灵活且相互独立呢？

常见的解决方案如下所示：

1. 重新实现一个类似 UINavigationController 的容器类视图管理器，这个容器类视图管理器做好不同 ViewController 间的导航栏样式转换工作，而每个 ViewController 只需要关心自身的样式即可。

2. 将系统原有导航栏的背景设置为透明色，同时在每个 ViewController 上添加一个 View 或者 NavigationBar 来充当我们实际看到的导航栏，每个 ViewController 同样只需要关心自身的样式即可。

3. 在转场的过程中隐藏原有的导航栏并添加假的 NavigationBar，当转场结束后删除假的 NavigationBar 并恢复原有的导航栏，这一过程可以通过 Swizzle 的方式完成，而每个 ViewController 只需要关心自身的样式即可。

这三种方案各有优劣，我们在网上也可以看到很多关于它们的讨论。

例如方案一，虽然看起来工作量大且难度高，但是这个工作一旦完成，我们就会将处理导航栏转场的主动权牢牢抓在手里。但这个方案的一个弊端就是，如果苹果修改了导航栏的整体风格，就好比 iOS 11 的大标题特效，那么工作量就来了。

对于方案二而言，虽然看起来简单易用，但这需要一个良好的继承关系，如果整个工程里的继承关系混乱或者是历史包袱比较重，后续的维护就像“打补丁”一样，另外这个方案也需要良好的团队代码规范和完善的技术文档来做辅助。

对于方案三而言，它不需要所谓的继承关系，使用起来也相对简单，这对于那些继承关系和历史包袱比较重的工程而言，这一个不错的解决方案，但在解决 Bug 的时候，Swizzle 这种方式无疑会增加解决问题的时间成本和学习成本。

我们的解决方案

在美团 App 的早期，各个业务方都想充分利用导航栏的能力，但对于导航栏的状态维护缺乏理解与关注，随着业务方的增加和代码量的上升，与导航栏相关的问题逐渐暴露出来，此时我们才意识到这个问题的严重性。

大型 App 的导航栏问题就像一个典型的“公地悲剧”问题。在软件行业，公用代码的所有权可以被视作“公地”，因为不注重长期需求而容易遭到消耗。如果开发人员倾向于交付“价值”，而以可维护性和可理解性为代价，那么这个问题就特别普遍了。如果是这种情况，每次代码修改将大大减少其总体质量，最终导致软件的不可维护。

所以解决这个问题的核心在于：明确公用代码的所有权，并在开发期施加约束。

明确公用代码的所有权，可以理解为将导航栏相关的组件抽离成一个单独的组件，并交由特定的团队维护。而在开发期施加约束，则意味着我们要提供一套完整的解决方案让各个业务方遵守。

这一节我们会以美团内部的解决方案为例，讲解如何实现一个流畅的导航栏跳转过程和相关使用方法。

设计理念

使用者只用关心当前 ViewController 的 NavigationBar 样式，而不用在 push 或者 pop 的时候去处理 NavigationBar 样式。

举个例子来说，当从 A 页面 push 到 B 页面的时候，转场库会保存 A 页面的导航栏样式，当 pop 回去后就会还原成以前的样式，因此我们不用考虑 pop 后导航栏样式会改变的情况，同时我们也不必考虑 push 后的情况，因为这个是页面 B 本身需要考虑的。

使用方法

转场库的使用十分简单，我们不需要 import 任何头文件，因为它在底层通过 Method Swizzling 进行了处理，只需要在使用的时候遵循下面 4 点即可：

• 当需要改变导航栏样式的时候，在视图控制器的 viewDidLoad 或者 viewWillAppear: 方法里去设置导航栏样式。
• 用 setBackgroundImage:forBarMetrics: 方法和 shadowImage 属性去修改导航栏的背景样式。
• 不要在 viewWillDisappear: 里添加针对导航栏样式修改的代码。
• 不要随意修改 translucent 属性，包括隐式的修改和显示的修改。

基本原理

以上，我们讲完了设计理念和使用方法，那么我们来看看美团的转场库到底做了什么？

从大方向上来看，美团使用的是前面所说的第三种方案，不过它也有一些自己独特的地方，为了更好的让大家理解整个过程，我们设计这样一个场景，从页面 A push 到页面 B，结合之前探讨过的方法调用顺序，我们可以知道几个核心方法的调用顺序大致如下：

1. 页面 A 的 pushViewController:animated:
2. 页面 B 的 viewDidLoad or viewWillAppear:
3. 页面 B 的 viewWillLayoutSubviews
4. 页面 B 的 viewDidAppear:

在 push 过程的开始，转场库会在页面 A 自身的 view 上添加一个与导航栏一模一样的 NavigationBar 并将真的导航栏隐藏。之后这个假的导航栏会一直存在页面 A 上，用于保留 A 离开时的导航栏样式。

等到页面 B 调用 viewDidLoad 或者 viewWillAppear: 的时候，开发者在这里自行设置真的导航栏样式。转场库在这里会对页面布局做一些修正和辅助操作，但不会影响导航栏的样式。

等到页面 B 调用 viewWillLayoutSubviews 的时候，转场库会在页面 B 自身的 view 上添加一个与真的导航栏一模一样的 NavigationBar，同时将真的导航栏隐藏。此时不论真的导航栏，还是假的导航栏都已经与 viewDidLoad 或者 viewWillAppear: 里设置的一样的。

等到页面 B 调用 viewDidAppear: 的时候，转场库会将假的导航栏样式设置到真的导航栏中，并将假的导航栏从视图层级中移除，最终将真的导航栏显示出来。

为了让大家更好地理解上面的内容，请参考下图：

说完了 push 过程，我们再来说一下从页面 B pop 回页面 A 的过程，几个核心方法的调用顺序如下：

1. 页面 B 的 popViewControllerAnimated:
2. 页面 A 的 viewWillAppear:
3. 页面 A 的 viewDidAppear:

在 pop 过程的开始，转场库会在页面 B 自身的 view 上添加一个与导航栏一模一样的 NavigationBar 并将真的导航栏隐藏，虽然这个假的导航栏会一直存在于页面 B 上，但它自身会随着页面 B 的 dealloc 而消亡。

等到页面 A 调用 viewWillAppear: 的时候，开发者在这里自行设置真的导航栏样式。当然我们也可以不设置，因为这时候页面 A 还持有一个假的导航栏，这里还保留着我们之前在 viewDidLoad 里写的导航栏样式。

等到页面 A 调用 viewDidAppear: 的时候，转场库会将假的导航栏样式设置到真的导航栏中，并将假的导航栏从视图层级中移除，最终将真的导航栏显示出来。

同样，我们可以参考下面的图来理解上面所说的内容：

现在，大家应该对我们美团的解决方案有了一定的认识，但在实际开发过程中，还需要考虑一些布局和适配的问题。

最佳实践

在维护这套转场方案的时间里，我们总结了一些此类方案的最佳实践。

判断导航栏问题的基本准则

如果发现导航栏在转场过程中出现了样式错乱，可以遵循以下几点基本原则：

• 检查相应 ViewController 里是否有修改其他 ViewController 导航栏样式的行为，如果有，请做调整。
• 保证所有对导航栏样式变化的操作出现在 viewDidLoad 和 viewWillAppear: 中，如果在 viewWillDisappear: 等方法里出现了对导航栏的样式修改的操作，如果有，请做调整。
• 检查是否有改动 translucent 属性，包括显示修改和隐式修改，如果有，请做调整。

只关心当前页面的样式

永远记住每个 ViewController 只用关心自己的样式，设置的时机点在 viewWillAppear: 或者 viewDidLoad 里。

透明样式导航栏的正确设置方法

如果需要一个透明效果的导航栏，可以使用如下代码实现：

[self.navigationController.navigationBar setBackgroundImage:[UIImage new] forBarMetrics:UIBarMetricsDefault];
self.navigationController.navigationBar.shadowImage = [UIImage new];

导航栏的颜色渐变效果

如果需要导航栏实现随滚动改变整体 alpha 值的效果，可以通过改变 setBackgroundImage:forBarMetrics: 方法里 image 的 alpha 值来达到目标，这里一般是使用监听 scrollView.contentOffset 的手段来做。请避免直接修改 NavigationBar 的 alpha 值。

还有一点需要注意的是，在页面转场的过程中，也会触发 contentOffset 的变化，所以请尽量在 disappear 的时候取消监听。否则会容易出现导航栏透明度的变化。

导航栏背景图片的规范

请避免背景图里的像素点没有 alpha 通道或者 alpha 全部等于 1，容易触发 translucent 的隐式改变。

如果真的要隐藏导航栏

如果我们需要隐藏导航栏，请保证所有的 ViewController 能坚持如下原则：

1. 每个 ViewController 只需要关心当前页面下的导航栏是否被隐藏。
2. 在 viewWillAppear: 中，统一设置导航栏的隐藏状态。
3. 使用 setNavigationBarHidden:animated: 方法，而不是 setNavigationBarHidden:。

转场动画与导航栏隐藏动画的一致性

如果在转场的过程中还会显示或者隐藏导航栏的话，请保证两个方法的动画参数一致。

- (void)viewWillAppear:(BOOL)animated{
    [self.navigationController setNavigationBarHidden:YES animated:animated];
}

导航栏固有的系统问题

目前已知的有两个系统问题如下：

1. 当前后两个 ViewController 的导航栏都处于隐藏状态，然后在后一个 ViewController 中使用返回手势 pop 到一半时取消，再连续 push 多个页面时会造成导航栏的 Stack 混乱或者 Crash。
2. 当页面的层级结构大体如下所示时，在红色导航栏的 Stack 中，返回手势会大概率的出现跨层级的跳转，多次后会导致整个导航栏的 Stack 错乱或者 Crash。

导航栏内置组件的布局规范

导航栏里的组件布局在 iOS 11 后发生了改变，原有的一些解决方案已经失效，这些内容不在本篇文章的讨论范围之内，推荐阅读UIBarButtonItem 在 iOS 11 上的改变及应对方案，这篇文章详细的解释了 iOS 11 里的变化和可行的应对方案。

总结

本文涉及内容较多，从 iOS 系统下的导航栏概念到大型应用里的最佳实践，这里我们总结一下整篇文章的核心内容：

• 理解导航栏组件的结构和相关方法的生命周期。
  • 导航栏组件的结构留有 MVC 架构的影子，在解决问题时，要去相应的层级处理。
  • 转场问题的关键点是方法的调用顺序，所以了解生命周期是解决此类问题的基础。
• 状态管理，转换时机和样式变化是导航栏里常见问题的三种表现形式，遇到实际问题时需要区分清楚。
  • 状态管理要坚持“谁修改，谁复原”的原则。
  • 转换时机的设定要做到连续可执行。
  • 样式变化的核心点是导航栏的显示与否与颜色变化。
• 为了更好的配合大型应用里的路由系统，导航栏转场的常见解决方案有三种，各有利弊，需要根据自身的业务场景和历史包袱做取舍。
  • 解决方案1：自定义导航栏组件。
  • 解决方案2：在原有导航栏组件里添加 Fake Bar。
  • 解决方案3：在导航栏转场过程中添加 Fake Bar。
• 美团在实际开发过程中采用了第三种方案，并给出了适合美团 App 的最佳实践。

参考链接

• UIAppearance Tutorial: Getting Started
• KMNavigationBarTransition

问题的由来

最近在开发过程中，遇到了一个自己还无法回答的问题，就是 Reactive Cocoa 里的两个 .d 文件到底有啥用，以及怎么用？

DTrace

DTrace 是一个动态追踪技术，说的可能更接地气一点，就是可以使用 DTrace 附加在一个已经运行的程序上，且不会打断当前程序的运行，也不需要重新编译或者启动此程序。

乍一听，感觉很不错，好像我们可以搞点事情了，但放到 macOS 和 iOS 的场景下就有了一些限制。

DTrace 只能在 macOS 上运行，Apple 也在 iOS 上使用 DTrace，用以支持像 Instruments 这样的工具，但对于第三方开发者，DTrace 只能运行于 macOS 或 iOS 模拟器。

基本概念

在 DTrace 里有两个比较重要的概念，它们分别是probe(探针)和 dtrace file(DTrace 脚本)。

探针是指我们利用在代码里埋的点，插的桩，它有一套标准的定义，本文在这里不展开了，感兴趣可以阅读这个资料：DTrace Book。

DTrace 脚本，是用 D 语言编写的脚本，既可以用 DTrace 脚本声明 probe，也可以触发 probe。

声明 probe 的例子:

// 声明 probe               
provider syncengine_sync {
    probe strategy_go_to_state(int);
}

或者调用 probe 的例子:

// 调用 probe  
syncengine_sync*:::strategy_go_to_state
{
    printf("Transitioning to state %d\n", arg0);
}

那么怎么启用 DTrace 呢？整体来说，有两种途径：

• 使用 dtrace 脚本来触发，也就是 .d 文件
• 使用 dtrace 命令来触发，也就是命令行里的 dtrace 命令

DTrace 的使用场景

那么从使用者的角度来说，DTrace 只适用于两种场景：

• 追踪系统内核代码：使用者只需要直接调用系统预埋的 probe 即可。
• 追踪 App 侧的自定义代码：使用者一方面需要在 App 侧埋 probe，另一方面也需要去调用自己埋的 probe。

对于追踪系统内核的代码，其实有很多文章在说明，这里就不展开来说了，感兴趣可以看看网上的文章, 大多都是在将这种场景的使用方式.

今天的目标也是为了解释第二个场景，进而说明 Reactive Cocoa 里的 .d 文件的用途。

在自己的代码里使用 DTrace 技术

这里我们设计一个 CLI 工具，这个 CLI 工具不会停止，也不会做任何事儿，它的逻辑大概如下（其实就是一个无限循环）:

#import <Foundation/Foundation.h>

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        while (1) {  }
    }
    return 0;
}

声明探针

此时我们在工程里创建一个 provider.d 文件声明一个自定义的 probe

provider zsq {
    probe go();
};

此时的文件目录是如下

▶ tree
.
├── main.m
└── zsq.d

预埋探针

在 Xcode 里面的 build rule 会有这么一个自动化操作，如果判断出目标文件是 .d 文件，也就是 dtrace 文件，会生成对应的 .h 文件。

结合上面的例子，此时 Xcode 的 build system 就会生成一个 zsq.h 文件，在 build log 里我们可以查看到它。

此时我们可以看一下 zsq.h 里的内容，对我们比较有用的是两个基于探针行为定义的宏 ZSQ_GO_ENABLED和 ZSQ_GO，感兴趣可以展开下面的代码来查看。

/*
 * Generated by dtrace(1M).
 */

#ifndef_ZSQ_H
#define_ZSQ_H

#if !defined(DTRACE_PROBES_DISABLED) || !DTRACE_PROBES_DISABLED
#include <unistd.h>

#endif /* !defined(DTRACE_PROBES_DISABLED) || !DTRACE_PROBES_DISABLED */

#ifdef__cplusplus
extern "C" {
#endif

#define ZSQ_STABILITY "___dtrace_stability$zsq$v1$1_1_0_1_1_0_1_1_0_1_1_0_1_1_0"

#define ZSQ_TYPEDEFS "___dtrace_typedefs$zsq$v2"

#if !defined(DTRACE_PROBES_DISABLED) || !DTRACE_PROBES_DISABLED

#defineZSQ_GO() \
do { \
__asm__ volatile(".reference " ZSQ_TYPEDEFS); \
__dtrace_probe$zsq$go$v1(); \
__asm__ volatile(".reference " ZSQ_STABILITY); \
} while (0)
#defineZSQ_GO_ENABLED() \
({ int _r = __dtrace_isenabled$zsq$go$v1(); \
__asm__ volatile(""); \
_r; })


extern void __dtrace_probe$zsq$go$v1(void);
extern int __dtrace_isenabled$zsq$go$v1(void);

#else

#defineZSQ_GO() \
do { \
} while (0)
#defineZSQ_GO_ENABLED() (0)

#endif /* !defined(DTRACE_PROBES_DISABLED) || !DTRACE_PROBES_DISABLED */


#ifdef__cplusplus
}
#endif

#endif/* _ZSQ_H */

通过这个自动生成的头文件，我们就可以在自己的代码中预埋自定义的 probe，大体的逻辑使用方式就是先判断 probe 是否 enable，如果 enable，再真的执行它。

#import <Foundation/Foundation.h>
#import "zsq.h"

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        while (1) {
            if(ZSQ_GO_ENABLED()) {
                NSLog(@"Hello");
                ZSQ_GO();
            }
        }
    }
    return 0;
}

触发探针

首先正常启用 CLI 命令后

// 启用 cli 命令行工具
..../SQTool

在没有触发 DTrace 之前，终端不会有任何输出

此时我们在另一个 terminal 里去启用 dtrace 来追踪预埋的探针

// -s 参数的 zsq.d 指的是定义的 probe 文件， 
// -P 参数的 zsq30629 指的是 probe name + PID, probe name 在 .d 里查看， PID 命令可以通过 ps -A 查看
sudo dtrace -s zsq.d -P zsq30629
// 或者
sudo dtrace -P zsq30629 // 如果你的 .d 文件已经被 dtrace 加载了，就无须重复使用 -s 参数重复加载

此时，dtrace 服务被激活，CLI 里预埋的 probe 生效，我们就看到执行 CLI 里的 terminal 不断的在输出 Hello，也就是被 ZSQ_GO_ENABLED() 包裹的逻辑之一。

总结

至此，我们完成了自定义探针的定义，预埋和调用。

那基于前面的 demo，我们来理解下 Reactive Cocoa 里的 .d 文件到底干了什么？以及怎么用？

以 Reactive Cocoa 里的 RACCompoundDisposableProvider 为例，它只是定义了一个 provider 为 RACCompoundDisposable，probe 为 added 和 removed 的探针。

而在 RACCompoundDisposable.m 中，会在 addDisposable 中预埋 RACCOMPOUNDDISPOSABLE_ADDED 的探针，感兴趣可以展开下面的代码来查看。

- (void)addDisposable:(RACDisposable *)disposable {
NSCParameterAssert(disposable != self);
if (disposable == nil || disposable.disposed) return;

BOOL shouldDispose = NO;

OSSpinLockLock(&_spinLock);
{
if (_disposed) {
shouldDispose = YES;
} else {
#if RACCompoundDisposableInlineCount
for (unsigned i = 0; i < RACCompoundDisposableInlineCount; i++) {
if (_inlineDisposables[i] == nil) {
_inlineDisposables[i] = disposable;
goto foundSlot;
}
}
#endif

if (_disposables == NULL) _disposables = RACCreateDisposablesArray();
CFArrayAppendValue(_disposables, (__bridge void *)disposable);

if (RACCOMPOUNDDISPOSABLE_ADDED_ENABLED()) {
RACCOMPOUNDDISPOSABLE_ADDED(self.description.UTF8String, disposable.description.UTF8String, CFArrayGetCount(_disposables) + RACCompoundDisposableInlineCount);
}

#if RACCompoundDisposableInlineCount
foundSlot:;
#endif
}
}
OSSpinLockUnlock(&_spinLock);

// Performed outside of the lock in case the compound disposable is used
// recursively.
if (shouldDispose) [disposable dispose];
}

那么基于这个探针，我们就可以使用 dtrace 去追踪 add 的行为。

那这种功能有什么用呢？

如果你在开发前端的时候使用 redux，估计你八成会使用到这样的一个 debug tool - reaction，它能将 saga 里的每个动作，展示在 debug tool 里面。

那么同理到我们的 Reactive Cocoa 中，我们就可以搞一个 debug tool 实时监控代码里某些行为，方便我们调试。

那 .d 文件对于我们意味着什么？

从组件化角度看，分为两种业务场景，一种是源码形式，一种是二进制形式

• 在源码形式下，需要保留 .d 文件：由于组件的内的 .m 文件还会依赖 由 .d 自动生成的 .h 文件，如果想让编译通过，就需要保留 .d 文件。例如 RACCompoundDisposable.m 会依赖 RACCompoundDisposableProvider.d 生成的 RACCompoundDisposableProvider.h 文件，
• 在二进制形式下，不需要保留 .d 文件：由于组件内的 .m 文件已经被编译成二进制，不再需要编译行为，.d 文件已经没有存在价值，也就不依赖 RACCompoundDisposableProvider.d 生成的 RACCompoundDisposableProvider.h 文件，

那结合上面的两个视角，我们在 CI 上又应该干点什么呢？

• 基于现在的状况（即没有人把 .d 生成的 .h 放到公开头文件里），我们就可以把把 .d 文件当做 .m 文件一样看待，即在二进制产物中删掉 .d 文件即可。

那么可能就会有人，为啥不能把 .d 生成的 .h 放到公开头文件里呢，这个行为合理么？

• 我认为是没有必要的，原因大致如下：
  • 首先 .d 文件生成的 .h 只是与 probe 相关的逻辑，为自己的组件提供了 dtrace 能力，方便自己的调试或者行为追踪。
  • 这种埋点自查的能力应当只在自己的组件内（例如组件 A）使用，即使提供给外界（组件 B）使用，那么组件 B 也无法追踪组件 A 的行为，组件 B 只能追踪自己的行为，如果想追踪自己的行为，那又为什么要用 A 里的 probe 呢？对吧。自己追踪自己就好，不要用别人的探针，避免歧义。
  • 所以这个 .d 文件从原理上是可以放到公开的 .h 文件中，但这并不是那么合理，所以从实际使用的角度上来说，是不应该将 .d 自动生成的 .h 文件放到公开的 .h 文件中。

好了，说到这里，我想你也大概明白了 .d 文件的作用和在组件化的时候要怎么对待它了，希望这篇文章能对你有所帮助！

参考资料

• Hooked on DTrace, part 1
• Hooked on DTrace, part 2
• Hooked on DTrace, part 3
• Hooked on DTrace, part 4
• DTrace
• DTrace Book

回顾 2020

在去年的《一次关于 Swift 在 iOS 生态圈里的现状调研》一文中, 我们分析了整个大环境的现状，在文章发表后得到了大家的广泛关注，时隔一年，我们再来看看有什么变化吧？

Swift 语言

版本变化

首先从去年的 5.2 版本，到现在即将发布 5.4 版本，Swift 经历了 2 个小的版本变化，分别是 5.3 和 5.4

其中 5.3 版本给出了以下几个语言特性：

• SE-0276：catch 语句在捕获 error 的时候，可以更加灵活自由，例如一次捕获多个 error 或者对 error 的值进行绑定。
• SE-0279：支持多个尾随闭包，这个特性主要是为 SwiftUI 准备的。
• SE-0266：enum 支持 comparable 协议，并根据顺序自行决定大小
• SE-0269：在某些场景下可以避免 self 关键字的声明
• SE-0281：通过 @main 关键字定位程序入口
• SE-0267：在函数的泛型和扩展中就可以使用包含 where 关键字的语句
• SE-0280：protocol witness 匹配模型在枚举值中的加强
• SE-0277：新增 Float16 的数据类型
• SE-0268：didSet 方法优化和语义更新
• 首先在 SE-0271 中，Swift Package Manager 在资源文件的支持上有了进一步的提升，同时，在 SE-0278 中，SPM 对本地化资源的支持也有了改进，而且在 SE-0272 中，SPM 终于支持了二进制形式的组件。在 SE-0273，SPM 允许我们对特定的 target 进行特殊的依赖配置。

其中在未来的 5.4 版本又新增了以下几个语言特性：

• SE-0287：提升了隐式成员表达式的类型推断能力。
• SE-0284：在函数中可以定义多个可变参数。
• SE-0289：在 5.1 就公布的 Function Builder 功能正式命名为 Result Builder，并在原先的基础上进行了完善。
• SR-10069：嵌套函数支持重载
• SE-0294：新增 executable 类型的 target，使得 SE-0281 新增的特性更易于使用。
• property wrapper 除了可以作为属性外，还可以在函数里作为本地变量。

On the road to Swift 6

在 2021 年的 1 月，Swift 社区的 Ted Kremenek，他的另一个身份是 Manager of the Languages and Runtime Team @Apple，在 swift.org forum 公布了一则名为《On the road to Swift 6》的文章

在这篇文章里，提到了一些对 Swift 6 的规划，从大方向来说，Ted 提了三点：

1. 加速整个 Swift 软件生态的发展：包含兼容更多的开发平台，简化软件的安装部署和大力发展各类工具库。
2. 打造极致的开发体验：包括更快的构建速度，更好用的调试工具，更灵敏的代码补全和更丰富的诊断信息。
3. 结合开发者的反馈进一步发展语言特性：包括完善 API 的设计，拓展其在底层系统，服务器和机器学习方面的应用场景，同时对某些主流的语言特性提供支持，例如并发特性和内存相关的特性。

同时 Swift 的核心团队也发生了一些变化，Saleem Abdulrasool 和 Tom Doron 作为新成员加入到核心团队，而 Dave Abrahams 则推出了核心团队。

这里稍微提一下的，Tom 是 SwiftNIO 的核心开发，同时在 SSWG(Swift Server Work Group) 项目中也是主要的发起者，而 Saleem 是 Swift to Windows 的核心发起者，这两个变动结合着最开始的三个大方向，可以看出整个核心团队是言行一致的。

另外关于 Swift 6 的公布时间，Ted 的原话是这样的：

所以这样看来，Swift 6 还是有一段时间才能与我们见面，毕竟人家说了 when those efforts culminate！

那反过来看，Swift 5 还将会是近期使用的主要版本。（PS：希望今年的 WWDC 21 不要被打脸）

技术社区

语言排行榜

同样我们来看一看编程语言排行榜 TIOBE 和 PYPL 的情况，在 TIOBE 的排行榜中，Swift 在今年的排名是第 15 名，而 Objective-C 已经彻底排在了 20 名之外了。

而在 PYPL 的排行榜中，Swift 和 Objective-C 的热度还是较为接近的。

从社区的语言排行榜来看，虽然乍一看，感觉还是 Swift 和 Objective-C 共存的大环境，但其实背后也反映出，Swift 已经被大部分开发者所接受了。

社区活跃度

同样通过 GitHut 2.0 这个工具对 GitHub 进行分析。

下面四张图的 Y 轴分别代表了 Pull Requests ，Pushes，Stars，Issues 的数量，蓝色的线代表 Objective-C ，浅橙色的线代表 Swift。

可以发现，在 Pull Request 方面，Swift 占比约 0.595%，而 Objective-C 占比约 0.335%

同时 Push 方面，Swift 占比约 0.476%，而 Objective-C 占比约 0.310%

在 Stars 方面，Swift 占比约 2.107%，而 Objective-C 占比约 1.067%

在 Issue 方面，Swift 占比约 0.767%，而 Objective-C 占比约 0.607%

总的来看，在 GitHub 的大环境中，社区中的开发者还是持续看好 Swift，也相对更加活跃，尤其在 Star 这项指标上可以明显看出，它高出了 Objective-C 近一倍！

商用 SDK 的技术选型

在今年我们还发现了一些有意思的现象，不少商用 SDK 也开始了 Swift 的迁移。

例如国外的 Nordic Semiconductor 公司，它是北欧的一个半导体公司，主营蓝牙芯片，在业界属于领先地位，不少使用它家芯片的团队会涉及到固件升级问题，无线的升级方案需要进行固件传输、校验、升级管理等动作，而这些动作都得使用它们家提供的 SDK 来完成。

在 Nordic Semiconductor 的 GitHub 页面上，我们可以看到目前提供的商用 SDK 中，iOS 端只有 Swift 版本，而 Android 端只有 Java 版本。

同时像 Google 的 Firebase 在其 RoadMap 里也明确指出了将更加关注 Swift 的使用体验并开始了部分改造。

相信不久的将来，会有越来越多的厂商加入到 Swift 的社区中，除了 Swift 是未来 这样人人都懂的道理以外，这两年新增的特性，例如 ABI 稳定，Module 稳定，以及 SPM 对 binary 组件的支持，都会导致厂商的态度改变，尤其是那些需要使用非源码形式发布组件的厂商，毕竟这些特性从根本上解决他们面临的工程问题。

Apple 生态

SDK 能力

同样，我们继续分析了 Apple Developer Documentation 下的 239 个 主题，发现今年的 Swift 独占和 Objective-C 独占的 SDK 情况如下

在 Swift 独占方面，新增了 3 个 SDK，分别是 Developer Tools Support，System，WidgetKit，其中 System 是个用于进行底层文件操作（low-level file operation）的库，似乎这也是 Apple 的首个用 Swift 编写的系统底层库(PS：如果说的不对，还请各位读者指正)；另外一个想说的重点就是 WidgetKit，这也是首次 Apple 在推广系统新特性的时候强制要求开发者必须使用 Swift 技术，这个策略我认为还是十分高明的，它为 Swift 技术的推广和应用找到了新的出路。

同时 Objective-C 独占方面，新增了一个 SCSIControllerDriverKit，但相比于去年，Professional Video Applications 和 IOUSBHost 两个 Objective-C 独有的 SDK 被改造成了 Swift 和 Objective-C 都可以使用的情况，而 QTKit 被彻底废弃了。

至此，我们发现了，Swift 独占库的数量首次大于了 Objective-C 的独占库，是不是很有意思！

原生 App 分析

国外的开发者 Timac 在其文章《Apple’s use of Swift and SwiftUI in iOS 14》里对 iOS14 中的 Swift 和 SwiftUI 的使用情况进行了分析。

iOS 14.0 包含了 291 个使用 Swift 技术的二进制文件（PS: 还有一个统计口径是 351 个，不过这里面有很多程序对 Swift 的使用很初级，所以 Timac 就将其排除了），这个数量比 iOS 13 多了一倍以上，另外 Swift UI 也在 iOS 14 上被广泛使用，目前已经有 43 个了，其中去年新增的翻译应用是完全使用 Swift 和 SwiftUI 编写的 App。

iOS 中不同编程语言的发展

同样是 Timac 在其文章《Evolution of the programming languages from iPhone OS 1.0 to iOS 14》给出了很多有意思的结论。

首先，在 iOS 14 中，总共有 4173 个二进制文件，具体的列表可以参考 iOS 14.0 (18A373) 统计，其中：

• 88% 使用 Objective-C
• 17% 使用 C++
• 8% 使用 Swift
• 8% 全部使用 C
• 1% 使用 SwiftUI

下面的图是 iPhone OS 1.0 到 iOS 14.0 中，各个二进制文件的情况，注意这里的二进制文件可以包含多个语言，所以下表的总数可能会大于二进制的总数，例如 iOS 14.0 里 44 + 351 + 337 + 708 + 3667 > 4173

从这个视角来看，也可以得出几个有意思的结论：

• 首先，iOS 的每个版本都变得更加复杂
• Swift 的使用在不断增多，而且至少目前来看，Swift 的使用已经超过了 C
• Objective-C 的增长还是比较稳定的
• C++ 的增长比较缓慢，或者说相当缓慢
• C 的增加几乎没有变化

如果上面的图看起来不明显，我们可以通过这个图来看趋势。

当然上面的分析是基于数量来进行的，那么如果我们从体积上进行分析，也就是二进制大小的角度来看，又会得出怎样的结论呢？

Timac 在其文章《Comparing iPhone OS 1.0 with iOS 14 using tree maps》里，也给出了一些自己的解读。

下面是 Timac 根据相关的数据和脚本绘制出来的 iOS 14 的 tree map（矩形式树状结构绘图法）

• 其中 Preinstalled Assets 和 Linguistic Data 是与机器学习相关的预置资源
• Health 相关的内容在 iOS 14 的占比不算小，可以看出其重视程度
• 在 iOS 3.1 之后，提供了 dyld shared cache 技术，红色区域就是支持这个特性的 framework。

当然，Timac 对这个结果又进行了更细致的划分，它的结果如下

这里我们从二进制的大小，或者代码量的多少来考察某个系统功能的重要性，我们可以明显的看到，Apple 的人工智能推动了设备上的机器学习，如图像和视频中的物体检测、语言分析、声音分类和文本识别等技术。

所以如果未来想继续在 iOS 上开发的话，机器学习可能会是一个必备的基础知识了（PS：如果你开发过 IntentConfiguration 类型的小组件，我想你大概就明白我在说什么了）。

国内外客户端的使用现状

数据样本

去年我们分析了国内外 App 使用 Swift 的情况，今年我们继续走起。

扫描的原理借鉴了《如何检测 iOS 应用程序是否使用 Swift？》，相应的工具可以参考 Swift App Analyzer，这是我和好基友 OneeMe 一起编写的。

App 排行榜的数据来源是 七麦数据 提供的，日期为 2021 年 3 月 21 日，国内免费应用 Top 100 榜单 和 国外免费应用 Top 100 榜单

下面是扫描的结果：

2021 年

在国外 Top 100 的免费应用中，Swift 混编占比 91%。

在国内 Top 100 的免费应用中，Swift 混编占比 59%。

在之前的文章中，《一次关于 Swift 在 iOS 生态圈里的现状调研》，我们也整理过一些数据。

在 2019 年，国内的 Swift 混编应用占比为 22%，国外的 Swift 混编应用占比 78%， 在 2020 年，国内的 Swift 混编应用占比为 30.4%，国外的 Swift 混编应用占比 82.3%。

如果将近几年的数据连着看，Swift 在国内外的变化趋势如下图所示：

数据解读

纯看数据的话：

• 在国内，Swift 混编占比达 59%，较去年的 30%，又增长了 29%，整体占比也已经过半了！
• 在国外，Swift 混编占比 91%，较去年的82.3%，又增长 9%，纯 Objective-C 的应用也只有个位数占比了。

那么我们再分析一些数据背后的内容：

• 从表面看，除了去年提到的 BAT 之外，今日头条，快手，滴滴，支付宝，京东，拼多多等一众应用也都在今年完成了 Swift 的初体验，比较有意思的是美团系的应用（美团，大众点评，美团外卖）目前似乎还没有任何动静。
• 虽然国内的 Swift 混编占比变高，但我个人认为，这并代表国内大部分公司要开始转型 Swift 技术了，这样的变化，主要是因为去年 Apple 新增的 Widget 技术导致的，因为想开发 Widget 必须使用 Swift 相关的技术，而上面提到的各个应用，大多都提供了相应的小组件。
• 如果历史有可以借鉴的地方，那么 2021 年的国内 Swift 占比（59%）与 2019 年的国外占比（78%）还算比较接近，至少不像去年（30% 和 82.3%）的差距那么大，那么按照这个趋势发展的话，我们是否可以预言在未来的 3-5 年内，国内的 Swift 混编应用占比也将达到 90% 左右？

总结与展望

在做完了今年的调研后，我们能得出什么结论呢？

• 虽然看起来现阶段的 Swift 还是在一个积累的过程，但随着 WidgetKit 这个标志性的 SDK 诞生，我相信这个发展阶段会从积累阶段慢慢转向发展期，毕竟现在 ABI 稳定了，Module 稳定了，对二进制组件的支持也有了，还有 Swift 语言本身的版本变化也逐渐稳定了，这些都给与了 Swift 很好的支持。
• Swift 的发展方向绝不只是为了 Apple 生态体系内的那点事儿，这个从社区的规划也好，从 Timac 的那几篇分析文章也好，我们都可以看出它在多元发展上的决心，Swift 真的很想破圈。
• 国内的 Swift 发展被去年的 iOS 14 新特性给盘活了，WidgetKit 功不可没，虽然还不能给出大部分公司都将转型的结论，但至少绝大部分互联网的头部公司已经兼容了 Swift 的开发，这是一个好的开始，相信在可见的未来，Apple 的转型决心必然会让国内的公司会更加重视这方面工作的重要性。

在最后，我来说说这一年的一些其他见闻：

虽然不久前 Google 归档了 Swift for TensorFlow 项目，让很多人看衰 Swift 在机器学习或者人工智能方面的发展，但其实我觉得是有点没必要，Swift 在这方面的发展其实并不依赖 Google，Apple 自己在这方面就很有建树，如果感兴趣应该看看 Machine Learning Research at Apple 这个网站，这才代表 Apple 和 Swift 在机器学习方面的真实水平。

另外，虽然还是能在某些技术群里看到 “Swift 无用”，”Swift 火不了”，”我们不需要用 Swift 开发” 的字眼，但这样的数量相比于前几年而言，真的越来越少了。

另外据我所知，字节跳动和快手团队正在大力发展 Swift 方面的建设，虽然这只是国内诸多公司的个例，但我相信随着这些头部大厂的加入，Swift 成为原生开发的主流趋势会在国内越来越明显，当然不得不承认，跨端技术在国内也有着极大的市场份额，所以估计未来作为 iOS 端上的程序员，可能要具备 Objective-C，Swift，JavaScript/TypeScript 和 Flutter 的语言技术栈。

好了，今年的调研报告就到此结束了，我们明年见！

参考文档

SketchK - 一次关于 Swift 在 iOS 生态圈里的现状调研 Paul Hudson - Hacking with Swift - What’s new in Swift 5.3? Paul Hudson - Hacking with Swift - What’s new in Swift 5.4? Swift.org forum - On the road to Swift 6 TIOBE PYPL GitHut 2.0 Apple - Apple Developer Documentation Timac - Comparing iPhone OS 1.0 with iOS 14 using tree maps Timac - Evolution of the programming languages from iPhone OS 1.0 to iOS 14 Timac - Apple’s use of Swift and SwiftUI in iOS 14 Timac - 如何检测 iOS 应用程序是否使用 Swift？ OneeMe - Swift App Analyzer Flexih - Snake List Apple - Machine Learning Research at Apple

概述

最近在工作中过程中基于 Swift 开发了两款命令行工具：

• Nezuko ，一款面向美团壳工程的，类 create-react-app 的脚手架工具。
• ImportSanitizer，一款能够修复不规范头文件引用方式的自动化工具。

在整个开发过程中，我们体会到了 Swift 带来的一些变化，当然这里既有好的，也有坏的，不过总的来说，使用 Swift 进行脚本开发还是一件让人愉悦的事情，所以我们迫不及待的邀请你，也就是这篇文章的读者，和我们一起加入 Swift 开发的大军中！

这篇文章通过 Step-By-Step 的方式，指导你完成一个基于 Swift 的命令行工具，不过在开始之前，我们先聊聊为什么要写脚本，以及为什么选用 Swift。

Why Scripting

对于软件工程师来说，我们经常会遇到这样的工作，例如重命名设计师提供的图片素材，在海量的数据中提取一些特定信息。这种工作有一些共性，就是它的逻辑很简单，就像代码里的 if-else 一样，只要你够严谨，就一定能得到想要的答案，

但这种机械性的工作很容易因为人为的因素导致错误，例如手抖，眼瞎，以及间歇性失忆，哈哈，而这时候，机器会显得比人靠谱多了！

同时，重复同样的工作是一件低效的事情，我们完全可以通过编写相应的代码将任务自动化，这将极大的提升我们的工作效率。

当然可能有人会说，我还是自己弄吧，但你不觉得这种重复的，机械性的工作很无聊么，我们可是要改变世界的工程师啊！

Why Swift

至于为什么使用 Swift 写脚本，我想有人可能会给出这样的答案:

但说实话，这是一个很主观的判断，并不应该成为我们使用 Swift 写 CLI 的客观因素，在实际使用了一段时间后，我认为下面几个因素才是我们使用 Swift 编写脚本的主要原因：

• 降低了 App 开发者编写脚本的门槛，减少了上下文切换的负担
• Swift 提供了一些真的很不错的内置库，例如 combine，core graphics，urlsession 等
• 可以将 App 里的代码引入脚本，避免重复工作

关于前两点，我想大家应该会比较好理解，毕竟每次在 Swift 代码和 Bash，Ruby，Python，JavaScript 中切换，会让我产生一种深深的抗拒感，另外在 iOS 上已经得到证明的 core graphics 有理由让我们相信它的品质，同时天然内置的 Combine 让我们在异步编程上有了很好的体验，这让我想起被 JavaScript 里 yield 支配的恐惧，问我为什么要用 yield，不妨来试试 React + Redux + Redux-Saga 的大礼包呀!

关于最后一点，我想展开说说，一方面是因为它基于我真实的开发体验，另一方面是它确实让我真正意识到 Swift 写脚本的优势所在。

在年初的时候，我曾经一度痴迷 SpriteKit，并尝试开发一款属于自己的横版过关游戏，这其中涉及到大量的图片处理，例如使用 Animation 的方式将多张静态图片整合成动态效果，大体的效果就像下面的 gif 一样

这背后的代码大概如下所示，通过读取相应顺序和数量的图片构建 gif 动画

Animation(
    name: "Units/swordsman/male/attack/right",
    frameCount: 8,
    duration: 1.12,
    tintColor: .blue
)

虽然看起来代码不多，手写一下就 ok 了，但你得知道，就这样一个杂兵角色，就会有攻击，跳跃，行走，跑动等等等动作，再加上各个方向，以及特殊效果，如果再考虑到，我们的游戏里面大概有 20 多个兵种和 4 个英雄，我想你大概已经体会到这个工作的痛苦了！

在一开始，我用的是 Ruby 来解决重复代码的生成工作，但这里为了减少上下文切换，我将采用 Swift 类型的伪代码来做展示，方便大家快速理解

let unitKinds = ["swordsman", "archer", "knight", "catapult"]

for kind in unitKinds {
    guard let config = try? File(path: "\(kind.identifer)/Config") else {
        continue
    }
    try codeGenerator.generateCode(from: config)
}

虽然这么写已经帮我节省了不少时间，但我还是得每次手动维护 unitKinds 数组，并保持它与游戏中的模型数据同步，这其实也挺烦人的，不是么？

class Unit {
    enum Kind: Int {
        case swordsman
        case archer
        case knight
        case catapult
    }
}

某日，看着上面的游戏模型数据，我突然顿悟，如果我用 Swift 编写脚本的话，我完全可以复用游戏里的数据模型啊！于是乎，便有了下面的代码：

import GameModels

for kind in EnumSequence<Unit.Kind>() {
    guard let config = try? File(path: "\(kind.identifer)/Config") else {
        continue
    }
    try codeGenerator.generateCode(from: config)
}

至此，我终于做到了不用再手动维护脚本里的任何代码，就可以直接与 App 里的源码保持一致，这样是不是很 cool！同样的道理，我们还可以应用到很多方面，例如直接利用网络层的 modle 文件生成 mock 数据，而不用在 JSON 编辑器上小心翼翼的粘贴复制了！

所以还在等什么呢，让我们开始写一个 Swift CLI 吧！

使用 SPM 搭建开发框架

为了开发 command line tool（CLI），我们需要创建一个新的文件夹，并使用 swift package manager（SPM）来初始化项目

$ mkdir CommandLineTool
$ cd CommandLineTool
$ swift package init --type executable

最后一行的 type executable 参数将告诉 SPM，我们想创建一个 CLI，而不是一个 Framework。

项目里的文件

在 SPM 初始化项目后，我们会得到如下的一个文件夹结构

.
├── Package.swift
├── README.md
├── Sources
│   └── CommandLineTool
│       └── main.swift
└── Tests
    ├── CommandLineToolTests
    │   ├── CommandLineToolTests.swift
    │   └── XCTestManifests.swift
    └── LinuxMain.swift

其中有几个需要关心的文件

• Package.swift 文件： 用于描述当前 Package 的信息及其依赖，需要记住的是，在 SPM 的世界里，不再有 Pod 的概念，与之对应概念是 Package，而 CLI 本身也是一个 Package
• main.swift 文件：这个文件在 Sources 目录下，它代表整个命令行工具的入口，另外记住不要更换这个文件的名字！
• Tests 文件夹：这个文件夹是用于放置测试代码的。
• .gitignore 文件：通过这个文件，git 会自动忽略 SPM 生成的 build 文件夹（.build 目录）以及 Xcode Project

将代码划分为 framework 和 executable

我的一个个人建议是，在一开始就最好将源代码分成两个模块，一个是 framework 模块，一个是 executable 模块。

这样做的原因有 2 点：

• 会让测试变得更加容易
• 让你的命令行工具也可以作为其他工具依赖的 Package

具体怎么做呢？

首先，我们要保证 Sources 目录下有两个文件夹，一个用于存放 executable 相关的逻辑，一个用于存放 framework 相关的逻辑，就像下面一样：

$ cd Sources
$ mkdir CommandLineToolCore

SPM 的一个非常好的方面是，它使用文件系统作为它的处理依据，也就是说，只要采用上述操作提供的文件结构，就等于定义了两个模块。

紧接着，我们在 Package.swift 里定义了两个target， 一个是 CommandLineTool 模块，一个是 CommandLineToolCore

import PackageDescription

let package = Package(
    name: "CommandLineTool",
    targets: [
        .target(
            name: "CommandLineTool",
            dependencies: ["CommandLineToolCore"]
        ),
        .target(name: "CommandLineToolCore")
    ]
)

通过上面这种方式，我们让 executable 模块依赖了 framework 模块。

构建 Xcode 项目

为了能方便的运行和调试代码，我们还需要使用配套的开发工具！

好消息是 SPM 可以根据文件信息自动创建 Xcode 工程，这意味着我们可以使用 Xcode 来开发 CLI 了。

而且在 .gitignore 中会自动忽略这个工程项目，这同时意味着，我们不需要更新 Xcode Project 文件，也不需要担心这类文件的冲突问题，只需要通过下面的命令即可完成工程文件的生成。

$ swift package generate-xcodeproj

记得需要在根目录下执行上面的命令，另外在执行过程中会得到一个 warning，让我们暂且忽略它，在后面我们会将其修复！

开始动手

定义程序入口

为了能够在命令行和测试用例中方便的运行我们的代码，我们最好不要在 main.swift 中添加过多的逻辑，而是通过程序调用的方式唤起 framework 中的主逻辑。

为了实现这样的目的，我们需要创建一个名为 CommandLineTool.swift 的文件，将其放在 framework 模块中（Sources/CommandLineToolCore），它里面的内容如下

import Foundation

public final class CommandLineTool {
    private let arguments: [String]

    public init(arguments: [String] = CommandLine.arguments) { 
        self.arguments = arguments
    }

    public func run() throws {
        print("Hello world")
    }
}

同时在 main.swift 中添加 run() 方法

import CommandLineToolCore

let tool = CommandLineTool()

do {
    try tool.run()
} catch {
    print("Whoops! An error occurred: \(error)")
}

Hello，World

让我们用命令行看看执行效果吧！不在在真正的运行前，我们还需要完成编译工作，让我们在根目录下执行 swift build 吧，然后再执行 swift run 命令。

$ swift build
$ swift run
> Hello world

增加依赖

除非你正在构建一些十分“特殊”的东西，否则你会发现自己需要为你的命令行工具添加一些依赖关系，毕竟有好用的轮子为啥不用呢？

任何 Swift Package 都可以被添加为依赖项，只需在 Package.swift 中指定它。