SwiftUI：专辑

2021-05-02  本文已影响0人  时光啊混蛋_97boy

原创：知识点总结性文章
创作不易，请珍惜，之后会持续更新，不断完善
个人比较喜欢做笔记和写总结，毕竟好记性不如烂笔头哈哈，这些文章记录了我的IOS成长历程，希望能与大家一起进步
温馨提示：由于简书不支持目录跳转，大家可通过command + F 输入目录标题后迅速寻找到你所需要的内容

目录

一、Moleskin Studio 视图构思案例

Moleskin 的一系列家族应用知名度相对较高，包含日历型应用 Timepage、笔记型应用 Flow、记事型应用 Actions。它家的应用素来以愉悦体验，顺滑的动画和简洁的设计闻名。而 Twitch 直播应用是海外最大的游戏直播平台，也是各类型游戏在海外做直播的首选合作对象，用户体量很大。如下图所示，左侧的是日历应用 Timepage，中间和右侧的是直播平台 Twitch。

1、Fun and Games with View Transforms

这篇主题演讲采用的技术方案是较老的 UIKit，不过其核心思路在 SwiftUI 中完全适用。作为对照，我将以下概念在 UIKit 和 SwiftUI 中的对应关系进行罗列。

Auto Layout 指的是自动排版，其原理是通过一系列开发者给出的约束条件，定位界面元素中的位置。SwiftUI 完全剔除了这个概念，主张视图根据逻辑关系自适应排版；

CGAffineTransform 指的是对界面中的视图进行形变操作。在 SwiftUI 中对应诸如 .scale() 等修改器；

CollectionView 指的是视图中，多个界面元素按照一定规则一字排开的视图排版方式，诸如「图书」应用中一字排开的书目；iOS 主屏幕上罗列开的应用图标，都是此类视图。SwiftUI 中对应 LazyVGrid 和 LazyHGrid。

以 Flow 应用为例，界面中按下全屏按钮后的界面元素隐藏，左侧笔迹工具的缩放消失、按钮位置的变化等，依靠的都是 AffineTransform 的 2D 变换。此类增加界面的趣味性，临时性的简单变换，一般情况下不会对界面造成副作用，比如开发者不需要担心按钮消失之后，用户再写东西时文字会跑偏之类问题。这类简单的视图变换往往会在变换结束后，让视图进入一个新状态或完全不改变原有内容，只是当作一段动画来使用。

当遇到复杂的转化时，诸如整体界面的转化，在带来更有趣体验的同时也可能造成诸多问题。比如让视图进行缩放或旋转等转化后，手势怎么办还能正常使用吗？滑动可以用吗？自动排版的限制条件会破坏吗？等等。以 Flow 应用为例，其中右侧的比的部分是 Child View Controller，每一只笔是 Collection View 中的一个信息点。

对于笔记界面中的每一种元素来说，实质上是数个 Collection Views 的集合。为保障每种界面元素在缩放时仍处在合理的位置，该界面实际上拥有海量的 Auto Layout Constraints 来对每一个元素的位置进行限制。

对于 Moleskin 团队来说，他们遇到的新需求是创建一款 iPhone 应用，如下图所示。如果将原有视图安放在 iPhone 上该如何操作呢？此时画笔的颜色选择，与画笔本身呃选择好像是旋转了九十度之后的结果。Moleskin 团队首先考虑的是重写，即对于每一只笔和颜色，重写一个专门适用于竖屏版本的界面。然而如上文所示，这是个工作量极大的工程，几乎重写每一个小细节，是让人崩溃的。且倘若完全重写，则意味着以后更新界面时要维护两个版本的内容，保障其一致性费时费力更多。

如果全部直接改变位置呢？没试过，有没有可能呢？滑动还有用吗？手势哈有用吗？Collection View 还有用吗？性能会变差吗？为解决以上问题，可以先创建一份草稿应用来做一些尝试。新建一个右侧代表颜色选择的应用，并尝试将其通过旋转九十度的方式放置在底边栏。

此步骤的操作中，开发者先给未经过变换的视图设置了限制条件，之后进行变换操作。然而结果失败了，底部并未如期旋转，而是出现了一个双排且尺寸奇怪的 Collection View。往好的方面考虑，至少滑动、触控等操作是正常的，但是整体计算存在错误，左右宽度等信息都出现明显异常。

对于这个问题，开发者接下来尝试将视图看作一个整体来对待。倘若单独对其中的每一个物件进行旋转，会破坏 Auto Layout Constraints 的限制条件，那将其视作一个整体如何？

新方案中，开发者将原有的选笔视图完整嵌套在了一个空置的 Wrapper 视图中。在新视图中，Auto Layout 限制条件完全不做改变，依旧以之前的设置为准。接着用 Wrapper View 将旋转后的原始图放置其中，将二者关联起来。结果如下图所示，外面的白色边框是新加入的 Wrapper 视图，内侧的绿框是原有视图和限制条件。

代码层面，将原视图放置在新 Wrapper 视图中。根据原视图的边界，用rotatedContentsView.frame = self.bounds 将视图大小统一。至此，视图旋转过程中遇到的界限判定问题，通过外置 Wrapper 视图而解决。

2、经验总结

对于将新视图放置在空置视图的旋转方案，基本上所有操作和性能层面上的担忧都得以解决。唯独拖拽操作的 新API 存在些小毛病，这一点得靠 Apple 修复。

如下图所示，从 iPad 将界面迁移到 iPhoen 端，用的是完全相同的视图。仅仅是新增了 Transform，而不是将界面做两遍，提升效率的同时降低了维护成本。

以上这套将视图放置在空视图之后叠加旋转的方案，也可以用在对系统控件的变化中。比如下图的基本滑动条、选择器等界面元素，经旋转后竖置能带来完全不同的使用感受。

Moleskin 还将这套方案用在了不同应用程序中。比如日历应用 Timepage，这款应用设计之初本不存在横屏视图，但它依靠 AffineTransform 的旋转的方案了欺骗系统，让其作为竖屏应用，在横屏时依旧展示出了更多的日程信息。如下图所示，从左侧的返回指示器可以看出，系统目前仍然把它当作纵向的应用，但视图内容得益于旋转操作，内容方面进行了横向展示。

3、注意事项

首先是不要用绝对数值进行对比，尽量直接向系统索要当下状态的视图数值。

旋转后最直观的问题是图标方向也会改变，需要自行取舍值不值得为了旋转而去修改图标。比如特别简单的视图，倒不如直接写。

在旋转之后，系统对于 Safe Area 的判定会有些奇怪，比如原始视图中纵向排列时，底部存在较大的安全区，旋转后系统会认为侧边栏的安全区为新的安全区，因此位置的判定上可能不及预期。

4、总结

这次特刊中，最直观的感受便是即便 Adam 这样的大神，具备极丰富的开发经验，在实际项目中也需要试错！诸如本文中将界面从 iPad 中的横向排布改为纵向排布，看起来简单的界面调整，实际花费了大量的时间和精力。

我原以为制作并维护 Moleskin 这三款高流量应用的是个比较大的开发团队。但实际了解过后也不尽然，这个团队成员分布在澳大利亚、美国、加拿大、菲律宾这几个地方，满打满算一共只有十个人。其合作方式基本上是完全的在线协作。

当团队中几个人合作时，我个人曾建议过通过注册商标来提升品牌可信度，用商业主体作为应用的代表方。而 Moleskin Studio 的运作方式与之前在商业主体文章中提到的类似，实际上只是一个注册挂名的品牌主体。用作产品销售、财务管理、纳税等事物。当你在经验个人应用或组建团队时，也可以将品牌这件事考虑进去。

二、Twitch 直播应用的设计案例

Twitch 直播应用是海外最大的游戏直播平台，也是各类型游戏在海外做直播的首选合作对象。Tim 是 Twitch 的 iOS 工程师，本文将关注讨论 Twitch 中设计指南的构建思路与心得。

1、Intro to Design Systems

无论是对于个人还是对于小团队而言，在制作某个产品时需要定义一个标准，而此处所有与设计元素有关的标准，就叫做设计系统 Design Systems。与之类似，设计指南 Design Guidelines、风格指南 Style Guide 指的多少也是这么一回事，核心在于为产品设计定调。

以乐高构建的房屋为例，其需要的很多元素属于常见的基本要素，诸如长方形房顶，方砖的墙面等。但同时也存在一些较为独特的元素，诸如下图中积木块中的「门」，它具备独特的门框设计。对于开发者而言，基础的积木块包括 SwiftUI 中一提供的界面元素，如按钮，滑动条等等。诸如门窗这类用在某场景下的特殊元素，则通常是由基础元素组合而成。

以Apple 原生应用和 Twitch 应用为例，都在原生组件的基础上进行了细微的差异化工作。比如 Apple 地图中底部的上拉一半的弹窗、商店页面中 Get 按钮的图案和动画、图书应用中的阅读时间提醒、Twitch 一样中的直播卡片等，都属于类似上述比喻中「门」这样的特殊元素的范畴。

2、设计原则 Principles

留白 Margin

留白指的是界面元素之间的距离感，当所有元素全部堆在一起时，往往给人杂乱无章的感觉，而留白有助于构建秩序。其常见方法之一是网格留白，比如下图中 Twitch 所采用的方案，在 Figma 中规范出一个网格，借此思考排列和对齐方式等要素。

文本 Typography

文本指的是应用程序中用到的文字种类、字号、颜色、位置等要素。以下图中 Twitch 的文本规范为例，右侧明确指出了字体的类别、字重等信息。左下角则给出了这些信息在实际代码中的命名规范，方便开发者和设计师进行参考。

主题色 Colors

应用程序的主题色也是应用身份的一部分，比如当你想到蓝色，很大可能脑袋中冒出的是支付宝；想到绿色，很可能想到微信；想到橘色，很可能想到淘宝。应用程序的主题色对塑造品牌认知帮助极大，因此有必要留心在应用中对颜色使用的一致性。

颜色细节

颜色细节：应用中除了主题色外，偶尔也会出现不同场景下的细节颜色使用。个人建议切忌贪多，这样反而容易将用户从主题色上带偏。如下图所示，Twitch 对于每个颜色都做了定义和预留，但实际应用中并不会全部使用，只是当作色卡预备。

同出于对颜色细节的思考。文本的颜色也应注重区分度，诸如有限程度高的内容，辅助型的信息等，都有必要给出明确定义。在 SwiftUI 中，Apple 提供的 .primary、.secondary 颜色可以作为文本色的快速上手方案。

主题

主题指的是将上述文本、颜色等信息打包在一起，形成诸如浅色模式、深色模式这样的组合概念。其中 Source of Truth 唯一真值原则依旧很重要，所有代码尽量诉诸于头一个信息源头，避免多个数据不匹配的情况。从代码层定义不同颜色。比如 Twitch 用到的 @propertyWrapper 方案，可以在不同场合提供对应主题相关的值。

边角缩放 Corner Radius

边角缩放好理解，不再赘述。在应用中需要注意的主要是视觉观感上的统一。

图标

图标方面，教程中推荐的方案是 Apple 推出的 SF Symbols。Twitch 为了照顾跨平台开发需求，选择的是一套自行设计的方案，如下图所示。这里没有对错，按自己的偏好来即可。值得一提的是，图标应尽量选择 PNG、PDF 这类矢量格式，确保怎么缩放都不糊。

层级关系

如下图所示，巧用阴影可以构建按钮与背景间的层级关系。比如图 2 中的按钮好像贴在背景上，图 5 中的按钮好像悬浮在屏幕之上。

3、界面模块 Primitives

除以上原则外，界面中最核心的便是上文提到的「基础积木块」和「特殊积木块」。这些积木块都可以被称作 Primitiives，也就是说有组成有价值的 UI 元素的最小单位。

以按钮为例，下图中由上至下，展示的就是从基础积木块过渡到特殊积木块的过程。其中最上方的 Log In 由 SwiftUI 直接提供，开发者可以通过增加修改器的方式获得自己想要的变种。

对于按钮的不同状态，操作系统一般会提供高亮等默认行为。Twitch 将这一流程更加具体化，如下图所示，展示了按钮在不同阶段的显示状态。

为方便开发者阅读，还可以考虑在设计文档中提供相应 API 写法。

除按钮外，应用通常包含许多类型的界面元素。以下图为例，开关、小标签、输入文本框等内容都有明确的样式。

4、组合 Patterns

将界面元素拼凑在一起，就形成了 组合 Patterns。举个例子，Action Sheet 弹窗是应用中常见的一类显示方案，它由「按钮、标签文字、图标、列表」等信息按照一定规则拼凑而成，形成了一个用于弹窗界面的「组合」。

若你的应用比较复杂，也可以考虑以组合为单位，在代码层面将其区分，以方便在应用的不同界面中使用。

对于弹窗来说，不同的使用场景可能会显示完全不同的内容，但都遵循弹窗这一组合的设计规范，如下图所示。

再举一个组合的例子，对于直播中的游戏，图片、主标题、副标题、标签这些元素，可以拼凑成卡片Cards 这个组合。而卡片组合也可以具备变种，在应用的不同区域呈现最合适的变种。

5、准备设计文档时的注意事项

在构思应用时，准备好设计文件，有助于确保设计师和开发者之间的顺利沟通。尽量减少因语言交流中的不一致而导致返工的情况。在准备设计文档时，应注意：命名上的规范、API 用法的明确说明、对界面元素中可能出现的变种全面考虑。

6、总结

在实际开发过程中，规整的文档和明确的设计规则有助于让每一个参与者都条理清晰；设计和代码层面遵循唯一真值原则可以避免因版本不同而造成的界面或数据差异；及时将界面模块化有助于提升代码的复用率。

三、Swift 语言特性更新

本文中，我选取了 Swift 5.2 - 5.4 中与 SwiftUI 应用息息相关的 6 个重要语言特性更新进行讲解，这些更新代表着 2020 - 2022 年间 Swift 语言的进化历程。之所以有必要了解这戏更新，一则是因为了解语言变化，有助于帮你快速熟悉 WWDC 中的新用法，二则是因为每年的范例代码随语言更新而变化，熟悉更新内容后有助于阅读代码，知道哪些写法是最新版本的。

1、Key Path Expressions as Functions

该提案指的是路径写法\.value写法可以替换(Sth) -> Value的函数写法，二者等同。举个例子，假设存在下图结构User用户，包含邮箱和是否是管理员两个属性常量。

struct User
{
    let email: String
    let isAdmin: Bool
}

假设我们希望从一组用户中筛选出为管理员的用户，按照以往尾部闭包的写法，如下图所示。运行该函数后，根据 $0.isAdmin 依次判断这组用户中，每一个用户是否为管理员。

user.filter { $0.isAdmin }

根据本提案，filter { $0.isAdmin } 可以被简化成路径写法 .filter(\.isAdmin)，其中 .isAdmin 句点之前的主体可以省略。filter { $0.isAdmin } 和 .filter(\.isAdmin) 二者均正确。

users.map(\.email)

users.filter(\.isAdmin)

2、Increase availability of implicit self in @escaping closures when reference cycles are unlikely to occur

Swift 语言通过自动索引计数 Automatic Reference Counting 的方案来进行内存管理，简称 ARC。举个例子，假设某实体 X 索引的目标是内存中的地址 a，ARC 记录索引计数为 1。当另一个实体 Y 也索引内存中的目标地址 a 时，ARC 自动更新，记录索引计数为 2。在代码运作时，Swift 语言会自动记录并增减 ARC 中每个实体的索引计数，当索引计数不为零时，在内存中保留该实体；当索引计数等于零时，从内存中清空，以此达到自动管理内存的目的。

值得注意的是，Swift 语言的自动索引计数与其它编程语言中常用的 垃圾回收 Garbage Collection 运作机制不同，但目的一致的，均是进行内存管理。ARC 虽更高效，但当开发者使用尾部闭包等语法时，容易产生一个叫做 内存循环 Reference Cycles 的问题。内存循环指的是在代码中，两个实体Instance互相索引，导致索引计数永远无法清零，内存空间也就因此没办法被再次使用。比如下图中，变量 john 和 unit4A 这两个变量实体，无论其是否被其它代码使用，假设二者在定义时互相索引，便会造成 ARC 无法清零的情况。

Swift 对于此类情况提出的解决方案是让开发者标注出 强索引 strong 和弱索引 weak，在强索引情况下，无论实体之间是否有关联，ARC 均不会清理计数不为 0 的实体。而弱索引指的是，当被索引实体的本体被清空时，其所有关联的子类实体也可以被清空。

为避免闭包中出现内存循环，Swift 用鼓励开发者在闭包中使用诸如 [weak self] 的写法，来明确告诉编译器哪个实体是弱索引。这种方括号中包含参数名的写法，叫做闭包的 抓取列表 Capture List，抓取列表存在的意义是告知编译器闭包中可能造成内存循环的实体。为了让开发者明确的知道代码中哪些实体被索引，Swift 语言要求闭包中的变量，若索引自身则必须写明 self。

得益于诸如 Combine 这样的异步数据流框架的出现，Swift 曾要求每次索引自身时必须写明 self 在某些情况下显得有些没必要。尤其是当 SwiftUI 出现后，这个用于提示开发者避免犯内存方面错误的写法反而变成了累赘，因此在本提案中，self 可以在某些情况（不易出现内存循环的情况下）下省略。以 SwiftUI 的删除修改器为例，曾经的写法为 .onDelete { self.viewModel.deleteItems(at: $0) }，省略 self 后的写法为 .onDelete { viewModel.deleteItems(at: $0) }，二者均正确。

3、Multiple Trailing Closures

这是一个在开发者群体中争议较大，但我个人非常喜欢的提案。在过去，尾部闭包的写法要求参数列必须写明除最后一个标签外，所有其它参数的标签。这种写法在代码逻辑中还勉强直观，但是在 SwiftUI 中简直就是灾难。以下图中的按钮为例，按钮 Button 拥有两个参数，分别是 action 即按钮做什么，和 label 即按钮长什么样。按照过去的尾部闭包写法，省略最后一个参数标签，如下图所示，代码中尤其是在参数列 action 的前后，多出了一个非常难看且多少莫名其妙的圆括号。

Button(action: { lasso.toggle() }) { Image(systemName: "lasso") }

本提案中，引入了多重尾部闭包的概念，允许开发者将参数列中的多个参数，以多个几个尾部闭包的写法依次罗列出来。新版如下所示，省略了圆括号读起来一目了然，即便遇到多个参数的 SwiftUI 视图也很直观。

Button { lasso.toggle() } label: { Image(systemName: "lasso") }

4、Type-Based Program Entry Points @main

对于诸如 Swift Playground 这样的单一文件来说，代码从上至下运行，非常好理解。但是对于复杂的 Xcode 应用项目来说，需要有一个代码运行的起始点。此前每个框架有不同的起始点写法，比如 @UIApplicationMain。2021 年之后，不同框架的起始点函数被一个统一的标识写法 @main 取代。以下图为例，框架中的协议静态函数 static func main()，在实际调用时，可直接写作 @main。

In a framework
public protocol ApplicationRoot
{
    //...
}

extension ApplicationRoot
{
    public static func main()
    {
        //...
    }
}
In MyProgram.swift
@main
struct MyProgram: ApplicationRoot
{
    //...
}

5、Extend implicit member syntax to cover chains of member references

在 Swift 语言中，有种很常见的链式省略写法 Implicit Member Expression，它指的是编译器通过上下文语境，自动判断句点前内容的主体。比如颜色 Color 这个结构中，若开发者想用到橘色，可以写作 Color.orange，链式省略写法允许省略 Color 这个主体，直接用 .orange 即可。

.foregroundColor(.orange)

但是在之前的版本中，链式省略不支持多次链接，比如在 SwiftUI 中，想用到一个透明度为 10% 的橘色，则必须写明 Color 这个主体才可以正常编译，如下所示。

.foregroundColor(Color.orange.opacity(0.1))

本次提案解决了之前多次链接中的主体无法省略问题。最新版本的以下代码可以正常编译，主体 Color 可以被省略。

.foregroundColor(.orange.opacity(0.1))

6、Local functions now support overloading

嵌套函数中的子函数支持重载了。通常来说，在函数 a 中定义函数 b，其中函数 b 叫做函数 a 的本地函数Local Functions，函数 a 和 b 的关系是嵌套关系。函数重载在之前的文章中提到过，指的是开发者可以定义函数名相同，参数列不同的函数，编译器会自动选择匹配参数列中参数类型的函数进行调用。如下图中，参数列 item 具备 I 和 II 两种类型，子函数支持重载，因此两个 b 函数可以被这样定义。

struct I { ... }
struct II { ... }

func a()
{
    func b(item: I) { ... }
    func b(item: II) { ... }
}

7、总结

编程语言不会凭空更新，而是在随着时间不断演进。比如在书写本文时，虽然介绍的最新版本是几天前刚刚发布的 Swift 5.4，但实际上 Swift 5.5 和未来很多后续更新早已进入排期。

以 Swift Evolution 提案为例，其开发进度完全开源，你可以直接查看 Swift 语言未来两三年的进化方向。如下图所示，左侧代表提案状态，中间的数字代表提案标号，标题代表提案内容，点击后可以查看详情。以 SE 0308 提案为例，其状态是「Implemented」，版本是 Swift 5.5，代表该提案内容已采纳并已落实在未来会发布的 Swift 5.5 版本中。关注语言的发展，有点像是在看预测未来的水晶球，有助于对未来几年的变化趋势做到心中有数。

四、WWDC 「电影节」观影指南

Apple Worldwide Developers Conference 是 Apple 每年 6 月举办的开发者大会，每次持续五天，简称 WWDC。虽然 WWDC 名称中强调「开发者」，但其中的很多内容其实并不仅仅对开发者有价值。知识的底层是互通的，而 Apple 具备丰富的实战经验，且非常擅长对基础知识的讲解。无论你感兴趣的是设计、开发、商业、游戏、AR 还是其它主题，总能从 Apple 为 WWDC 制作的丰富主题类别的科普内容中找到属于你的那几个，并从中受益。

新冠疫情前，开发者大会往往由 Apple 租用某会议中心，全球开发者购票后前往与会的形式进行。但由于每次抢票的人很多，这些年一直是以抽签的方式确定购票资格，且会议期间周边食宿会像过节一样炒高价格。受限于场地大小和与会成本，即便是比较大的开发团队，往往也只有少部分人能参与。

新冠疫情期间，WWDC 2020 和 WWDC 2021 切换成了对所有人免费的线上举办形式。除了和工程师直接交流的「一对一讨论」要求付费的开发者账号才能预约外，开发者大会当周的全部演讲，都会在会议当周以每天早晨一次性放出当天所有视频的方式进行。

之所以在本教程中反复强调 WWDC 的重要性，是因为它是开发者获取知识更新的最佳信息源，也几乎是 Apple 对外公示公司当年在不同方面所做工作的唯一渠道。通过 WWDC，开发者可以了解到接下来一年会发布的软硬件趋势，从而提前进行准备。个人认为，WWDC 具备如下优势：

1、节目单

如果说 Apple 的产品发布会是用户的春晚，那 WWDC 就是开发者的电影节了。在每年的 WWDC 电影节中，Apple 会放出各品类的超过 100 个视频，供与 Apple 生态有关的人观看了解。电影节从时间上分为两个阶段，分别是会议当周的周一和其余四天，下文会分类简单介绍下观影要点。

在最新一年的电影节开始之前这段时间，很适合回顾之前的优质影片。对于设计和商业向的视频，单独成主题的内容比较多。对于技术向的视频，新一年的内容往往是建立在前几年的基础之上的，提前开始准备，也有助于你快速跟上新一年的进度。近期特刊中，我将介绍电影节的构成，并推荐一些优秀节目。

2、周一

WWDC 第一天主要有两大节目，分别是主题演讲 Keynote 和全平台更新 Platforms State of the Union。

主题演讲 Keynote：通常来说第一天上午的主题演讲会邀请媒体参与，介绍这一年最新版本系统所 Beta 版本所具备的特性，并发布诸如 Mac 等新硬件。主题演讲没有任何前置观看条件，其定位是 Apple 在新的一年中，针对新软硬件更新的媒体通稿。媒体通常会在 WWDC 主题演讲之后便会拿着这份通稿进行不同角度的解读。

全平台更新 Platforms State of the Union：WWDC 上午的媒体通稿通常宣告着 WWDC 面向消费者更新的终结，但实际上下午的全平台更新才是 WWDC 这场年度开发者盛宴的开幕式。在周一下午全平台更新视频中，会由 Apple 不同部门的演讲者，针对新一年操作系统的技术进行要点的讲解，其内容将为接下来四天的各类型节目定调。此视频非常干货，若你在整个 WWDC 你只决定看一个视频，建议考虑 Platforms State of the Union，它有助于增强你对 Apple 对于生态系统中不同设备的了解，进行全局的思考。

以上二者是 WWDC 的保留节目。简单回顾：其中主题演讲没有任何前置条件，可以理解为精心制作的新闻稿；全平台更新视频干货更多，提到但不过分深究技术细节，是了解大局的极佳视频，适合任何对 Apple 生态感兴趣的人。两个视频观影过程都会是轻松愉快的。

3、周二 - 周五

WWDC 第一天主要有两大节目，分别是专题片 Sessions 和工程师问答 Labs。

专题片 Sessions：每届 WWDC 的期间发布的专题片约有 100 个，在 WWDC 的后四天中，会以每天 20 - 30 个的频率放出。其主题包含设计、框架、多媒体、开发工具、图形和游戏、应用商店和分发这六大项。以我个人的观看经验来说，其中三成左右专题片，诸如设计、AR、商业模式等话题可能自成主题，并不需要任何前置知识，带有强烈的科普性质，适合推荐给任何感兴趣的人。其余七成左右视频需要一定的前置知识，且讲解时的跳跃性较强，往往需要重复观看并配合查阅文档来深入了解。

以上二者是 WWDC 中最重要的知识充电环节。通常来说，即便是对于经验极为丰富的开发者，四天内也消化不同主题的一百多个视频也是几乎不可能的。你可以根据个人兴趣有的放矢，优先选择自己最感兴趣的主题，把相关视频啃掉，不必满把抓。

我个人的观看习惯是在在会议期间用 2 倍速观看视频，前期不求详细掌握，只求抓住要点即可。记录在观看中遇到的问题，及时预约 WWDC 期间对应的工程师问答进行解惑。至于彻底掌握最新的内容，完全可以用 WWDC 结束后的几周甚至几个月来慢慢消化，不急这一小会。

与 WWDC 一同到来的还有对应的 iOS、iPadOS、watchOS、macOS、tvOS 系统的 Beta 版更新。为了能及时跟着 WWDC 视频中提到的概念进行学习，建议开发者在 WWDC 第一天结束前，对相关设备进行更新，以便为剩余四天的专题片做好准备。

4、观影渠道

若你拥有 iPad、iPhone、Mac 之中的任何一台设备，应用商店中免费的「开发者 Developers」应用是 WWDC 的最佳观看渠道，点击即可下载。最新的 WWDC 内容将在此应用中第一时间发布，往届 WWDC 的视频也都可以分类查看，你还可以下载、标记观看记录并添加书签，十分推荐。

若你不太在意诸如观看记录和下载等附加功能，也可以用任何设备直接访问 Apple 的「WWDC 官网」来观看视频。若你在官网上暂时没看到视频内容的链接，不必担心，这是因为每年 WWDC 开始前一个月上一届的网站内容会下架。新一年的 WWDC 官网会在开发者大会前一周进行更新，提供专题片、工程师问答、范例代码下载、开发者论坛的对应链接，耐心等待网站迭代即可。

5、总结

受新冠疫情影响，WWDC 从现场与会的线下挪到了线上，「线下版」和「线上版」的 WWDC 各有优劣。

过往的「线下版」在某种程度上是开发者之间交友和沟通的平台，拥有极高的社交价值。但受限于现场演讲中可能出现的小技术问题、直接展示中需要的与现场观众互动、为照顾同时进行的不同专题片而被迫的固定时长等因素，让 WWDC 专题演讲的节奏感常无法尽善尽美。

「线上版」得益于其在线播放的本质，可以在更短的时间触及更多人。得益于精致的剪辑与后期，不受时长限制这两个优势，需要 15 分钟讲完的话题不必堆到半小时；需要 45 分钟讲完的视频也可以畅快地用上 45 分钟。个人感觉「线上版」的 WWDC 观影体验是明显更好的。但有得必有失，线上版失去了开发者面对面沟通这一部分，需要诸如论坛和在线讨论等方式来进行补充。

本文的观影指南中，你了解了 Apple 开发者大会是什么。在今年的 WWDC 视频发布后，我将在本教程中对新增内容做探讨与更新。接下来几篇特刊中，我将继续 WWDC 的内容的讨论，介绍一些过往的优秀专题片。

五、WWDC 「电影节」设计向视频种草

WWDC 设计向视频包含以下五个子类，主要侧重与对应用程序设计理念，交互方式等主题的讲解。本文中推荐的视频基本没有前置要求，均为设计相关的理论科普。无论你是否懂编程，仅仅是出于对设计理念的学习了解，都十分推荐这一系列视频。

文中推荐的视频，可以在「开发者 Developers」应用中「设计」分区找到。从我个人角度出发，仍然推荐直接观看英文的版本，我看了一些应用中视频的中文翻译，觉得术语上还是显得生硬，反而让原本直观的概念更难懂。不过这些视频均支持中文字幕，部分甚至支持中文语音，你可以根据自身对英语的接受程度进行选择。

为更加直观的阐述概念，本文会直接使用「中文 + 英文」视频标题进行推荐，并用中文说明我的推荐原因。你可以点击文章中的「🔗」图标直达视频，若你使用的是中文版本的应用，或想直接在网页上观看，该链接依然可用。

1、交互设计 Interaction Design

交互设计指的是人与物，或物与物之间的沟通方式，WWDC 中主要探讨的是用户「怎么样」与设备交互这个话题。若单纯的讨论开发者这个角色，交互设计主要探讨的是以人为中心的人机交互 HCI。人机交互是一门交叉学科，比如从心理学科的如何与设备交互产生满足感，提高可用性；从计算机学科的如何实现这一操作；从设计学科出发的如何优化设计，提升交互效率与界面的可发现性。

按钮的一生 The Life of a Button 🔗：如果你想设计一个烤面包的按钮，你会怎么做？作为交互设计的入门，本视频短小精炼，讲述了此按钮设计的心路历程。其中包含了交互方式、视觉设计、音频反馈等内容，从多个维度切入并思考用户的交互体验。

流畅的界面 Designing Fluid Interfaces 🔗：此视频发布于全面屏设备 iPhone X 推出后，讲解了 Apple 对于流畅顺滑的操作体验的思考，以及背后在动画，交互等方面的实现方式。流畅的界面应该是有趣、好玩的，给用户以愉悦感。与此同时，界面的交互应时刻与用户的操作同步，是用户手指的延伸。

走心的设计 Intentional Design 🔗：好的设计建立在走心的基础之上。何谓走心？演讲者提出了五个概念：1. 大胆简化 2. 深度理解 3. 极度专注 4. 情感连接 5. 直接沟通。好的设计是一种动态的、沉浸式的、私人的体验，能满足用户的心理以及行为需求。设计者需要在产品中有的放矢，做果断的决策进行取舍，对每一丝细节精细打磨，而后才可能让产品的使用体验变得愉悦而自然。

智能设计与应用的自我进化 Design for Intelligence: Apps envolved 🔗：此视频与交互设计相关度较低，更核心的点，在于其讲到了未来数年中应用于系统之间关系的变化。在过去，系统和应用之间的沟通很少，有点像是商场与商户的关系。当商户变多时，来购物的用户面临的选择也会纷繁复杂。假设商场能够从商户处获取信息，再给予这些信息给用户以指导，这样便可以帮助用户尽快实现目标。本视频中，讲解了系统与应用间沟通方式智能化趋势。

2、原型设计 Prototyping

原型设计指的是想法落地的最初次的试验阶段，教程之前提到的 MVP 可以是原型设计中可用度较高的这一版。原型设计这个阶段，投入的思考成本较高，但因为没有进入生产阶段，所以改动空间非常大。在原型设计期间，最重要的目的是确保产品设计是否能达到预期目标，因此强调「验证与完善」这两个概念。

六十秒完成原型设计 60 Second Prototyping 🔗：在想实现一个新想法没那么难，难的是迈出第一步。如果你现在脑中有一个灵感，只有 60 秒的时间将它落实，你会怎么做？本视频通过一个计时器案例，讲解了快速制作产品原型的过程和思考方式。

良好的开发习惯 Great Developer Habits 🔗：此视频不仅适用于 Apple 开发者，也适合任何工作生活中包含编程需求的人。它从规整代码、整理文档、阶段性测试等角度，梳理出一套有关于「开发习惯」的系统性建议。

3、声音与触感 Sound and Haptics

声音和触感是人类的两个重要感官，耳朵听到的，肢体感受到的。声音和触感由于没有视觉那么容易描述，因此常被人忽略。实际上，这二者是用户体验非常重要的组成部分，是需要精心设计的。举个例子，如果用户在提交表单，填对了手机发出咔它的震动，填错了也发出咔它的震动，那这个真的基本毫无意义。而倘若对二者加以区分，错误的时候强烈急促的震动，正确的时候清脆明快的震动，这样触感本身就传递出了信息，有了存在价值。声音同理，是加强沉浸感的重中之重。

设计声音 Designing Sound 🔗：声音在设备中扮演着重要角色。本视频的演讲者通过一些实际范例，直观的展示了音频传递出的不同信息。除此之外，该视频中还有一段实例演示，展示大家耳熟能详的 iPhone 铃声及提醒是通过什么乐器录制出来的。

设计音频触感体验 Designing Audio-Haptic Experience 🔗：此视频介绍了声音和触感设计的基本概念，通过触感，建立起真实世界和数字世界的沟通渠道。试想一个桌上弹球游戏，当小球碰到屏幕边界时，你能明确感受到它碰到了什么地方。配合与声音的联动，更丰富生动的游戏体验便营造出来了。除此之外，该视频还提到了音频与触控模块化的概念，设备上的声音与震动，与音频合成的概念不谋而合。

4、视觉设计 Visual Design

视觉设计指的是设计者对美的感受，其中包含了对图片、文本、空间、排版、颜色等属性的应用。视觉设计的概念某种程度上与平面设计是互通的，均着重于「看起来怎么样」这件事情。优秀的视觉设计有助于用户快速定位重要信息、树立独特明晰的品牌形象等。

设计的基本原则 Essential Design Principles 🔗：汽车档位、电灯开关、机票信息，为什么会形成如今的设计？在开始设计之前，你应该思考的是「为什么」要做这件事，而后才是「怎么做」。本视频中，演讲者用一个机场设计指示牌的例子，阐述并科普了设计的基本原则，这些原则普遍适用于各类设计中，属于优秀的基础知识科普视频。

优秀设计的特征 The Qualities of Great Design 🔗：优秀的设计不是魔法棒一点就成，而是需要背后的设计师付出心血并精心考量。这是我个人在全部 WWDC 演讲中最喜欢的一个视频，讲的由浅入深，探索优秀设计所具备的特质。优秀的设计并不随机，其存在可以给人以愉悦，让人快速地达成目的。这些理念也在 教程 3.3 的设计十诫中也有提到。无论是产品设计、工业设计、包装设计、界面设计等等，其理念是互通的。

5、字体 Typography

字体设计也是许多人忽略的一部分，但也是设计中极为重要的一部分。比如字体家族，能带来不同的观感。对于偏向儿童的产品，可以使用圆体字加强亲和感。合理调节字间距、行距等属性，可以带来不同的视觉感受。在恰当的位置加粗，可以突出强调某个功能点等等。

字体排印和字体 Typography and Font 🔗：在任何设计中，都离不开字体。这是一节优秀的字体设计理论基础课，它包含了对诸如 Kerning、Leading、Spacing、可读性等概念的讲解。并阐述了 SF 字体家族的的设计思路，以及诸如 Monospace 等距字体的使用场景等。

包容性应用设计 Inclusive App Design 🔗：应用程序与常面对全球的用户，这些用户所在地的文字表达方式，书写习惯，语言程度等都有较大差异。该视频用世界上的不同语种进行举例，深入各地文字习俗上的差异，并介绍了如何在应用产品的设计中留意这些差异。以此创建包容性，适应性强的应用。比如下图中，英语的「点按打开」表达方式，在希腊语用户的设备中长度几乎翻倍，而在中文语境中可能长度极短。

用户界面字体排印详情 The Details of UI Typography 🔗：这是一节优秀的字体历史课，在介绍字体发展史的同时，讲解了字体在 UI 设计这个实际使用场景中的注意事项。除此之外，该视频还讲解了许多系统级功能，诸如动态字体的设计原因，这些理念可以被迁移到其它使用场景中。

6、总结

本文中，你从「交互设计、原型设计、声音和触感设计、视觉设计、字体」这五个维度，了解了 WWDC 中的极优秀的设计向科普视频。本文中仅筛选出我个人看过的，无前置条件的视频。

WWDC 像一本百科全书，受限于篇幅，无法对其全部视频一一解析，除文中提到的视频外，还有诸如「一见倾心」讲解应用启动体验设计，「设计师与工程师沟通」这类思维方式差异等优秀视频，建议你根据个人喜好观看。在我看来本文中推荐的视频含金量极高，不仅充分讲解了理论背景，而且结合多年的实践经验举例讲解，无论你是否考虑做一名开发者，都能从这些视频中受益颇丰。

六、iOS 15、iPadOS 15、watchOS 8、macOS 12 体验及思考

1、iOS 15

iOS 15 之后的最直观感觉就是快。所有动画速度长度都被大幅缩短，使用体验极度顺滑，和 iOS 14 在手感上有极其明显的差异。新通知中心每个信息的高度被缩短，信息更直观。整体设计更趋于圆润，包括设置菜单，观感变化明显。得益于 SwiftUI 对界面迭代的自动化，预期用上新技术的应用都能自动适配新设计。音乐等服务中新增了分享按钮，猜测支持类似 QQ 音乐等类似的一起听功能。

新的浏览器使用体验和逻辑完全不同，Safari 的主页定制功能依旧很棒。整体信息栏目从之前的上方彻底挪到了下方，比如图三所示。信息栏会在网页加载完成后飞速隐藏，直接结果就是下图中间那张图，网页的内容为王，没有任何其它信息，很干净。由于底部边栏也被移除了，新增标签页转变成了左滑手势。来回切换不同标签页也是左右滑动。

新的天气被重新设计，变成了卡片式 UI。气象图等功能支持显示周边地区的天气情况。比较有趣的是下图右侧的天气预报，可以用一个小动画展示地区周边的天气情况。

新的使用场景，在下拉菜单栏中增加了模式选择。以驾车模式为例，以往的一刀切禁止通知不敢大用。新的场景模式中，用户可以自己定制允许的信息和应用来源，并对设备的通知模式进行调整。关于 Carplay 的部分，我出门驾驶了一圈，当前测试版 iOS 15 中未发现界面与 iOS 14 有什么变化，驾驶的专注模式也没有场景细节选项。

试用新的场景功能后，发现这的确是我一直想要的特性。之前的时间控制方案，设置十分杂乱，且关闭困难。比如点开了时间控制，但是忘记勾选电话选项，结果漏接。想要关闭时又得找半天设置，折腾几次就懒得用。而本次更新的场景模式切换使用起来很方便，出了导入应用的流程被优化外，甚至可以设置允许那个主屏被显示。对于需要送货等实效性较强的场景，可以交给系统判断是否突破场景设置，打算长期使用这个新功能。

2、iPadOS 15

iPadOS 15 在浏览器方面有大幅改变，一开始还挺不适应的。左侧标签栏目前的功能只能说可以用，但体验还需要明年继续打磨。整体交互逻辑从浏览器本身下放到标签页上，喜不喜欢见仁见智。新的小组件和 iPhone 运作方式类似，应用抽屉点击右下角的图标呼唤出，动画效果极佳。

多任务的体验大幅改进。在此之前，呼出 iPadOS 有点像一道斗智斗勇的测试，不知道应用何时全屏、何时居中、何时在左右两侧、何时叠加在另一个应用之上。新的按钮设计修正了这个交互方式不明确的问题，如下图右侧应用顶端所示，点按新的小圆点按钮后，会呼出多任务菜单。点选当前应用的排列方式即可，交互更直观。

3、macOS 12

macOS 已经转变为与其它系统平齐的大版本号更新，新版本是 macOS 12 Monterey。

邮件方面，打开便会提醒开启邮件隐私保护。这是本次发布会中新增的安全功能，是为了应对邮件自动加载远程内容时，泄露本机 IP 地址的问题。

macOS 上的浏览器界面变得整洁许多，如下图所示。Safari 的隐私保护能力进一步得到提升，在以往的跨平台追踪保护的基础上，这次新增了对所有追踪器隐藏 IP。比较头大的地方在于按钮隐藏的过多，比如我找了半天没找到刷新，后来才想起来全部功能都藏在标签页右侧的汉堡菜单里。

4、watchOS 8

watchOS 的几个感知度较强的新特性，如左侧的冥想应用，真的是播放一段动画并配有文字提醒，让你琢磨琢磨当天有哪些幸福的事。下图居中时新的分享菜单。右侧的新的卡包是我很期待的一个功能，这点在微信等二维码支付方式不普及的海外感知更明显，随时需要用到诸如信用卡这样的东西，在海外的使用需求中，拍手表很方便，因为随时都带着。若根据 Apple 本次发布会的计划，以后酒店身份证等卡片都能存在这里，的确能省去丢卡的问题。

5、思考

AR 眼镜

发布最早要在 2022 年底到 2023 年初，准备工作稳步推进。Apple 这点真不错，做事始终很稳重。比如今天发布的用上雷达传感器的物体识别技术，就是在做最后的扫描层面的准备工作。技术层面的准备与 AR 的科普于应用场景不再多提，若你感兴趣过去几年 Apple 做了些什么，「关联阅读：我对 AR 眼镜的观察、雷达 LiDAR 传感器」

本机智慧

发布会中提到的 On-device Intelligence，其实是最近几年 Apple 对于设备思考的极重要点。它的核心意义在于将所有能在设备上做的事情与数据，全部留在设备并通过 A 和 M 系列芯片中的专属硬件来处理。本机智慧通过机器学习和推荐算法，在保障绝对隐私的情况下，让设备更懂用户，为用户服务。本次的发布会中，可以看到全面铺开的各种音频、视频、应用层面的功能，都是以此为基础。2017 - 2019 Apple 系统应用开始尝试、2020 开放给开发者、2021 也就是本次的迭代中，跨平台、跨应用、跨领域全面铺开。

iPadOS 和 macOS

这部分我看到仍有许多用户困惑，想要二者重合。这是不可能的，它们二者是完全不同的东西和操作方式，强扭的瓜不甜，目标用户不同没必要合二为一。但在设计层面，要保障设计语言的一致性，这是今年发布会中隐藏着的主要思路。在 Apple 生态系统设备增多的同时，增强设备间的连结感是另一个隐藏思路。比如今天提到的 HomePod mini 与 Apple TV 的联动、跨平台光标与键盘控制，都是极度优秀的技术突破。「关联阅读：iPad 光标」

性能

M 或 A 系列芯片性能都非常强大，对于绝大多数人的使用需求性能过剩。在带来畅快体验的同时，硬件性能反倒是现在选购新设备时最不需要考虑的一件事。很多人期待的 FCP、Xcode 等专业应用向 iPad 的产品线的迁移是一定会来的，不过这些专业应用往往开发周期长，还需要时间。「关联阅读：M1 实际体验」

软件的隐性提升

诸如 macOS、iPadOS、iOS、watchOS 是 WWDC 的年度例行更新。今年主要集中在「场景」上，主推基于本机智慧的场景分类，让设备更了解用户在当下场景中的使用需求。iPadOS 相比 iOS 缺失的诸如自定义小组件位置和应用抽屉等功能，被完善到 iPadOS 中；macOS 的 Safari 被重新设计，与iPadOS 的使用体验同步，并将浏览器插件带入移动端。iPadOS 重大变革的第一步是今年力推的应用标签页，与 macOS 优秀的多任务体验进一步靠拢，为 iPad 应用的生产力提升放下新脚印。

服务及用户体验

服务层面，Apple 在如隐私保护、在线办公、健康这些偏当下的，人性层面的主题中，依旧付出很多努力。Apple One 中的六个服务多少也有些进度推进。个人最开心的是 Apple 地图的又一次跨越式提升，过去几年中，苹果地图在体验上从落后谷歌很多到远远甩开，这点我看在眼中。新的诸如道路立交桥实体化，极度精致的交通细节，以及与 Watch 的联动等功能都已经是我生活中离不开的一部分。诸如地图中的地球选点、数字身份证、Apple Pencil 的快速笔记、Message 的内容自动整理、iOS 的天气图等新功能，可以说锦上添花。

上一篇下一篇

猜你喜欢

热点阅读