向远公园 | Step Park

订阅 Apple Music 该选哪个区？——中美坡港台日六大地区全对比（第二版）

2021-11-01T03:34:26+08:00

《订阅 Apple Music 该选哪个区？——中美坡港日五大地区全对比》这篇文章给许多 Apple Music 选择地区有困惑的读者提供了许多帮助，一年多以后，Apple Music 服务和相关的 Apple 媒体服务、Apple 硬件也发生了不少的变化，是时候将整篇文章翻新，推出全新的第二版-《订阅 Apple Music 该选哪个区？——中美坡港台日六大地区全对比》，让它继续发光发热。

第二版序

一年多以前，当我不满于阉割的国区 Apple Music 时，下定决心要把 Apple Music 服务迁往非中区，纠结该选哪个区作为我的下一站，在网络上搜寻各种资料期望能根据我的需求做出我的判断，每一篇文章、每一份资料、每一个论坛中的讨论都让我多获得一点信息，但没有一篇文章好好把这个对于中国大陆地区 Apple Music 用户的痛点讲清楚、讲透彻，于是我决定自己来写一篇，所以就有了《订阅 Apple Music 该选哪个区？——中美坡港日五大地区全对比》这篇文章。

这篇文章发布在我的博客网站-向远公园，截止到 2021 年 10 月底，浏览量 34500 次+，页面平均停留时长 6 分 19 秒，超过 70% 的访问来源于 Google 搜索引擎；同时文章发布在我一直喜爱的数字生活网站-少数派，由于种种原因，它并没有在首页被推荐过或在少数派其他媒体渠道分发过，但截止到 2021 年 10 月底，这篇文章仍在少数派获得了接近 120000 的浏览量（大部分来源于读者根据自己需求获得的搜索结果），得到 201 次充电，收获 78 条评论；并同时被我喜爱的专注、及时、优质的 IT 资讯 Telegram 频道-「Newlearnerの自留地」推荐，截止到 2021 年 10 月底，获得 8100+ 的浏览量。

当你在 Google 搜索引擎中搜索「Apple Music 美区」、「Apple Music 换区」、「Apple Music 选哪个区」等类似搜索关键词时，我的这篇文章一定会出现在数一数二的位置，期望能给你带来帮助。并且在某些搜索结果下，通过 Google 的自动化系统，Google 自动地将文章中的总结部分作为精选摘要直接呈现在搜索结果中，而这一功能，没有任何入口人工主动触发，全部依靠算法的结果，也即依靠每一个搜索者的搜索需求和点击行为。

在这之间，我不断收到来自读者的点赞评论，他们欣喜地告诉我我的文章恰到好处地帮到了他们；同时，通过我博客网站上的收款码，也意外收到了一些读者毫不吝啬的现金激励。我很欣慰自己的文章发挥了它的价值，帮助到了越来越多在选择 Apple Music 服务上有困惑的人，并持续发光发热。

一年多以后，Apple Music 服务和 Apple 媒体服务以及相关的 Apple 硬件在这段时间里发生了许多不算大也不算小的变化：

2020 年 4 月：Apple Music 网页版由 Beta 版转向正式版，并首次在第三方电视端-三星电视上上线，拓宽了 Apple Music 的服务渠道；
2020 年 7 月：台湾地区开售 App Store 充值卡，更便捷的支付方式让台区亦成为 Apple 媒体服务地区选择之一；
2020 年 8 月：Beats 1 电台升级为「Apple Music 1」，新增「Apple Music Hits」和「Apple Music Country」两个电台；
2020 年 9 月：Apple 服务家族增加新成员 Apple Fitness+，同时推出集合了 iCloud、Apple Music、Apple Arcade、Apple TV+、Apple Fitness+、Apple News+ 的 Apple 服务全家桶 Apple One；
2020 年 10 月：Apple 在美国地区推出 Apple Music TV 24 小时直播频道；
2020 年 10 月&12月、2021 年 4 月：HomePod mini、AirPods Max、Apple TV 第六代推出，拓宽了 Apple Music 服务的硬件载体；
2020 年 12 月：Apple Music 服务在 Google Nest 音箱和显示屏系列设备上上线；
2021 年 6 月：Apple 宣布 Apple Music 推出支持杜比全景声的空间音频功能，还将为曲库中的上千万首歌曲带来无损音频选项；
2021 年 8 月：Apple 收购古典音乐流媒体服务 Primephonic，Apple Music 订阅用户将享受到大幅提升的古典音乐欣赏体验；
2021 年 9-10 月：Apple Fitness 服务和 Apple One 服务在更多国家和地区开放；
2021 年 10 月：Apple Music 推出更便宜的「声控」购买方案，并新增更多基于心情和活动的歌单，可与 Siri 强强联合，AirPods 3 发布，HomePod mini 推出三款全新配色，Apple Music 在 Sony PS5 上线；
2021 年 10 月：iOS 15.1、HomePod 15.1 发布，HomePod 和 HomePod mini 获得完整的无损音频功能解锁，HomePod 还可解锁支持杜比全景声的空间音频功能；Apple 媒体服务美区增加对简体中文的本地化支持，Apple Music 美区解锁简体中文显示功能。

至此，我觉得有必要将一年多以前的文章进行一遍翻新，根据上面的这些变化，删掉过时的内容，更新有变化的内容，新增值得被对比的内容。于是就有了之前文章的第二版，也就是你现在所看到的：《订阅 Apple Music 该选哪个区？——中美坡港台日六大地区全对比（第二版）》。希望更新后的这篇文章能够继续为互联网中困惑的你我他带去帮助，希望能为自由开放的互联网世界带去更多的一点光。

第二版更新概要

为了让读者更快速清晰地知道第二版相比第一版更新了哪些内容，也为了能让看过第一版的用户只关注更新的内容，不至于从头再读一遍，所以我特意把第二版的更新做了概要，罗列如下：

新增

新增：全文在第一版对比中国、美国、新加坡、中国香港、日本五大地区的基础上，增加了中国台湾地区的对比；
新增：「在线曲库」部分补充了可能因不同地区时差原因造成的歌曲/专辑上线时间有差异，进而造成不同地区曲库数量的差别的情况；进一步完善了因中国大陆地区特殊原因造成歌曲/专辑上线时间过晚的情况描述；
新增：「电视与影片」部分新增 Apple Music TV、Apple Music on Apple News 的描述；
新增：「多平台使用」部分新增对于 Apple Music 支持杜比全景声的空间音频功能和无损音频功能的描述，新增 HomePod 即将在所有销售地区支持多用户声控识别功能的描述；
新增：「价格对比」中新增对于 Apple Music 声控订阅方案的描述，完全更新 Apple Music 六大地区四大订阅方案的横向对比表格，新增四大地区 Apple One 订阅服务的横向对比表格和描述；
新增：「付款方式」中新增对于台区开售 App Store 充值卡的信息，更新部分文字描述。

更新

更新：「在线曲库」部分曲库数量上，非中国大陆区曲库数量相比之前的 6000 万增加至 9000 万，中国大陆地区仍保持为「上千万首歌曲」；
更新：全面翻新「电台」部分中的内容，包括但不限于新增的 Apple 直播广播电台、中国大陆地区上线的部分 Apple 直播广播电台点播内容、完全更新对于电台部分六大地区的横向对比图；
更新：「朋友」部分更新部分图片，更新其中对于中区用户查看用户自己创建的播放列表时更细节的描述；
更新：「iTunes Store & iTunes Match」部分微调 iTunes Match 的部分文字描述；
更新：「曲库语言逻辑」部分更新了由于美区 Apple 媒体服务支持简体中文本地化后变化的结果，完全更新对比表格；
更新：「内容推荐」部分微调了部分文字描述，完全更新对于浏览 tab 六大地区的横向对比图，增加了对于六个地区推荐内容的更细致的分析描述；
更新：「多平台使用」部分对于第三方电视端和游戏机、智能音箱的文字描述和图片进行了更新，对于在 Apple TV 上使用 Apple Music 补充了更多描述，对整个部分的文字描述进行了微调；
更新：「多 Apple ID 使用」部分补充对 Apple Store app、Apple News、Apple Fitness+、Apple One 服务的相关描述，并完全更新 Apple 媒体服务在六大地区的对比表格；
更新：「总结」部分完全更新六大地区横向对比表格，并对总结文字进行了扩充描述。

删除

删除：「在线曲库」部分提及中国大陆地区主流流媒体 app 时删除「虾米音乐」；
删除：「多平台使用」部分中删除了目前已不可用的第三方网页端和 app 服务。

正文开始~

2015 年 6 月 30 日 Apple 正式推出「Apple Music」音乐流媒体服务。9 月 30 日，Apple Music 在中国大陆地区上线。相比于美国地区个人订阅每月 9.99 美元的价格，中国大陆地区的个人订阅价格为每月 10 人民币，可以说几乎是全球最低。但喜欢听音乐的人很多不愿意选择价格如此低廉的国区 Apple Music，反而在重重困难下选择订阅其他地区的 Apple Music，这是为什么呢？
这篇文章选取了常见的美国区、香港区、台湾区、新加坡区、日本区，与中国大陆区的 Apple Music 在曲库数量、功能差异、内容展示、多平台使用、多 Apple ID 使用、订阅付费等多个方面进行对比，并附带介绍了一些容易被忽略的相关功能，以期让你在选择 Apple Music 地区时能有一个明确的方向。

在线曲库

相信选择非中国大陆区的朋友，最大的原因就是曲库。在 Apple 官网上的 Apple Music 介绍中，中国大陆地区的描述是「上千万首歌曲」，美区的描述是「90 million songs」，即「九千万歌曲」，差距不言自明。

其他非中区的曲库数量和美区相当，但因为不同区上架的歌曲一般都是根据不同区的用户喜好、歌手发展区域等，最终由版权授权决定，所以还是会有些差别，不存在某个地区所有的歌都有的情况。在线曲库没有的歌曲，可以自己上传到 iCloud 音乐资料库，并同步到所有设备。
如果想知道确切的某首歌、某张专辑、某个歌手在某个地区的 Apple Music 上有没有上架，可以通过 Apple 官方的「Apple Music 营销工具」查询，全球所有上线 Apple Music 的地区均可查询，建议电脑端访问。如果查询不到则说明没有在那个地区上架。
需要注意的是，由于全球不同地区时差的原因，某一歌曲/专辑可能存在先在时间早的地区上架，一段时间后才会时间晚的地区上架，这样因为时间的原因也可能造成曲库的临时不同。比如，某个专辑设定了上线时间为某日凌晨零点，根据各个地区的时差，大概会按照日本→中国台湾&香港&大陆&新加坡→美国的先后顺序上架，美国可能晚于其他地区 12 小时左右。

一个上千万，一个九千万，大到九倍的差别，到底具体差在哪呢，中国大陆的曲库到底少了什么？通过几个例子来看下：

版权分割

曲库差异最基本的原因就是版权，在中国大陆地区尤其明显。众所周知，中国大陆地区的主流音乐播放软件是 QQ 音乐、网易云音乐……Apple Music 并不是主流，某些歌曲的版权自然争不过主流平台，特别是腾讯这个龙头老大。

例如，TFBOYS 的歌曲在新加坡区和中国大陆区的上线情况如下图：

除了版权分割导致的数量差异，还存在不同区上线时间不一致的情况。歌手「Eminem」于 2020 年 1 月 17 日推出全新专辑《Music To Be Murdered By》。当时美区正常上架，中区不见其踪影，很长一段时间后才姗姗来迟，利用这段时间可能完成了内容认证，但听众尝鲜只能晚别人一拍。

儿童不宜内容？

含有性描述、暴力、脏话、毒品等这些儿童不宜内容的歌曲在 Apple Music 会被打上 E 标（E 在此指英文单词「EXPLICIT」），也俗称「脏标」。这类歌曲在中区会被进一步处理，处理的方式五花八门。

还是上面提到的歌手「Eminem」的这张专辑《Music To Be Murdered By》，在中区，脏标版本只上架了歌曲序号为 4、20 的这两首歌，非脏标版本上架了全部的 20 首歌曲，但脏话在歌曲和歌词中均被和谐。

歌手「Enrique Iglesias」的《SEX AND LOVE》这张专辑，由于在专辑封面和专辑名字中含有「SEX」这个词语，在中区得到了特别处理。

歌手「Nicki Minaj」的《Queen》这张专辑，其专辑封面在中区得到了特殊处理。

歌手「Lauv」的《~how i’m feeling~》这张专辑，前两首歌的歌名中包含了「drugs」和「fuck」这两个词语，在中国区未上架。

法律法规影响

根据不同地区的法律法规，部分歌手的歌曲不能在某些地区上架或上架一段时间后被下架，例如下图中的歌手 LiZhi。

功能差异

相比于曲库的差异，不同地区 Apple Music 功能上的差异似乎讨论的不多。实际情况是，根据不同地区对音乐内容的政策不同，相关功能也就会不同，而且差异还不小。

广播电台

广播电台功能应该是功能差异中最容易发现的，如果你进入 Apple Music 「广播/Radio」栏目，相比非中区，中区的内容比较单薄，之前只有根据歌曲类型由机器自动生成的一些风格电台，最近才新增了一些 Apple 直播电台的点播或者说录播节目内容，无任何直播内容。
这主要是因为中区 Apple Music 没有「Apple Music 直播广播电台」功能和「地区性直播广播电台」功能。

Apple Music 直播广播电台目前包括「Apple Music 1」、「Apple Music Hits」、「Apple Music Country」三个直播电台。
其中「Apple Music 1」的前身是「Beats 1」，根据 Apple 的描述，「Beats 1 是一个 24 小时直播电台，由 Apple 的 DJ 在洛杉矶、纽约和伦敦进行广播。在 Beats 1 收听由著名艺人和 DJ 主持的直播节目和独家采访，并发现来自世界各地的新音乐。」

2020 年 8 月 19 日 Apple 发出新闻稿，Beats 1 电台升级为「Apple Music 1」，新增「Apple Music Hits」和「Apple Music Country」两个电台。这三个电台均可在非中区的 Apple Music 中收听直播。

Apple Music 直播广播电台除了包括实时广播以外，在 Apple Music 中还可以听到往期的直播回放，看到相关视频，如与歌手的访谈。Apple Music 也会根据 Apple Music 直播广播电台的内容，将相关歌手、专辑、单曲、播放列表打包成组，推荐给用户。
除了 Apple Music 直播广播电台，非中区的 Apple Music 还包括本地或其他地区与音乐有关的实时直播电台。

下面这张图几乎在同一时刻截取了六大地区 Apple Music 「广播/Radio」模块下的展示内容，供参考。可以看出，中国大陆地区的内容明显少于其他地区，日本区额外提供了很多本土内容，是除了美国区之外本地化做的非常不错的一个地区。

值得注意的是，即使你没有订阅 Apple Music，你也可以在限定时间内收听 Apple Music Hits 和 Apple Music Country 直播节目，在所有时间收听 Apple Music 1 直播节目和其他直播电台。

朋友

朋友功能算是 Apple Music 在音乐轻度社交上的一些探索，随 2017 年的 iOS 11 开始推出，其主要目的是可以与朋友更好地分享正在收听的内容。以下所有功能均未在中国大陆区上线。

个人主页&关注朋友：每一个使用 Apple Music 的用户都可以建立自己的个人主页，在主页中可以看到正在听的音乐、分享的自己创建的播放列表以及关注和被关注的用户，这项功能没有地区隔离，也就是说你可以关注全世界任何一个地区的使用此功能的 Apple Music 用户。当然，个人主页是否公开、正在听的音乐是否展示、自己创建的播放列表是私密还是公开完全由你自己控制。

「朋友们正在听」列表和「Friends Mix」智能歌单：当你关注了其他人后，就可以在「现在就听/Listen Now」模块下看到「朋友正在听」列表，同时在 Apple Music 的各个地方（如专辑封面、播放列表封面、专辑详情页面、播放列表详情页面）可以看到正在听的朋友的头像。当关注的朋友足够多时，Apple 会自动生成「Friends Mix」智能歌单，结合你的喜好，收录近期朋友听的歌，每周更新。你可以通过链接访问其他人的 Friends Mix 歌单，中区用户也可以。

搜索别人公开分享的播放列表：当用户创建的播放列表设置为公开时，你可以通过搜索功能搜索到这些播放列表。中国区仅支持通过链接查看，不支持搜索，且不支持查看用户创建的播放列表的自定义专辑封面。

全球 Top 100 歌单

2018 年 Apple Music 推出了每日更新的全球及各个地区的 Top 100 歌单，例如「Top 100: USA」歌单，一般固定在「浏览/Browse」模块下展示。该功能在美区、新加坡区、日区已上线，港区、台区、中区未上线。

在 2019 年年末，Apple Music 又推出了全球和各地区的年度 Top 100 歌单，例如「Top 100 Songs of 2019: Global」歌单。当时在有每日 Top 100 歌单的地区的「浏览/Browse」模块下做过推荐展示。这些歌单现在可以通过搜索或链接访问。

电视与影片

Apple Music 中的「电视与影片」大部分是自制的与音乐有关的电视节目，如 Apple Music 曾经主推的《Carpool Karaoke》、《Planets of the Apps》、「Up Next 系列」（如《Up Next: Billie Eilish》，音乐纪录片《The Changes Interview》，一般均自带中文字幕。电视与影片可以和歌手、歌曲、专辑、播放列表，甚至是 App Store 中的内容、iTunes Store 中的内容打包到一起做内容推荐。该功能未在中国大陆区上线。

在 Apple Music 中，曾经有专门的入口进入「电视与影片/TV&Movies」模块，目前该入口在几次改版后下线，该模块被弱化，但未停止更新。电视与影片目前可以通过搜索、链接或者编辑内容推荐访问。
2020 年 10 月，Apple Music TV 直播频道在美区上线，24 小时通过视频+音频的形式不间断直播与音乐相关的内容，相关推荐位会根据内容的编排灵活推荐 Apple Music TV 的内容，同时 Apple TV+ app 中一般也会有相应的入口。需要注意的是，Apple Music TV 因为只在美国地区上线，所以只能通过美国 IP 访问，使用其他地区的 IP 在即使是订阅了 Apple Music 美区的情况下也无法访问。

同时，由于美区有上线 Apple News 服务，故在 Apple Music 中包含相关 Apple Music on Apple News 的引流入口。

iTunes Store & iTunes Match

在 Apple Music 音乐流媒体推出之前，全球许多个国家或地区（不包括中国大陆地区）一直可以通过 iTunes Store 付费购买歌曲或专辑。Apple Music 中的歌曲会随着版权的变化发生变化，一首歌现在可以听，并不代表你永远可以听，它属于音乐流媒体；iTunes Store 中的歌曲只要你购买了，那就属于你自己，它属于电子音乐购买。
根据版权的授权，部分歌曲可能存在在 Apple Music 中没有上架，但在 iTunes Store 中上架的情况，例如「Justin Biber」的专辑《Purpose (Deluxe)》中的第 11 首歌《Where Are Ü Now》未在 Apple Music 中上架（灰色不可播放状态），但可以在 iTunes Store 中通过购买整张专辑的方式获得。

同一个 Apple ID 下，在 iTunes Store 中购买的音乐会自动进入 Apple Music 的资料库。
iTunes Match 是 Apple 于 2011 年推出的一项服务，如 Apple 官方描述，「通过 iTunes Match，您可以在自己的所有设备上访问您的所有音乐，甚至还可以访问您从 CD 等其他来源导入的歌曲。」简而言之，iTunes Match 的功能主要是「匹配（不等于上传）用户导入的音乐」和「在设备间同步音乐资料库」，可以说是「iCloud 音乐资料库」的前身。该服务未在中国大陆地区上线。

Apple Music 推出后，涵盖了 iTunes Match 的所有功能。iTunes Match 不再推广，但并没有停止运营，现在你仍可以通过 iTunes Store 的页面底部找到入口，按年订阅 iTunes Match。
由于早期中国大陆地区没有 iTunes Store 功能，也就没有推出过 iTunes Match，现在的 Apple Music 也就不包括 iTunes Match。但在实际情况中，中国大陆地区的 Apple Music 在使用资料库上传歌曲后，某些歌曲可以呈现「已匹配」状态。2019 年 1 月有网友在 V2EX 发帖称，原来上传后状态为「已匹配」的无压缩、无 DRM 保护的歌曲变成了「已匹配」的有压缩、有 DRM 保护的歌曲，而非中区不存在这种情况。2019 年 2 月又有网友在 V2EX 发帖称，自己上传的歌曲不仅存在上述问题，歌曲还出现了不明杂音，不知此情况是否为个别现象或是 bug。故此功能在中国大陆区的具体规则十分模糊。

类似艺人

「类似艺人」是指在 Apple Music 的歌手页面的最底部，会推荐其他相似的艺人/歌手。非中区都包含此功能，中区没有显示此模块，不显示原因未知，很迷惑。例如，下图中歌手「周杰伦」的页面：

音乐向导

「音乐向导」可以理解为 Apple Music 中某些官方机构、组织创建的播放列表合集，这个功能随着 Apple Music 改版被弱化，从之前的专门入口演变到现在只能通过搜索或链接访问，但并没有停止更新。非中区的音乐向导基本一致，但中区只包含部分，其他即使通过链接也无法访问。例如，以「music」为搜索关键字搜索音乐向导：

曲库语言&内容推荐

曲库语言逻辑

Apple Music 的曲库显示语言是指除歌曲本身之外的文字的显示语言，如专辑介绍、歌单推荐语、歌单封面、歌手名字等。一般情况下，专辑和歌曲的名字在各个地区都是一样的，但根据专辑在全球的发行情况的不同，也存在专辑和歌曲名字被翻译成当地语言的情况，比如部分中文歌曲在美区是以英文名呈现的。
各个地区的 Apple Music 支持的显示语言是不同的，一个地区并不会支持全球所有语言，会根据对应地区的用户的常用语言来决定，且不止一种，并一定包括英文，但只有一种会被作为「主要显示语言」。
以 iPhone 为例，如果 iOS 系统的语言设置为 Apple Music 在本地区支持的显示语言的某一种，那么 Apple Music 就会以系统设置的语言展示；如果 iOS 系统的语言设置为 Apple Music 在本地区不支持的显示语言，那么 Apple Music 就会以「主要显示语言」展示。
为了更好地理解上述逻辑，把五个地区的 Apple Music 在不同系统语言下展示情况列举如下：

2021 年 10 月，美区的所有 Apple 服务进行了更新，增加了对简体中文本地化的支持，也即美区媒体内容正式支持简体中文。
由上表可以看出，中区、美区、新加坡区可以在系统设置为简体中文时显示为简体中文，其余语言下均为英文；港区、台区在除英文系统下均显示为繁体中文；日本区只有在系统设置为英语时显示英语，其他情况下均显示为日语，包括简体中文系统设置下。
值得特别提及的一点是，日语歌曲的歌曲信息在日区非日语系统环境下和其他区所有语言环境下一般都以「罗马音」形式展示，这是许多人吐槽的一点。

内容推荐

除了自己搜索发现或者通过外部链接访问以及机器智能推荐，在音乐软件中发现音乐的另一种途径是人工内容推荐，这一部分也是 Apple Music 在推出时强调的亮点之一。人工内容推荐在 Apple Music 中占据了较大的篇幅，整个「浏览/Browse」模块几乎都是人工内容推荐，比如带有推荐语的最新专辑推荐、根据时间/节日/时事等编排的歌单列表推荐、本地特别发行专辑推荐、近期本地热门影视原声歌曲推荐、热门艺人 MV 推荐、即将发布专辑推荐等。
根据各地区用户对音乐的偏好不同，即使在曲库差不多（除中区）的情况下，Apple Music 推荐的内容也会不同。概括来看，中区、台区、新加坡区内容推荐以华语音乐（偏国语）和欧美音乐为主，美区内容推荐以欧美音乐为主，港区内容推荐以华语音乐（偏粤语）和欧美音乐为主，日区内容推荐以日语音乐和欧美音乐为主，且本土内容特色凸显。
下面这张图几乎在同一时刻截取了六大地区 Apple Music 「浏览/Browse」模块下的展示内容，供参考。笔者截图时正值 2021 年万圣节前夜，可以看到美区的内容推荐中包含了许多与万圣节相关的内容，且十分醒目，整体上内容十分充实；新加坡区、日本区也有少量的与万圣节相关的内容推荐，且得益于日本地区独特的文化，日本区本土特色内容十分突出；港区、台区相比前三个区少了地区每日排行榜的展示；中区则在港台区的基础上又少了 Apple Music 电台的推荐。

多平台使用

Apple Music 是支持多平台的音乐流媒体服务，除了 iPhone、Android 手机，你还可以在 iPad、Mac、Windows、网页端、Apple TV、Apple Watch、HomePod、第三方电视端&游戏机、第三方智能音箱、CarPlay 、第三方网页端和 app 上使用。

iPhone、iPad、Apple Watch、HomePod、Mac：苹果常见的自家产品系列自然不用多说，系统原生支持，所有地区帐号均可在上述设备正常使用。2019 年从 macOS Catalina 开始，Apple Music 和 iTunes Music Store 从 iTunes app 中分拆成了独立的「音乐/Music」app；即使在 HomePod 上登录未发售地区的 Apple ID，也可以正常使用 Apple Music。

搭配合适的 AirPods 系列耳机、HomePod 系列音箱，你可以在 Apple 硬件设备上体验 2021 年 6 月最新推出支持杜比全景声的空间音频功能和无损音频功能，这两项新加入的功能对于 Apple Music 订阅用户完全免费。

2021 年 10 月，Apple 为 HomePod mini 新增了三款全新配色，同时在新闻稿中提到「更多地区支持多用户声控识别：今年晚些时候起，Siri 将支持所有可购买 HomePod mini 地区的多用户声控识别功能，用户可以在家享受根据喜好定制的音乐，收听自己的播放列表，使用个人请求功能等。」因此，家庭中的不同用户可以通过不同的声音操控 HomePod，从而只播放属于自己的 Apple Music 播放列表。

Android 手机、Windows：2015 年 11 月，Apple Music 正式上线五个月后，Apple Music Android app 正式发布，你可以通过 Google Play 或者从 Apple 网站直接下载 Apple Music Android app。通过 Apple Music Android app 你可以将其与 Chromecast、Android Auto 结合使用。在 Windows 中，你需要通过安装 iTunes app 使用 Apple Music 相关服务。所有地区帐号均可在上述设备正常使用。

网页端：2019 年 9 月 Apple 上线了网页端的 beta 版 Apple Music，用户可以在浏览器中使用 Apple Music。2020 年 4 月，Apple Music 网页版正式上线，其访问地址是： https://music.apple.com/。值得注意的是，在笔者的电信网络环境下，当登录网页版的 Apple Music 时，输入完帐号和密码提交后，存在一直卡住无法登录的情况，通过非中国大陆地区的 IP 访问时，则可以正常登录，估计是由于登录时某个访问的域名访问不畅导致的。

Apple Music Web Beta 版在之后被用来公开测试一些即将上线的功能，例如 2020 年 8 月，Apple Music Web Beta 版开始测试与 iOS 14、iPadOS 14 对应的新样式、新模块，「为你推荐」调整为「现在收听」，搜索更加突出了按类别搜索，整体个性化内容推荐更加丰富。

Apple TV:Apple Music 同样在 Apple TV 上提供服务。由于 Apple TV 未在中国大陆地区发售，使用国区 Apple ID 登录 Apple TV，没有「音乐/Music」服务，无法正常使用 Apple Music（B 站上有 up 主通过卡 bug 的形式也可使用国区 Apple ID 帐号进入 Apple TV 设备上的 Apple Music，但不推荐），其他五个地区的 Apple ID 可正常使用。

第三方电视端&游戏机： 2020 年 4 月， Apple Music 以独立 app 的形式在三星智能电视上上线，这是 Apple 的媒体服务在第三方设备上的又一次扩张。可以预见，支持 Apple TV app 的智能电视/盒子（如 LG、Amazon Fire TV、Sony）在未来应该也会上线 Apple Music app。2021 年 10 月，Apple Music 同样以 app 的形式在 Sony PS5 游戏机上上线，这是 Apple Music 首次在游戏机上上线。在第三方智能电视和游戏机上使用 Apple Music 可以具体见官方的支持说明文档。

关于第三方电视端的 Apple Music 值得注意的几点：

和 Apple TV app 以及 AirPlay 2 功能一样，Apple Music app 目前不支持国行设备，LG、三星国行设备可以通过换区解决（换区指南↗︎ ），其它国行设备暂时无法解决；
同一设备上，Apple Music app 和 Apple TV app 的帐户登录是独立的，也就是说你可以在同一设备上使用不同的 Apple ID 同时登录两个 app，这在 Apple 自己的设备上是无法实现的；
你可以在第三方电视端的 Apple Music app 中登录并正常使用国区 Apple Music，这在 Apple TV 上也是无法实现的。
CarPlay：你可以将 iPhone 与你的 Apple CarPlay 车载连接，从而在汽车的中控界面中使用 Apple Music。支持 CarPlay 的车型可前往 Apple 官网查看，所有地区的 Apple ID 都可以在 CarPlay 中使用 Apple Music。

第三方智能音箱：你可以在 Amazon Echo、Amazon Fire TV、Sonos 上连接 Apple Music 帐户以使用 Apple Music 服务，具体可查看官方说明文档；从 2020 年 12 月开始，你还可以在 Google Nest 音箱和显示屏系列设备中使用 Apple Music 服务，具体可查看官方说明文档。在第三方智能音箱设备上使用 Apple Music 可能需要设备支持销售地区的 Apple Music 帐户。

第三方网页端和 app：利用 Apple 提供的 MusicKit，开发者可以在自己的 iOS app、Android app、网页端接入 Apple Music 服务，可以是部分功能接入，可以是全功能接入，即作为一个第三方 Apple Music 客户端，iOS 端 app 通过请求「媒体与 Apple Music」权限访问 Apple Music 内容，Web 端 app 通过 Apple ID 授权第三方登录的方式登录使用。例如：
- 第三方网页端：Musish、Apple Music Web Player From Naveed Golafshani、feverTunes、Zachary Seguin Music。
- 网页中嵌入自定义 Apple Music 内容：我的个人博客的「Music」页面 - 未登录时歌曲只可以试听，登录订阅帐号后可完整播放。
- 第三方 iOS app： Marvis Pro、Soor ▹、SongOwl。
- 接入 MusicKit 的工具型 iOS app：Shazam（歌曲识别）、MusixMatch（歌词）、SongShift（歌曲迁移）、Mixmum（自定义歌单）、MusicHarbor（歌手关注）。

多 Apple ID 使用

该部分主要适应于 Apple 设备，非 Apple 设备一般不存在多 Apple ID 使用的情况。

以 iPhone 为例，系统中的 Apple ID 帐号分为「iCloud 帐号」和「iTunes Store 与 App Store 帐号」：
- iCloud 帐号负责管控与云同步相关的功能，例如同步照片、通讯录、日历、备忘录、Safari 收藏夹、钥匙串以及 iCloud 云盘功能，需要注意的是，目前 Apple Store app 关联的是 iCloud 帐号。
- iTunes Store 与 App Store 帐号可简称为 Apple 媒体帐号，负责管控系统中所有与内容媒体相关的功能，例如 App Store、Apple Music、iTunes Store、Apple TV+、Apple News、Apple Fitness+、Podcast、Books、TestFlight。
同一台设备上登录的 iCloud 帐号和 Apple 媒体帐号可以相同，也可以不同，默认相同。
其他 Apple 设备的逻辑大体相似。

由于非中区 Apple ID 付款方式终归不如中区便利，在中国大陆使用非中区 Apple Music 的用户一般还同时拥有一个中区 Apple ID，常用于 App Store 的付费应用和服务的购买和订阅或者下载只在中区上架的 app（如 Bilibili）。但基于上述逻辑，你无法在同一台设备上让 Apple Music 登录 A 帐号，App Store 登录 B 帐号，Apple TV+ 登录 C 帐号……于是你就不得不有切换 Apple 媒体帐号的需求。
在 iOS 设备、HomePod 上切换 Apple 媒体帐号时可借助系统自带 iCloud钥匙串、1Password 等工具自动填充密码，减少输入，简化流程；在 watchOS 设备上，Apple 媒体帐号与配对的 iPhone 保持同步；在 macOS 设备上切换 Apple 媒体帐号时可借助1Password 等工具填充密码；由于 Apple TV 定位于家庭中多用户使用的设备，在 Apple TV 中可登录多个 Apple ID，从 tvOS 13 开始，需要切换 Apple 媒体帐号时可一键切换，无需输入密码。

第一点值得特别注意的是，在 iOS 设备和 macOS 设备上切换 Apple 媒体帐号时，Apple Music 资料库里已下载的内容中，属于 Apple Music 的内容会被从设备本地移除，属于用户自己上传的内容不会被移除。重新登录此 Apple ID 后，需在开启Apple Music 资料库后重新下载（系统内也可能保留有上次下载内容的缓存，若有可快速加载）。

第二点值得特别注意的是， Apple 媒体服务设有 90 天帐号与设备绑定逻辑，具体如下：当在一台设备上使用不同的 Apple ID 启动 Apple 媒体下载功能（如开启 Apple Music 资料库，下载 iTunes Store 购买的音乐、电影、电视剧）时，系统会提示你需要将此设备与当前登录的 Apple 媒体帐号绑定，90 天内不能使用其他 Apple ID 的 Apple 媒体下载功能。绑定后若再使用其他 Apple ID 开启 Apple 媒体内容下载功能时，系统会提示此设备已与其他 Apple ID 绑定，并告知还剩余多少时间。若不小心错误地触发绑定，可联系 Apple 官方客服，有一定几率可以提前解绑。以上适应于 iOS、Android、Mac、Windows 设备。

关于 app 的下载，对于从 A 帐号下载的 app，在登录 B 帐号的情况下，只要 B 帐号所在地区的 App Store 有上架此 app，无需切换回 A 帐号就可检测到该 app 的更新，并可以正常更新，第一次更新时可能要求输入 A 帐号的登录密码。
关于 app 的内购和订阅，对于 A 帐号购买的 app 的内购和订阅，一般情况下只能在登录 A 帐号的情况下才能恢复购买；在使用 A 帐号下载的 app 中，不能在登录 B 帐号时进行内购和订阅的付费。
对于只在中区或者只在某一个地区上架的应用需要更新时，可以通过这个小工具快速切换当前设备 Apple 媒体服务到对应的地区，检查 app 更新并完成下载更新。注意该工具仅是通过一个链接跳转到了其他区的 Apple 媒体服务，并没有修改 Apple ID 的地区，你也不能购买/播放其他地区的应用/音乐。你也可以利用这个工具查看任一地区的 Apple Music、App Store、Apple TV 内容。若不能正常跳转可尝试通过非中国大陆地区 IP 访问。

除了 App Store 和 Apple Music，Apple 媒体服务还包括 iTunes Store（影片、电视节目、音乐、铃声和提示音）、Apple Arcade、Apple TV+、Apple TV Channel、Apple Books（图书、有声书）、Apple 播客、Apple News（含 Apple News+）、Apple Fitness+。2020 年 9 月，Apple 将自家的多个服务打包成 Apple One，可以以优惠的价格一站式使用 Apple 提供的多个付费服务。具体来看，将 Apple Music、Apple TV+、Apple Arcade、iCloud+ 50G 打包成个人套餐，可供一个人使用；将 Apple Music、Apple TV+、Apple Arcade、iCloud+ 200G 打包成家庭套餐，可供家庭中最多六人共享使用；将 Apple Music、Apple TV+、Apple Arcade、iCloud+ 2TB、Apple News+、Apple Fitness+ 打包成高级套餐，可供家庭中最多六人共享使用。
根据政策和版权的限制，不同地区提供的 Apple 媒体服务不同。在使用某一个地区的 Apple ID 时，你可能也会用到其他 Apple 媒体服务，故将六个地区的 Apple 媒体服务的提供情况列表对比如下，要注意的是即使提供相同的服务，在不同区的表现也可能差异巨大：

其中 Apple TV app 即使不支持某个第三方 app 作为一个频道订阅，但还可以支持搜索、展示第三方 app 的内容，如 Disney+、Amazon Prime Video，该功能目前在美区、日区帐号中提供，但支持范围不同，具体支持列表参见 Apple 官方网站。
当然，即使某项功能提供服务，在不同的地区提供的内容也是不同的。例如所有未经允许的含有 VPN 功能的 app（如 Speedtest、Adguard）都无法上架中区、未在中国大陆地区提供服务的 app（如 Netflix、Spotify）没有上架中区、因各种原因被屏蔽的 app（如 Skype、Pinterest）无法上架或主动不上架中区、某些中区上架的 app 为中区特供版（如中区 Sky 光·遇、非中区 Sky 光·遇，中区 Flipboard、非中区 Flipboard）、Apple 播客中的节目在中区经过筛选（如《Drake Freestyle》未上架中区）。
总的来看，相比其他区，美区的 Apple 媒体资源拥有独占的 Apple News+、Apple Fitness+ 和 Apple One 高级套餐，其最丰富，功能最齐全，其次是日区、新加坡区、台区，港区因为没有 Apple Arcade 服务，所以不支持任何等级的 Apple One 套餐，也整体显得有点掉队。
真心期望 Apple 能在未来的版本中将各个媒体服务的 Apple ID 独立，不过希望渺茫🙃。

订阅付费

价格对比

Apple Music 包括个人订阅、学生订阅（需定期验证学生身份）、家庭订阅（可与其他同一地区的五个人组成家庭组）三种，同时在 2021 年 10 月，Apple 宣布即将在部分国家和地区（一般为 HomePod 发售的地区）推出「声控订阅/Voice Plan」方案，此方案相比个人订阅方案，不支持在非 Apple 设备上使用，不支持空间音频、无损音频、歌词显示、缓存歌曲到资料库几个功能，更像是一个特别适应于在 HomePod 上想听就听的入门级订阅方案。

在购买 Apple Music 服务时，不同地区的价格也不一样。六大地区的具体订阅价格如下（人民币换算参考 2021 年 10 月底中国银联各货币对人民币汇率，仅供参考，请以即时的汇率为准，下同）：

从上表中可以看出，中区比其他地区便宜数倍，美区最高，其次是日区，港区和新加坡区价格相当，台区相比便宜不少。因新加坡地区未发售 HomePod，故暂未有计划推出 Apple Music 声控订阅方案。
由于 Apple One 服务的推出，很多用户期望通过更便宜的价格用上多个 Apple 服务，故也将美国、新加坡、台湾、日本四个地区的 Apple One 服务订阅价格对比如下：

同 Apple Music 服务的订阅价格类似，美区价格最高，但提供高级套餐；新加坡区和日本区的家庭套餐价格相当，台区相对更便宜；日本区的个人套餐反而最便宜，其次是台区、新加坡区。

付款方式

付款方式可能是使用非中区 Apple ID 除注册过程之外的另一个重大障碍。根据 Apple 官方的描述，六个地区的 Apple ID 支持的付款方式如下表：

因为 Apple ID 支持的付款方式中的信用卡和借记卡严格限制为本地区发行，所以除中区外一般情况下各个地区最便捷的付款方式还是通过充值卡。值得欣喜的是，2020 年 7 月，台湾地区开售 App Store 充值卡，这使得中国大陆地区用户便捷使用台区 Apple ID 成为可能。
对于中国大陆用户，充值卡最方便购买的是美区，其次是港区、台区、日区，再次是新加坡区，通过第三方购买充值卡一般都会比正常汇率高一些，越方便购买的溢价越少。
目前只有美区、日区充值卡可通过 Apple 官方网站购买，10 美元/1000日元起售，通过 Email 发送，可使用中国大陆发行的 Visa/Master/AE 银行卡支付。
对于除充值卡外，中国大陆用户常用的一些付款方式，在此简要说明，不做详述：
- 美区：美区 Paypal 绑定中国大陆发行的 Visa/Master 银行卡再绑定 Apple ID（绑定成功率低，极易风控，特别注意不要通过此方式为 Apple ID 充值，极易封 Apple ID，无法挽回）；
- 港区：香港地区发行的 Visa/Master 虚拟储值卡，如拍住赏、八达通 O! ePay（开卡可能需要香港手机号，需验证护照/港澳通行证，充值不方便）、AliPay HK（开通帐户需要香港手机号，需验证护照/港澳通行证，充值不方便）；
- 日区：中国大陆地区发行的部分 JCB 信用卡。
想要曲库丰富&功能齐全，订阅价格就高；想要订阅价格低，曲库就不丰富，功能就不齐全。那曲库丰富&功能齐全、价格低廉就不能两全其美吗？能，来看印度区：
- 印度区同样是九千万的曲库，功能齐全；
- 个人订阅价格为 99 卢比每月，折合人民币约 8.91 元；声控订阅和学生订阅价格为 49 卢比每月，折合人民币约 4.41 元；家庭订阅价格为 149 卢比每月，折合人民币约 13.41 元，平均每人折合人民币约 2.24 元；
- 但是，印度 Apple ID 的付款方式仅支持印度发行的银行卡和通过印度银行卡和印度本土支付方式（如 Net Banking、RuPay、UPI）充值 Apple ID 余额，没有充值卡，想要付款难上加难；
- 另外，印度区的 Apple Music 内容推荐面向印度本土用户，印度风味十足。
所以即使价格低廉、曲库丰富、功能齐全也并不推荐印度区，除非你搞定付款方式以及不在乎印度风味的内容推荐，并对同时使用的其他 Apple 服务没有什么要求。

顺畅使用

Apple Music 作为一项全球音乐流媒体服务，在全球都有布置服务器，但在中国大陆地区使用 Apple Music，因为地域、运营商网络等因素，可能在访问某些服务/功能时加载速度过慢或无法加载。下表列出了 Apple Music 各个功能模块的主要访问域名，其他非主要访问域名（如图片加载、服务器判断等）未列出，若相应服务加载存在问题（特别是播放缓冲问题）可考虑通过非中国大陆地区 IP 地址访问（可能有遗漏）：

总结

综上，文章从在线曲库、包含功能（广播电台、朋友、Top 100 歌单、电视与影片、iTunes Store、类似艺人、音乐向导）、曲库语言、内容推荐、多平台使用、多 Apple ID 使用、订阅价格、付款方式多个方面对六个常见地区的 Apple Music 及其相关功能进行了对比阐述，来看下面这张总结性表格：

一句话总结：

中区：曲库阉割，功能缺失，简体中文界面，Apple 媒体资源匮乏，价格低廉，适合对曲库没有强烈需求、用不到 Apple 更多媒体服务、懒得折腾的你；
美区：曲库丰富，功能齐全，英文和简体中文界面兼顾，Apple 媒体资源丰富，充值卡容易购买，适合钟情欧美歌曲、使用 Apple 全家桶服务的你；
港区：曲库丰富，功能齐全，繁体中文界面，Apple Arcade 迟迟不推出，Apple One 亦卡在路上，略显掉队，充值卡购买难度中等，适合钟情华语歌曲（偏粤语）和欧美歌曲、对 Apple 媒体服务没有强依赖、不介意繁体中文的你；
台区：曲库丰富，功能齐全，繁体中文界面，Apple 媒体服务基本齐全，充值卡购买难度中等，价格相对低廉，适合钟情华语歌曲（偏国语）和欧美歌曲、偏爱多个 Apple 媒体服务、不介意繁体中文的你；
新加坡区：曲库丰富，功能齐全，简体中文界面，Apple 媒体服务基本齐全，充值卡购买难度较大，适合钟情华语歌曲（偏国语）和欧美歌曲、偏爱多个 Apple 媒体服务、有稳定充值卡购买渠道的你；
日区：曲库丰富，功能齐全，英文和日语界面兼顾，没有中文支持，本土特色十足，Apple 媒体服务基本齐全，充值卡购买难度中等，适合钟情日语歌曲和欧美歌曲、偏爱多个 Apple 媒体服务、不介意日文/钟情于日本文化的你。

看到这里的你，根据自己的需求心里有做出选择了吗？

全新 iPhone 12 发布，再谈 iPhone 屏幕尺寸

2020-10-19T03:19:44+08:00

之前写的文章《从第一代 iPhone 细数到 iPhone 12，iPhone 屏幕尺寸进化历程背后的 app 设计哲学》吸引了众多对 iPhone 屏幕尺寸或者对 app 适配感兴趣的读者，在文章发布的各个渠道，特别是在少数派引起了一番热烈的讨论。文章从设计、开发等多个角度讲述了 iPhone 屏幕尺寸进化历程背后的 app 设计哲学，希望读者能够从我梳理的历史脉络和总结的进化逻辑中获得启发。同时文章也顺势推测了未来 iPhone 特别是 iPhone 12 系列会出现的一些变化，这部分虽不是文章重点，但当时处于在 iPhone 12 即将发布的时间点，自然也引起了众多读者的兴趣。

如今，iPhone 12 、iPhone 12 Pro 系列正式发布，屏幕参数尘埃落定。对比之前文章对 iPhone 12 屏幕参数较为保守的推测，真正的 iPhone 12 屏幕参数变化可谓十分激进。本文就作为之前文章的后续，基于之前文章所讲的 iPhone 屏幕尺寸的进化逻辑，来复盘一下 iPhone 12 的屏幕参数到底是如何变化的，对于普通用户在 iPhone 12 上使用 app 又有什么影响。

如果你还没有阅读过之前的文章，强烈推荐你先阅读，否则本文中的提到到的一些概念你可能会云里雾里😜

Update：

2020/10/26：更新了「iPhone 12/iPhone 12 Pro 上的 App 适配实例」部分

iPhone 12 系列屏幕的变化

iPhone 12 系列包括 6.1 寸 iPhone 12 机型和 5.4 寸 iPhone 12 mini 机型，全部配备 OLED 屏幕。

6.1 寸 iPhone 12

6.1 寸 iPhone 12 的屏幕分辨率为 1170px × 2532px，PPI 为 460，与 6.1 寸 iPhone 11 的屏幕分辨率（828px × 1792px）并不相同。在之前文章也有讲到过，虽然是相同尺寸，但屏幕由 LCD 材质换为 OLED 材质，由于成像原理的不同，要想保持同样的清晰度观感，分辨率必须提升。
6.1 寸 iPhone 12 的逻辑分辨率为 390pt × 844pt，比例因子为 @3x。Apple 为了保证在屏幕尺寸稍有变大的情况下，PPI 不降低，没有妥协继续使用 375pt 的逻辑分辨率宽度，而是启用了全新的逻辑分辨率宽度「390pt」，仅仅增加了 15pt。由逻辑分辨率宽度为 375pt × 812pt 的 5.8 寸 iPhone 11 Pro 进化到逻辑分辨率宽度为 390pt × 844pt 的 6.1 寸 iPhone 12，两者的宽高比例仍然保持相同，所以其变化逻辑仍然采用了之前文章总结的「等比放大」方法。

既然出现了全新的逻辑分辨率宽度，那 app 要完美运行在新的机型中就需要进行适配。没有适配新机型的 app 将以 375pt × 812pt@3x（同 5.8 寸 iPhone 11 Pro）的样式放大显示在 iPhone 12 上，相当于把图像放大了 1.04 倍，相比已经适配的 app 看上去会有些模糊。App 要想适配新机型，至少需要通过 Xcode 12.1 及以上版本编译 app，并根据实际情况调整适配 app 布局。

适配的速度就要看各位开发者了，比如下图中的「我的天气」app 在 iPhone 12 发售前就已经完成了对 iPhone 12 系列的适配显示。

5.4 寸 iPhone 12 mini

5.4 寸 iPhone 12 mini 的屏幕分辨率为 1080px × 2340px，PPI 为 476，清晰度位列 iPhone 12 系列第一名。
由 iPhone 12 mini 的屏幕分辨率除以比例因子 @3x 得到逻辑分辨率 360pt × 780pt，很多人自然而然地就会以为这就是 iPhone 12 mini 的逻辑分辨率。然而通过已经发布的 Xcode 12.1 GM 版本的模拟器可以查到 iPhone 12 mini 的渲染分辨率（截图的大小）实际为「1125px × 2436px」，比物理分辨率（屏幕的物理参数）放大了 1.04 倍。同当年的 iPhone 6 Plus 一样，Apple 再次使用了一样的变化手法。
1125px × 2436px 的渲染分辨率对应的逻辑分辨率为 375pt × 812pt@3x，正是之前 5.8 寸 iPhone 11 Pro 的逻辑分辨率，这样 app 想完美运行在 iPhone 12 mini 上就无需再进行额外的适配工作。但由于像素不是点对点显示的，显示图像可能会有不锐利的问题，但由于其高 PPI 的存在，这个感知不会明显。

iPhone 12 Pro 系列屏幕的变化

iPhone 12 Pro 系列包括 6.1 寸 iPhone 12 Pro 机型和 6.7 寸 iPhone 12 Pro Max 机型。

6.1 寸 iPhone 12 Pro

6.1 寸 iPhone 12 Pro 与 6.1 寸 iPhone 12 的屏幕参数完全相同，屏幕分辨率为 1170px × 2532px，PPI 为 460，逻辑分辨率为 390pt × 844pt，比例因子为 @3x。
对于 app 适配 iPhone 12 Pro 的逻辑也与 iPhone 12 完全相同，在此不再赘述。

6.7 寸 iPhone 12 Pro Max

6.7 寸 iPhone 12 Pro Max 的屏幕分辨率为 1284px × 2778px，PPI 为 458。
6.7 寸 iPhone 12 Pro Max 的逻辑分辨率为 428pt × 926pt，比例因子为 @3x。同样地，Apple 为了保证在屏幕尺寸稍有变大的情况下，PPI 不降低，没有妥协继续使用 414pt 的逻辑分辨率宽度，而是启用了全新的逻辑分辨率宽度「428pt」，仅仅增加了 14pt。由逻辑分辨率宽度为 414pt × 896pt 的 6.5 寸 iPhone 11 Pro Max 进化到逻辑分辨率宽度为 428pt × 926pt 的 6.7 寸 iPhone 12 Pro Max，两者的宽高比例仍然保持相同，所以其变化逻辑仍然采用了之前文章总结的「等比放大」方法。

对于 app 适配也是一样，app 要完美运行在新的机型中就需要进行适配。没有适配新机型的 app 将以 414pt × 896pt@3x（同 6.5 寸 iPhone 11 Pro Max）的样式放大显示在 iPhone 12 Pro Max 上，相当于把图像放大了 1.03 倍，相比已经适配的 app 看上去会有些模糊（具体观感真机上手后再来补充）。App 要想适配新机型，至少需要通过 Xcode 12.1 及以上版本编译 app，并根据实际情况调整适配 app 布局。

放大显示功能

在之前文章中有讲到目前大部分的 iPhone 机型都配备了放大显示功能，关于放大显示最重要的一点就是，其实质是将高一级的逻辑分辨率降级到同一比例的低一级的逻辑分辨率。
在 iOS 14 Beta 版本中开始出现了 5.8 寸 iPhone 11 Pro（ 375pt × 812pt@3x）的放大显示功能，其逻辑分辨率为 320pt × 693pt@3x，当时的推测是这很可能是 5.4 寸 iPhone 12 mini 的真正分辨率。然而现实情况是这只是 Apple 虚构的一个机型分辨率，至少在现在这个时间点，这个机型是不存在的，当我确定这个结论时也是十分诧异。

那这个虚构的逻辑分辨率又用在了哪些地方呢？具体来看：
在有了这个虚构的逻辑分辨率 320pt × 693pt 之后，5.8 寸的 iPhone 11 Pro、iPhone iPhone Xs、iPhone X 机型自然就支持了放大显示功能。

但由于这个 320pt 的全面屏逻辑分辨率宽度不存在于任何一个现有的机型，要想 app 正常运行在这个逻辑分辨率之下，也得需要进行适配。如果不进行适配，将会以 iPhone 5s 的大小显示，也即上下有黑边。

再来看全新的 iPhone 12 系列的放大显示，6.7 寸的 iPhone 12 Pro Max 开启放大显示后，会降级到 375pt 宽度，也即 iPhone 11 Pro 大小；6.1 寸 iPhone 12/iPhone 12 Pro 、5.4 寸 iPhone 12 mini 开启放大显示后，都会降级到 320pt 宽度，也即前面提到的虚构机型的大小，如果 app 没有适配全面屏的 320pt 逻辑分辨率宽度，同样会出现上下有黑边的情况。

320pt（全面屏）这个新增的逻辑分辨率宽度隐藏在放大显示功能背后，可能更不会引起 app 开发者的注意，适配的进度可能会更慢。

内容显示数量

至此，iPhone 12 系列在标准显示模式下新增了 390pt（iPhone 12/iPhone 12 Pro）、428pt（iPhone 12 Pro Max）两种新的逻辑分辨率宽度，在放大显示模式下新增了 320pt（iPhone 12/iPhone 12 Pro、iPhone 12 mini）一种新的逻辑分辨率宽度。总共增加了 390pt、428pt、320pt（全面屏） 三种逻辑分辨率宽度。

逻辑分辨率的大小会决定屏幕上内容显示数量的多少。针对于不同逻辑分辨率的屏幕，下图对比了其内容显示数量。几个值得特别注意的点：

之前的 6.1 寸 iPhone 11 是 414pt 宽度，同 6.5 寸 iPhone 11 Pro Max 一样，而 6.1 寸的 iPhone 12/iPhone 12 Pro 减少到了 390pt 宽度，相比于以前，横纵向显示数量变少了，但比例因子由 @2x 变为 @3x，总体上 PPI 也即清晰度大幅提升了。对于从 iPhone Xʀ、iPhone 11 更新到 iPhone 12、iPhone 12 Pro 的用户在初期可能会不适应。
从 375pt 增加到 390pt，从 414pt 增加到 428pt，虽然横纵向的确可以显示更多的内容，但对比发现后，其实差异不会很明显。
iPhone 12/iPhone 12 Pro、iPhone 12 mini 的放大显示都是 320pt，很多 app 可能都没有适配，而且整体承载内容数量较少较挤，并不适合作为日常使用。

再附一张台湾 iOS 开发者 @ethanhuang13 在 Xcode 模拟器使用不同机型显示同一个网站上的内容对比情况。

Size Class

Size Class 尺寸等级同样是之前文章中所提到的 iPhone 尺寸变化过程中的一个重要概念。

全新的 iPhone 12 系列在竖屏下，毫无悬念，依然同其他 iPhone 一样是「compact width，regular height」。但在横屏下，有几个需要注意的点：

6.1 寸的 iPhone 12/iPhone 12 Pro 系列由于其逻辑分辨率比 6.1 寸 iPhone 11 小一些，所以其横屏的 Size Class 是「compact width，compact height」，与 iPhone 12 mini、iPhone 11 一样。因此在如「信息」这样支持左右分栏布局样式的 app 上显示时就只能显示某个联系人的短信内容，如下图；
6.7 寸的 iPhone 12 Pro Max 其横屏的 Size Class 自然是「regular width，compact height」，与 iPhone 11、iPhone 11 Pro Max 一样，在「信息」app 中可以分左右两边显示短信列表和具体的短信内容，如下图。

iPhone 12/iPhone 12 Pro 上的 App 适配实例

10 月 23 日，6.1 寸的 iPhone 12 和 iPhone 12 Pro 正式发售，我也在真机上对 app 适配的情况进行了测试。
在标准显示模式下，如前文所讲，未适配的 app（未通过 Xcode 12.1 及以上版本编译）会直接等比放大 iPhone 11 Pro 的大小以充满全屏，由于不是点对点显示，屏幕多少会有些发虚的感觉，整体文字显示稍微偏大，但 app 布局一般不存在什么问题，如下图中的「微信」、「微博」，从键盘高度更高就可以看出它们是被等比放大了。

被网友吐槽最多的是 app「哔哩哔哩」，其状态栏（显示时间、网络、电量的顶部区域）与下部的内容发生了重叠，导致搜索栏及其旁边的按钮很难被按到。虽然并不知道「哔哩哔哩」的代码具体是如何写的，但猜测很可能是没有使用 Apple 提供的 Safe Area 定义（之前文章有讲），而是根据机型判断了状态栏下部内容与屏幕顶部的距离，对于之前的全面屏机型统一写死为 44pt，对于其他机型统一写死为 20pt。而在代码未更新前，iPhone 12、iPhone 12 Pro 就属于未知的其他机型，状态栏下部内容自然就与状态栏重叠了。这种判断方法是十分傻瓜的。

iOS 设备的状态栏 Status Bar 高度也是在不断变化的，在非全面屏时代，状态栏的高度一直都是 20pt，所以在当时很多 app 采用了和现在 B 站同样的代码编写逻辑，写死状态栏高度，因为所有非全面屏机型都一样，所以一直没有出过什么问题。但直到 iPhone X 的出现，状态栏高度变成了 44pt（因为刘海区域的存在），增加了 24pt，这让很多写死状态栏高度的 app 原形毕露。不过随着对 iPhone X 的适配，这种问题后面就很少出现了。
从 iPhone X 一直到 iPhone 11 Pro、iPhone 11 Pro Max，状态栏的高度一致都维持 44pt 没变。但从 iPhone 12 系列开始，状态栏的高度又发生了新的变化。通过 Xcode 模拟器可以发现，iPhone 12 mini 的状态栏高度是 50pt，iPhone 12/iPhone 12 Pro、iPhone 12 Pro Max 的状态栏高度是 47pt，和之前完全不一样。而在放大显示模式下，不同机型的状态栏高度还会更加复杂。

Apple 调整全面屏的状态栏高度的原因还不好下定论，但这么多变的状态栏高度就是在时刻提醒开发者不要根据机型判断状态栏高度，应该使用 Apple 提供的 Safe Area 工具进行内容布局。

来到放大显示模式下，iPhone 12 、iPhone 12 Pro 的显示效果可谓是惨不忍睹。如前文所讲，在放大模式下，iPhone 12 、iPhone 12 Pro 的逻辑分辨率宽度是 320pt（全面屏），这是一个完全虚构的机型，如果开发者不够细心，将会完全忽视对它的适配。对于未适配但已经以 Xcode 12 及以上版本编译的 app，可以全屏，但可能布局错乱，例如下图中的「YouTube」、「微博」，底部的标签栏 Tab Bar 很明显出现了错位问题。

而对于未适配也未能以 Xcode 12 及以上版本编译的 app，不能全屏，只能以 iPhone SE（第一代）的大小显示，上下有大黑边，例如上图中的「微信」、「支付宝」。
对于已经适配了的 app，由于其逻辑分辨率宽度只有 320pt，这么窄的宽度上布局非常拥挤，文本也显得很大，真的是老人机的感觉。总的来说，iPhone 12、iPhone 12 Pro 的放大显示模式在当面这个时间点体验很差，几乎是不可用状态。

总结

纵观 iPhone 12 全系列的屏幕分辨率变化，Apple 为了保持 PPI 也即屏幕清晰度只增不减，不得不在之前已有的逻辑分辨率宽度上同样利用「等比放大」的方法小幅放大了一点形成了两个新的逻辑分辨率宽度：390pt、428pt，同时为了让 iPhone X、iPhone iPhone Xs、iPhone 11 Pro、iPhone 12、iPhone 12 Pro、iPhone 12 mini 这些机型都具备「放大显示」功能，暗暗增加了 320pt（全面屏）这个新的逻辑分辨率宽度。整体上可谓十分激进的进化，虽然显示效果达到了最佳，但对于众多开发者和第一批尝鲜的用户来说，不得不有一段时间的阵痛期。这或许也在某些层面体现了 Apple 的偏执吧。

而 iPhone 12 mini 再次使用了渲染分辨率与物理分辨率不同的操作方法，也有些许延续传统的感觉。

至此到 2020 年的现在这个时间点，iPhone 的逻辑分辨率宽度进化到了 **320pt（非全面屏、全面屏）、375pt（非全面屏、全面屏）、414pt（非全面屏、全面屏）、390pt（全面屏）、428pt（全面屏）**八小种、五大种。下图用图示的方式展示了从 2007 年到 2020 年 iPhone 屏幕尺寸进化的历程，包括尺寸、物理分辨率、渲染分辨率、逻辑分辨率、PPI、放大显示功能、进化逻辑等，具体可点击查看大图。

iPhone 屏幕逻辑分辨率激进变化的背景下，或许 Apple 已释放出了足够的信号：未来的屏幕大小不再是一成不变的，app 的显示区域也是可大可小的，针对于不同设备尺寸适配 app 的方法已经过时，循着 Apple 给出的方法和工具，让 app 自由地在屏幕上呈现，或许才能找到未来的路。

参考文章

从第一代 iPhone 细数到 iPhone 12，iPhone 屏幕尺寸进化历程背后的 app 设计哲学

2020-08-19T15:08:31+08:00

从 2007 年发布的第一代 iPhone 到 2019 年发布的 iPhone 11 系列，iPhone 的屏幕尺寸已涵盖 3.5 寸、4 寸、4.7 寸、5.5 寸、5.8 寸、6.1 寸、6.5 寸七种，传闻将于今年秋季发布的 iPhone 12 还会增加 5.4 寸、6.7 寸两种尺寸。随着时间轴的推移，iPhone 的屏幕尺寸已经变得越来越多，越来越复杂，一个 app 要适配所有的这些屏幕尺寸，在从设计、开发到推广的整个过程中都需要考虑诸多因素。

在 iOS 14 Beta 3 版本中，有[用户发现] (https://9to5mac.com/2020/07/22/ios-14-beta-gives-us-a-glimpse-of-the-system-interface-on-the-5-4-inch-iphone-12/) 5.8 寸的 iPhone X/Xs/11 Pro 机型新增了「放大显示」功能，进而发现 iOS 14 可以以 960 x 2079 像素这个新的分辨率正常运行。而在之前的版本中，5.8 寸的 iPhone 机型上一直没有放大显示功能，结合新发现的运行分辨率，我们有理由推测 Apple 正在为一款小屏幕手机做准备，而这个分辨率很可能就是传闻中即将发布的 5.4 寸 iPhone 12 的准确分辨率。

在这 13 年间 iPhone 的屏幕尺寸是怎样一步步进化到此的？基于软硬一体的设计，屏幕物理尺寸的变化背后包含着怎样的进化规律？这些变化对我们朝夕相处的手机 app 又产生了什么影响？根据已有的进化规律，我们是否可以展望未来的 iPhone 还会走向何方？基于 iOS 14 Beta 中发现的新线索，我们又可以推断出 iPhone 12 的哪些更多信息呢？本文就来说道说道。

iPhone 起源：从 3.5 寸的小屏幕开始

从第一代 iPhone 到 iPhone 4s

第一代 iPhone 于 2007 年发布，配备 320 × 480 像素（pixel，可简写为 px）的 3.5 寸屏幕，PPI （表示每英寸所具有的像素数，数字越大清晰度越好）为 163，这块支持多点触控的小屏幕开创了 iPhone 历史的先河。

2008 年 iPhone 3G 发布，其搭载的 iPhone OS 2.0 系统首次支持了 App Store 功能，自此第三方 app 开始逐渐在 iPhone 上大放异彩；2009 年 iPhone 3GS 发布，相比前一代，其屏幕从 18 位色升级到了 24 位色，屏幕表现更加丰富。iPhone 3G 和 iPhone 3GS 这两代的屏幕尺寸和分辨率与初代 iPhone 完全相同，即 320px × 480px 的 3.5 寸屏幕，PPI 为 163。

2010 年具有全新硬件设计的 iPhone 4 发布，其屏幕分辨率升级为 640px × 960px，是前几代 iPhone 的两倍，屏幕尺寸仍然保持 3.5 英寸，PPI 达到了 326。在如此高的像素密度下，人眼已经几乎看不到屏幕上的像素点，因此 Apple 称之为「Retina/视网膜屏幕」。2011 年发布的 iPhone 4s 与前一代的屏幕分辨率和尺寸保持相同。

至此 iPhone 的屏幕分辨率由一种变化到两种，在同样大小的 3.5 寸手机屏幕上，更高的分辨率不是为了显示更多的内容，而是为了让屏幕上的内容更加清晰。Retina 屏幕在渲染图像时，每四个像素成为一组，输出原来屏幕的一个像素显示的大小区域内的图像，以此提供了更高的图像精细度，下面的对比图可以直观地看出这种变化，右边的图片明显比左边的图片更加清晰锐利。

如果一个 app 还没有适配新的 Retina 屏幕分辨率，在 Retina 屏幕上显示就会显得很模糊。

既然存在两种不同的分辨率，在 app 设计上就需要针对它们提供不同尺寸的设计图，比如下面的这个照相机的图片，在非 Retina 屏幕上它的高度是 44 像素，而在 Retina 屏幕上的高度就变成了88 像素，是非 Retina 屏幕上的两倍。

但我们知道，无论是不是 Retina 屏幕，这个照相机的图片在 3.5 寸屏幕上的实际显示大小是相同的，而如果用像素去表示的话，它们的数字却是不同的，这会带来很多沟通和操作成本，需要一种更好的方法去表示这个照相机图片的尺寸，「Point 点」的概念应运而生。

脱离像素密度：Point 点的诞生

Point 点（可简写为 pt）是专门为 Apple 操作系统设计的一个单位，它与屏幕上的像素密度无关，只与屏幕上的内容多少有关。
在第一代 iPhone 到 iPhone 3GS 的非 Retina 屏幕上，一个点就等于一像素，可以表示为 @1x；而在 iPhone 4 到 iPhone 4s 的 Retina 屏幕上，一个点等于两个像素，可以表示为 @2x。而日后发布的一些设备（如 iPhone 6 Plus、iPhone X）还会出现一个点等于三个像素的情况，可以表示为 @3x，这种 @1x、@2x、@3x 可以称之为「比例因子」。

从下面的图示可以看出，在物理尺寸相同时，从 @1x 到 @3x 图像清晰度依次递增。

回到上一部分提到的照相机的图片，它的高度就可以直接统一表示成 44pt，不再需要提及是什么设备、什么样的屏幕，这样极大地减少了沟通成本，剔除了设计时无关的干扰因素。设计师在进行设计时可以直接按照 44pt 的高度进行设计，设计好的图像对应导出「camera@1x.png」和「camera@2x.png」两张图片，非 Retina 屏幕的 iPhone 在显示时会自动调用第一张图片，Retina 屏幕的 iPhone 在显示时会自动调用第二张图片。
用与像素密度无关的单位「point 点」来表示设计内容的尺寸的优势在日后 iPhone 的屏幕尺寸变得更加复杂之后会更加凸显。

进一步，第一代 iPhone 到 iPhone 3GS 的屏幕分辨率可以表示为 320pt × 480pt @1x，iPhone 4、iPhone 4s 的屏幕分辨率可以表示为 320pt × 480pt @2x。而使用「point 点」这个单位表示的分辨率我们可以称之为「逻辑分辨率」，而使用「px 像素」这个单位表示的分辨率我们可以称之为「渲染分辨率」。

通过「逻辑分辨率」我们可以比较屏幕上显示内容的多少，前五代 iPhone 的逻辑分辨率相同，所以显示内容的数量没有差别；通过「渲染分辨率」以及屏幕尺寸我们可以计算出 PPI，进一步比较屏幕的清晰度，iPhone 4、iPhone 4s 相比前几代 iPhone 的屏幕尺寸相同，但渲染分辨率更高，PPI 更高，所以屏幕更加清晰锐利。

不只 Apple 的操作系统中有 point 这样的与像素密度无关的单位，在其他平台上为了设计和开发方便，也同样存在类似的表示方法，比如 Android 平台上的单位「dp」，想要了解更多可以查看 Android 设计规范。

iPhone 非全面屏时代：屏幕尺寸渐大渐多

4 寸、4.7 寸、5.5 寸全面开花

2012 年 Apple 发布了配备 4 寸屏幕的 iPhone 5，这是历史上 iPhone 屏幕尺寸的第一次改变，屏幕的分辨率为 640px x 1136 px，PPI 仍然为 326，也即相比 iPhone 4s 屏幕清晰度没有变化，其比例因子仍然为 @2x，其逻辑分辨率为 320pt × 568pt 。iPhone 5 搭载的 iOS 6 系统是 iOS 系统拟物化设计的最后一个版本，也是最成熟的一个版本。

仔细观察上面的数字我们可以发现，相比 iPhone 4s，iPhone 5 在横向上的内容宽度与前一代保持一致，但纵向上增多了 88pt，也即在纵向上可以显示更多的内容了。
如果一个 app 没有适配新的 iPhone 5，它将会在 iPhone 5 上以 iPhone 4s 的大小样式显示，也即上下会各留出 44pt 的黑边。

这种通过屏幕逻辑分辨率「横向不变、纵向变长」来增长屏幕尺寸的方式是 iPhone 屏幕进化的重要方式之一，在日后还会多次看到，
同时由于这种变化导致的 app 上下存在黑边的适配问题也同样会多次出现。

2013 年 Apple 发布了相比 iPhone 5 屏幕没有发生变化的 iPhone 5s 和 iPhone 5c，它们的屏幕逻辑分辨率仍然为 320pt × 568pt @2x。同年 Apple 推出了 iOS 7，从此设计风格由拟物化风格转向扁平化风格。

由于屏幕的逻辑分辨率没有发生变化，app 就不需要为新机型的屏幕进行适配。凡是可以运行在 iPhone 5 上的 app 都可以在 iPhone 5s、iPhone 5c 上正常显示。

2014 年 iPhone 6 和 iPhone 6 Plus 同时发布，iPhone 的屏幕尺寸再次发生重大变化，根据不同人群的使用需求和偏好，由之前的一种主流尺寸衍变成了一大一小两种尺寸。
小屏旗舰 iPhone 6 采用 4.7 寸屏幕，屏幕逻辑分辨率为 375pt × 667pt，比例因子为 @2x，PPI 为 326；大屏旗舰 iPhone 6 Plus 采用 5.5 寸屏幕，屏幕逻辑分辨率为 414pt × 736pt，比例因子首次采用 @3x，PPI 为 401。

这次的 iPhone 6 Plus 有一点比较特殊的地方，其渲染分辨率为 1242px × 2208px，但其设备真实的屏幕物理分辨率只有 1080px × 1920px，也即处理器渲染的图像分辨率比屏幕自身物理分辨率更高，在实际显示时相当于将渲染的图像缩小了 1.15 倍。图像在屏幕上显示时如果能做到像素一对一显示效果才能最完美，但 Apple 在此机型上作出了妥协，究其原因可能是因为当时 1080p 的屏幕的广泛使用可以削减手机成本、加快出货日期，同时也可以有更好的续航能力。

这是历史上 iPhone 屏幕尺寸的第二次重大变化，但与之前的 4 寸 iPhone 5s 仔细对比观察，你会发现新的 4.7 寸和 5.5 寸的屏幕与以前的 4 寸屏幕宽高比例是相同的，所以可以理解成 4 寸的屏幕分别「等比放大」了约 1.17 倍和 1.29 倍，变成了现在的 4.7 寸和 5.5 寸屏幕。屏幕逻辑分辨率在宽度和高度上的增加，可以让屏幕上一次性展示更多内容，减少用户滚动屏幕的频率。
至此，从屏幕逻辑分辨率的宽度来看，分化出了三种：320pt、375pt、414pt。在 app 设计时一般以 375pt 宽度为基准，其他宽度 app 的设计进行针对性处理。实际上，这三种宽度的逻辑分辨率一直到 2019 年都没有再发生变化。

如果没有适配新机型的 app 在显示时，由于和上代 iPhone 具有相同的屏幕比例，所以会直接将 iPhone 5s 的 app 放大显示到屏幕上。用户的直观感受就是虽然屏幕变大了，但仅仅是将原有的内容放大了，而不是在屏幕上可以一次性展示更多内容。而且因为不是像素一对一显示，屏幕上的内容看上去会不够清晰锐利。

这种通过将屏幕逻辑分辨率「等比放大」来增长屏幕尺寸的方式也同样是 iPhone 屏幕进化的重要方式之一，在日后也会多次看到，同时由于这种变化导致的 app 被整体放大显示的适配问题也同样会多次出现。

2015 年到 2017 年 Apple 相继发布了 iPhone 6s 和 iPhone 6s Plus、iPhone 7 和 iPhone 7 Plus、iPhone 8 和 iPhone 8 Plus，它们的屏幕参数与 iPhone 6、iPhone 6 Plus 保持了一致。4.7 寸和 5.5 寸屏幕的 iPhone 也在四年间迅速普及。

至此，iPhone 非全面屏时代可以基本宣告结束了。

屏幕不断被放大的产物：放大显示功能

如前文所讲，iPhone 5s 的 4 寸屏幕、iPhone 6 的 4.7 寸屏幕、iPhone 6 Plus 的 5.5 寸屏幕的宽高比例是相同的，它们是依次放大的。于是从 iPhone 6、iPhone 6 Plus 开始，iOS 新增了一个这些机型独有的功能——「放大显示」，简单来看它将屏幕上的内容放大显示以便于存在视力障碍的用户更轻松使用 iPhone，当然你也可以根据自己的偏好选择使用放大显示模式。

将屏幕上的内容，特别是包含了众多第三方 app 的内容进行整体放大而不让布局错乱并不是一件简单的事，为了减少不必要的设计和开发成本，放大显示功能巧妙地利用了已有的屏幕逻辑分辨率。具体来说，放大显示的实质是将高一级的逻辑分辨率降级到同一比例的低一级的逻辑分辨率，比如当放大显示模式开启时， 5.5 寸屏幕可以使用 4.7 寸屏幕的逻辑分辨率来显示内容，4.7 寸屏幕可以使用 4 寸屏幕的逻辑分辨率来显示内容。将低一级的逻辑分辨率放到更大的屏幕上展示，自然会有放大效果，适配了大屏幕 iPhone 的 app 自然也适配了更小屏幕的 iPhone，这样就可以完全没有额外的设计和开发成本。

适配不同尺寸屏幕的布局工具：Auto Layout

随着 iPhone 机型越来越多，屏幕尺寸越来越多，屏幕的逻辑分辨率也越来越多。设计师和开发者在设计和开发 app 时需要对多种屏幕布局进行适配调整，才能让 app 在每一台 iPhone 上完美运行。

iPhone 上的 app 中的内容包含文字、图片、按钮、输入框、导航栏等各种各样的形式，我们可以把这些不同形式的元素统称为「View 视图」。要确定 iPhone app 中每一个 view 在屏幕上的布局，可以想到的最直观的方式就是确定这每一个 view 的摆放位置和尺寸，摆放位置可以通过在屏幕上建立坐标系后利用横纵坐标（x, y）来表示，尺寸可以通过描述一个 view 的宽度和高度来表示。这种确定了每一个 view 的位置和尺寸的布局方式不会受内部或者外部因素所影响，可以称之为「绝对布局」。

例如下图中的这个例子，在 iPhone 8 上有一个 app，app 的界面中展示有四个不同颜色的方块。按照绝对布局的方法来确定四个方块的位置和尺寸：

红色方块的位置坐标是（138，32），宽度为 100，高度为 100；
黄色方块的位置坐标是（138，156），宽度为 100，高度为 100；
绿色方块的位置坐标是（138，280），宽度为 100，高度为 100；
蓝色方块的位置坐标是（138，404），宽度为 100，高度为 100。

当把上面确定的每个方块的绝对布局参数放到 iPhone 8 Plus 的屏幕上显示时，我们就会发现四个方块在屏幕上显示的位置有些奇怪。仔细思考下，在 iPhone 8 的屏幕上四个方块的位置坐标之所以可以确定下来，是因为我们想要这四个方块在屏幕水平方向上是居中对齐的。当移动到 iPhone 8 Plus 的屏幕上，屏幕的逻辑分辨率发生了变化，屏幕变宽了，如果还是按照之前的位置参数放置四个方块，其自然不会在屏幕水平方向上处于居中对齐的位置了。

要想要 iPhone 8 Plus 屏幕上的四个方块在水平方向上也能居中对齐显示，那四个方块的位置坐标就需要相对应发生变化。这种「分而治之」的处理方式固然可以面面俱到，但其耗费的成本也是巨大的，在屏幕尺寸不断变复杂的时间点上，需要一套方法去整合不同屏幕上的 app 布局，这套方法就是诞生于 iOS 6 并逐渐发展成熟的「Auto Layout 自动布局」方案。

Auto Layout 是一种相对布局的方案，它不要求直接给出每一个 view 的位置和尺寸信息，而是通过建立 view 之间的约束关系（constraint），动态计算出在不同情景时每个 view 的具体位置和尺寸。

来看下图中的这个例子，蓝色方块命名为「BlueView」，红色方块命名为「RedView」，它们之间的距离是 8，通过图中所示的等式就可以表示出这两个 view 之间的约束关系，用自然语言来描述就是：

红色方块的左端 = 1.0 × 蓝色方块的右端 + 8

这里特别提及的一点是，在描述蓝色方块右端和红色方块的左端之所以不直接使用「right 右」和「left 左」这两个单词，而是使用了「trailing 尾」和「leading 头」这两个单词，是因为这样的描述可以更好地兼顾从右向左书写的语言（如阿拉伯语）的 app 的适配，利于 app 实现国际化。

通过两个方块之间相对的约束关系，不论在任何尺寸的屏幕上，这两个方块之间的距离都是 8，不会因为两个方块各自的位置和尺寸而变动。

回到上面绝对布局中所举的例子，现在用相对布局的方法来思考下四个不同颜色的方块该如何布局，按照 Auto Layout 的思想，可以确定界面上 view 的几个约束关系：

红色方块的宽和高 = 黄色方块的宽和高 = 绿色方块的宽和高 = 蓝色方块的宽和高 = 100；
红色方块的顶部 = 屏幕顶部 + 32；
纵向上不同颜色方块之间的距离 = 24
红色方块的 X 轴中心位置 = 黄色方块的 X 轴中心位置 = 绿色方块的 X 轴中心位置 = 蓝色方块的 X 轴中心位置 = 屏幕的 X 轴中心位置。

通过上面确定的四个约束关系，四个方块的尺寸固定了下来，但在屏幕上的位置并没有完全固定，会相对于屏幕尺寸发生动态变化。这样当整个界面显示在 iPhone 8 Plus 或者其他尺寸的屏幕上时，四个方块就能始终在屏幕水平方向上居中对齐。

通过 Auto Layout 这个武器，利用相对布局的思想，设计师和开发者确定好不同 view 之间的约束关系，就能让整个界面在不同尺寸的设备上都能正确地显示，不再需要一个设备一套设计方案，这样的设计也被称为「适应性布局设计」。

以上示例只是 Auto Layout 的一个简单示意，在实际情况中，app 界面上包含各种 view，约束关系自然更加复杂，Auto Layout 的作用也会更加明显。且从更大范围来看，不只屏幕尺寸变化，Auto Layout 的这种适应性布局设计方案还可以适应各种外部和内部变化：

外部变化：
- 不同屏幕尺寸；
- 不同 Size Class（下一部分会讲到）；
- 旋转设备改变使用方向；
- iPad 上进入或退出 Slide Over、Split View 模式；
- 来电和录音时状态栏变高。
内部变化：
- App 自身改变导致的内容变化；
- App 支持国际化；
- App 支持「Dynamic Type 动态类型」。

想要了解更多可参考 Apple 提供给开发者的「Auto Layout Guide」。

iOS 、iPadOS 生态下的重要武器：Size Class

通过 Auto Layout，不同屏幕尺寸的设备都可以用一套设计方案来布局内容，但这并不代表不同尺寸的屏幕上显示的内容布局都应该是一样的，比如同一个 app 在 iPhone 和 iPad 上的布局一般是不一样的，更何况屏幕在使用时还需要区分横竖和竖屏的使用场景，app 横屏和竖屏显示的内容布局也会不一样。从 iOS 8 开始推出的「Size Class 尺寸级别」就是为了解决这个问题。

Size Class 根据 app 的实际使用场景定义了不同尺寸的屏幕、不同方向的屏幕在「width 宽度」和「height 高度」上的尺寸级别，较短的宽度/高度定义其级别为「compact」，意为紧凑，可放置较少的内容；较长的宽度/高度定义其级别为「regular」，意为普通，可放置较多的内容。宽度和高度与这两个级别相互组合就形成了四种尺寸级别。特别注意的是，同一个尺寸的设备，横屏和竖屏的尺寸级别并不一定是完全相反的。

如下图，iPhone 8 在竖屏时的 Size Class 是「compact width，regular height」，在横屏时是「compact width，compact height」；iPhone 8 Plus 在竖屏时是「compact width，regular height」，在横屏时是「regular width，compact height」，与 iPhone 8 并不相同，因为 iPhone 8 Plus 屏幕尺寸更大。

不同屏幕尺寸、不同屏幕方向的 iPad 也同样有 Size Class 的定义，如 iPad Pro 11 寸在竖屏时是「regular width，regular height」，在横屏时也是「regular width，regular height」。特别的，从 iOS 9 开始，iPad 上的 app 支持以 Slide Over 侧拉或者 Split View 分屏浏览的形式显示，在这些使用场景中，它们也被定义了 Size Class。

想要了解每个 iPhone 和 iPad 的 Size Class 以及 Size Class 的更多内容可参考 iOS Human Interface Guidelines 中的相关章节以及我的文章：

在不同尺寸的设备上让 app 都大放异彩：尺寸级别和核心要素 Size Classes and Core Components - 向远公园 | Step Park

有了 Size Class，设计师和开发者在设计和开发 app 时就不需要根据繁多的屏幕尺寸和屏幕使用方向等多个内外因素来确定 app 内容布局，新的屏幕尺寸出现时也无需再单独适配。来看几个具体的 Size Class 应用实例。

第一个例子，2018 年 6.5 寸屏幕的 iPhone Xs Max 发布前，有人在 iOS 12 的 Beta 版本中发现当让 iPhone 模拟器运行在传闻中的 iPhone Xs Max 分辨率之下时，部分系统自带 app 在横屏时的内容布局与 5.8 寸的 iPhone X 不一样，比如「信息」app 横屏时，5.8 寸屏幕只能显示某个联系人的短信内容，但 6.5 寸屏幕就可以分左右两边显示短信列表和具体的短信内容。据此进一步印证了 6.5 寸的 iPhone Xs Max 的存在。
同一个 app 在不同屏幕尺寸的屏幕上显示的内容布局不同，究其原因，如下图所示，在屏幕宽度上 5.8 寸屏幕的 Size Class 是「compact width」，6.5 寸屏幕的 Size Class 是「regular width」，Size Class 不同，所以它们的 app 内容显示布局不一样。

第二个例子，再次回到在 Auto Layout 中提到的 app，基于已经确定的四个方块的约束关系，当在 iPhone 横屏使用时，我们会发现由于四个方块是竖直排列的，所以不能在横屏时的屏幕上显示完全，左右两侧还有较大的空间被浪费掉了。

当利用 Size Class 对不同情况下的内容进行布局，iPhone 竖屏也即 Size Class 为「compact width，regular height」时，四个方块在屏幕上水平居中对齐，纵向排列；iPhone 横屏也即 Size Class 为「any width，compact height」（any 包括 compact 和 regular 两种情况）时，四个方块在屏幕上竖直居中对齐，横向排列，这时的布局约束关系为：

红色方块的宽和高 = 黄色方块的宽和高 = 绿色方块的宽和高 = 蓝色方块的宽和高 = 100；
红色方块的左侧 = 屏幕左侧 + 110；
横向上不同颜色方块之间的距离 = 24
红色方块的 Y 轴中心位置 = 黄色方块的 Y 轴中心位置 = 绿色方块的 Y 轴中心位置 = 蓝色方块的 Y 轴中心位置 = 屏幕的 Y 轴中心位置。

进一步，当 app 运行在 iPad 上，也即 Size Class 为「regular width，regular height」时，四个组成一个方块组，分两行排列，整个方块组在屏幕上竖直居中对齐，这时的布局约束关系为：

红色方块的宽和高 = 黄色方块的宽和高 = 绿色方块的宽和高 = 蓝色方块的宽和高 = 100；
整个方块组的左侧 = 屏幕左侧 + 485；
纵向、横向上不同颜色方块之间的距离 = 24
整个方块组的 Y 轴中心位置 = 屏幕的 Y 轴中心位置。

这样同样的内容在 iPhone 横屏、竖屏和 iPad 的不同设备和使用场景上布局不同，把上面三种情况的内容布局的约束关系总结概括一下：

共用约束关系：
- 红色方块的宽和高 = 黄色方块的宽和高 = 绿色方块的宽和高 = 蓝色方块的宽和高 = 100。
Size Class 为「compact width，regular height」，也即 iPhone 竖屏时：
- 红色方块的顶部 = 屏幕顶部 + 32；
- 不同颜色方块之间的距离 = 24
- 红色方块的 X 轴中心位置 = 黄色方块的 X 轴中心位置 = 绿色方块的 X 轴中心位置 = 蓝色方块的 X 轴中心位置 = 屏幕的 X 轴中心位置。
Size Class 为「any width，compact height」，也即 iPhone 横屏时：
- 红色方块的左侧 = 屏幕左侧 + 110；
- 横向上不同颜色方块之间的距离 = 24
- 红色方块的 Y 轴中心位置 = 黄色方块的 Y 轴中心位置 = 绿色方块的 Y 轴中心位置 = 蓝色方块的 Y 轴中心位置 = 屏幕的 Y 轴中心位置。
Size Class 为「regular width，regular height」，也即 iPad 横竖屏时：
- 整个方块组的左侧 = 屏幕左侧 + 485；
- 纵向、横向上不同颜色方块之间的距离 = 24
- 整个方块组的 Y 轴中心位置 = 屏幕的 Y 轴中心位置。

第三个例子，随着 iPad 的定位在逐渐向电脑靠拢，人们对 iPad 上的 app 生产力要求越来越高，需要利用好 iPad 这块大屏幕的空间、更容易地在 app 内进行导航，所以在 iPadOS 14 中，iPad app 增加了侧边栏这个导航样式，用户可以在侧边栏上更容易找到 app 不同层级的内容入口。但由于侧边栏占据了较大的显示面积，所以侧边栏不适合内容显示区域较小的情景。
例如下图中的「音乐」app，在 iPad Pro 11 寸上全屏展示时，此时 Size Class 为「regular width，regular height」，app 使用侧边栏作为导航方式；当「音乐」app 以 Slide Over 形式运行时，此时 Size Class 为「compact width，regular height」，横向上显示空间有限，所以 app 改用以前的标签栏作为导航方式。

想要了解更多有关于 iPadOS 14 侧边栏以及针对 iPad 如何设计 app 的内容，可参考我的文章：

利用好 iPad 的大屏幕 —— 如何为 iPadOS 14 设计 app？ - 向远公园 | Step Park

有了 Size Class 这个武器，在 iPhone 和 iPad 上进行 app 的自适应布局设计变得更加方便统一。但目前的 Size Class 并不是完美的，因为 iPad 横屏和竖屏时的 Size Class 在最初设计时都被定义为了「regular width，regular height」，所以当想要针对 iPad 横屏和竖屏有不同的内容布局方案时，Size Class 并不能满足，还需要依靠其他判断条件。随着 iPad app 的地位的提高，也许以后的 Size Class 会进化出更多的级别以应对上述情况。

iPhone 转向全面屏时代：不规则屏幕的出现

全面屏的 5.8 寸、6.1 寸、6.5 寸

2017 年 iPhone 转向全面屏时代，搭载 iOS 11、配有 5.8 寸屏幕的 iPhone X 发布，屏幕分辨率为 1125px × 2436px，PPI 达到 458，屏幕尺寸和屏幕分辨率都发生了重大变化，而且屏幕由以前的 LCD 屏改为了 OLED 屏。由于从非全面屏到全面屏的进化，iPhone 去除了 Home 键，由软件层面的 Home Indicator 代替；去除了 Touch ID，由刘海内的Face ID 代替；屏幕的四角也变成了圆角，整块屏幕不再是规则的矩形。

5.8 寸的 iPhone X 的逻辑分辨率为 375pt × 812pt，比例因子为 @3x。逻辑分辨率在横向上是与 4.7 寸的 iPhone 8 的屏幕相同的，在纵向上比 iPhone 8 多了 145 pt，纵向上可以显示更多内容了。所以 iPhone X 的逻辑分辨率实际上是对 iPhone 8 的逻辑分辨率「横向不变，纵向变长」得来的，这与从 iPhone 4s 到 iPhone 5 的屏幕进化方式相同。

屏幕变长，未适配新机型的 app 将会在 iPhone X 上以 iPhone 8 的大小显示，上下留有黑边。同时，由于刘海和 Home Indicator 的加入、屏幕四角改为圆角，在全面屏 iPhone 上设计开发 app 还需要综合考虑这些改变，具体可参考我的文章：

Designing For iPhone X —— iPhone 上有了刘海，设计和开发到底该咋整? - 向远公园 | Step Park

2018 年 5.8 寸的 iPhone Xs 发布，与 iPhone X 的屏幕保持一致，同时全面屏 iPhone 家族新增了 6.5 寸的 iPhone Xs Max，屏幕分辨率为 1242px × 2688px，PPI 为 458。2019 年 5.8 寸的 iPhone 11 Pro 和 6.5 寸的 iPhone 11 Pro Max 发布，与上一代的屏幕保持一致。

2018 年 Apple 还同时发布了 6.1 寸屏幕的 iPhone Xʀ，屏幕分辨率为 828px × 1792px，PPI 为 326；2019 年 iPhone Xʀ 的继承者 iPhone 11 发布，与上一代的屏幕保持一致。

2018 年和 2019 年全面屏 iPhone 家族新增的 6.1 寸屏幕和 6.5 寸屏幕，它们虽然屏幕尺寸不同，但逻辑分辨率相同，都为 414pt × 896pt，不同的是 6.1 寸的比例因子为 @2x，6.5 寸的比例因子为 @3x，所以它们显示的内容数量是相同的，但 6.5 寸的屏幕清晰度更高。
这两个机型的逻辑分辨率在横向上是与 5.5 寸的 iPhone 8 Plus 相同的，都为 414pt，在纵向上比 iPhone 8 Plus 多了 160pt，所以也是采用「横向不变，纵向变长」的逻辑进化而来。5.8 寸的全面屏 iPhone 是由 4.7 寸的非全面屏 iPhone 进化而来，6.1 寸/6.5 寸的全面屏 iPhone 是由 5.5 寸的非全面屏 iPhone 进化而来，同时 4 寸、4.7 寸、5.5 寸的非全面屏 iPhone 的宽高比例是相同的，5.8 寸、6.1 寸、6.5 寸的全面屏 iPhone 的宽高比例也是相同的，6.1 寸、6.5 寸也可以看做是由 5.8 寸屏幕「等比放大」而来。

如果 app 没有适配新的机型，将会在 6.1 寸和 6.5 寸的屏幕上把 iPhone X 的 app放大到全屏显示，清晰度不如已经适配的 app；如果 app 连 iPhone X 都没有适配，则会以 iPhone 8 Plus 的大小显示，上下留有黑边。有关于更大屏幕的全面屏 iPhone 适配和设计，可参考我的文章：

Designing For iPhone Xs、iPhone Xs Max、iPhone Xʀ — 比大还大，更大的刘海屏 iPhone app 如何适配 - 向远公园 | Step Park

不止是 iPhone，iPad Pro 系列也在 2018 年的产品迭代中提高了屏占比例，引入了 Face ID 和 Home Indicator，使软件层面的操作逻辑与 iPhone 保持一致，iPad Pro 的屏幕进化也发生了与 iPhone 屏幕进化类似的过程，并且由于 iPad app 支持 Slide Over、Split View 显示模式，对 app 的适配和设计提出了更高的要求，有关于这一部分可参考我的文章：

Designing For New iPad Pro and Apple Pencil — 适配没有刘海的 iPad Pro 与有刘海的 iPhone Xs 有什么不同? - 向远公园 | Step Park

为了推动 app 生态的进化，Apple 在之前也向开发者发出通知，2020 年 6 月 30 日之后，所有要更新或新上架的 iPhone app 必须支持所有的 iPhone 屏幕尺寸，iPad app 必须支持所有的 iPad 屏幕尺寸。同时强烈鼓励开发者对 iPad app 支持多窗口、多任务功能（侧拉、分屏浏览、画中画）。

适应屏幕新变化：Safe Area

在非全面屏 iPhone 的时代，从 iOS 7 开始，为了让 app 在设计和开发时更容易、更正确地进行布局，Apple 引入了「Layout Guide 布局指导」的概念。简单来说，显示在 iPhone 上的 app 中不仅包括 app 本身要显示的内容，如文字、图片等，还包括一些让 app 更易用、更统一的系统控件，如状态栏、导航栏、标签栏、搜索栏、工具栏等。这些系统控件一般会在屏幕顶部或底部占据一定的区域，而除去这部分才是 app 真正显示内容的区域。

如下图所示，在 iPhone 8 上，屏幕顶部的状态栏、导航栏、搜索栏的区域称为「Top Layout Guide」，屏幕底部的标签栏的区域称为「Bottom Layout Guide」，app 内真正显示的内容应该在这两者之间进行布局。
由于屏幕是一个规则的矩形，无论是竖屏还是横屏，系统控件只会出现在屏幕顶部和底部，屏幕左右两侧是不受约束的。

进入全面屏时代，刘海的加入，屏幕四角由直角改为圆角使得屏幕不再是一块规则的矩形，同时软件层面 Home Indicator 变成了常驻系统控件，原先的 Top Layout Guide 和 Bottom Layout Guide 已经不能再适应新需求，从 iOS 11 开始进化成了「Safe Area 安全区域」。

如下图所示，Safe Area 是一块可供自定义内容展示的规则矩形。在竖屏时，由于顶部刘海和底部 Home Indicator 的存在，需要空出这两块区域；在横屏时，由于一侧有刘海，一侧没有，但为保证内容对称，所以左右两侧需空出等宽的区域，而屏幕底部也需要为 Home Indicator 空出一定的区域。进一步，当放置了系统控件之后，Safe Area 会在上面的基础上进一步缩小。

在使用 Auto Layout 对界面上的 View 确定布局约束时，就可以直接利用上 Safe Area 以适应不同的使用场景。举一个简单的例子，下图中红色方块的其中一条布局约束就可以定义为：

Size Class 为「compact width，regular height」，也即 iPhone 竖屏时：
- 红色方块的顶部 = Safe Area 的顶部 + 32；
Size Class 为「any width，compact height」，也即 iPhone 横屏时：
- 红色方块的头部 = Safe Area 的头部 + 110。

这样利用 Safe Area 确定的布局方案会根据不同机型的 Safe Area 的不同进行自动调整，不再需要为每个机型单独适配，界面上的元素也就不会出现被遮挡的情况。

总的来看，有了 Safe Area 的定义，app 在设计和布局自定义内容时应该处于 Safe Area 之内，避免与屏幕的圆角、刘海、Home Indicator 发生重叠或裁切，但对于可滚动的内容以及控件/页面的背景颜色，可以让其延伸到屏幕边缘，以形成连续显示的效果。

可以说全面屏 iPhone 的诞生催生了 Safe Area，让 Layout Guide 更加完善，为众多第三方 app 在设计和开发时提供了内容布局指导，以让它们在整个 iOS 系统中保持一致性。

OLED 屏的影响：支持深色模式

iPhone 从非全面屏向全面屏进化的过程中，部分型号的屏幕也从 LCD 屏幕进化到了 OLED 屏幕，同时伴随 iPhone 的屏幕尺寸越来越大，耗电自然也会增多，续航变成了用户日常使用手机的重要关注点。

基于 OLED 材质屏幕的显示特点，当屏幕显示黑色的面积越大越省电，这也是从 iOS 13 开始 app 在系统级别上支持了深色模式的一个原因。适配了深色模式的 app 可以让用户根据需要和偏好选择使用浅色模式还是深色模式，深色模式可以让用户更加聚焦于内容本身，更加适合在灯光条件较暗的环境下使用手机。但有一点特别注意的是，深色模式不等于低对比度，因为开启了深色模式而使得 app 上的内容识别度和可读性下降，这不是一种正确的做法。

想要了解更多关于 iPhone 上的深色模式，可参考我的文章：

更长更大的屏幕下的交互变化

随着 iPhone 的屏幕尺寸变得越来越多，屏幕变得更长更大，iOS 系统的许多交互也在不断发生进化，在此举两个例子。

新的大标题导航栏

从 iOS 11 开始，为了让用户更加明确自己处于 app 的哪个位置，让 app 突出自己的核心模块，系统引入了一种新的导航栏样式：大标题导航栏，它比以前的导航栏样式更加醒目，在纵向上占据了更多的屏幕空间，这增强了刚进入这个页面的用户的空间感，而当用户滚动 app 的内容时，用户已经知道所处的位置，大标题导航栏又可以自动地缩小，以让此时的用户把注意力放在内容本身上。

想要了解更多关于大标题导航栏，可参考我的文章：

iOS 11 的设计有什么新变化？ - 向远公园 | Step Park

新的菜单样式

在 iOS 14/iPadOS 14 中新增了一种菜单样式，当用户点击按钮时，新的菜单会直接显示在菜单旁边，而不再是使用以前的 Action Sheet（从屏幕底部弹出的菜单选项）样式，例如下图中的「提醒事项」app 。新的菜单样式可以让用户在较大的屏幕上更好地理解菜单选项和按钮之间的关系，同时可以不需要大幅度移动手指就可以完成操作。

值得注意的是，以前的 Action Sheet 样式也并不是不再使用，当执行破坏性操作（比如删除操作）时，仍然建议使用 Action Sheet 来让用户完成操作的二次确认，因为 Action Sheet 会吸引用户的注意力，只有将手指移动到屏幕才能做出选择，避免了误触的情况发生。

iPadOS 14 中也同样增加了这种菜单样式，这也与 macOS 中的弹出菜单交互逻辑保持一致，更有利于 iPad app 通过 Mac Catalyst 技术向 Mac 平台转移。

想要了解更多关于 iOS 14/iPadOS 14 新的菜单样式，可参考我的文章：

iOS 14/iPad OS 14 新组件：菜单、日期和时间选择器、颜色选择器 - 向远公园 | Step Park

全面屏的放大显示

前文提到，从 iPhone 6 开始，iOS 在部分机型中新增了「放大显示」功能，放大显示的实质是将高一级的逻辑分辨率降级到同一比例的低一级的逻辑分辨率。在全面屏 iPhone 中，6.1 寸、6.5 寸的 iPhone 具备放大显示的这个条件，所以这两种尺寸的 iPhone 在系统中同样可以开启放大显示模式；但 5.8 寸的 iPhone 不存在比它还要低一级的同一比例的逻辑分辨率，所以 5.8 寸的 iPhone X、iPhone Xs、iPhone 11 Pro 一直没有放大显示功能。

展望未来 iPhone

根据目前媒体获得的消息，2020 年秋季将会有四款 iPhone 发布，旗舰系列包括 5.4 寸的 iPhone 12（非最终命名，下同）和 6.1 寸的 iPhone 12 Plus，超旗舰系列包括 6.1 寸的 iPhone 12 Pro 和 6.7 寸的 iPhone 12 Pro Max。

旗舰 iPhone 12 会是什么样？

本文开头提到，在 iOS 14 Beta 3 版本中有用户发现 5.8 寸的 iPhone 也有了放大显示这个功能，根据前文所讲的放大显示的存在条件，我们可以推测存在一款 iPhone 与 5.8 寸 iPhone 的屏幕是同一比例，且逻辑分辨率比 5.8 寸 iPhone 低一级。
同时还发现 Xcode 中的模拟器可以正常运行在 960px × 2079px 分辨率下，假设比例因子为 @3x，其屏幕逻辑分辨率就为 320pt × 693pt。
综上两个发现，传闻中的 5.4 寸 iPhone 的屏幕参数似乎已浮出水面。

5.4 寸 iPhone 12 由 4 寸 iPhone SE 第一代进化而来

小屏旗舰 iPhone 12 配备 5.4 寸屏幕，屏幕渲染分辨率为 960px × 2079px，PPI 约为 424，逻辑分辨率为 320pt × 693pt @3x。

在本文最初成文时，我没有太多考虑 6.1 寸 iPhone 12 Plus 会是什么样，本以为相比上一代不会发生什么变化，毕竟它和 iPhone Xʀ、iPhone 11 具有相同的屏幕尺寸，但与读者讨论后我发现我忽略了一个细节—— iPhone 12 Plus 会改用 OLED 屏幕，而同样分辨率的 LCD 屏和 OLED 屏的清晰度观感是不一样的。

如下图，左边 LCD 屏幕的像素排列方式是 RGB，三个子像素点不论是大小还是个数都是相同的；右边 OLED 屏幕的像素排列方式是 Pentile，绿色像素点是红蓝像素点的 2 倍，而且单个红蓝像素点面积要比绿色像素点大。正是因为 OLED 屏幕上像素排列方式的特殊，在相同尺寸相同分辨率的条件下，LCD 屏幕会比 OLED 屏幕更清晰，特别是在红色和蓝色较多的情况下。所以为了达到与 LCD 屏幕相同的屏幕清晰度观感，只能提高 OLED 屏幕的分辨率。若 OLED 屏的 iPhone 12 Plus 保持与上一代一样的屏幕分辨率这肯定就说不过去了。

所以猜测大屏旗舰 6.1 寸屏幕的 iPhone 12 Plus 会改用 375pt × 812pt @3x 的逻辑分辨率。

回到小屏旗舰 iPhone 12 上，可以看出 5.4 寸 iPhone 12 的逻辑分辨率的宽度与 4 寸的 iPhone SE 第一代是相同的，都是 320pt。5.4 寸的 iPhone 12 的屏幕变化实质也是「横向不变，纵向变长」，相比 iPhone SE 第一代，纵向上多了 125pt，当 app 没有适配新尺寸的 iPhone 时，上下会出现黑边。这样来看，5.4 寸的 iPhone 12 就是之前大家翘首以待的全面屏 iPhone SE。

屏幕显示的内容数量较少

屏幕的逻辑分辨率影响着屏幕上内容的数量，下图列举对比了目前三种宽度逻辑分辨率的 iPhone 显示同一内容时的实际情况，可以很明显地看出：

宽度 414pt 的 6.1 寸、6.5 iPhone 显示的内容最多，375pt 的 5.8 寸 iPhone 次之，320pt 的 5.4 寸 iPhone 最少；
图片显示区域，414pt 宽度的 iPhone 上可以看到第三张图片的 1/4，375pt 宽度的 iPhone 上几乎看不到第三张图片。320pt 宽度的 iPhone 上第二张图片都不能显示完全；
文字显示区域，屏幕宽度和高度会共同影响屏幕上能显示文字的数量；
特别地，320pt 宽度的 5.4 寸 iPhone 上，导航栏的按钮已经显得有些拥挤了。

非全面屏 4 寸的第一代 iPhone SE 仍然支持 iOS 14、全面屏 5.4 寸 iPhone 再次引入 320pt 宽度，在屏幕日趋变大的今天，设计师和开发者仍然需要为 320pt 这样较窄宽度的 iPhone 进行 app 设计、适配和开发。

刘海变窄变小？

全面屏 iPhone 的刘海中包含的物理元器件并不随 iPhone 的屏幕尺寸所变化，根据网上找到的资料，刘海的宽度大概为 209pt。在目前放出的 iOS 14 Beta 版本中，刘海附近的状态栏显示区域（包含基本的时间、信号、网络和电量信息）并没有发生设计上的改变，而当把现有的状态栏放到 320pt 宽度的 iPhone 上时，我们会发现其无法承载现有的状态栏信息，那这是否可以推测 5.4 寸的 iPhone 12 抑或是整个 iPhone 12 系列的刘海会变得更窄更小呢？

超旗舰 iPhone 12 Pro 又会是什么样？

超旗舰 6.1 寸的 iPhone 12 Pro 和 6.7 寸的 iPhone 12 Pro Max，相比于上一代屏幕尺寸都有一定程度的小幅增大。根据之前 iPhone 屏幕逻辑分辨率的进化规律，我认为 Apple 对于逻辑分辨率的改变是比较谨慎的，因为新的逻辑分辨率对设计师和开发者就意味着新的设计、适配和开发工作，iPhone 的屏幕尺寸就会更加碎片化，所以如果 iPhone 12 Pro 的尺寸真的是 6.1 寸和 6.7 寸，猜测屏幕尺寸的整体变大可能是由于屏幕边框变窄导致，iPhone 12 Pro 系列的屏幕逻辑分辨率和渲染分辨率应该与上一代保持一致，PPI 稍有降低。

iPhone 屏幕还会怎么变？

目前 iPhone 的最大尺寸是 6.5 寸，这个尺寸的手机对于用户日常使用来说已经基本到达极限，如果按照之前的屏幕进化规律通过「横向不变，纵向变长」或者「等比放大」的方法继续变大已经没有必要，但不可否认的是，更大的显示屏幕更有利于内容的显示和多任务的操作，对于手机来说，体积尽量小，但屏幕尽量大的折叠屏手机可能会成为未来的发展方向。
隔壁 Android 阵营已经有多家厂商发布了折叠屏手机，比如三星 Galaxy Fold、华为 Mate X，折叠屏也很可能成为 iPhone 未来发展的一个方向，iPhone 的屏幕很有可能出现第三个进化方法——横向放大，纵向不变。

畅想一下，在折叠屏 iPhone 上，你可以让 app 按照以前接近两倍的显示面积来显示；也可以让一个 app 全屏显示，另一个 app 以小窗口的形式悬浮在另一个 app 之上，类似 iPadOS 上的 Slide Over；更可以让两个 app 并排显示，类似 iPadOS 上的 Split View。

一方面，app 在设计内容布局时使用了 Auto Layout、Size Class、Safe Area 这些武器，app 的布局适应性更高；另一方面更多的 iPad app 已经可以以任何尺寸自适应布局灵活显示，固定尺寸大小的 app 设计思想正在被弱化，同时 app 多任务、多窗口的功能已在 iPadOS 中进化得逐步完善。基于这两方面，到折叠屏 iPhone 推出时，iOS 和 iPadOS 上的 app 适配的阵痛期就会更短。

总的来看，iPhone 屏幕逐渐变大，甚至翻倍，尺寸接近 iPad，iPad 部分功能下放到 iPhone 上，iPhone 与 iPad 的边界会变得逐渐模糊；同时，iPad 的 app 通过 Mac Catalyst 技术向 Mac 平台转移，Mac 逐步放弃 Intel 芯片，逐渐采用 Apple Silicon，iPad 和 Mac 的边界也同样在变得模糊。或许在未来的某一天，iPhone、iPad、Mac 的 app 生态会逐渐融合，合为一体。

总结

从第一代 iPhone 到 iPhone 12，每一次屏幕尺寸的变化不仅仅是硬件上物理参数的变化，背后还有着缜密的 app 设计逻辑牵制着硬件参数的变化：

**横向不变，纵向变长：**从 iPhone 4s 到 iPhone 5，从 iPhone 8 到 iPhone X，从 iPhone 8 Plus 到 iPhone Xʀ、iPhone Xs Max，从 iPhone SE 第一代到 iPhone 12 采用了这个变化规律，纵向上比以前可以看到更多内容；
**等比放大：**从 iPhone 5s 到 iPhone6、iPhone 6 Plus，从 iPhone X 到 iPhone Xs Max、iPhone Xʀ、iPhone 12 采用了这个变化规律，横纵向上都比以前可以看到更多内容；
屏幕尺寸不断增多，但屏幕逻辑分辨率宽度现在只有 320pt、375pt、414pt 三种。

为了让 app 能在各种屏幕尺寸的 iPhone 上都能完美显示，下面的武器必不可少，它们隐藏在 app 背后，默默发挥着作用：

Point 点：抛开像素密度的干扰，专注于内容数量的对比；
Auto Layout 自动布局：不对每一台设备进行绝对布局，通过确定 view 之间的约束关系针对所有设备进行相对布局；
Size Class 尺寸级别：竖屏、横屏，小屏、大屏，不同使用情景采取不同内容布局方案；
Safe Area 安全区域：非规则屏幕下的内容布局规范。

屏幕尺寸的不断进化也带来了 iPhone 上功能和交互的变化：

放大显示功能：使用低一级的同比例的逻辑分辨率在更大屏幕上显示内容；
深色模式功能：让 OLED 屏幕更省电；
新的大标题导航栏：利用更长的屏幕展示更醒目的标题，增强用户在 app 内的空间感；
新的菜单样式：缩短用户操作路径，让按钮与操作之间关系更紧密，与 Mac 上的菜单样式保持一致。

对于即将到来的 5.4 寸 iPhone 12，基于 iOS 14 Beta 版本中发现的线索，可以猜想：

从逻辑分辨率上来看，5.4 寸 iPhone 12 基于第一代 iPhone SE 横向不变，纵向变长进化而来；
小屏便利的同时，内容显示数量作出了牺牲，320pt 的屏幕宽度相比于更大尺寸显示的内容数量偏少；
刘海可能会变窄变小以承载完整的状态栏信息。

在 iPhone 屏幕尺寸发展走到极限的今天，未来的 iPhone 可能会朝着折叠屏的方向发展，出现第三种变化方式——横向放大，纵向不变，而在这之前已有了许多铺垫：

iPad 上的 app 支持 Slide Over 侧拉、Split View 分屏浏览等多任务功能，支持一个 app 的多窗口功能；
App 的内容布局可以自适应多种不同尺寸、不同比例的屏幕，在 Auto Layout、Size Class、Safe Area 的帮助下，固定尺寸的 app 设计思想被弱化，Apple 生态圈的 app 自由变换显示尺寸指日可待；
Apple 自身也在强力推进开发者的 app 适配所有的屏幕尺寸。

纵观 iPhone 的屏幕进化历程可以看出 iPhone 的屏幕进化不仅仅是硬件上物理参数的改变，还伴随着软件上设计和开发逻辑的不断完善，前期硬件和软件的进化或许早已为以后的软硬件埋下了种子，这种软硬一体，硬件和软件相互影响、相互牵制的设计思想可能正是解释很多人会问到的「为什么总感觉 iPhone 比 Android 好用一点，但又说不出具体哪里好？」这种问题的一个答案。
「罗马不是一日建成的」，智能手机的生态走到今天，各家手机厂商的产品已是大差不差，但可能就是在那些微不足道的地方的细细耕耘、日积月累默默地抓住了用户的心。

为 iOS 14 设计全新的小组件

2020-08-05T23:11:23+08:00

在 iOS 14 中，主屏幕的使用体验焕然一新，通过引入「小组件」主屏幕变得更加动态化和个性化。新的小组件设计得更加大胆、一目了然，不仅可以显示在 iPhone 的主屏幕上，还能显示在 iPhone 和 iPad 的全新的「今天视图」中以及 macOS Big Sur 中的新的通知中心中。
本文将以最核心的 iOS 14 的小组件为例，聊一聊 iOS 14 小组件的变化和如何为 iOS 14 设计小组件。

小组件新的变化

在 iOS 14 中，整个小组件的体验被完全重新设计，它有着完全不同的新的视觉外观，并有着强大的新的能力。你的 app 的小组件要展示的信息可以比以前更及时更情景化，通过拖放、编辑可以让人们用一种直观、灵活的方式直接控制他们的小组件。

特别要提到的一点就是人们现在可以把这些小组件直接添加到他们的主屏幕页面上，这为用户创造了一种全新的体验小组件的方式，所以在设计时，你需要考虑一整套新的设计考量因素。

另一个需要提到的亮点是「智能堆叠」（Smart Stacks），这个功能可以让你在一个位置添加多个不同的小组件，并可以在多个不同的小组件之间轻扫快速切换。但智能堆叠最强大的一点在于它可以根据你的使用习惯动态改变。在基于你的行为和使用场景的基础上，智能堆叠可以在某个特定的时间自动轮换展示与你最相关的那个小组件。这样在你自己操作之前，你想要寻找的信息就会早已出现你的面前。

例如，当我醒来时我可能想要知道今天的天气状况：

当我在上班路上时，我总是播放最近喜欢的音乐：

而在下午，我总是会查看交通状况如何以及回家需要多长时间：

到了晚上，我会查看并阅读一些当天的新闻头条：

这是一个基于我的行为习惯的智能堆叠小组件的示例，但是智能堆叠的小组件及其行为对于每个人都是不同的，它会根据人们使用设备的方式以及对人们最重要的信息作出判断和选择。

新的小组件是支持在 iOS、iPadOS、macOS 多个平台上跨平台使用的，所以通过 WidgetKit 创建的小组件用户界面是完全用 SwiftUI 构建的，这也是 Apple 平台中第一个只支持 SwiftUI 的功能。SwiftUI 也使得对动态类型、深色模式功能的支持变得更简单。

以上是关于小组件新功能的一个快速浏览，记得人们与小组件发生交互的方式，在接下来的文章中还会深入了解这些功能。

小组件的基本特性

小组件的设计有三个主要的特性：一目了然、高相关性、个性化。

一目了然

后面的文章会讲到，小组件可以提供多种尺寸，最小的小组件尺寸只有主屏幕上四个图标的空间大小，所以你需要好好利用好这个空间。人们每天在主屏幕上停留的时间是有限的，平均每个人每天要前往主屏幕 90 次，但只会在主屏幕上停留一小会儿。他们不应该需要与小组件发生交互才能获取更多信息，应该只需要轻轻一瞥就能发挥小组件的最大价值，内容本身就是焦点。

有一点非常重要：小组件不是一个迷你 app。把小组件看作是你的 app 的更多内容被放置在了主屏幕上，而不是把一个具备完整功能的迷你 app 放置在了主屏幕上。

高相关性

高相关性是小组件的第二个特性。例如，早上的时候我更关心天气状况，但在白天工作时我会更关心提醒事项中的内容，在一天结束时我想要听听音乐。特别是在手机这个平台上，我们希望充分利用好每一处空间，通过一种方式确保你想要的小组件可以及时出现在你的面前，这就是智能堆叠，它可以帮助你始终在堆叠的最上面显示你最想看到的小组件，你可以通过 WidgetKit API 帮助系统判断什么时候你的小组件是高度相关的，什么时候不是。

个性化

一个好的小组件也应该是个性化的。就像天气 app 的小组件一样，你可以根据自己的需要选择不同尺寸的小组件，还可以选择小组件中要展示的天气位置信息。

设计小组件

当设计一个小组件时，这里有两个主要的设计过程需要特别注意：构想和创造。

小组件的构想

设计准则

在第一部分，文章会谈到一些设计准则以帮助指导你的想法，并去深入了解一些你需要在这一步考虑的重要的新功能。
新的小组件系统完全围绕内容而创造，为了创造一个好的小组件，你需要理解用户如果回到你的 app 中需要查看的最有用的信息或者体验是什么。

在考虑小组件的想法和目标时，我们需要聚焦于三个设计目标方向：个性化 personal、信息性 informationnal、情景化 contextual。

我们想要寻找那些个人的东西，因为它们可以与你的 app 的一部分或者与个人相关的体验之间创建更深的情感连接。
小组件提供了一个好的方式从人们的设备的众多信息源中筛选出一部分重要的信息来展示。展示正确的信息可以节省人们在你的 app 中做重复性操作的时间。
人们一整天都会和自己的设备在一起，有很多信号可以推测一个人所处的情景环境。情景可以帮助在正确的时刻展示正确的信息，创建一个似乎可以预测人们的需求和下一步动作的更好的体验。

来看下在设计一些小组件时，这三个目标方向是怎样让我们确定想法，做出决定的。
「日历」app 的小组件，就像 app 图标一样它展示了一周的一天和现在的日期，还展示了你的下个会议或者日程。像是日程开始时间和日程位置这些可以一瞥而见的细节可以让人们不用打开 app 就可以找到这些信息。

如果你的时间表很忙、日程很多，小组件会收起一些低相关的信息，优先展示众多日程中最重要的部分。

当一天即将结束时，不要展示一个空白的小组件，而是展示明天的日程。这是一个超越当前情景时刻思考、拓宽情景相关的时间范围的好例子。

一个更突出个性化的细节是小组件会根据你居住的地区显示假期日历，并在一些特别的节日添加了提醒。

当某个联系人的生日到来时，会显示一个礼物图形，并把这条信息放在最前面，这样从主屏幕上你可以感受到与小组件的更个性化的情感连接。

「照片」app 的小组件是个性化小组件体验是什么样的一个好例子。在这个小组件中，最令人愉悦的体验是展示最佳照片而不是展示最近拍摄的照片。

除了回忆照片，还会展示为你推荐照片。利用情景化的优势，这个小件还会展示过去的今天的照片回忆。

「天气」app 的小组件展示了当前位置的城市名字、包含最高和最低温度的当前温度信息以及接下来几个小时的天气信息。这个小组件是情景化小组件是什么样的一个好例子。

小组件中展示独一无二的天气信息，如大风、雷电、是否下雨、什么时候开始下雨，并可以根据情景增加接下来几个小时的天气预报信息。

地图常用于确认你的地理位置，查看周围有什么。

「地图」app 的小组件建立在这种空间意识上，当你不在家或者开车去了其他地方，小组件会显示你停车的地方。

如果你接下来有一个日程，小组件会显示到那里有多远，根据情景展示去那里的路线。当你不在家时，小组件会展示你回家需要花费的大致时间。

你可以在这些所有的例子中看到小组件是动态变化的，是为用户提供有用信息的，情景化细节让小组件的使用体验变得更加个性化、更加适应一个人的需求。

支持编辑

小组件的一个新的能力是人们可以编辑小组件。在构想小组件时，你需要仔细思考这个。因为它可以改变你要在一个小组件上所展示信息的多少。
来看一下天气 app 的小组件的编辑功能是如何工作的。在 iOS 14 中的编辑状态下，你的小组件会像 app 的编辑模式时那样晃动，你可以点击一个小组件以查看它可以允许你编辑什么信息。在这里，天气小组件可以让你改变它展示的天气信息的具体位置。

默认情况下它会展示你当前位置的天气信息，所以当一个人添加一个小组件，他不需要做什么额外的工作。如果我点击位置区域，我就可以获得一个我喜爱的天气城市的列表供我选择，或者可以通过搜索选择其他位置。

在 iOS 14 中，你可以添加尽可能多的天气小组件，针对于每一个天气小组件编辑调整成你想要的位置。这个功能最好的一点是它避免了那种把各种信息组合在一起的十分复杂的单个小组件，这样可以让用户根据自己对信息的需求选择添加多个小组件，通过编辑功能让每个小组件显示自己想要的信息。现在我可以让多个位置的天气信息同时摆放在一起。

在 iOS 中的大多数小组件支持编辑功能，像是下图中的时钟小组件一样，你可以选择不同的提醒列表、股票、备忘录或者世界时钟来展示在桌面上。

这些都是支持编辑功能的小组件的主要使用场景，也可以有其他使用场景。思考一下你可以给用户提供哪些选项以最大化人们使用小组件时的实用性和灵活性。

多种样式

在构想过程中还需要考虑的一点是决定是否要提供小组件的多种样式。对于「股票」app，有两种不同的想法：一种是提供一个小组件展示你的关注列表的概括信息，一瞥就能看见；另一种是每一支股票作为一个小组件，以跟踪它的具体信息，就像前面提到的天气小组件一样。

在 iOS 14 中的某些 app 提供了多种样式的小组件，像是「新闻」app 可以让你跟踪某个话题下的新闻热点，「备忘录」app 让你展示最喜欢的备忘录或者添加一个共享的备忘录文件夹。

综上，文章讲了在构想小组件时一些重要的设计准则和考量，下一部分会讲到怎样把这些想法落地成具体的小组件。

小组件的创造

在小组件的创造这一部分有三点需要讲。

尺寸和交互

第一点是尺寸和交互，新的系统支持三种尺寸供你设计：小、中、大，让小尺寸的小组件显示 app 中最有用的内容。

小尺寸的小组件支持一个点击目标，点击后可以跳转到小组件上对应的内容中，跳转到的地方取决于你的 app 结构是怎样的。
来看几个具体的例子，小尺寸的日历小组件总是显示接下来的日程，点击它会跳转到 app 中「天」视图中的最新日程，同时可以让对这一天的其他日程有一个大概浏览。

小尺寸的新闻小组件可以预览一个你可能感兴趣的新闻故事，点击它会跳转到 app 中那个新闻故事中。

中尺寸和大尺寸的小组件有着类似的熟悉的形状，这两种尺寸可以承载更多内容，支持多个点击目标。在这两种小组件中点击一部分内容也会跳转到 app 中对应内容的位置。

例如在新闻的小组件中，点击任何一篇文章会跳转到 app 中你点击的那个新闻故事中。

在小组件系统中有三个不同的点击样式：

Fill Style：这种适合于当这部分需要深入链接到 app 中的某一部分内容，小尺寸的小组件都用的这种样式，因为它只支持一个点击目标；

Cell Style：这种适合于让小组件中被选中的部分保持它本身的形状，例如文件 app 的小组件；

Content Style：这种适合于在小组件中选中一部分内容本身时使用，例如日历 app 的小组件。

内容和个性化

第二点是内容和个性化。让你的小组件落地的最重要的一部分是其中的内容是什么，在设计小组件时你应该把内容和个性化一起思考。问问你自己：当用户打开你的 app 时在寻找什么？在你的 app 中搜寻那些对用户有用的独特信息。

来看几个思考内容和个性化的例子。在设计小组件时，我们通过思考 app 本身的样子来考虑个性化。对于天气小组件，我们使用熟悉的天气条件背景样式，还有来自于 app 中的图形样式。

对于新闻小组件，我们从你看到的新闻故事的丰富的故事图表中汲取灵感。

对于日历小组件，我们从它的极简外观和熟悉的红色配色来汲取灵感，将目光全部聚焦于接下来的日程。

另一个寻找个性化的方法是从你的 app 的图标中汲取灵感。像是备忘录的小组件，我们从备忘录样式的图标中汲取灵感：

播客的小组件，我们从紫色渐变样式的图标中汲取灵感：

同样的提示 app 的小组件使用了 app 图标中的黄色渐变：

当说到在你的小组件中放置内容时，有两种设计模式。第一种是在所有三种尺寸上扩展的布局，像是天气 app 的小组件，在每种尺寸上添加额外的信息；

第二种是不同的尺寸的内容是完全不一样的，像是新闻 app 的小组件，小尺寸的包含新闻故事的丰富内容，中尺寸的聚焦于展示更多新闻故事。

当你为每种尺寸进行设计时，确保不要把小尺寸的内容放大到更大尺寸上。

仔细考虑每种尺寸上要展示的信息，选择每种尺寸最合适的信息来展示。例如屏幕时间的大尺寸小组件，因为有了更多的空间可以展示更多有用的信息，我们在小组件上增加了表格的尺寸，同时包含了分类和 app 细节。

如果你的 app 没有更多信息在大尺寸的小组件上展示，你可以只支持特定的尺寸，不需要在所有尺寸的小组件上都应用同一个想法。

像下面这个例子一样，你可能想要在小尺寸的小组件上展示一些概括性的信息，我们只推荐在小组件上展示最多四条信息。

模式

再来讲一讲更多关于小组件模式的细节。当我们设计小组件时，有一些常见的布局模式可以应用于不同的尺寸，这些模式可以帮助你在一开始的时候将你的想法逐渐落地。

当你自己设计自定义的布局样式时，在所有尺寸上都要遵守 16pt 的布局边界以确保在与其他小部件摆放在一起时，小部件上的内容是一致的。

对于有形状的布局，像是圆形或者其他嵌入图形，可以在所有尺寸上使用更紧凑的 8pt 布局边界。

这些形状的边角如果靠近小组件的边缘，那它们应该和小组件的圆角半径有着相同圆心。

因为小组件的圆角半径在不同尺寸上是不一样的，我们提供了一个 SwiftUI 容器以让你的小组件的形状可以自动与小组件的圆角半径保持相同圆心，而不需要手动指定具体的圆角半径值。

对于字形，你应该使用 SF Pro 或者 SF 的其他变形（比如 SF Mono、SF Pro Rounded）。如果使用一个自定义字体对于你的小组件表达品牌和个性化十分重要，确保它和其他小组件放在一起时可以保持和谐。

小组件应该在浅色外观和深色外观模式下都保持显示良好。例如日历 app 的小组件，整个小组件会像 app 本身一样在浅色和深色外观之间变化。

播客 app 的小组件，因为整个背景是渐变的，在两种外观下都可以显示良好。

备忘录小组件因为有着顶部的标志性颜色和下半部分的白色，在深色外观下就只对下半部分进行调整，这样就和 app 内部保持一致了。

每一个小组件必须提供一个占位符用于系统无法展示小组件的真实数据的时候。你应该在这个状态展示基本的图形元素，在信息展示的文本区域显示区块。

当系统从占位符状态变成可以读取到真实数据时，实际的内容就可以直接替换掉固定的元素，不需要让布局或者颜色发生较大的变化。

在添加小组件时的预览界面，展示的就应该是真实数据，这可以让用户在预览时就能直观地感受到在真正使用时的体验。

小建议

最后一件要讲的事是在设计小组件时要记住的一些小建议。

如果你的 app 汇集了不同来源的内容，你应该在小组件中只使用一个 logo，像下面这个例子。为了在不同尺寸的小组件上保持一致性，你的 logo 应该总是位于右上角，不要再添加额外的文字标记。

不要在小组件上放置你的 app 图标；

不要在小组件上放置你的 app 名字，因为在小组件的下面系统会显示你的 app 名称；

不要把指导用户使用或告知用户的文字放置在小组件上，如果有什么重要的事情需要传达给用户，使用一种图形方式来表达；

当在一个小组件上展示时间先后顺序的内容时，不要使用「最近更新」这样的话语。

小组件的展望

iOS 14 的小组件焕然一新，它的核心目标是将 app 中的重要的、用户需要经常查看的核心内容提取出来，方便用户在需要的时候可以在主屏幕等地方一目了然地看到。但相比 iOS 13 的小组件，其极大地弱化了甚至可以说剔除了在小组件内进行简单交互的功能，比如在小组件内控制智能家居、在小组件内管理剪贴板、在小组件内进行简单的数据计算等，iOS 14 的小组件更强调内容的静态展示，用户需要查看更多内容、进行更多操作，与小组件发生交互后会直接进入 app 内对应的模块。

信息静态展示、不允许内部交互、跨平台通用、SwiftUI Only 这些对小组件大刀阔斧的改变在一段时间内对开发者、对用户或许会是痛苦的，但这也许只揭开了小组件的冰山一角，传闻中的 Apple Glasses 说不定才是小组件真正崭露头角的地方？

参考链接

iOS 14/iPad OS 14 新组件：菜单、日期和时间选择器、颜色选择器

2020-08-05T23:18:15+08:00

纵观 iOS 系统的发展和 iOS 设备的变化，iPhone 的屏幕变得越来越大，纵向上越来越长，iPad 上需要展示更多紧凑的内容；iOS 设备支持各种输入方式；Mac Catalyst 技术让越来越多的 app 从 iPad 转移到 Mac 上去，所以在以前的 iOS 系统中的很多组件样式不能继续适用现在的需求，这篇文章就来讲一讲在 iOS 14 和 iPadOS 14 中新增的三个组件：菜单、日期和时间选择器、颜色选择器。

菜单

新的菜单样式

在 iOS 14 及其之后的版本中，通过点击一个按钮可以显示一个人们可以从中选择的列有条目或操作的下拉菜单。你可以用一个下拉菜单（简称为菜单）提供与按钮操作直接相关的条目，或者提供一个在当前情景下有用的操作列表。例如像下左图这样，在照片 app 中点击导航栏上的添加按钮就会显示一个菜单。这个样式可能会让你联想到 iOS 13 的 context menus 情景化菜单（下右图）。

为什么要从 iOS 14 开始添加这个新的菜单样式呢？在 iOS 13 中，一般情况下菜单在 iPhone 上会以 action sheet 形式呈现，在 iPad 上会以 popover 形式呈现。这些组件从很早期的 iOS 版本就开始一直伴随我们，它们为许多功能提供了帮助。

但是随着 iPhone 的屏幕变得越来越长越大，iPad app 的内容变得越来越丰富和紧凑，以前的 action sheet 和 popover 开始显现出一些劣势，在显示时他们会在背景内容上生成一层遮罩，这是一个很重的过渡效果，特别是在像 iPad 这样的更大的屏幕上。即使 action sheet 中每一个操作的文本标签很短，但每一个操作却占据了较大的空间。Action sheet 中提供的操作功能也是有限的，例如不能用于导航目的。特别是在 iPhone 上，我总是需要大幅度的移动我的手指到屏幕的另一边去选择一个操作或者取消这个操作。

iOS 14 中新的菜单样式解决了许多问题。一开始，菜单会直接显示在你点击的按钮旁边，你在选择某个操作时就不需要大幅度地移动手指，而且人们可以马上理解菜单条目和他们执行的操作之间的关系。点击按钮、出现菜单的这个过渡十分快速和轻量化，简短顺滑，不需要让背景内容变暗。在菜单中的条目也变得更小、更精确，但仍然保持可点击，而且还对比较长的文本支持多行显示。

iOS 13 中的菜单只能被用在执行某些操作时，而 iOS 14 的新的菜单也可以用在选择和导航上。在菜单中显示的内容与情景化菜单中的操作是相似的，每个操作在左侧有一个文字标签 label，在右侧有一个可选的图标 icon，可以是 SF Symbol 或者一个自定义的图片。菜单可以添加一个标题以帮助用户理解需要做出什么选择，还可以通过添加分隔线来增加层级关系。

菜单可以从任何形式的按钮中弹出。例如，在音乐 app 中的排序按钮，点击后在弹出的菜单上保持手指不放直接移动到想要选择的操作上然后释放就可以了。或者，简单地点击按钮，再点击一个想要的操作即可完成选择。

在任何时候，我可以点击菜单外面的区域以关闭菜单，这会使菜单直接隐藏并回到之前的情景中，因此没有必要再在你的菜单中添加一个取消操作，让整个菜单只聚焦于具体想要进行的操作就好。

新的菜单样式遵从 iOS 和 iPadOS 的系统辅助功能设置，例如旁白、增强对比度、减弱动态效果、更大字体。

菜单的应用场景

菜单可以通过各种不同的方式被使用，在 iOS 14 中有几种最普遍的应用场景：消除歧义、导航、选择和展示次级操作。

消除歧义

菜单可以帮助你消除选择的歧义、明确用户操作的目的。用户带着一个目的出发，选择了一个操作，这个操作会展示一个菜单用来消除歧义，向用户进一步询问操作的目的。
例如，在照片 app 的左上角有一个添加按钮，点击按钮会展示一个菜单问你具体想要添加什么。

在备忘录 app 中，有一个操作可以在备忘录中添加一张图片，点击它会问你想要通过哪种方式添加图片。

再来看照片 app，当我编辑完成一个视频时，右下角有一个完成按钮可以保存我编辑好的视频，点击它会问我想要怎样保存它。

选择

菜单还可被用于选择目的。例如在播客 app 中，点击右上角的排序按钮，菜单被用来做出选择，系统会根据你的选择调整内容的排序方式。

展示次要操作

菜单还可被用于展示一些次要操作。在界面中的一个简单的查看更多按钮就是展示一个包含一系列操作的菜单的好方式。这些操作通常没有那么重要，所以不需要突出显示在主界面上，但是它们仍然需要简单地被访问到。将二级操作放进菜单中可以让你的设计更加整洁，帮助你将注意力放在真正重要的地方。

例如在文件 app 中，界面完全聚焦于你的内容。作为比较，iOS 13 的文件 app 中有许多操作散落在界面上，这会把人们的注意力从内容上吸引走。所以通过把这些二级操作简单地整理收集到一个菜单中，整个 app 就会变得更易于使用。

又例如在信息 app 中，像下面这样把一些二级操作放进一个菜单可以让整个界面变整洁。

但你可能会问最终结果为什么是这样，而不是把导航栏上的所有操作都收入一个菜单中呢？请注意，把所有的操作都收进一个菜单中绝不是一个值得鼓励的方法，额外的一次点击会让那些重要的操作被隐藏起来，不能让用户理解在这个界面中可以做些什么。所以要在首要操作和次要操作之间找到一个平衡，决定哪些操作可以放进一个菜单，哪些操作需要突出展示。在信息 app 中，发信息这个操作是非常重要的且操作频繁的，所以不应该被收入菜单之中。

一些额外的操作并不总是需要被收入到一个查看更多的按钮中，它们也可以通过不同的手势来让菜单展现。例如在 Safari 浏览器中，点击右上角的标签按钮会让你管理你的标签页，但是当点击并按住标签按钮时，就会显示一系列与标签相关的操作。

其他使用规范

当二级操作是破坏性操作时的处理方式：如前文所提到的，新的菜单样式不再需要你大幅度移动手指到屏幕顶部选择一个操作，但是有时你会误触，而破坏性的操作会造成你输入的信息丢失。我们需要确保在执行破坏性操作之前有足够的缓冲空间，在不同的操作系统中，我们总是通过向用户二次确认来实现这个目标。为了避免不小心删掉什么东西，确认操作不能和删除操作放在同一个位置。

例如，在提醒事项 app 中，在删除一个列表时，当我点击删除操作时，一个 action sheet 会出现在屏幕底部让我二次确认是否真的要删除，我必须移动我的手指到屏幕下面以确认删除或者取消。这个操作所花费的时间和努力是值得的。

对于在菜单以外的破坏性操作，仍然推荐在 iPhone 上使用 action sheet，在 iPad 上使用 popover 来完成二次确认。比如在邮件 app 中，当你在写邮件的页面上点击左上角的取消按钮时，它就会问你是想要保存草稿还是删除草稿。在这里没有使用菜单样式，因为菜单样式会更容易误删掉草稿，而 action sheet 和 popover 可以让你的手指移动幅度更大，以防止误删草稿。所以 action sheet 这种样式并不是不再使用、可以废弃了。

所有在菜单上的这些改进都基于一直以来菜单是如何在 Mac 上如何工作的进行设计的，你可以看到你能够在相似的场景中使用这些菜单。例如消除歧义、导航。这会让你的 app 更容易从 iPad 平台转换到 Mac 平台上去。

小结

小结一下新的菜单样式：

它一部分代替了 iPhone 的 action sheet 和 iPad 的 popover；
菜单的使用场景：
- 消除歧义：通过菜单进一步向用户确认操作目的以消除歧义；
- 导航：通过菜单给出一个可以前往的页面列表来完成导航；
- 选择：通过菜单给出一个选择列表来完成选择；
- 显示次要操作：通过一个显示更多按钮或者点击并按住的操作来显示一个包含了一些二级操作的菜单；
破坏性操作需要二次确认，可以通过 action sheet 或者 popover 实现；
新的菜单样式会让你更容易把你的 app 从 iPad 带到 Mac 上去。

日期和时间选择器

以前的日期和时间选择器是下图这样的，它由多个拨轮组成，你可以调整每个拨轮以选择一个日期或者一个时间。

从 iOS 14 开始，新的日期和时间选择器变成了下图这样，包括单独的日期选择器、单独的时间选择器、日期和时间组合在一起的选择器。

让我们来具体看看它们是如何工作的。提醒事项是一个可以告诉你如何使用新的日期和时间选择器的好例子。例如，我为某个提醒事项添加一个提醒日期，你就可以看到新的日期选择器会显示出来。每一天、每一周、每一月的展示更加清晰，你可以通过左划或者右划在不同的月份之间切换，也可以通过点击某个月份/年份来更快速地选择月份和年份。

提醒事项也可以让你选择一个特定的提醒时间，在需要填写时间时，你可以看到新的时间选择器会显示出来。不再是使用拨轮，现在可以通过直接键盘输入确定时间。

不论是使用什么输入方式：触摸、Apple Pencil、键盘或者光标，新的设计让人们更容易选择日期和时间。

在 iOS 14 Beta 版本中使用了新的日期和时间选择器之后，许多用户对此发出了反对的声音，特别是对于用户经常用到的闹钟中的时间选择器，虽然键盘输入时间看似更加直观方便，但相比以前的拨轮效率提升并不大，反而失去了触控、声音、触感三者结合在一起的操作愉悦感。
在 iOS 14 Beta 5 版本中，Apple 似乎做出了「妥协」，在现有键盘输入时间的操作方式上增加了以拨轮的形式滚动选择时间的操作方式，用户可以根据自己的使用习惯选择不同的交互方式。

但新的拨轮可交互区域仅仅只有时间显示的一小块区域，操作十分受限，准确度因此也不高，或许 Apple 还是倾向于让用户使用新的键盘输入交互方式。虽然这种方式改变了用户多年以来的使用习惯，但功能上并没有打折扣，而且在使用鼠标、触控板时也更加友好，同时还与 macOS 中的时间输入交互保持基本一致，更有利于 app 转换到 Mac 平台上。

期待一下 iOS 14 正式版本中这个小小交互的最终模样。

新的日期和时间选择器可以直接插入到界面之中，就像是上面的提醒事项所展示的一样。但有时候会有一些特殊情况，在 iOS 14 中你可以通过一种更紧凑的方式展示日期和时间选择器。当你在紧凑模式下向 UIKit 请求显示一个日期选择器时，你可以获得下面这样一个按钮，它会用 app 的主颜色和一个面板效果显示一个日期，点击按钮会以模态形式展示一个新的日期选择器。

单独的时间选择器或者日期和时间混合在一起的时间选择器也是类似这样。

这种模式通常更适合不能直接在视图内显示日期和时间选择器的情况。例如，当我在通讯录中添加某个联系人的生日时，点击按钮会展示新的日期选择器，我可以根据自己的需要自由修改日期，选择好后点击外部区域以完成确认。

新的日期和时间选择器同样遵从系统的辅助功能设置。例如下图中的更大字体示例。

新的设计也统一了 iPad 和 Mac 上日期和时间选择器的样式，它们有着相同的信息，可以让 iPad app 更好地转换到 Mac 上。

小结一下：

改善了日期和时间选择器，有了更好地展示方法；
可以在视图之内使用，也可以使用新的紧凑模式；
因为在两个平台上具备相同的信息，所以可以更好地从 iPad 转换到 Mac 上去。

颜色选择器

iOS 14 提供了一个新的颜色选择器供你使用。你可以使用四种不同的方式选择一个颜色：网格、光谱、直接输入 RGB 色值或者从屏幕中取色。

你从屏幕中吸取的颜色总会是会显示在左下角，你可以把颜色保存到色盘上，这样就可以在其他 app 中使用了。

新的颜色选择器是让你选择你想要使用的颜色的好方式。例如，当我在 iPad 上使用 Apple Pencil 时，通过颜色选择器我就可以方便地选择我想要的颜色。

新的设计也将 iPad 和 Mac 选择颜色的样式统一，你可以更方便地把 app 从 iPad 转换到 Mac 上去。

小结一下：

颜色选择器是 iOS 14 开始出现的新的组件；
你可以通过四种方式选择你想要使用的颜色；
色盘中的颜色可以跨 app 使用；
新的颜色选择器可以帮助你的 app 从 iPad 转换到 Mac 上去。

参考链接

利用好 iPad 的大屏幕 —— 如何为 iPadOS 14 设计 app？

2020-07-09T20:15:49+08:00

利用自动布局、Mac Catalyst、全终端统一购买等技术，许多 app 可以扩展到更多设备和平台。人们可以有更多机会在所有他们喜欢的设备中选择一个最适合的去使用他们喜欢的 app。对于设计师和开发者来说，这意味着我们需要聚焦于每个平台最适合什么，进一步在每个设备和每个平台上创造更好的体验。

一方面，在 Mac 上，你可以利用 Mac 巨大的屏幕，它有着最精确的输入方法，macOS app 支持所有的那些高级的使用实例和功能，让每一个人都可以用上它。

另一方面，在 iPhone 上，iPhone app 可以让你通过多点触控快速、简单地随时随地地访问那些最重要的功能。对于这两者来说，你的 app 的设计方向应该都十分明确。

但对于 iPad 来说呢？因为 iPad 处于两者之间，但并不意味着它的使用场景只处于两者之间。一个好的 iPad app 的目标应该有它的独特之处，这也是这篇文章想要讲的。

在这篇文章中会首先讲下在 iPadOS 14 中的 app 中应用的一些设计准则，接着会讲一讲怎么把这些设计准则应用到你的 app 中。

Layout 布局

作为 iPad 最突出的一点就是它有一块大屏幕。在你设计一个 iPad app 时，你的第一步就应该是利用好这块大屏幕来展示你的内容和用户界面。
下面通过 iPadOS 14 原生 app 的几个实例来具体看下你该如何实现这一点。

扁平化 app 导航

避免为了更新屏幕上的一部分内容而出现大的全屏幕的过渡。下图是 iOS 13 中的「照片」app，你可以选择一个相册或者一个媒体类型（如人像），接着它就会滑动过渡到你选择的具体内容并以全屏展示。这是简单的、熟悉的，而且这个逻辑在 iPhone 上运转良好。

在 iPad 上也有着相似的导航结构，但是在屏幕右侧有大块的屏幕空间没有被利用起来。

所有在 iPadOS 14 中，「照片」app 增加了边栏来作为导航，不再有大块的没有被利用的空白空间，右侧的照片内容可以充满整个屏幕，左侧的边栏也能发挥它的功能。

这种显示结构也带来了另外一个好处。如果你想在 app 中的不同部分切换，去往不同的相册，查看不同的照片，现在只需要点击一下就可以了。
同时这个结构也会让拖放操作更加容易，因为你要放置的目标，也即你想放置照片的相册，在屏幕上总是可见的。

展示更多的内容

这是一个很简单的道理，你在 iPad 上获得了一块更大的屏幕，所以为了填满它你需要更多的内容。回到 iOS 12，下图是 iPad 主屏幕的样子，你可以看到所有的图标之间的距离是很远的，它们在空间上是稀疏的。

在 iPadOS 13 中，多增加了一行一列的图标。而现在在 iPadOS 14 中，进一步增加了新的小组件。现在图标还是很大，但是你可以一次性看到更多，它更好地利用了整个屏幕空间。

再来看另外一个例子。下图是 iPadOS 13 中的「文件」app。文件充满了整个屏幕，看上去已经没有空白空间可以增加更多了。但是它一次性只展示了 12 个图标，它可以变得更好。

在 iPadOS 14 中，「文件」app 中的图标变得更小了，但仍然足够大到看得清、容易点击，所以整个 app 仍然是可用的。这是一个通过对可用屏幕空间更好地利用，从而轻微地改变内容密度来让整个 app 变得更加有效率、更加强大的一个好的示例。现在「文件」app 可以展示原来的三倍数量的图标。

只要保证你的文本是清晰可读的，你就应该看看有没有更好的办法在你的 app 中展示更多的内容。

添加更多上下文关系

在 iPhone app 中，你总是聚焦于一个特定的事情，因为在这样一个小屏幕上只有那么一点空间去展示内容。但是在 iPad 上，你可以获得更多的空间用来一次性展示更多的内容。
下图是在 iPadOS 13 中当你在「文件」app 中重命名一个文件时的样子，除了能看到重命名的文件你看不到其他东西，但这也意味着你丢失了有关于其他文件的上下文关系。

在 iPadOS 14 中，为了保持上下文关系，即使你在重命名一个文件时，屏幕上的其他内容也是可用的。你可以使用文件夹的其他文件的名称来作为重命名文件的参考。

所以像「文件」app 一样，检查你的 app 中有遮罩或者遮挡了屏幕上其他部分内容的地方，看看能否保持上下文关系可见，这会让你的 app 更加轻量化、更加强大。

另一个例子是弹出框（popover），当你要展示一个东西来自于哪里的上下文关系时，弹出框很有用。例如，当你在日历中查看或者编辑某个特定的日程时，弹出框的箭头可以帮助你知道那个日程来自于哪一天。

进一步来看下 iPadOS 13 中的日历弹出框，这个弹出框的箭头只是指向了一个叫「日历」的按钮，它没有给出任何的有用的上下文关系。

所以在 iPadOS 14 中，日历菜单被移动到和日历日程同一层级，现在你可以在查看日历日程或者与日历日程发生交互的同时，改变不同日历的可见性，结果会马上显示在屏幕右侧。

仔细审查你的 app，看看是否有任何的弹出框或者模态菜单，看看它们是否给人们有用的上下文关系，是否挡住你的 app 的其他内容，尝试着让那些控件在同一层级而不是相互遮盖会不会变得更好。如果你的 app 需要同时在 macOS 上运行，更要避免使用模态窗口，因为 Mac 拥有更大的屏幕和最大的窗口，所以在 macOS 上模态 UI 比在 iPadOS 上使用得更少了。

另一方面，在像 iPhone 上这样的紧凑型设备上，你可能没有足够的空间一次性展示多个东西，你不应该勉强这样做，你不应该把多个部分的 UI 压缩到一个屏幕上。当你没有足够空间在同一个层级上展示每一件东西时，模态仍然是一个聚焦在一个特定部分内容的好的选择。

沉浸于内容任务中

有时候，iPad 最神奇的体验来自于屏幕不只是一块玻璃时，整个设备会变成内容的一部分，比如在「图片」app 中翻动书页或者在「Apple TV」app 中观看视频，亦或是在「备忘录」app 中使用 Apple Pencil 涂涂画画。
在「照片」app 中，当你深入编辑一张照片时，它使用了一种为 iPad 特别设计的自定义的沉浸式布局。你可以看到所有的控件在屏幕的左侧或右侧对齐，这样当你手持 iPad 时可以方便地用两手使用它们。在大屏幕上，你会看到照片的呈现是赏心悦目的，编辑控件不会盖住你的照片。

来看另一个例子，在 iPadOS 14 的「音乐」app 中，正在播放界面占据了整个屏幕，这样你可以完全聚焦于正在播放的音乐和歌词。与 Mac 相比较，这种聚焦于一个特定部分内容的能力对于 iPad 来说是独一无二的、特别的。软件可以让硬件本身几乎消失，就像变成内容的一部分。

Inputs 输入

iPad 是一个触控优先的设备，但是从一开始，iPad 就支持多种输入方式。最开始支持键盘，到现在支持 Apple Pencil 和触控板。最好的 iPad app 是支持所有的这些输入方式，让每种输入方式做自己最擅长的事情。

当然，你应该从多点触控开始。在 iPadOS 中的每一个东西都被设计成易于点击或者可以通过快速流畅的手势进行操作。你的 iPad app 应该总是支持这些触控交互方式。即使你打算支持其他的输入方式，但你仍需要确保你的 app 在触控体验上是极好的。

在支持多点触控之后的下一步就是利用 iPadOS 的内建功能支持其他的输入方式。对于使用妙控键盘或者其他键盘的用户来说，你应该在 app 中确保所有的指令都被添加了键盘快捷方式。很多人喜欢使用键盘快捷方式，如果你的 app 有这些快捷方式，用户会很喜欢，但这些快捷方式不会阻碍其他用户的使用。
如果你把你的 app 通过 Mac Catalyst 带到 Mac 上去，所有的这些键盘快捷方式都可以被转换到 Mac 上，这对于用户使用很方便。

除了键盘，现在 iPad 还支持了触控板。大多数的触控板支持都是自动的，因为在 iPadOS 中所有的内建控件都已经支持触控板操作。

你也可以把指针系统延伸到任何你添加的自定义控件上或者自定义交互上。有关于 iPadOS 的指针系统，可参考《 iPadOS 指针系统的设计规范 iPadOS Pointing System Design Guideline》。

你也应该支持 Apple Pencil 的随手写（Scribble）功能，像指针支持一样，当你使用系统的文本输入控件时，你将会自动获得随手写功能的支持。但是如果你有自定义的控件，你应该确保支持随手写功能，因为人们期望在整个设备上的所有 app 中都能使用随手写功能。

这就是使用 iPadOS 上各种输入方式的所有内建功能。有一点值得特别提及的是，各种输入方式可以同时工作，你可以在 iPad 上把多种输入方式组合在一起成为一个交互，这可能会创造很多之前没有存在过的交互方式。

例如将键盘和触控组合在一起。在 Safari 中，你可以通过在键盘上按着 command 键时在屏幕上点击链接，从而在新标签中打开网页；按着 Option 键时在屏幕上点击链接，从而下载一个文件；按着 Ctrl 键时点击链接，从而获取更多操作选项。

在你的 app 中，你也应该支持将多种输入方式组合在一起使用。你可以支持哪些标准的系统行为，例如按住 Option 键时拖动元素实现复制或者按住 Shift 键时点击元素实现选择一组元素。

将 Apple Pencil 和触控组合在一起也是一种方案。在「Loom」app 中，它将 Apple Pencil 和触控组合在一起以更快地画出框架。在左边，你可以通过触控使用转盘来选择哪一个框架是你需要绘制的；在右边，可以使用 Apple Pencil 绘制实际的动画框架，这样就可以大幅提高工作效率。

这就是可以让你的输入更加强大的一些方法。

还有最后一点，为了让你的 app 变得更加快速，一个核心方法就是让你的 app 始终保持响应。无论屏幕上发生了什么，动画、过渡或者是任何进程，它应该对于各种输入总是可响应的。

这里有一个例子，iPadOS 14 的下拉菜单在展开过程中，你就可以通过一个点击选择某个操作。如果需要等到菜单完全展开才能操作，那就会感到 app 运行很缓慢，像是 app 跟不上你的思考速度一样。

另一个例子是在之前当你展开一个下拉菜单时，点击菜单外面的区域你只可以关闭它，你不能把手势传递到菜单下面的内容。而在 iPadOS 14 中，在展开下拉菜单时，你可以在做出滚动底部内容的手势时，同时关闭菜单并开始滚动内容，app 一直处于时刻保持可响应的状态。

这些微小的交互很微不足道，但是当你真正用到的时候，会发现它们很加分。人们会发现无论在什么情境下，iPad 都会时刻响应用户的各种输入方式，这会增强用户的信心。人们有时候会抱怨动画过渡太慢，时间过长，需要等它们完成才能继续操作。如果你的 app 是时刻保持响应的，用户可以随时与 app 发生交互，那这些动画就可以帮助人们获取情境关系而不是阻挡用户操作。

Sidebars 边栏

系统 app 中边栏的应用

为了优化 iPad 的布局，在 iPadOS 14 中的一个核心功能就是边栏（sidebar）。来看几个系统 app 的示例。
下图是 iPadOS 13 中的「家庭」app，你可以看到在标签栏（tab bar）中有许多空余的水平空间，这没能充分利用好 iPad 这块屏幕。导航到一个特定的房间需要更多的步骤。你需要点击「房间」标签，然后打开房间的弹出框，找到你要找的房间，点击并切换过去。这在当你在黑暗中想打开一盏灯时显得格外繁琐。

现在在 iPadOS 14 中，使用边栏替代了标签栏，这样更好地利用了大屏幕，你通过简单的单次点击就可以进入任何你想查看的房间，你还可以通过简单地拖放重新排列房间。

在「音乐」app 中也添加了边栏，它为前往整个音乐资料库的各个部分提供了更快速的导航。

在「文件」app 中的边栏让导航和自定义变得比以前更加简单。新的边栏支持编辑模式，让展示、隐藏、重新排序内容变得更加简单。你也可以简单地通过拖放动作将重要的内容在边栏创建一个快捷方式，人们可以按照自己的需要调整边栏上的内容。边栏甚至支持收起展开文件夹，你通过一个手指就能重新排列内容。

「照片」app 中也增加了边栏，让导航变得更加简单和快速。内容放置在一个可折叠的群组中，你可以把媒体类型群组折叠以快速访问下面的相册。

如果你点击边栏顶部的开关按钮，边栏就可以收起来，让你的照片充满整个屏幕。

要想再让边栏出现，可以从屏幕左侧轻扫，这样就可以让边栏以遮罩的形式出现，你可以随时在需要的时候召唤出边栏，在需要与内容发生交互时，边栏又会自动隐藏，你可以专注于照片本身。

当然，你也可以通过点击边栏开关按钮让边栏重新出现，而不自动隐藏。

当在竖屏使用情景时，边栏会自动切换为遮罩模式，这是为了确保你的内容在水平方向有足够的展示空间，同样地，你可以通过点击边栏开关按钮或者从屏幕左侧轻扫重新唤出边栏。

在 iPad 的多任务模式下也是类似的模式。例如在分屏视图中没有足够的空间显示边栏和你的内容，边栏就会切换成遮罩模式。

来看一下「邮件」app，iPad 上的「邮件」app 的一个特别之处就是它支持三列布局，这对于将邮箱和邮件的层级视觉化非常有帮助。在 iPadOS 13 中，三列的布局只在最大的 iPad Pro 上是可用的，更小的 iPad 被限制为只能展示两列布局。在 iPadOS 14 中发生了变化，所有的 iPad 都可以显示三列的布局，在屏幕左侧轻扫就可以让第三列显示出来，你可以同时查看邮箱、邮件列表和邮件内容。一旦你处理完边栏上的任务，布局会自动收回两列的布局以为内容腾出空间。

当边栏以遮罩样式出现时，三栏的布局也可以正常显示。从屏幕左侧轻扫显示边栏，如果你需要第三列的内容，继续向右轻扫，这样两个并排的边栏就会以遮罩样式显示在内容上面。现在所有运行 iPadOS 14 的 iPad 都可以使用这种样式。

在 iPadOS 上创建的边栏会在 macOS 上被转换为 mac 样式的边栏，所以对于 Catalyst app 来说，边栏也是创建导航结构的好方法。

总结一下 iPadOS 14 的新的边栏功能：

它优化了 iPad 的布局；
它支持模态编辑和非模态编辑，用户可以快速导航到对于他们最重要的地方；
它支持多窗口或者多 app 之间的拖放操作；
它的内容可以以可折叠的群组形式呈现；
它可以以遮罩形式展示，这样就不会与其他内容抢占空间；
可以通过流畅的轻扫手势让其出现和隐藏，快速简单；
把三列布局的优势带到了所有的 iPad 上。

Split View 分栏视图设计规范

iPadOS 14 的边栏是由之前的 Split View 分栏视图演化而来，先来看下分栏视图的设计规范。

Split View 分栏视图管理着你的 app 中的首要层级的内容层级展示。分栏视图包括了一个两列或三列的界面，展示了一个主要列（primary column）、一个可选的补充列（supplementary column）和一个二级的内容面板（content pane）。在主要列中的变化会驱动可选列中的内容变化，进而影响展示的内容。分栏视图对于在多个内容层级之间进行导航非常有用，像是在邮件中为了浏览每封邮件需要在邮箱和邮件中来回穿行。

分栏视图可以展示不同的内容，但是许多系统 app 使用一个分栏视图创建了一个基于边栏的界面。在这种类型的界面中，主要列展示了一个边栏，可选的补充列展示了一个列表视图，二级内容面板展示选择内容的详细细节。

在 iPad 上，使用分栏视图而不是标签栏（tab bar）：分栏视图提供了和标签栏相同的快速导航功能，但可以更好地利用好更大的显示屏。
为每个列的类型选择合适的样式：主要列展示边栏时，则使用边栏的外观样式。这个外观对于 app 的层级导航和展示一系列内容列表都是合适的，比如邮件 app 中的邮箱。补充列展示列表视图时，使用普通（plain）的边栏外观样式。这个外观对于展示独立的内容列表是合适的，像是邮箱中的邮件。具体开发指导可参见「UICollectionLayoutListConfiguration.Appearance」。
在主要列和补充列中，始终高亮活跃的选中部分：虽然二级内容面板会变化，但它应该总是与其他列中的清晰可识别的选中内容相关联。这个选中内容可以帮助人们理解列与列之间的关系，确定前后文关系。
如果合适的话，允许人们在列与列之间拖放内容：因为分栏视图提供了对多个内容层级的访问，人们可以通过在列与列之间拖拽和释放条目，快速地将其从 app 中的一部分内容移动到另一部分

具体开发指导可参见「 UISplitViewController 」。

Sidebar 边栏设计规范

Sidebar 边栏为 app 提供了层级导航，可以让用户快速访问你的 app 中的首要层级的一系列内容。在边栏中选择一个条目可以让人们导航到一个特定部分的内容中去。例如，在邮件 app 中的边栏展示了一个所有邮箱的列表，人们可以选择一个邮箱访问邮件列表，选择一封特定的邮件在内容面板展示内容。

你通过使用一个边栏样式的列表创建一个边栏，并把它放在一个 Split View 分栏视图中的主要列。

在一个边栏上应用正确的外观：为了创建一个边栏，使用一个 collection view 列表中的边栏外观布局，具体开发指导可参见「UICollectionLayoutListConfiguration.Appearance」
使用一个边栏组织 app 的层级信息：边栏是一个扁平化信息层级和同时提供对几个相同层级的信息分类的访问的好方法。使用一个边栏快速导航到 app 的核心部分或者首要层级的内容（如文件夹和播放列表）。
任何可能的时候，让人们自定义一个边栏的内容：因为一个边栏为你的 app 提供了导航，你可以使用它为人们提供了快速访问他们关心的内容的快捷方式。让用户来决定哪些条目是最重要的才是最好的。
不要阻止人们隐藏边栏：允许人们隐藏边栏以为内容创建更多的空间，可以通过内建的边缘滑动手势再次显示边栏。避免默认情况下隐藏边栏。
保持边栏中的标题清晰准确：删除不必要的和冗余的词语。例如，在邮件 app 中就没有在每个邮箱的标题中出现「邮件」字样，而是使用了更准确的术语，比如「有旗标」、「草稿」。
通常情况下，避免在一个边栏中展示超过两个层级之外的内容：当数据层级超过两级时，应该在分栏视图的补充列中使用一个列表视图。

具体开发指导可参见「UICollectionLayoutListConfiguration」。

在你的 app 中添加边栏

有两种样式的 app 导航非常适合边栏：扁平型和层级型。
扁平型导航使用了一个扁平的结构，第一层级的不同部分的内容具有差不多的比重，你通常会使用标签栏在不同部分间导航，像是「照片」、「音乐」这种 app。

层级型导航在需要对内容进行组织和在不同层级之间的内容来回横穿的 app 中更加普遍，像是「邮件」、「备忘录」这种 app。

除非你的 app 是沉浸型 app 比如游戏，否则一般都可以归类为这两种导航样式，这两种都可以添加新的边栏。我们可以从已经有 tab bar 的app 说起。Tab bar 是让导航变得简单的最有用的工具之一，当你看到 tab bar 时，你能马上知道自己在哪，可以去往哪里。使用 iPad 和 iPhone 的用户也很熟悉 tab bar，所以对于用户来说也没有什么学习成本，它可以清晰地传达出 app 最重要的几个部分。所以无论你的 app 多么复杂，tab 都可以让你的 app 结构容易理解。

所以在考虑引入一个边栏时，可以考虑把原有的几个 tab 放在边栏的最顶端。

边栏可以作为 tab bar 的等价物，但不要完全在 iPad 上放弃 tab bar。边栏仅适用于 regular 宽度的布局，在 compact 宽度的布局下应该仍然使用 tab bar。

确保在边栏和 tab bar 中有相同的第一层级的条目，这会让你的 app 不管在什么尺寸等级下都可以保持熟悉。

接下来再来考虑还要在边栏中添加什么。考虑下你的 app 的所有内容，我们发现最适合放在边栏上的内容是那些比较长的内容列表，特别是那些用户自己生成的，像是「照片」中的相册或者「音乐」的播放列表，把这些放在你的主要导航部分的下面。

在向边栏添加这些内容时，把它们组织在一个可折叠的群组下面，这可以在第一层级的内容和下面的内容之间保持正确的层级关系。即使是通过两种方式到达相同的内容也没有关系，比如通过一个顶级导航和通过一个下面的文件夹到达同一部分。
你可以选择继续添加额外的其他内容，但是不要在边栏上铺开整个 app。如果边栏变得超载，需要很多滚动和多次展开才能找到东西，那就失去了本身作为快速跳转的目的。

如果你的边栏的内容是用户可配置的，添加一个「添加」按钮，把它放到每一个可配置部分的底部。这可以让人们在他们使用内容的相同地方创建自定义的内容。

如果你的 app 的导航更类似于层级型导航，把顶级层级的内容摊开放在边栏的顶端，就像是「邮件」app 那样会有多个邮箱显示在边栏中。在下面可以添加你的 app 中最重要的部分的快捷方式。
记住边栏不适合浏览很深的、网状的层级结构，内容的整个层级不应该被全部放在边栏上。

总结一下如何在你的 app 中加入边栏：

不要在 compact 宽度的尺寸等级下使用边栏，在这种情况下，边栏应该被转换为 tab bar 或者标准表单样式；
不要在同一个界面混用边栏和 tab abr，边栏和 tab bar 是同一种内容的两种不同展现形式，混用会创造一种令人困惑的导航结构；
不要把整个 app 都摊开在边栏上；
在边栏的顶端放上最重要的导航部分；
在 compact 宽度时，把边栏转换成 tab bar；
建议在边栏上使用轮廓型图形，在 tab bar 上使用填充型图形；
考虑在边栏上添加额外的内容，确保那些内容对于用户来说是重要的，并把它们放置在一级导航模块下面，列表样式的内容和用户生成的内容都是好的选择；
把同一层级的内容放在一个可折叠的群组中；
支持编辑模式，用户可以根据需要自定义边栏；
确保支持拖放功能，用户会希望把东西拖放到边栏上的文件夹，也希望把内容拖放到边栏上以创建快捷方式。

Toolbar 工具栏

在 iPadOS 14 中，另一个更好地为了利用 iPad 空间的改进是工具栏。在 iPadOS 13 中的工具栏占据了更多的空间，像前面提到的 tab bar 一样，工具栏也没有充分利用好空间。

所以在 iPadOS 14 中，一些工具栏控件被移动到了顶部，一般最多有三个。

当没有足够的空间，比如 compact 宽度时，这些工具栏控件仍然会保持在底部。

总结

根据 iPad 的特性，有针对性地设计 iPad app；
扁平化 app 的层级结构，让内容充满整个屏幕，以展示更多的内容，给用户更多的上下文关系；
支持 iPad 的所有输入方式：触控板、键盘、Apple Pencil 和多点触控，让它们协同配合，创造绝佳的交互；
使用边栏实现更快速地导航，在边栏中包含 app 中重要级别的层级；
把重要操作和控件从底部的工具栏上移动到顶部的导航栏上以利用好 iPad 的大屏幕。

参考链接

在 App 中提供出色的无障碍使用体验

2020-05-25T18:48:23+08:00

2020 年 5 月 21 日是第 9 个全球无障碍宣传日。无障碍使用也是 Apple 产品设计时的目标之一，我们倾向于认为无障碍功能的意义就是让每个人都能使用科技，正如 Apple 所说「让每一个人受益的科技，才是真正强大的科技。」

在 Apple，无障碍技术分成值得关注的四个部分：认知、动作、视觉、听觉。Apple 提供了一系列的功能去解决所有这些部分的问题，但总而言之，是你所做的工作和 Apple 提供的辅助功能技术让我们为残障人士建立的平台变得出色。

让你为之工作的所有好内容对于每个人都是可用的，这为我们创造了一个更好、更包容的社区，改善了全世界成千上万用户们的生活。

这篇文章会跳过无障碍功能的一些基本介绍，可以查看其它有关辅助功能的文章：

首先来看一个词「可用」，「可用」很好，确保让你的 app 的所有内容对于辅助功能技术都是可见的，这是关键的第一步。但是我们不只是想让我们的 app 可用，没有人会到处吹嘘自己的 app 是可用的，我们想让我们的 app 是出色的，我们想让使用 app 的人感到愉悦。那么当谈到「出色」时，这对于无障碍功能又具体意味着什么呢？这就是这篇文章想要讲的，希望能提供给你一些有帮助的指导建议。

文章聚焦于两个部分，一部分是视觉设计，另一部分是辅助功能技术使用体验，针对于这两个部分讲一讲你需要具体考虑些什么。

视觉设计

透明和模糊

我们在 iOS 系统的许多地方使用透明和模糊效果，它可以为我们的操作系统创造一种鲜活的、独特的感觉。
但是对于一些人来说，特别是那些视力不好的人，模糊和透明效果可能会在可读性上造成不好的结果，甚至是造成一定的眼部压力。

所以我们提供了一个辅助功能设置用来减少透明和模糊效果。像下图这样，不是去模糊背景，而是使其变暗，这样你仍然知道你处在系统的什么场景中，但是视觉噪声却减少了。而对于控件，以前是会有背景颜色透进来，而现在是固定的背景色，可读性更高了。

对于主屏幕 app 文件夹和聚焦页面也是一样的处理方式。这是一个好的示例，因为我们从用户的壁纸中取得一个样本然后给背景上色，用户仍然能感受到设备的个性化和情景化，但同时通过固定背景增强了对比度和可读性。

作为一名开发者，你可以通过检查减少透明度设置是否开启来控制透明和模糊效果的使用、调整你的 UI。在 iOS 和 macOS 上你可以通过下面的代码来作判断：

// Transparency and Blurring 

// iOS 
extension UIAccessibility { 
	public static var isReduceTransparencyEnabled: Bool { get } 
} 

// macOS 
extension NSWorkspace { 
	open var accessibilityDisplayShouldReduceTransparency: Bool { get } 
}

对比度

当谈到感知能力时，内容和内容背景的对比度十分重要。一个颜色越接近另一个颜色，它们就越难辨认。

某种颜色在较大尺寸时是可读的，但当内容变小时就不行了。例如对于文本来说，字号越小字母看起来越容易混在一起。

我们推荐你遵从网页内容无障碍规范中所说的最小对比度 4.5:1 的要求。

当然，你能够获得的最高对比度就是黑色和白色之间，大约是 21:1，这对于所有的文本尺寸都是合适的。

再来看一些灰色与黑色的对比度情况。下图中的灰色在文本较大时是合适的，但在文本比较小时就不合适了，因为你的眼睛无法辨别出字母的形状，4.5:1 的对比度对于看得清来说算是刚刚及格。

下图中的灰色与背景黑色的对比度只有 2.9:1，在一个小屏设备上，即使字体尺寸很大，你也会遇到看不清的情况，这个对比度太低了。

你可以使用 Xcode 中在辅助功能查看器（accessibility inspector）里内置的工具去查看颜色组合之间的对比度以及特定的文本尺寸下这个对比度是否合适。使用的规范就是上面提到的。

然而，即使对比度大于 4.5:1，对于那些视力条件不好的人来说，当颜色出现在各种 bar 上时，可读性对他们来说仍然存在问题。所以我们提供了一个全局的「增强对比度」设置选项。在以前版本的 iOS 中，这个设置项被称为「加深颜色」。在 iOS 和 macOS 上你可以通过下面的代码来作判断：

// Increase Contrast (Darken Colors) 

// iOS 
extension UIAccessibility { 
	public static var isDarkerSystemColorsEnabled: Bool { get } 
} 

// macOS 
extension NSWorkspace { 
	open var accessibilityDisplayShouldIncreaseContrast: Bool { get } 
}

如果你使用了标准的 UIKit 控件并开启了 tint color，这些配置就可以自动完成。

尺寸

改变设备上的内容尺寸会对内容展示和被感知的方式产生巨大的影响。对于低视力用户来说，这是很有帮助的。
下面以「日历」app 说明。下图中左边的是默认字体尺寸，右边的是某一种更大的辅助功能尺寸。

如果我们模拟下一个低视力的人实际看到的情况，增大尺寸所能获得的好处就可以立马显现出来，右边的文本仍然是可读的。

在 iOS 中，你可以检查确认用户设定的设备字体尺寸是什么，这里有七种标准的字体尺寸，默认为「大 large」。你还可以开启「更大的辅助功能字体」，再获得五种更大的字体尺寸。

字体大小问题解决了，但是有可能默认的字体字重和图形粗度也会造成阅读困难。所以在 iOS 中，你可以开启「粗体文本」设置选项。

如果你使用了标准的 UIKit 控件和系统字体，你不需要做什么就可以获得这项特性的支持，但如果你使用了你自己的文本解决方案或者自定义字体，亦或是你只是想在系统的粗体文本设置选项开启时让 app 中的分隔线更粗一点，你可以检查确认这个设置项是否被开启，从而进行必要的调整。

// Bold Text 

extension UIAccessibility { 
	public static var isBoldTextEnabled: Bool { get }
}

动效

动画是有趣的，它总是可以让内容变得生动活泼，它可以在用户的交互和他们动作带来的效果之间提供一个直接的关联。然而，某些条件下，特别是那些会影响大脑中枢平衡的耳内条件可能会使运动和动画产生问题，会造成诸如眩晕或者不平衡甚至恶心这样的问题。

注：由于动效的示例需要动态动画展示，目前暂以静态画面代替，可根据文字描述在手机上操作查看示例展示的情况。

下面是几个动画的示例。第一个是缩放和放大动画。在下图中的左边，默认情况下，在打开一个时钟 app 时，我们会放大 app icon，时钟 app 的 UI 同时放大；在右边，当开启「减弱动态效果」时，打开 app 的动效就会变成简单的交叉淡入淡出效果。

第二个是快速转动和旋转效果。来看一下信息 app 发送信息时的全屏回声效果，可以看到内容是沿着 Z 轴转动同时改变大小，这些类型的动效组合在一起可能就会造成问题。如果开启了「减弱动态效果」，就会给用户提供一个提示以让用户主动选择去播放这些信息效果，而不是自动播放。

第三个是平面转换动画。当在 Safari 中点击显示所有标签页按钮时，你可以看到网页卡片的平面转换成了一个模拟的 3D 空间。而当减弱动态效果开启时，这个动画就会变成一个简单的淡入淡出动画，并且会闪烁一下你的当前页面的那个卡片，以让你知道你是从哪里来的。

第四个是不同方向和不同速度的动画。在信息中，当滚动信息列表时，每一个信息气泡之间会有弹性，如果开启了「减弱动态效果」，上面说的这个效果就没有了，会变成普通的滚动。

最后一个是外围移动效果。iOS 中的天气 app 在背景中会有微弱的动效以表明当前的天气条件。在下图的左边，你可以看到云彩在慢慢的移动，日光闪闪。但是如果你滚动到下面的天气详细信息，这些动画就会变成外围动画，这在某些情况下是有问题的，例如开车时查看天气预报，你会感到恶心。你的聚焦区域的上方如果出现水平运动会触发大脑的一些反应。当开启「减弱动态效果」时，我们会把背景动画效果关闭。

通常情况下，我们不想要你只是简单地移除所有的动画，简单地移除一个动画并不总是一个很好的体验，你不想让用户体验打折扣，你可以只是采用一些虽然不同但同样有趣或者吸引人的适合用户的方案。我们也有一个设置让你去检查确认动画是否应该被减少并根据需要做出调整。在 iOS 和 macOS 上你可以通过下面的代码来作判断：

// Motion

// iOS 
extension UIAccessibility { 
	public static var isReduceMotionEnabled: Bool { get } 
} 

// macOS 
extension NSWorkspace { 
	open var accessibilityDisplayShouldReduceMotion: Bool { get } 
}

复杂度

App 在我们的生活中扮演着重要角色，科技是简单的和容易使用的，科技应该增强了我们的生活而不是增加额外的不必要的负担，这对我们十分重要。只在美国，每六个孩子就有一个发育障碍，从言语障碍到更严重的像是自闭症这样的发育障碍。

对于有认知障碍甚至是有慢性疾病的人来说，使用一个 app 需要比正常人花费更多的精力，所以我们如何确保我们的 app 是简单的、最小负担的呢？

App 应该是容易导航的，它们具有相似的结构和清晰的、有逻辑的因果关系。
我们应该能够在没有遇到任何障碍的前提下，快速开始使用我们的 app，完成最普遍的任务。
我们的 app 应该有一致的行为，这样当我在一个地方学习到了什么时，就可以运用到其他地方。

使用标准的 UIKit 界面就很好，因为人们熟悉这些系统界面和控件的工作方式，UIKit 也是 iOS 的设计语言。所以如果你设计了一些自定义的东西，与 UIKit 中的类似控件的行为保持一致将会帮助人们从直觉上知道如何使用你的 app。

这些都可以归结为人们体验你的 app 的方式，它们对于使用辅助技术（如旁白或者切换控制）的人们同样重要。

辅助功能技术使用体验

使用辅助技术的体验会和普通用户的使用体验有很大不同。旁白使用非常多的手势（如滑动、多指点击），切换控制扫描不同的项目，提供合理的、快速的操作。

对于这两者都有与任何标准手势或者交互相等价的内建操作，但是怎样让使用这些技术的 app 的用户体验变得出色？我们想让基础的工作变得出色，尽管这些辅助技术的用户体验你的 app 的方式是完全不同的，但是给非辅助功能用户创造好的体验的相同的设计原则也可以应用在这里。你需要简单的导航、可预测的行为、行动优先、一致性，还要特别注意那些分开的元素是通过情景化来传达的，那么相同的情景也应该传达给辅助功能用户。

实例

下面将通过一个实例来说明如何审查一个 app 的辅助功能使用体验。

这个 app 的名字是「Exceptional Dogs」，其目标是通过让用户浏览一系列需要找寻新家庭的小狗的信息来让这些小狗的收养过程更简单。下图就是这个 app 的界面：

在顶部，有一个小狗的轮播 UI，展示了我可以浏览的不同小狗的图片。在左下角有一个「收藏」按钮，我可以点击它收藏特定的某只小狗；在右下角有一个图册按钮，点击后可以以一个模态视图查看更多的小狗图片。并不是所有的小狗都有一个图册按钮，当从一个有图册的小狗滑向一个没有图册的小狗时，图册按钮会淡出。
在图片的下面，是每只小狗的具体信息，包括名字、品种、年龄、体重、性别、性格等等，最后还包括小狗现在所在的救助站的位置信息，提供了两个按钮：一个是在地图上显示具体的位置，另一个是拨打电话。

现在在这个 app 中开启旁白功能，来看看一个盲人用户或者视障用户是如何消化这个 app 的复杂度的。会发现下面的这些问题：

旁白可以正确地在轮播 UI 中滚动，但是直到最后一个轮播图片之后才能读出收藏按钮和图册按钮，以及下面的小狗的具体信息。
在图册的模态窗口中，当滑动到最后一张图片后再继续滑动，旁白会继续播放模态窗口下面或者说背后的内容，这会让用户困惑或者分心。
在每只小狗的具体信息部分，所有的文字是从左到右、从上到下朗读的，但我们在听到「名字」这个词语之后，下一步想听到的应该位于「名字」词语下面的小狗的名字，而现在听到的是「品种」这个词语。视觉上结构没有问题，但对于旁白来说，它的结构顺序就是错乱的，这会减少旁白用户的情景化创建，造成不必要的认知负担。
对于救助站信息上的两个按钮，对于旁白来说目前也是缺乏情景化的。当我听到「打电话按钮」时，我不清楚这个操作是和什么相关，即使视觉上很清楚。

以上发现的这些问题不会让我们的 app 不可用，但它们给用户造成了不必要的认知负担，而我们的目标是创造一个杰出的无障碍用户体验。
审查之后，来看解决方案：

我们需要每一只小狗的操作和数据可以快速可访问，可以定义收藏按钮和图册按钮是每一只小狗的次级操作（sub elements），这样你就可以通过左右滑动访问小狗的收藏按钮、图册按钮、具体信息；

// Custom Accessibility Elements 

public class UIAccessibilityElement : NSObject { 
	public init(accessibilityContainer container: Any) 
} 

extension NSObject { 
	open var accessibilityElements: [Any]? 
}

通过 accessibilityIncrement 和 accessibilityDecrement 来在不同的小狗之间进行导航，这样你就可以通过上下滑动来切换不同的小狗；

// Increment and Decrement 

extension NSObject { 
	// Must have UIAccessibilityTraits.adjustable 
	open func accessibilityIncrement() 
	open func accessibilityDecrement() 
}

对于小狗信息中的文本标签和其对应值进行分组，减少了信息组的数量，提高了导航速度，还让用户更清楚旁白讲的是什么，这样旁白就可以一次性读出小狗信息中的文本标签和其对应值；

对于小狗信息中救助站部分，在之前是被分为了三个部分，同样缺乏场景化，我们也是将他们组合在一起。同时我们考虑这个部分的关键信息，就是小狗所在的救助站的信息，所以我们可以把另外两个按钮作为救助站信息的额外两个动作，这样在旁白读到救助站信息时就会同时告诉用户这里有额外的操作可用，可通过上下滑动听取具体的操作；

// Custom Actions 

extension NSObject { 
	open var accessibilityCustomActions: [UIAccessibilityCustomAction]? 
} 

class UIAccessibilityCustomAction : NSObject { 
	open var name: String 
	open var target: AnyObject? 
	open var selector: Selector 
	
	public init(name: String, target: Any?, selector: Selector) 
}

最后一部分是图册部分，让旁白排除掉模态界面之外的元素，同时屏幕上的元素发生改变时需要让辅助功能技术知道，以让其尝试重新聚焦。

// Modality 

extension UIView { 
	open var accessibilityViewIsModal: Bool 
}

// Screen Change 

extension UIAccessibility { 
	public static func post(notification: UIAccessibility.Notification, argument: Any?) 
} 

extension UIAccessibility.Notification { 
	public static var screenChanged: UIAccessibility.Notification 
}

总结

值得注意的是，为你的 app 的辅助功能创造自定义的界面有时候并不是一个好的解决方案，有时简单的调整就是最好的调整，但是当你在让你的 app 变得无障碍时你真正应该做的是不仅仅是在表面思考，更应该深入思考对于那些通过辅助科技使用 app 的用户来说意味着什么。

可用是让 app 无障碍使用的第一步，但我们还可以做得更好，我们可以我们也应该为用户提供出色的、愉快的使用体验以满足他们的独特需求。

从一开始就考虑 app 的无障碍使用特性的设计将会赢在起跑线上；
让你的 app 的设计可以根据用户的系统设置做出修改；
带着目标去创造无障碍使用体验，内容保持优先，导航简单直观。

参考链接

Deliver an Exceptional Accessibility Experience - WWDC 2018 - Videos - Apple Developer

iPadOS 指针系统的设计规范 iPadOS Pointing System Design Guideline

2020-05-08T18:12:09+08:00

iPadOS 13.4 介绍了对于增强使用了指针设备（鼠标、触控板）的 iPad的使用体验的动态指针效果及其行为模式。当人们使用一个指针设备时，iPadOS 会自动适配指针到当前的操作场景中，并提供丰富的视觉反馈和恰到好处的精确度，用来提高效率、简化日常任务。

iPadOS 的指针系统给人们一种与 app 和内容进行交互的额外的方式，但它并没有代替触控。有些人可能会继续只使用触控操作，而其他人可能会更喜欢使用指针操作或者两者结合。让人们去选择如何与你的 app 进行交互，避免压缩你的 app 的界面或者作出一些要求他们必须使用指针的改变。

启用指针系统交互

无论人们使用的是触控操作、指针设备或者是键盘，都以提供一个一致的体验为目标：人们期望在使用触控操作和一个连接的输入设备之间能够顺畅移动，他们不想为每种模式或者每个他们使用的 app 学习不同的交互。
当人们通过连接的设备使用熟悉的手势时，确保你的 app 的所有区域正确无误：例如，如果人们可以在屏幕上通过滑动手指操作内容，那就考虑他们通过在触控板上使用两个手指、通过鼠标点击和拖拽或者滚动鼠标滚轮执行相同的动作是否说得通。
当人们长按一个修饰符按键，与你的 app 中的对象进行交互时，确保一个一致的体验。：例如，如果人们可以在拖拽时长按 Option 键复制一个对象，当人们使用触控操作或者鼠标拖拽时结果应该是一样的。
仅在有必要、有用的地方区分指针输入和手指输入：例如，当人们在使用指针输入设备时，视频进度条可以给人们一种额外的方式定位视频的某个位置。在这个情景中，人们可以使用指针设备或者通过触控操作拖动播放光标，但是在使用指针设备时，他们可以悬浮/hover 并点击一个精确的目标位置。
让人们使用悬浮/hover 操作去显示和隐藏安歇可以自动最小化或淡出的控件：例如，人们可以通过在上面悬浮指针以使 Safari 最小化的工具栏显示出来（当指针移开时工具栏会再次最小化）。人们也可以在播放全屏视频时通过悬浮指针去显示或者隐藏播放控件。

指针形状和内容效果

iPadOS 将指针和指针悬浮在上面的元素的外观和行为结合在一起，让焦点集中在人们的目标对象上。你可以直接支持系统提供的指针效果或者修改这些效果以适合你的 app。
默认情况下，指针的形状是一个圆形，但是它可以在悬浮在特定元素或区域时展示一个系统定义的或者自定义的形状。例如，当指针悬浮在一个文本输入区域时，他会自动变成熟悉的 I 光柱形状的输入光标。

通过内容效果（content effect），当指针悬浮在上面时，UI 元素或者指针下面的区域也可以改变他的外形。取决于内容效果的类型，指针可以保持它现在的形状或者转变成一个与元素新外形相结合的一个形状。
iPadOS 定义了三种内容效果，让焦点集中在你 app 中不同的交互元素类型上：高亮/highlight、抬升/lift、悬浮/hover。

高亮效果会把指针转化成一个半透明的圆角矩形，这个矩形会作为控件的背景，并包括一个柔和的视差效果。微弱的突出和动感让焦点都集中在控件上，不会分散人们在他们的任务上的注意力。默认情况下，iPadOS 会把高亮效果应用到栏按钮（bar button）、标签栏（tab bar）、分段控件（segmented control）和编辑菜单（edit menu）上。

抬升效果将微弱的视差效果和提升的外形结合起来，让一个原色看起来浮在了屏幕上。当指针消失在元素下面时，iPadOS 通过将元素放大，在元素下方添加一个阴影，在元素上方添加一个柔和的镜面高光来创造一种抬升的错觉。默认情况下，iPadOS 会把抬升效果应用到 app 图标和控制中心的按钮上。

悬浮效果是当指针悬浮在元素上面时，一种让你把自定义的大小、描边或者阴影值应用到元素上的通用效果。悬浮效果将你的自定义的值结合起来，并把焦点聚焦在一个元素上，但是它不会转变默认的指针形状。

指针磁吸机制

除了通过指针的转变和内容效果让焦点聚焦在元素上，iPadOS 也可以通过让元素看起来在吸引指针来定位一个元素。当人们移动指针靠近一个元素或者他们将指针滑向一个元素时，他们就可以体验到这种磁吸效果。

当人们移动指针靠近一个元素时，当指针触及一个元素的热区（hit region）系统就会开始转换指针的形状。因为热区通常情况下会延伸到一个元素的可见边界之外，在指针看起来要接触到元素之前，指针就会开始转换，从而创造出一种元素正在把指针拉过去的错觉。

当人们将指针滑向一个元素时，iPadOS 会检查指针的轨迹以发现最有可能是目标的那个元素。当有一个元素在指针的路径中时，系统就会使用磁吸机制把指针拉向元素的中心。。

默认情况下，iPadOS 会把磁吸机制应用到使用抬升效果（如 app 图标）和高亮效果（如栏按钮）的元素上，不会应用到使用悬浮效果的元素上。因为一个悬浮效果的元素不会转换默认的指针形状，在上面添加磁吸机制会造成指针跳动的效果，可能会让人们感到失去了指针的控制。

系统也会把磁吸机制应用到文本输入区域，在那些地方当人们选择文本时，如果他们做出了无意的竖直移动，就可以帮助人们避免跳跃到另一行。

支持标准指针和效果

在可以的时候，启用系统提供的内容效果：人们会快速习惯于他们在整个系统中看到的内容效果，通常会期待这种体验也会应用到他们使用的 app 中。为了提供一个一致的用户体验，遵守每个效果的设计意图。特别的：
- 对于包含透明背景的一个小元素使用高亮效果；
- 对于包含不透明背景的一个小元素使用抬升效果；
- 对于大元素和根据需要自定义大小、描边、阴影属性的元素使用悬浮效果。
对于标准按钮和文本输入区域倾向于使用系统提供的指针外观：当指针行为以他们期待的方式呈现时，你可以在 app 中让人们感到更加舒服。
在可交互元素的周围添加边界间距以创造舒服的热区：你可能需要做测试以决定一个元素热区的合适尺寸。如果热区太小，它可以让人们在与元素进行交互时，感到必须十分精确。另一方面，当一个元素的热区太大，人们可能感到需要花费很大的力气把指针从一个元素上移开。通常情况下，在包含边框的元素周围添加大约 12pt 的边界间距的效果比较好，对于没有边框的元素，在元素的可见边界周围添加大约 24pt 的边界间距的效果最好。

对于自定义的栏按钮创建相邻的热区：如果栏上的相邻按钮的热区之间存在空隙，在指针在按钮之间移动时，指针会短暂地恢复成它的默认形状，这是一个会让人们感到注意力被分散的动画。
对于那些有抬升效果的非标准元素，指定它们的圆角半径。使用系统提供的提升效果，随着指针隐去，指针会转换成与元素形状相匹配的形状。默认情况下，指针使用系统定义的圆角半径去转换成一个圆角矩形。如果你的元素是一个不同的形状（例如它是圆形），你需要提供半径值，这样指针才能无缝地渐变成元素的形状。

自定义指针形状和效果

对于行为表现像系统标准元素的自定义元素倾向于使用系统提供的指针效果：当一个自定义元素的行为表现地像一个标准元素，人们通常会期望使用熟悉的指针交互与其互动。例如，如果在一个自定义导航栏的按钮没有使用标准的高亮效果，人们可能就会产生一种割裂感。
在你的整个 app 中用始终一致的方式使用指针效果：例如，如果你的 app 帮助人们绘画，在你的 app 中的每一个绘画区域都应该启用一个相似的指针体验，人们才可以把一个地方获取到的知识应用到另一个地方。
避免创造不必要的指针和内容效果：当指针的外观或者指针下面的 UI 元素发生变化时人们就会注意到，他们期望这些变化是有用的。创造一个仅仅是装饰性的指针效果会分散人们的注意力，甚至是因为没有提供任何的实际价值而惹火人们。
保持自定义的指针形状简洁：理性情况下，指针的形状传达了人们可以在当前情景下可以执行的操作，它不需要分散人们太多的注意力。例如，Keynote 在某些场景下会把指针转换成了一对箭头，表明了人们可以拖拽一个选择手柄的方向。如果人们没有马上理解你的自定义指针形状，他们可能就会在尝试搞清楚指针形状是什么意思上浪费时间。

考虑通过展示可以提供有用信息的自定义的注释增强指针体验：例如，在你的 app 中，你可以在指针悬浮在一个图形区域上面时展示 X 和 Y 值。例如下图中，Keynote 使用注释去展示一个可改变大小的图片的当前宽度和高度。

避免展示指针的指导使用文字：一个展示了指导使用文字的指针会让一个 app 变复杂、变得难于使用。在你的界面中优先考虑清晰和简洁，而不是提供指导说明，这样无论人们是通过指针还是触摸操控屏幕，他们都可以快速掌握如何使用你的 app。
在定义自定义悬浮效果时，考虑阴影、缩放和元素空间的相互作用：通常情况下，为可以增加尺寸而不会和周围元素显得拥挤的元素保留缩放比例。例如，缩放对于一个 table row 就不能运行良好，因为一个 row 不能在不覆盖相邻 row 的前提下扩展。对于一个周围只有很小空间的元素，考虑使用仅包括描边，但不包括缩放和阴影的悬浮效果。另外，如果不使用缩放只使用阴影的效果也不好，因为这种情况下，元素的阴影表明元素在屏幕上升起来了，但未缩放的元素却没有表明离用户更近了。

注：目前文章大部分文字来源于对 HIG 中指针系统的翻译，后续可能会补充一些实际应用案例以及开发实例。

参考链接

Pointers (iPadOS) - User Interaction - iOS - Human Interface Guidelines - Apple Developer

订阅 Apple Music 该选哪个区？——中美坡港日五大地区全对比

2020-03-18T01:13:44+08:00

2015 年 6 月 30 日 Apple 正式推出「Apple Music」音乐流媒体服务。9 月 30 日，Apple Music 在中国大陆地区上线。相比于美国地区个人订阅每月 14.99 美元的价格，中国大陆地区的个人订阅价格为每月 10 人民币，可以说几乎是全球最低。但喜欢听音乐的人很多不愿意选择价格如此低廉的国区 Apple Music，反而在重重困难下选择订阅其他地区的 Apple Music，这是为什么呢？
这篇文章选取了常见的美国区、香港区、新加坡区、日本区，与中国大陆区的 Apple Music 在曲库数量、功能差异、内容展示、多平台使用、多 Apple ID 使用、订阅付费等多个方面进行对比，并附带介绍了一些容易被忽略的相关功能，以期让你在选择 Apple Music 地区时能有一个明确的方向。

What's New

2020-03：
- 增加了一个在国区使用 iTunes Match 遇到问题的案例⤴︎；
- 修正了多 Apple ID 使用时有关 app 内购/订阅的描述⤴︎。
2020-04：
- 增加了 Apple Music 网页版正式上线的相关信息⤴︎；
- 增加了 Apple Music 首次在第三方电视端——三星电视上上线的相关信息⤴︎。
2020-05：
- 修正了「Apple Store」app 的帐号机制描述，不再跟随系统的 App Store 帐号，而改为跟随 iCloud 帐号⤴︎。
2020-07：
- 因台湾地区开售 App Store 礼品卡，增加了对 Apple Music 台湾区的简单介绍⤴︎。
2020-08:
- Apple Music Web Beta 版再次上线，测试 iOS 14/iPadOS 14 新样式、新功能⤴︎；
- Beats 1 电台升级为「Apple Music 1」，新增「Apple Music Hits」和「Apple Music Country」两个电台⤴︎。

在线曲库

相信选择非中国大陆区的朋友，最大的原因就是曲库。在 Apple 官网上的 Apple Music 介绍中，中国大陆地区的描述是「上千万首歌曲」，美区的描述是「60 million songs」，即「六千万歌曲」，差距不言自明。

其他非中区的曲库数量和美区相当，但因为不同区上架的歌曲一般都是根据不同区的用户喜好、歌手发展区域等，最终由版权授权决定，所以还是会有些差别，不存在某个地区所有的歌都有的情况。在线曲库没有的歌曲，可以自己上传到 iCloud 音乐资料库，并同步到所有设备。
如果想知道确切的某首歌、某张专辑、某个歌手在某个地区的 Apple Music 上有没有上架，可以通过 Apple 官方的「Apple Music 营销工具」查询，全球所有上线 Apple Music 的地区均可查询，建议电脑端访问。如果查询不到则说明没有在那个地区上架。

一个上千万，一个六千万，大到六倍的差别，到底具体差在哪呢，中国大陆的曲库到底少了什么？通过几个例子来看下：

版权分割

曲库差异最基本的原因就是版权，在中国大陆地区尤其明显。众所周知，中国大陆地区的主流音乐播放软件是 QQ 音乐、网易云音乐、虾米音乐……Apple Music 并不是主流，某些歌曲的版权自然争不过主流平台，特别是腾讯这个龙头老大。

例如，TFBOYS 的歌曲在新加坡区和中国大陆区的上线情况如下图：

除了版权分割导致的数量差异，还存在不同区上线时间不一致的情况。歌手「Eminem」于 2020 年 1 月 17 日推出全新专辑《Music To Be Murdered By》。当时美区正常上架，中区不见其踪影，一段时间后才姗姗来迟。

儿童不宜内容？

还是上面提到的歌手「Eminem」的这张专辑《Music To Be Murdered By》，在中区，脏标版本只上架了歌曲序号为 4、20 的这两首歌，非脏标版本上架了全部的 20 首歌曲，但脏话在歌曲和歌词中均被和谐。

歌手「Enrique Iglesias」的《SEX AND LOVE》这张专辑，由于在专辑封面和专辑名字中含有「SEX」这个词语，在中区得到了特别处理。

歌手「Nicki Minaj」的《Queen》这张专辑，其专辑封面在中区得到了特殊处理。

歌手「Lauv」的《~how i’m feeling~》这张专辑，前两首歌的歌名中包含了「drugs」和「fuck」这两个词语，在中国区未上架。

法律法规影响

根据不同地区的法律法规，部分歌手的歌曲不能在某些地区上架或上架一段时间后被下架，例如下图中的歌手 Li Zhi。

功能差异

电台

电台功能应该是功能差异中最容易发现的，如果你进入 Apple Music 「广播/Radio」栏目，相比非中区，中区的内容十分单薄，只有根据歌曲类型由机器自动生成的一些电台。

这主要是因为中区 Apple Music 没有「Beats 1」电台功能，根据 Apple 的描述，「Beats 1 是一个 24 小时直播电台，由 Apple 的 DJ 在洛杉矶、纽约和伦敦进行广播。在 Beats 1 收听由著名艺人和 DJ 主持的直播节目和独家采访，并发现来自世界各地的新音乐。」Beats 1 除了包括实时广播以外，在 Apple Music 中还可以听到往期的 Beats 1 直播回放，看到 Beats 1 的相关视频，如与歌手的访谈。Apple Music 也会根据 Beats 1 的内容，将相关歌手、专辑、单曲、播放列表打包成组，推荐给用户。

2020 年 8 月 19 日 Apple 发出新闻稿，Beats 1 电台升级为「Apple Music 1」，新增「Apple Music Hits」和「Apple Music Country」两个电台。这三个电台均可在非中区的 Apple Music 中收听。

除了 Beats 1 电台，非中区的 Apple Music 还包括本地或其他地区与音乐有关的实时直播电台。

下面这张图几乎在同一时刻截取了五大地区 Apple Music 「广播/Radio」模块下的展示内容，供参考。

值得注意的是，即使你没有订阅 Apple Music，你也可以收听 Beats 1 直播电台和其他直播电台。

朋友

朋友功能算是 Apple Music 在音乐轻度社交上的一些探索，随着 2017 年的 iOS 11 开始推出，其主要目的是可以与朋友更好地分享正在收听的内容。以下所有功能均未在中国大陆区上线。

个人主页&关注朋友：每一个使用 Apple Music 的用户都可以建立自己的个人主页，在主页中可以看到正在听的音乐、分享的自己创建的播放列表以及关注和被关注的用户，这项功能没有地区隔离，也就是说你可以关注全世界任何一个地区的使用此功能的 Apple Music 用户。当然，个人主页是否公开、正在听的音乐是否展示、自己创建的播放列表是私密还是公开完全由你自己控制。

「朋友们正在听」列表和「Friends Mix」智能歌单：当你关注了其他人后，就可以在「为你推荐/For You」模块下看到「朋友正在听」列表，同时在 Apple Music 的各个地方（如专辑封面、播放列表封面、专辑详情页面、播放列表详情页面）可以看到正在听的朋友的头像。当关注的朋友足够多时，Apple 会自动生成「Friends Mix」智能歌单，结合你的喜好，收录近期朋友听的歌，每周更新。你可以通过链接访问其他人的 Friends Mix 歌单，中区用户也可以。

搜索别人公开分享的播放列表：当用户创建的播放列表设置为公开时，你可以通过搜索功能搜索到这些播放列表。中国区仅支持通过链接查看，不支持搜索。

全球 Top 100 歌单

2018 年 Apple Music 推出了每日更新的全球及各个地区的 Top 100 歌单，例如「Top 100: USA」歌单，一般固定在「浏览/Browse」模块下展示。该功能在美区、新加坡区、日区已上线，港区、中区未上线。

在 2019 年年末，Apple Music 又推出了全球和各地区的年度 Top 100 歌单，例如「Top 100 Songs of 2019: Global」歌单。当时在有每日 Top 100 歌单的地区的「浏览/Browse」模块下做过推荐展示。这些歌单现在可以通过搜索或链接访问。

电视与影片

Apple Music 中的「电视与影片」大部分是自制的与音乐有关的电视节目，如 Apple Music 曾经主推的《Carpool Karaoke》、《Planets of the Apps》、「Up Next 系列」（如《Up Next: Billie Eilish》，最近上线的音乐纪录片《The Changes Interview》，一般均自带中文字幕。电视与影片可以和歌手、歌曲、专辑、播放列表，甚至是 App Store 中的内容、iTunes Store 中的内容打包到一起做内容推荐。该功能未在中国大陆区上线。

在 Apple Music 中，曾经有专门的入口进入「电视与影片/TV&Movies」模块，目前该入口在几次改版后下线，该模块被弱化，但未停止更新。电视与影片目前可以通过搜索、链接或者编辑内容推荐访问。

iTunes Store & iTunes Match

在 Apple Music 音乐流媒体推出之前，全球许多个国家或地区（不包括中国大陆地区）一直可以通过 iTunes Store 付费购买歌曲或专辑。Apple Music 中的歌曲会随着版权的变化发生变化，一首歌现在可以听，并不代表你永远可以听，它属于音乐流媒体；iTunes Store 中的歌曲只要你购买了，那就属于你自己，它属于电子音乐购买。
根据版权的授权，部分歌曲可能存在在 Apple Music 中没有上架，但在 iTunes Store 中上架的情况，例如「Justin Biber」的专辑《Purpose (Deluxe)》中的第 11 首歌《Where Are Ü Now》未在 Apple Music 中上架（灰色不可播放状态），但可以在 iTunes Store 中通过购买整张专辑的方式获得。

同一个 Apple ID 下，在 iTunes Store 中购买的音乐会自动进入 Apple Music 的 iCloud 音乐资料库。
iTunes Match 是 Apple 于 2011 年推出的一项服务，如 Apple 官方描述，「通过 iTunes Match，您可以在自己的所有设备上访问您的所有音乐，甚至还可以访问您从 CD 等其他来源导入的歌曲。」简而言之，iTunes Match 的功能主要是「匹配（不等于上传）用户导入的音乐」和「在设备间同步音乐资料库」，可以说是「iCloud 音乐资料库」的前身。该服务未在中国大陆地区上线。

Apple Music 推出后，涵盖了 iTunes Match 的所有功能。iTunes Match 不再推广，但并没有停止运营，现在你仍可以通过 iTunes Store 的边栏找到入口，按年订阅 iTunes Match。
由于早期中国大陆地区没有 iTunes Store 功能，也就没有推出过 iTunes Match，现在的 Apple Music 也就不包括 iTunes Match，以上是官方描述。但在实际情况中，中国大陆地区的 Apple Music 在使用 iCloud 音乐资料库上传歌曲后，某些歌曲可以呈现「已匹配」状态。2019 年 1 月有网友在 V2EX 发帖称，原来上传后状态为「已匹配」的无压缩、无 DRM 保护的歌曲变成了「已匹配」的有压缩、有 DRM 保护的歌曲，而非中区不存在这种情况。2019 年 2 月又有网友在 V2EX 发帖称，自己上传的歌曲不仅存在上述问题，歌曲还出现了不明杂音，不知此情况是否为个别现象或是 bug。故此功能在中国大陆区的具体规则十分模糊。

类似艺人

音乐向导

「音乐向导」可以理解为 Apple Music 中某些官方机构、组织创建的播放列表合集，这个功能随着 Apple Music 改版被弱化，从之前的专门入口演变到现在只能通过搜索或链接访问，但并没有停止更新。非中区的音乐向导基本一致，但中区只包含部分，其他即使通过链接也无法访问，如音乐向导「Disney Music」。例如，以「music」为搜索关键字搜索音乐向导：

内容展示

曲库语言逻辑

Apple Music 的曲库显示语言是指除歌曲本身之外的文字的显示语言，如专辑介绍、歌单推荐语、歌单封面、歌手名字等。一般情况下，专辑和歌曲的名字在各个地区都是一样的，但根据专辑在全球的发行情况的不同，也存在专辑和歌曲名字被翻译成当地语言的情况，比如部分中文歌曲在美区是以英文名呈现的。
各个地区的 Apple Music 支持的显示语言是不同的，一个地区并不会支持全球所有语言，会根据对应地区的用户的常用语言来决定，且不止一种，并一定包括英文，但只有一种会被作为「主要显示语言」。
以 iPhone 为例，如果 iOS 系统的语言设置为 Apple Music 在本地区支持的显示语言的某一种，那么 Apple Music 就会以系统设置的语言展示；如果 iOS 系统的语言设置为 Apple Music 在本地区不支持的显示语言，那么 Apple Music 就会以「主要显示语言」展示。
为了更好地理解上述逻辑，把五个地区的 Apple Music 在不同系统语言下展示情况列举如下：

由上表可以看出，美区在表中所列五种语言的系统设置下均显示为英语；新加坡区可以在系统设置为简体中文时显示为简体中文；港区在除英文系统下均显示为繁体中文；日本区只有在系统设置为英语时显示英语，其他情况下均显示为日语，包括简体中文系统设置下。
值得特别提及的一点是，日语歌曲的歌曲信息在日区非日语系统环境下和其他区所有语言环境下一般都以「罗马音」形式展示，这是许多人吐槽的一点。

内容推荐

除了自己搜索发现或者通过外部链接访问以及机器智能推荐，在音乐软件中发现音乐的另一种途径是人工内容推荐，这一部分也是 Apple Music 在推出时强调的亮点之一。人工内容推荐在 Apple Music 中占据了较大的篇幅，整个「浏览/Browse」模块几乎都是人工内容推荐，比如带有推荐语的最新专辑推荐、根据时间/节日/时事等编排的歌单列表推荐、本地特别发行专辑推荐、近期本地热门影视原声歌曲推荐、热门艺人 MV 推荐、即将发布专辑推荐等。
根据各地区用户对音乐的偏好不同，即使在曲库差不多（除中区）的情况下，Apple Music 推荐的内容也会不同。概括来看，中区内容推荐以华语音乐（偏国语）和欧美音乐为主，美区内容推荐以欧美音乐为主，新加坡区内容推荐以华语音乐（偏国语）和欧美音乐为主，港区内容推荐以华语音乐（偏粤语）和欧美音乐为主，日区内容推荐以日语音乐和欧美音乐为主。
下面这张图几乎在同一时刻截取了五大地区 Apple Music 「浏览/Browse」模块下的展示内容，供参考。

多平台使用

Apple Music 是支持多平台的音乐流媒体服务，除了 iPhone、Android 手机，你还可以在 iPad、Mac、Windows、网页端、Apple TV、Apple Watch、HomePod、第三方电视端、第三方智能音箱、CarPlay 、第三方网页端和 app 上使用。

iPhone、iPad、Apple Watch、HomePod、Mac：苹果常见的自家产品系列自然不用多说，系统原生支持，所有地区帐号均可在上述设备正常使用。2019 年从 macOS Catalina 开始，Apple Music 和 iTunes Music Store 从 iTunes app 中分拆成了独立的「音乐/Music」app；即使在 HomePod 上登录未发售地区的 Apple ID，也可以正常使用 Apple Music。

Android 手机、Windows：2015 年 11 月，Apple Music 正式上线五个月后，Apple Music Android app 正式发布，你可以通过 Google Play 或者从 Apple 网站直接下载 Apple Music Android app。通过 Apple Music Android app 你可以将其与 Chromecast、Android Auto 结合使用。在 Windows 中，你需要通过安装 iTunes app 使用 Apple Music 相关服务。所有地区帐号均可在上述设备正常使用。

网页端：2019 年 9 月 Apple 上线了网页端的 beta 版 Apple Music，用户可以在浏览器中使用 Apple Music，其访问地址是：https://beta.music.apple.com/。由于是 beta 版，部分功能暂时不可用，例如 Beats 1 直播电台、Apple 原创音乐视频、智能播放列表，并且你不能在网站中开启 Apple Music 的订阅。值得注意的是，在笔者的上海电信网络环境下，直接访问网页端 Apple Music 会自动跳转至 Apple Music 苹果官网，导致网页端 Apple Music 服务无法正常使用，若使用非大陆地区网络访问则是正常的，其他地区和运营商网络访问情况未知，导致这个问题的原因未知。

2020 年 4 月，Apple Music 网页版正式上线，其访问地址是： https://music.apple.com/ ，Apple Music 包含的大部分功能都可在网页版中使用。

2020 年 8 月，Apple Music Web Beta 版开始测试与 iOS 14、iPadOS 14 对应的新样式、新模块，「为你推荐」调整为「现在收听」，搜索更加突出了按类别搜索，整体个性化内容推荐更加丰富。
Apple TV:Apple Music 同样在 Apple TV 上提供服务。由于 Apple TV 未在中国大陆地区发售，使用国区 Apple ID 登录 Apple TV，没有「音乐/Music」服务，无法正常使用 Apple Music，其他四个地区的 Apple ID 可正常使用。

**第三方电视端：**2020 年 4 月， Apple Music 以独立 app 的形式在三星智能电视上上线，这是 Apple 的媒体服务在第三方设备上的又一次扩张。可以预见，支持 Apple TV app 的智能电视/盒子（如 LG、Amazon Fire TV、Sony）在未来应该也会上线 Apple Music app。

关于第三方电视端的 Apple Music 值得注意的几点：
- 和 Apple TV app 以及 AirPlay 2 功能一样，Apple Music app 目前不支持国行设备，LG、三星国行设备可以通过换区解决（换区指南↗︎），其它国行设备暂时无法解决；
- 同一设备上，Apple Music app 和 Apple TV app 的帐户登录是独立的，也就是说你可以在同一设备上使用不同的 Apple ID 同时登录两个 app，这在 Apple 自己的设备上是无法实现的；
- 你可以在第三方电视端的 Apple Music app 中登录并正常使用国区 Apple Music，这在 Apple TV 上也是无法实现的。
CarPlay：你可以将 iPhone 与你的 Apple CarPlay 车载连接，从而在汽车的中控界面中使用 Apple Music。支持 CarPlay 的车型可前往 Apple 官网查看，所有地区的 Apple ID 都可以在 CarPlay 中使用 Apple Music。

第三方智能音箱：你可以在 Amazon Echo、Amazon Fire TV、Sonos 上连接 Apple Music 帐户以使用 Apple Music 服务，具体可查看官方说明文档。在 Amazon 设备上使用 Apple Music 可能需要 Amazon 设备销售地区的 Apple Music 帐户。

第三方网页端和 app：利用 Apple 提供的 MusicKit，开发者可以在自己的 iOS app、Android app、网页端接入 Apple Music 服务，可以是部分功能接入，可以是全功能接入，即作为一个第三方 Apple Music 客户端，iOS 端 app 通过请求「媒体与 Apple Music」权限访问 Apple Music 内容，Web 端 app 通过 Apple ID 授权第三方登录的方式登录使用。例如：
- 第三方网页端：Musish、Apple Music Web Player From Naveed Golafshani、feverTunes、Zachary Seguin Music、Maeve。
- 网页中嵌入自定义 Apple Music 内容：我的个人博客的「Music」页面 - 未登录时歌曲只可以试听，登录订阅帐号后可完整播放。
- 第三方 iOS app： Marvis Pro、Soor ▹、SongOwl、SoundShare。
- 接入 MusicKit 的工具型 iOS app：Shazam（歌曲识别）、MusixMatch（歌词）、SongShift（歌曲迁移）、Miximum（自定义歌单）、MusicHarbor（歌手关注）。

多 Apple ID 使用

该部分主要适应于 Apple 设备，非 Apple 设备一般不存在多 Apple ID 使用的情况。

以 iPhone 为例，系统中的 Apple ID 帐号分为「iCloud 帐号」和「iTunes Store 与 App Store 帐号」：
- iCloud 帐号负责管控与云同步相关的功能，例如同步照片、通讯录、日历、备忘录、Safari 收藏夹、钥匙串以及 iCloud 云盘功能；
- iTunes Store 与 App Store 帐号可简称为 Apple 媒体帐号，负责管控系统中所有与内容媒体相关的功能，例如 App Store、Apple Music、iTunes Store、Apple TV、Podcast、Books、TestFlight。
同一台设备上登录的 iCloud 帐号和 Apple 媒体帐号可以相同，也可以不同，默认相同。
其他 Apple 设备的逻辑大体相似。

由于非中区 Apple ID 付款方式终归不如中区便利，在中国大陆使用非中区 Apple Music 的用户一般还同时拥有一个中区 Apple ID，常用于 App Store 的付费应用和服务的购买和订阅或者下载只在中区上架的 app（如 Bilibili）。但基于上述逻辑，你无法在同一台设备上让 Apple Music 登录 A 帐号，App Store 登录 B 帐号，iTunes Store 登录 C 帐号……于是你就不得不有切换 Apple 媒体帐号的需求。
在 iOS 设备、HomePod 上切换 Apple 媒体帐号时可借助系统自带 iCloud钥匙串、1Password 等工具自动填充密码，减少输入，简化流程；在 watchOS 设备上，Apple 媒体帐号与配对的 iPhone 保持同步；在 macOS 设备上切换 Apple 媒体帐号时可借助 1Password 等工具填充密码；由于 Apple TV 定位于家庭中多用户使用的设备，在 Apple TV 中可登录多个 Apple ID，从 tvOS 13 开始，需要切换 Apple 媒体帐号时可一键切换，无需输入密码。

第一点值得特别注意的是，在 iOS 设备和 macOS 设备上切换 Apple 媒体帐号时，iCloud 音乐资料库里已下载的内容中，属于 Apple Music 的内容会被从设备本地移除，属于用户自己上传的内容不会被移除。重新登录此 Apple ID 后，需在开启 iCloud 音乐资料库后重新下载（系统内也可能保留有上次下载内容的缓存，若有可快速加载）。

第二点值得特别注意的是， Apple 媒体服务设有 90 天帐号与设备绑定逻辑，具体如下：当在一台设备上使用不同的 Apple ID 启动 Apple 媒体下载功能（如开启 iCloud 音乐资料库，下载 iTunes Store 购买的音乐、电影、电视剧）时，系统会提示你需要将此设备与当前登录的 Apple 媒体帐号绑定，90 天内不能使用其他 Apple ID 的 Apple 媒体下载功能。绑定后若再使用其他 Apple ID 开启 Apple 媒体内容下载功能时，系统会提示此设备已与其他 Apple ID 绑定，并告知还剩余多少时间。若不小心错误地触发绑定，可联系 Apple 官方客服，有一定几率可以提前解绑。以上适应于 iOS、Android、Mac、Windows 设备。

关于 app 的下载，对于从 A 帐号下载的 app，在登录 B 帐号的情况下，只要 B 帐号所在地区的 App Store 有上架此 app，无需切换回 A 帐号就可检测到该 app 的更新，并可以正常更新，第一次更新时可能要求输入 A 帐号的登录密码。
关于 app 的内购和订阅，对于 A 帐号购买的 app 的内购和订阅，一般情况下只能在登录 A 帐号的情况下才能恢复购买；在使用 A 帐号下载的 app 中，不能在登录 B 帐号时进行内购和订阅的付费。
对于只在中区或者只在某一个地区上架的应用需要更新时，可以通过这个小工具快速切换当前设备 Apple 媒体服务到对应的地区，检查 app 更新并完成下载更新。注意该工具仅是通过一个链接跳转到了其他区的 Apple 媒体服务，并没有修改 Apple ID 的地区，你也不能购买/播放其他地区的应用/音乐。你也可以利用这个工具查看任一地区的 Apple Music、App Store、iTunes Store 内容。若不能正常跳转可尝试通过代理访问。

除了 App Store 和 Apple Music，Apple 媒体服务还包括 iTunes Store（影片、电视节目、音乐、铃声和提示音）、Apple Arcade、Apple TV+、Apple TV Channel、Apple Books（图书、有声书）、Apple 播客、Apple News（含 Apple News+）。根据政策和版权的限制，不同地区提供的 Apple 媒体服务不同。在使用某一个地区的 Apple ID 时，你可能也会用到其他 Apple 媒体服务，故将五个地区的 Apple 媒体服务的提供情况列表对比如下：

其中 Apple TV app 即使不支持某个第三方 app 作为一个频道订阅，但还可以支持搜索、展示第三方 app 的内容，如 Disney+、Amazon Prime Video，该功能目前在美区帐号中提供，具体支持列表参见 Apple 官方网站。
当然，即使某项功能提供服务，在不同的地区提供的内容也是不同的。例如所有未经允许的含有 VPN 功能的 app（如 Speedtest、Adguard）都无法上架中区、未在中国大陆地区提供服务的 app（如 Netflix、Spotify）没有上架中区、因各种原因被屏蔽的 app（如 Skype、Pinterest）无法上架或主动不上架中区、某些中区上架的 app 为中区特供版（如中区 Sky 光·遇、非中区 Sky 光·遇，中区 Flipboard、非中区 Flipboard）、Apple 播客中的节目在中区经过筛选（如《Drake Freestyle》未上架中区）。
总的来看，美区的 Apple 媒体资源最丰富，功能最齐全，其次是日区、新加坡区、港区。
真心期望 Apple 能在未来的版本中将各个媒体服务的 Apple ID 独立，不过希望渺茫🙃。

订阅付费

价格对比

Apple Music 包括个人订阅、学生订阅（需定期验证学生身份）、家庭订阅（可与其他同一地区的五个人组成家庭组）三种，在不同地区的价格也不一样。五大地区的具体订阅价格如下：

从上表中可以看出，中区比其他地区便宜数倍，美区最高，其次是日区，港区和新加坡区价格相当。

付款方式

付款方式可能是使用非中区 Apple ID 除注册过程之外的另一个重大障碍。根据 Apple 官方的描述，五个地区的 Apple ID 支持的付款方式如下表：

因为 Apple ID 支持的付款方式中的信用卡和借记卡严格限制为本地区发行，所以除中区外一般情况下各个地区最便捷的付款方式还是通过礼品卡。对于中国大陆用户，礼品卡最方便购买的是美区，其次是港区、日区，再次是新加坡区，通过第三方购买礼品卡一般都会比正常汇率高一些，越方便购买的溢价越少。
目前只有美区礼品卡可通过 Apple 官方网站购买，20 美元起售，通过 Email 发送，可使用中国大陆发行的 Visa/Master 银行卡支付。
对于除礼品卡外，中国大陆用户常用的一些付款方式，在此简要说明，不做详述：
- 美区：美区 Paypal 绑定中国大陆发行的 Visa/Master 银行卡再绑定 Apple ID（绑定成功率低，易风控）；
- 港区：香港地区发行的 Visa/Master 虚拟储值卡，如拍住赏、八达通 O! ePay（开卡可能需要香港手机号，需验证护照/港澳通行证，充值不方便）、AliPay HK（开通帐户需要香港手机号，需验证护照/港澳通行证，充值不方便）；
- 日区：中国大陆地区发行的部分 JCB 信用卡。
想要曲库丰富&功能齐全，订阅价格就高；想要订阅价格低，曲库就不丰富，功能就不齐全。那曲库丰富&功能齐全、价格低廉就不能两全其美吗？能，来看印度区：
- 印度区同样是六千万的曲库，功能齐全；
- 个人订阅价格为 99 卢比每月，折合人民币约 9.37 元；学生订阅价格为 49 卢比每月，折合人民币约 4.64 元；家庭订阅价格为 149 卢比每月，折合人民币约 14.1 元，平均每人折合人民币约 2.35 元；
- 但是，印度 Apple ID 的付款方式仅支持印度发行的银行卡和通过印度银行卡充值 Apple ID 余额，没有礼品卡，想要付款难上加难；
- 另外，印度区的 Apple Music 内容推荐面向印度本土用户，印度风味十足。
所以即使价格低廉、曲库丰富、功能齐全也并不推荐印度区，除非你搞定付款方式以及不在乎印度风味的内容推荐。

以下是 2020 年 7 月更新：
文章仅选取了中美坡港日五个地区的 Apple Music 进行了对比，部分读者可能对为什么没有涵盖台湾区有疑问？最大的原因就是台湾地区 App Store 的支付方式不包括礼品卡，所以无法长期稳定使用台湾地区的 Apple 付费媒体服务。
不过这一情况现已发生改变。2020 年 7 月 2 日台湾地区开售 App Store 礼品卡，用户可通过台湾地区的线下便利店等渠道购买到实体 App Store 礼品卡，虽然现在暂时没有发现线上销售渠道，但这已为日后可以长期稳定使用台湾地区的 Apple 付费媒体服务奠定了基础。

下面的表格总结了 Apple Music 台湾地区的基本情况：

由上表可以看出，台湾区 Apple Music 曲库丰富、功能基本齐全（缺少全球 Top 100 歌单），最吸引人的是相比港区价格更加低廉，若日后台湾地区 App Store 礼品卡可以在线上渠道普及，那就完全可以作为港区的一个替代选择。

顺畅使用

总结

综上，文章从在线曲库、包含功能（电台、朋友、Top 100 歌单、电视与影片、iTunes Store、类似艺人、音乐向导）、曲库语言、内容推荐、多平台使用、多 Apple ID 使用、订阅价格、付款方式多个方面对五个常见地区的 Apple Music 及其相关功能进行了对比阐述，来看下面这张总结性表格：

一句话总结：

中区：曲库阉割，功能缺失，简体中文界面，Apple 媒体资源匮乏，价格低廉，适合对曲库没有强烈需求的你；
美区：曲库丰富，功能齐全，英文界面，Apple 媒体资源丰富，礼品卡容易购买，适合听欧美歌曲的你；
港区：曲库丰富，功能齐全，繁体中文界面，礼品卡购买难度中等，适合听华语歌曲（偏粤语）和欧美歌曲的你；
新加坡区：曲库丰富，功能齐全，简体中文界面，礼品卡购买难度较大，适合听华语歌曲（偏国语）和欧美歌曲的你；
日区：曲库丰富，功能齐全，英文/日语界面，礼品卡购买难度中等，适合听日语歌曲和欧美歌曲的你。

看到这里的你，根据自己的需求心里有做出选择了吗？

Apple 无障碍功能设计规范

2020-05-25T18:36:44+08:00

人们会使用 Apple 的无障碍功能/辅助功能（Accessibility）（例如减少透明度、旁白、增加字体尺寸）以适合他们的方式去个性化他们如何与设备交互。一个可用的 app 通过设计支持这些个性化，无论人的能力和人们如何使用他们的设备，让每一个人都能享受绝佳的使用体验。

减少透明度示例：点此查看示例视频↗︎
旁白示例：点此查看示例视频↗︎
按钮形状示例：点此查看示例视频↗︎

障碍和解决方案 Impairments and Accommodations

全世界大约每七个人中就有一个人有影响他们与世界、与设备进行交互的身体残疾或障碍。人们经历身体障碍可能在任何年纪、持续时间不定、严重程度不一。某个状况下的障碍（如开车、在晴朗的天气远足或者在一个安静的图书馆学习这些临时条件）可能会在不同时间影响几乎每个人与设备进行交互的方式。

设计 app 一开始就应该考虑包容性，让每一个人都能使用你的 app。审视下面四个主要的障碍分类以及对应解决它们的辅助功能。

视觉

视觉障碍包括失明、色盲、各种形式的视力丧失以及各种看屏幕不舒服或者困难的情况。对于有障碍的用户来说，Apple 在每个平台上都提供了旁白（Voice Over）功能，并支持显示调节功能例如颜色反转、大文本、缩放和放大器。

听觉

除了各种类型的听力丧失，听力障碍还包括人们不想他们的设备发出大的声响时的情况，例如当他们在剧院中时。Apple 提供了与功能进行听觉交互的替代方式，例如隐藏式字幕、视觉和触感通知、键入以使用 Siri 模式。

肢体和运动

有肢体和运动障碍的人可能在握持或操作设备上有困难。Apple 提供了几种解决方案无需精确的运动控制，就可以去帮助人们使用他们的设备：

切换控制（Switch Control）将自适应设备与 iPhone、iPad、Mac 和 Apple TV 集成在一起；
Siri 帮助人们使用声音控制 app 和设备；
辅助触控（Assitant Touch）让标准手势容易执行。

读写能力和学习能力

读写能力和学习能力的障碍包括口语和阅读上有困难、管理复杂性以及保持专注上有困难。为了减少认知负担，为有读写能力和学习能力障碍的人提供帮助，Apple 提供了一些功能，例如朗读屏幕内容（Speak Screen）、打字反馈（Typing Feedback）以及 Safari 阅读器（Safari Reader）。

包容型设计的最佳实践

每个人都能用上和理解的 app 的包容性设计让越来越多的人有机会享受你的 app。下面这三个最佳实践可以帮助你创造一个包容的 app。

在脑子里记住让辅助功能融进你的设计中

辅助功能不只是让那些有残疾的用户能够获取信息，而是让所有人能够获取信息，不论他们的能力或所处环境。时刻记住让辅助功能融进你的设计中意味着优先考虑简洁和感知能力，测试每一个设计决策以确保它没有把有不同能力或者使用不同方式与 app 进行交互的用户排除在外。

简洁（Simplicity）：创造熟悉的、一致的交互可以让复杂的任务变简单、易于执行。
感知能力（Perceivability）：无论人们通过视觉、听觉或是触觉。确保所有的内容可以被感知到。

支持个性化

你早已在设计 app 时考虑了环境的变化（如设备的方向、屏幕尺寸、分辨率、颜色范围、分屏浏览），因为你想要人们在任何情景、任何支持的设备中都能尽情使用你的 app。只要再付出一小点努力，你就可以让你的 app 支持辅助功能，人们使用这些辅助功能可以个性化他们与设备交互的方式。

当你使用了标准控件去实现你的 app 的 UI，文本和界面元素会自动适配几个辅助功能设置，例如加粗文本、大文本、反转颜色和增强对比度。

审查和测试你的 App 的辅助功能

审查可以检查你的 app 中的每一个元素，给你一个全面的问题列表以待修复。测试帮助你确保所有的用户都可以在你的 app 中完成最重要的任务，不论他们与设备是如何交互的。
当你将辅助功能打开，测试了重要的用户路径，你将会理解使用不同方式与设备进行交互时所遇到的挑战。你也会发现你的 app 中用户体验不好的地方。

例如，在一个社交 app 中一个常见的用户路径是回复一个评论。这个任务可能会包括：

读发出的评论；
选择一个评论去回复；
打开回复页面；
编辑回复；
发布回复。

对于你的 app 的每一个关键用户路径，打开一个辅助功能，例如旁白、减少动态效果、大文本，确保你可以在用户路径中完成每一个任务而没有遇到困难。在你修复你没有考虑到的所有问题之后，打开另一个不同的辅助功能，再测试一遍用户路径。

在 Xcode 中的辅助功能查看器可以帮助你审查、测试、修复你的 app。

用户交互

像旁白这样的辅助使用技术和像显示调整这样的辅助功能扩展了人们与他们设备的交互方式。因为这些技术和功能与系统提供的交互结合在了一起，在你的 app 中正确地支持系统交互的辅助功能是十分重要的。

手势

让所有的控件和交互元素都有一个点击目标，尺寸上至少达到 44pt x 44pt：行动不便的人需要更大的点击目标去帮助他们与 app 进行交互。太小的控件可能会让所有的用户很难去点击。
不要覆盖平台的自有手势：不管在使用什么 app，人们期待系统手势（如下滑显示通知中心、系统偏好设置中定义的触控板手势）可以正常工作。
在交互上使用简单手势：复杂的手势（例如多指手势、长按或者需要重复按钮）可能对某些人来说是有挑战的。使用最简单的手势可能改善每一个与你的 app 进行交互的人的使用体验。
对给予手势的操作提供可替代方案：给可能不能执行某个特定手势的人提供一个其他选择。例如，如果需要在一个表单中滑动删除某一行，你应该给人们一个可以通过编辑模式或者某个条目详情页面上提供一个删除按钮来完成删除条目的可替代方案。

在你的 iOS app 中让拖放功能可用：当你在你的 app 中使用辅助功能 API 去识别拖拽来源和放置目标时，辅助功能技术可以帮助人们拖拽屏幕上的条目。
不要通过 iOS 上的 3D Touch 功能或者 Apple Watch 上的 Force Touch 功能访问你的 app 的核心功能：并不是每一个人都可以按压屏幕获得由 3D Touch 或者 Force Touch 提供的额外功能。即使人们的设备不能使用 3D Touch 或者 Force Touch，也要确保所有的用户都可以在你的 app 中执行重要的操作。

触感

支持系统定义的触感：许多人依赖于触感功能，这可以在人们不能看到屏幕时，帮助人们与 app 进行交互。例如，系统 app 在一个任务成功或失败时或者一个事件要发生时通过触感通知人们。在你的 app 中保持一致地使用系统定义的触感，这样就不会让人们感到困惑。

按钮和控件

刻画自定义元素的辅助功能：你可以使用辅助功能特性（UIKit）和辅助功能属性（AppKit）去告知辅助功能技术一个元素是如何表现的。例如，使用一个「button」或者「NSAccessibilityButton」去刻画一个 view 作为一个按钮，那意味着旁白会在「按钮」词语之后读出 view 的描述，这可以告诉人们这个 view 的行为和按钮是相似的。
使用一个一致的样式层级去表达按钮的相对重要性：人们可以开启按钮形状，以从周围的内容中更好地辨认出活跃的按钮。当你使用一个一致的按钮样式的层级时，人们可以基于按钮的外观掌握按钮的重要性。例如，最重要的按钮是圆角矩形，并有颜色填充；二级按钮没有颜色填充，但可能使用核心颜色展示一个文本或图形；最不重要的按钮使用了一个下划线样式的文本。
优先使用系统提供的开关样式：UIKit 提供了一个开关，它通过开关把手的位置和填充颜色表明了开关的状态。然而对于某些人来说，额外的文字标签使它更容易意识到一个开关现在是开还是关。当你使用提供提供的开关样式时，如果用户开启了开/关标签，iOS 会自动展示开/关图形。

考虑给链接一个视觉上的指示，例如一个下划线：使用颜色表明一个链接是可以的，但如果把它作为唯一的链接指示，色盲人群可能就不能意识到这个区别。

用户输入

可以让人们通过说话输入信息而不仅是打字：在文本输入区域添加一个听写按钮，可以让人们选择说话作为他们的首选输入方式。如果你创造了一个自定义的键盘，确保为听写功能添加一个麦克风按键。
支持使用 Siri 或者 Siri Shortcuts 仅通过声音执行重要的任务。
不要阻止用户选择纯文本：许多用户依赖于通过选择文本作为文本转对话（TTS）的输入或者作为查找文本翻译的输入。

确保旁白用户可以导航到每一个元素：旁白从屏幕的元素中获取辅助功能信息以帮助人们理解每个元素的位置以及人们可以做什么。系统提供的 UI 元素默认包括这些辅助功能信息，但是旁白不能帮助人们发现和使用自定义元素，除非你的 app 提供这些信息。
通过指定元素之间是如何成组、排序和连接的来改善旁白体验：靠近、对齐和其他情景线索可以帮助正常视力用户感知到屏幕上元素之间的关系，但是这些线索对于需要使用旁白的用户来说并不友好。检查你 app 中元素之间的关系只能被正常视力用户所感知到的地方，并向旁白描述这些关系。

例如，下图中的布局依赖于靠近和居中来表明每个词语是上面的图片的一个标题。然而，如果你不告诉旁白每张图片应该与对应词语成组，旁白就会这样读出来："A large container holding a variety of mangoes. A large container holding many green artichokes. Mangoes come from trees that belong to the genus Mangifera. Artichokes come from a variety of a species of thistle."因为旁白默认情况下会从左到右读出元素。

使用静态文本介绍一个控件是另一种用于正常视力用户的视觉线索。在下面列举的例子中，系统偏好设置告诉旁白文本"Default web browser:"，因为这是弹出按钮的文字标签，所以使用旁白的用户可以搞清楚这个控件的含义。

当屏幕上的内容或者布局改变时注意旁白的变化：内容或者布局的突然变化对于旁白使用者将会非常困惑，因为那意味着他们对于当前屏幕的思维脑图不再准确。报告屏幕上的变化十分重要，这样旁白和其他辅助功能技术才可以帮助人们更新对屏幕的理解。
在激活会打开一个不同网页或 app 的控件前警告人们：没有警告就改变当前情景会给人们造成困惑，突然强迫人们重建对屏幕上环境的思维模型。
对于所有重要的界面元素提供可替代的文本标签：可替代的文本标签在屏幕上是不可见的，但是这些文本标签让旁白用声音描述出了屏幕上的元素，让有视觉障碍的人导航内容更简单。系统提供的控件默认情况下都会包含这个有用的文字标签，但是对于自定义的元素，你需要自己创造自定义标签。例如，如果你创造了一个表示可以自定义评分的按钮，对于这个辅助功能元素，你可能要提供文字标签「评分」。
支持旁白转子：使用旁白的用户可以使用屏幕上的一个控件叫做「转子/rotor」，用来通过标题、链接或其他部分的类型来在文档和网页中导航。转子也可以让盲文键盘显示出来。你可以通过让转子识别相关条目，以帮助旁白用户在你的 app 中的相关条目之间导航。
在一个 macOS app 中，让人们使用键盘去导航和与屏幕上的所有元素进行交互：理想情况下，人们可以打开全键盘访问，并在你的 macOS app 中只使用键盘执行所有任务。除了辅助功能键盘快捷方式，macOS 还定义许多其他的键盘快捷方式，许多用户会经常用到。为了支持所有的用户，避免在你的 app 中覆盖任何系统定义的键盘快捷方式十分重要。

文本尺寸和字重

当设计一个包容的 app 时，要记住保持文本尺寸、字重和布局的清晰和可读性。

使用动态类型，测试你 app 的布局可以适应所有的辅助功能尺寸：动态类型可以让人们选择适合他们工作的尺寸。确认你的设计可以缩放，对于文本和图形在所有的辅助功能字体尺寸下都是可读的。

当字体尺寸增加时，避免切割文本：人们可以通过简单滚动就能看到和默认字体尺寸同样数量的文本的情况是最好的。不要切割文本，除非人们可以打开一个单独的页面去阅读余下的内容。
当字体尺寸增加时，同时增加有意义的图形的尺寸：如果你使用图形去表达重要的信息，确保图形在大字体尺寸时也是容易看到的。

不论用户的字体尺寸选择是什么，保持一个一致的信息层级：例如，当字体尺寸非常大时保持主要的元素顶部对齐，这样人们不会失去对这些元素的跟踪。
在你的 app 中使用 regular 到 heavy 级别的字体字重：使用 regular、medium、semi-bold 或者 bold 字体字重，因为它们都是容易被辨认的。避免使用 ultraLight、thin 和 light 字体字重，这些很难看清。
当用户开启粗体文本时，确保你的 app 正确响应，看起来没有问题：人们会在设置中打开粗体文本以让文本和图形容易看清。作为回应，你的 app 应该让所有的文本更粗，让所有图形的描边更粗。

确保自定义的字体是清晰可读的：自定义的字形有时很难阅读。除非你的 app 对于自定义字体有一个迫切的需求，例如品牌目的或者为了创造一个沉浸的游戏体验，否则最好是使用系统默认字体。如果你使用了自定义字体，确保它是容易阅读的，特别是在小尺寸下。
避免全文两端完全对齐：两端完全对齐的文本创造的留白会让很多人很难阅读和聚焦在文本上。左对齐（对于从右向左的文本就是右对齐）为有学习和读写障碍的人（如诵读困难症）提供了一个框架参考。
对于较长段落的文本，避免使用斜体或者全部大写的样式：斜体和全部大写用于某些情景下的强调是可以的，但是过度使用这些样式会让文本很难阅读。

颜色和对比度

不要仅靠颜色去区分对象或者传达重要信息：如果你的 app 使用颜色去传达信息，确保同时提供文本标签或者图形，这样色盲用户也可以同样理解它。
对于文本，倾向于使用系统颜色：当你的文本颜色使用由 UIColor 或者 NSColor 定义的颜色时，文本可以对辅助功能（如反转颜色、增加对比度）设置正确响应。
注意色盲用户：许多色盲用户很难从橘色中分辨蓝色或者从绿色中分辨红色（还有一部分很难从灰色中分辨绿色或红色）。避免使用这些颜色组合作为区分两种状态或者值的唯一方式。例如，不要仅使用红色和绿色圆圈去表明离线和在线状态，你可以使用一个红色方形和一个绿色圆形来表示。一些图片编辑软件会包括帮助验证色盲用户的工具。

对「反转颜色」设置正确响应：当人们在一个较暗的背景下查看内容时可能会打开反转颜色。在反转颜色的智能反转模式中，图片、视频和全色图标（例如 app 图标和非模板型图片）不会反转，深色的 UI 会依旧保持深色。
使用强烈对比的颜色来改善可读性：许多特征会影响对颜色的感知，包括字体尺寸和字重、颜色亮度、屏幕分辨率和光照条件。当你增加视觉元素（如文本、图形和控件）的颜色对比度，你可以帮助更多人在更多的情景下使用 app。为了发现在你的 UI 中相邻的颜色对比度是否满足最小可接受的水平，使用一个基于 WCAG 颜色对比度准则的在线颜色对比度计算器。
使用文本尺寸来帮助决定对比度：通常情况下，更小或者更轻字重的文本需要更大的对比度才能保持可读。利用下面提供的值作为指导：

外观效果和动效

虽然像模糊、透明、移动这样的效果时传达信息的有用的方式，但一些人会因此被分散注意力或者感到不舒服，还有一些人完全不会感知到这些效果。避免使用外观效果作为传达重要信息的唯一方式，这样不管人们如何与你的设备进行交互，他们都可以享受你的 app。

透明度和模糊效果

当用户打开「减少透明度」辅助功能设置时，改变模糊效果和透明度：例如，模糊内容和透明效果的区域应该变得大部分不透明。最好的结果是，在不透明区域使用一个不同于该区域时模糊或透明时的颜色值。

动效

除非对于你的 app 目的时必不可少的，否则不要必须使用动效：通常情况下，人们应该能够不依赖于任何动效就使用你的 app。
当「减弱动态效果」辅助功能设置开启时，收紧动效：如果人们会被分散注意力或者在浏览动效（例如放大、缩小、快速转动或者周围的动态）时感到头晕或者恶心，他们就可以打开「减弱动态效果」。为了响应这个设置，考虑收紧你的动态的物理特性，这样它们还可以保持丰富和吸引人，但是可以减弱动态效果。例如：
- 收紧弹簧以减少跳跃效果或者跟着用户的手指轨迹进行 1:1 的运动。
- 避免对在 Z 轴层级的深度变化添加动效；
- 避免对模糊效果添加动效；
- 用淡入淡出替代滑入滑出以避免动效。
让人们可以控制视频和其他动效效果：避免在没有提供一个控制按钮或者其他可以控制的控件时自动播放视频或者效果。
当展示移动或者闪烁的元素时保持谨慎：虽然微弱的移动和闪烁可以抓住用户的注意力，但这些效果也会让人分心，对于有视力障碍的人这些效果没有用。更糟的是，一些闪烁元素可能会造成癫痫病的发作。在所有的情况中，避免使用移动和闪烁作为传达信息的唯一方式。

内容

稿件、图片、音频和视频提供给人们想从你的 app 中获得的信息。你可以通过努力让表达简单、提供信息的可替代版本来让你的内容对每个人都是可用的。

稿件和图片

编辑稿件，使其简单明了：当稿件是直接的、不复杂的、没有错误的时，所有的用户都可以从中受益。
对传达信息的所有图片提供可替代的描述：如果你没有描述你的内容中有含义的图片，你就会阻止使用旁白的用户完整体验你的 app。为了创造一个有用的描述，可以通过向能看到这个图片的人讲述一目了然的内容开始。因为旁白会朗读出图片周围的文本和任何说明文字，将焦点聚焦在描述图片本身想要传达的信息上。

让信息图表完全可用：提供一个对信息图表的简洁的描述以解释它在传达什么信息。如果人们可以与信息图表进行交互以获得更多或不同的信息，你需要让这些交互对使用旁白的用户也可用。辅助功能 API 提供了表示自定义交互元素的方式，这样辅助功能技术就可以帮助人们使用它。
针对于辅助功能技术隐藏仅仅是装饰功能的图片：让旁白功能描述一张仅仅是装饰性的图片可能会浪费用户的时间，增加他们的认知负担，没有任何好处。
给每一个屏幕一个单独的标题，提供可以在你的信息层级中识别是哪一部分的标题：当人们打开一个界面时，标题是他们从辅助功能技术中获取到的第一部分信息。为了帮助人们理解你的 app 的结构，为每个屏幕创造一个可以简要地描述它的内容和目的的单独的标题。相似地，人们需要精确的章节标题以帮助他们建立一个每个屏幕的信息层级的思维脑图。

音频和视频

提供可隐藏字幕：可隐藏字幕给人们一个视频中音频消息的文字信息的等价物。使用可隐藏字幕可以让你提供同一个内容的多种翻译，允许系统选择匹配用户设置的那个版本。因为可隐藏字幕并不总是可用的，提供普通字幕也很重要。
提供声音描述：使用声音描述提供那些只以视觉形式呈现的重要信息的口头描述。
考虑提供视频的文本记录：提供一个包含音频和视频信息的完整的视频的文本描述是一个好主意，这样人们可以用不同的方式享受视频。

注：目前文章大部分文字来源于对 HIG 中无障碍功能/辅助功能的翻译，后续可能会补充一些实际应用案例以及开发实例。

参考链接

Introduction - Accessibility - Human Interface Guidelines - Apple Developer

核心设计原理（下）

2019-10-06T18:17:00+08:00

核心设计原理的上半部分通过一个去夏威夷旅游的经历中的所见所闻所想讲述了导向、反馈、可见性、一致性、心智模型几个设计原理，旅程还没有结束，这是核心设计原理的下半部分。

接近性 Proximity

你按了一下开关关掉浴室的灯走出来，太阳落山了，屋子里有些暗，所以你打开了走廊的灯。接着你走进卧室，按下开关打开了另外几盏灯。这概括来说就是设计原理「接近性」。接近性是有关于控件和它控制的对象之间的距离。

一个控件离那个对象越接近，两者之间的关联就可能越大，浴室的灯的开关在浴室里，走廊的灯的开关在走廊里，卧室的灯的开关也当然在卧室里。好的接近性也是符合人体工程学的。通常情况下，你离物体或者感兴趣的区域越近，你越可能与它进行交互或者控制它，人们认为走进浴室时可以打开浴室灯的开关。所以把灯的开关放在门的旁边，需要的时候伸一下胳膊就能够到。

接近性对表现控件之间的关系也有用。例如，如果你在墙上看到一些开关，你知道其中一个可以控制灯的开关，然后你就可以假设其他开关也是灯的开关。

如果其中一个是控制灯的亮度，那最好把它与其他分隔开来。这种设置让人们更容易记住哪个开关是控制灯的亮度，哪个开关是控制灯的开关。

分组 Grouping

上面说的这种设置和安排就是「分组」。分组是一个非常基础和重要的设计原理。分组可以帮助人们理解元素之间的关系，它是确定设计结构的关键核心。
虽然我们理解这个，但许多 app 没有有效地利用分组，它很容易被忽视。现在来看一些接近性和分组如何构建设计的结构、建立控件和它影响的对象或视图的例子。
在「Keynote」app 中，接近性帮助我们把显示菜单与幻灯片导航器和画布区域联系在了一起。几个对象创建工具放置在了画布的上方，创建后这些对象将会在画布上出现。格式和文稿选项的切换位于这些面板显示的正上方。

在「Sketch」 app 中，你可以看到分组如何被用于将彼此相关的控件聚在一起，像是成组/取消成组控件、转换和编辑工具控件、路径操作控件、图层排序控件。

你的界面越大，对接近性和分组的需求绝对会越高，但这个设计原理对 iPhone、iPad 甚至 Apple Watch 这样的小屏幕也很重要。

映像 Mapping

现在回过头来再来看下调整灯的亮度的开关。看看这个开关，你现在可能并不能知道开关是开着还是关着，但当把开关改成滑动条的样式的时候，你就知道它是关着的了。这就是映像，映像让你知道它是开着还是关着，映像是指控件的设计能象征它所控制的对象，向上就是调亮灯光，向下就是调暗灯光，用一个可以上下移动的控件在这里是可以讲清楚的，对于如何调整亮度没有模糊。

映像也与控件之间是如何排列的有关。它们的顺序应该象征着被控制对象的配置。对于卧室的多盏灯与多个开关来说，良好的映像就是让灯的开关镜像安排成灯的布局。通过专注于映像，会更容易做出在哪里放置控件、如何排序它们甚至该使用哪个控件的选择。

当映像不够清楚的时候，你会发现文字标签的出现，这有作用，但不是一个好的解决方案。阅读需要花费时间，对人们记住控件的位置或者如何与它们进行交互没有帮助。

在界面的场景中，使用一个水平的滑块调整一个水平属性更加直观，类似的，使用一个拨号盘调整旋转角度比滑块或者步进器的效果更好。

当然，最好的映像是最直接的映像，可以让人们直接能操纵对象，这更直观、更精确，例如在 macOS 上的鼠标指针或者 iOS 上的手势。

可供性 Affordance

接下来要去餐厅吃晚饭。当你坐下来时，你会在你面前看到一个空盘子。用这个空盘子可以做什么呢？你可以用来装食物，你也可以用它来做其他事。盘子很光滑，很容易转起来，盘子有一个边缘，很容易像飞碟一样抓住并扔出去，开个玩笑了。我们对如何与这个盘子进行交互的见解就是「可供性」。换句话说，一个盘子的物理特性提供了关于这个盘子可以提供给我们什么交互的视觉和触觉提示。

我们看着盘子思考，我们把食物放进去，或者我考虑用这个盘子把我的食物运到另一个地方，我们不会考虑用这个盘子去装水。可供性不是对象本身的属性，它更多的是人和对象之间的关系。可供性基于一个人的身体能力而不同，因此可供性对每一个人都不一样。例如，一个飞碟提供了我可以抓住和扔出去的能力，但对于我的狗，一个飞碟只提供了狗抓住的能力，没有扔出去的能力。一个盘子提供了我用它吃饭的能力，我的狗也能感知得到这个可供性。

因为可供性是主观的，一个人能感知到的可供性其他人可能感知不到。当与一个可能进行的动作相关时，人会更可能地感知到可供性。例如，虽然我可以把这个盘子当做茶托，但这是一个几乎不可能的动作，所以我不能容易地感知到一个盘子可以做茶托的可供性。我很可能把事物放在里面，所以我容易感知到一个盘子可以装食物的可供性。

这种可供性的感知与每个环境、每个你交互的对象都有关系。当你走进一家餐馆时，你经过了一道提供给你可以穿过的可供性的门，门比人高比人宽，你可以想到你的身体可以轻松穿过去，地面平坦连续，你可以想到你自己可以没有障碍地走过去，不会被绊倒。

你坐的椅子提供了可以坐的可供性，你面前的桌子提供了可以把东西放在上面的可供性，你脚下的地面提供了可以让你歇歇脚的可供性。

人制造的产品都会通过提示提供可供性，它让人们知道哪些操作是可以进行的，这些提示的明显程度和可见性帮助人们知道交互的正确或倾向方式。

app 同样也是这样。滑块可以让人在轨道上拖动小圆点，拨盘让人旋转，按钮让人可以点击。在每一个这样的例子中，可供性都在用最大的效率传达。事实上，随着时间推移，我们会更加习惯于抽象事物。按钮就是物理真实世界按钮的一个高度抽象，两者之间的关联就是圆角弧度。

在滑块小圆点周围微弱的阴影把它与轨道分开，这表明它可以被独立移动。甚至是这个视觉提示都不是完全必要的。多余大多数人来说，看到一条直线上有一个填充的圆形就足以感知到它的滑块可供性。

有时可供性通过动画来传达。在「天气」app 中轻点，会看到画面滑上去一点，这表明内容区域可以被滚动。不管你用了什么技术，你的 app 的界面必须清晰的表现它提供了什么行为能力。如果没有的话，人们就不知道如何合适地与其进行交互，他们会用你 app 不提供的方式与其进行交互，他们会对不可交互的控件感到困惑。

渐进展开 Progressive Disclosure

现在我们知道了食物应该去哪儿，现在该点菜了。我想要一个芝士汉堡，我跟服务员说了我要的菜，服务员问我几分熟，我说七分熟；他问我要哪种芝士，Cheddar/Swiss/Jack/Gruyere/Cottage，我说要 Cheddar；他问我是否要加点培根、鸡蛋、牛油果，我说不需要；他问我是否需要薯条、输啦或者洋葱圈，我说要洋葱圈。上面说的这个过程就是「渐进展开」设计原理。

渐进展开是用来管理复杂度的技术，这个术语只用于交互设计的场景中。渐进展开可以让人们在由简单到复杂的过程放松。

渐进展开也与隐藏复杂度有关，人们只需要简单可用的界面就能完成基本的任务。

订芝士汉堡时如果你需要考虑所有的选项，那将是复杂且令人怯步的。当有人带着你通过这个过程作出决定，你自己定制芝士汉堡就会更容易。某些在之前你清楚做出的选择可能会需要你之后做出其他选择。例如，如果我需要薯条，服务员会问我需要哪种薯条，因为我说不需要薯条所以我就不关心有哪几种薯条，告诉我有什么薯条将会浪费我的时间和精力。

八二原则 80/20 Rule

渐进展开是管理复杂度和简化做决定的过程的有必要、有帮助的技术。但是这个技术会淹没信息和功能，讲到如何合适地使用渐进展开总是会提到八二原则。八二原则就是说系统 80% 的影响都是由 20% 的变量造成。对于一个 app 来说，这意味着 80% 的效益来自于它显示的 20% 的操作，或者说 80% 的使用 app 的人只会使用 20% 的功能。当然，确认的数字是不同的，但基本原理是有效的。

并不是所有的信息和功能都是平等的，有一些更重要。所以为了减少杂乱，简化做决定的过程，使用渐进展开隐藏不重要的事情是一个好方法。换句话说，如果你的 app 很复杂，让最常用的 20% 的功能更容易被发现，其余 80% 隐藏起来是可行的。一个典型的例子就是打印对话框，大多数时候，人们只关心基本参数，使用哪个打印机，打印几份，打印哪几页，屏幕上显示的只有不到 20% 的功能，但却超过了 80% 用户想要的功能。如果需要更多功能，通过点击一下既可以展开。渐进式展开不仅减少了视觉杂乱、让打印更简单，而且也不会让人感到困惑。

通过让事情保持简单，人们会更少地感到被威胁、被淹没或者让自己陷入麻烦，而更有经验的用户可以快速找到他们想要的操作和选项。

对称性 Symmetry

经过了一晚上的好好休息后，今天我们要去海边潜水了。到达海滩，你戴上护目镜，穿上潜水服，调整好通气管，进入大海，你能看到很多热带鱼。海底的景色很美，为什么呢？这就要说道最后一个设计原理，对称性。对称性我们都很熟悉，当我们想到对称性时，我们通常会想到镜面对称或者两面对称。实际上还有更多对称方式，还有放射旋转对称、平移对称。这三种对称在自然中是普遍存在的。

对称形式是一种有效的形式，我们会把它与健康、稳定、平衡、有序联系在一起，我们感觉它赏心悦目，也许还有进化的理由。即使没有物理上相互连接的对称元素感觉上也是有关联的。当我们看到一个中括号时，我们的大脑就不会无意识地把它们看做一个整体。

当你在海中游时，你会看到各种对称。实际上不管是哪种植物或动物，不管是海里游的、地上跑的、天上飞的，都可能会包含一两种对称。大多数的人造物体也是这样。

一个开关是水平竖直中心对称的，水龙头是对称的，车也是对称的。

有吸引力的界面倾向于混合使用镜面对称和平移对称。在「天气」app 中，镜面对称提供了一种平衡感，核心元素沿着一条中线对齐，而其他元素也几乎呈平衡分布。

同样的模式在「相机」、「时钟」、「电话」等等其他 app 中也有出现。

平移对称给界面一种结构感，重复使用相似的元素。

你可以在「时钟」app 中的城市和时间排列中看到平移对称，在「天气」app 中的城市列表中看到平移对称。当为你的 app 界面进行布局时，寻找机会使用对称以提供平衡感、有序感。

总结

以上所展现的设计原理展示了人类认知的基本原理，它们简单而强有力地提醒了你设计的本质和目的，它们提供一种理解的框架，一种表述设计优劣的语言。通过这些设计原理，你会更清晰地知道你的 app 设计该如何帮助满足人们的需求，对安全的需求，对理解的需求，对实现目标的需求，对体验美丽和快乐的需求。

这些设计原理看上去很简单，但应用到实际工作中并不简单。

每一个设计原理都指向不同的方向，告诉你的 app 的设计该怎么做。设计通常就是解决这些分歧，即使是一名有经验的设计设计师也要面临这些困难。
也有可能有太多好东西可以用，但太多的反馈会令人烦恼，太多的可见性会让人分心，太多的渐进展开会让工作流没有效率。所以你必须要自己衡量，谨慎判断，周全考虑。
哪些设计原理更适合，取决于你设计的 app 类型、平台、屏幕尺寸、用例、目标用户经验水平等等。种种因素都会影响某个时间点、某个设计原理的适应性。

设计是一个有挑战的工作，没有人说设计是简单的，但当你理解了基础，设计会更简单，让这些设计原理做你的北斗星，指引你做出更好的 app 服务于你的目标用户，这才是重中之重。相对的，你的目标用户也会意识到你的努力工作，他们会感激你的周全和体贴，他们会感知到 app 中的人文关怀。

参考链接

Essential Design Principles - WWDC 2017 - Videos - Apple Developer

核心设计原理（上）

2019-10-05T23:03:42+08:00

当我们谈论设计时，我们总是聚焦于设计的技术和过程。虽然这些考虑很重要，但是它们不会成就好的设计，至少它们本身不能。好的设计是在一个更基础、更人性的层级上由有关于设计是什么的更深的理解所指导。这就是设计原理所告诉我们的。它们会传达出我们如何感知到周围世界的核心事实，还有我们如何处理信息、我们如何做决定、我们如何交流。这些事实是永恒的、通用的。它们可以应用于各种图形设计、建筑设计、室内设计、零售店设计、风景设计、汽车设计等等。设计的原理不是告诉我们在设计中如何做出特定的事情，而是告诉我们为什么要做这些事情。这是好的设计建设的基础。

在 Apple 总是使用术语「human interface 人机交互」来描述其他人称之为「user interface 用户交互」的东西。人机交互这个说法并不普遍，没有被广泛使用，但它在 Apple 中有很长的历史。我们的设计指导文档被称为「HIG」，也就是「Human Interface Guidelines 人机交互规范」。这个文档可以追溯到 1978 年。

「用户」这个词语有一种冷冰冰的效果，它勉强定义了人和界面之间的关系。而「人类」这个词语更能凸显我们在为谁所设计。如果说我只是人类，那表明我会有不完美的地方，会有缺点，可能达不到你的期望。另一方面，「人类」这个词语也用来表达我们最好最高尚的品质。当你承认一个人的人性（humanity）时，你就在承认他们的善良、同情、慷慨、友好。

设计一个界面从根本上讲就是服务其他人。设计的目标不是做一个漂亮的 app 、一个有条理的 app、一个简单或者专注的 app。这些事情当然也十分重要，但它们不是真正的目标。真正的目标是为人服务或者说积极地影响使用你的 app 的人的生活。
真正重要的唯一一件事就是你的 app 怎样很好的满足你的目标用户的情感和实际需求。我们有保证安全和可预测未来的需求；我们有了解知识、理解含义的需求；我们有完成任务、实现我们的个人和专业目标的需求；我们也有体验美丽和快乐的需求。

设计绝佳的 app 应该提供这些东西，这样的 app 让用户更容易预测未来动作的结果，用户会感到稳定、坚固、值得信任；通过提供清晰有帮助的信息帮助用户做出见多识广的选择；它们流线化和简化了工作流，因此人们可以有效率的、有作用的完成他们的任务；它们也应该有审美上的快乐、享受、优美的体验。使用具备这些品质的 app 会让人感到愉悦、满意，你可以告诉人们是谁创造了完全考虑他们需求的 app，你会感知到为了让事情快速成功完成所付出的所有的时间和所有的努力。每一个事情都是有目的的，每一个事情都是可理解的，这会让人感觉到很人性。

这篇文章分享的一些设计原理可能是显而易见或者是很基础的。但大多数意义深远的东西都是最简单的。因为这些设计原理是通用的，所以我们可以看看它们是如何在现实世界构建我们的体验的，接下来会通过一个「去夏威夷旅行」的实际例子来讲讲这些设计原理。

导向 Wayfinding

旅行的第一站是「机场」。在我们去机场的路上，会看到各种标识，告诉我们如何去机场的路、每一个航站楼的具体信息、去登机口的方向。、

当到达登机口时，我们会通过标识知道我们已经到达正确的位置。如果我们到达了错误的位置或者登机口变更，我们可以获得去往附近登机口的方向。为防止有紧急情况或者我们需要离开，标识会清晰地指出出口的位置。

这些引导我们的标识系统我们称之为「导向系统」。导向系统帮助人们在复杂的环境中快速成功地导航。这对让人们感到有方向感和安全十分重要。人们在机场很疲惫，他们有时差，他们在赶路，他们很紧张，所以机场需要仔细深入的考虑导向系统。好的导向系统提供了人们通常会去到的地方的一个全面易懂的列表，它们提供了在这些地方的需要的细节，它们是完全与情景相关的。当我们进入的系统越来越深，它们就会变得更加特定。它们通过清晰的告知人们的当前位置和相关其他位置帮助人们弄清方向，而且它们提供了一条清晰的退出的道路。知道你可以回到一个你熟悉的地方或者开始的地方是令人欣慰的。
导向通过回答一些基本的问题帮助我们感到安全：我在哪？我可以去哪？当我到那时可以找到什么？周围有什么？我如何出去？没有这些问题的答案，我们就会迷路。

你的 app 的界面也是一个巨大的古老的导向系统。导航栏、内容区域、标签栏，它们都是你 app 里提供导向的工具。导航栏标题和选中的标签栏条目让人们知道他们在哪儿，内容区域的标签栏让人们知道他们可以去哪儿、周围有什么，简单着色和可识别的标签栏图标、易懂的文字标签告诉人们当他们到那里时可以发现什么，后退按钮提供了一条退出路径，可以帮助人们识别他们进入的 app 区域。你的 app 的每一个屏幕都应该这些问题，否则用户就会迷路。

所以，彻底检查你的 app，每次到达一个屏幕，问问自己是否很好地回答了这些问题，每一个屏幕是否帮助人们知道他们在哪儿，每一个屏幕是否帮助提供选项给人们以告诉他们还可以去哪儿？如果有些屏幕不能清楚地回答这些问题，那就有一些工作需要做。

反馈 Feedback

到达目的地，我们要去租一辆车前往酒店。让人们以高速度驾驶两吨重的物体行驶在路上这件事有些滑稽，特别是当人们可能很疲惫或者要去不熟悉的地方时。现在，因为驾驶车辆的潜在危险，汽车制造商必须认真思考车辆的内部设计。安全是考虑的第一位。所以，对我们来说这是一个学习反馈设计原理的好方式。
反馈帮助我们有信心地、安全地操纵车辆，反馈帮助我们预料到可能让某些功能不能运转或者让车辆不能动的问题。对于汽车来说，它提供了许多种类型的反馈。

状态反馈：让我们知道车辆现在是怎样的；
完成反馈：让我们知道我们执行的动作是否成功完成或者失败了；
警告反馈：告诉我们潜在的问题；
错误反馈：告诉我们尝试的操作造成了错误。

为了我们的安全、其他乘客和行人的安全，汽车提供的反馈必须是清晰、及时、易懂的。具体来看下，车辆是如何与我们沟通的。
第一个来看状态反馈。当我们上了车准备走时，看看档位，它告诉我们处于停车状态。知道现在车辆处于哪个档位状态十分重要，重要到在档位和仪表盘上两个地方都有展示。仪表盘上的其他状态让我知道燃料状态，我可以在补充燃料前预估到可以走多远；让我知道当前的速度，帮助我避免拿到超速罚单。这对驾驶者来说是两个很重要的信息。

app 中的状态信息应该一样清楚。例如在「邮件」app 中，未读状态指示标记帮助人们知道该优先读哪些邮件；在「日历」app 中，状态指示标记帮助人们看到什么时间有人不能参加会议，以进一步帮助人们决定是否要调整会议时间；在「相机」app 中，红点、一点点增加的时间、录制按钮的状态三个元素可以让人们知道正在录制视频，它们都让人们知道珍贵但转瞬即逝的时刻正在被记录。清晰直接地展示状态对节约人们时间和帮助他们避免犯错非常重要。

第二个来看完成反馈。我们准备出发，所以我发动了汽车引擎。我们可以听到引擎发动的声音，可以感觉到发动机的震动，可以看到仪表盘上的数字活跃了起来，毫无疑问这表示我们可以出发了。当我从停车档位变换到行驶档位，我可以获得触觉反馈让我知道我已经变换了档位。当我驶离停车点时，我可以听到车门锁定的声音。这一切都是自动发生的，我们获得这些反馈非常重要，这些反馈是可靠的，是用汽车的方式告诉我们一切正常，一切如你所期待的那样发生，这让驾驶者更能专注于其他认知任务，如确定驶离停车点是否安全。

在 app 中的完成反馈有着同样的目的，例如锁定 iPhone 的声音，一个邮件被标记为未读时的动画或者邮件被删除时的动画，这些提示是谨慎的、没有攻击性的，但它们很难被忽视，它们告知我们设备如期望的所运行。
当然，确认反馈可以更加明显，Apple Pay 交易成功的动画和声音-触感就是一个例子，这很难被忽视。每一个在你 app 中的操作都应该提供某种形式的确认反馈，因为这让人们知道动作执行成功很有必要。

第三个来看警告反馈。警告可以帮助人们提前知道潜在的错误，比如低机油、低制动液、低燃油。警告可以通过状态指示标记、信息、仪表盘、内建显示器、声音或者以上所有来告知人们。这些警告很重要，它们让给我们保持安全，保护我们的车不受伤害。

最后一个来看错误反馈。在车上，错误反馈非常关键。如果你打算启动一辆没有燃料的车，你将会得到一条错误信息。

错误状态总是让人失望和沮丧，最好是在一开始就帮助人们避免犯错误。警告和确认反馈就对此有帮助。例如，检查表格内每行信息的有效性就是让人们知道哪些值是被接受的，哪些是不被接受的好方法。实时反馈可以帮助人们修正信息，在之后就不会遇到错误。

你也可以尝试猜测人们打算做什么或者犯错误时会做什么，并做出一些合理的事情。例如，在「Things 3」app 中，如果你在日期中输入 6 月 31 日这个不存在的日期，这对人们来说是一个常见的错误，这时 app 不会显示错误或警告，而是自动修正为日期 7 月 1 日。如此小的一个调整，但很聪明、很人性化。

正如你在前面所看到的，清晰、及时、易懂和提供信息的反馈很关键，反馈解答了极为重要的问题：我能做什么？刚刚发生了什么？现在正在发生什么？将来会发生什么？许多 app 在提供反馈上没有做的很好。

没做好的原因可能是在设计时，容易只想到固定的屏幕，而忘记随着时间不断前进、后退可交互的这种体验。好的反馈就像是与设计它的人进行对话。作为一个设计师，反馈就是你让 app 回答人们没有说出来的问题的方式，让人们知道他们该怎么做以及给他们提供有帮助的指导。所以，当你设计你的 app 时，想象你与使用 app 的人有一个对话。如果你在一个房间里跟他们对话你会说什么？你怎样说？一个简单但有效的方法是寻求没有用过你的 app 的人的建议，让他们告诉你他们在想什么，什么地方是不清楚的，他们认为什么东西是困惑的，接着向他们解释你的 app 是如何实际工作的。引导他们，向他们解释正在发生什么，他们应该注意什么。之后回过头来，考虑你说的和 app 表达的有何不同。当有人要向我解释他的 app 的设计，通常会比设计本身更清晰，人们对我说的东西填补了设计中忽视的部分。

可视性 Visibility

如果人们看不见，好的反馈也没用。可视性捕捉的是十分明显的东西，当控件和信息是清晰可见的时候，一个设计的可用性会被很好地改善。仔细思考下可视性在你的车里是多么重要。仪表盘在你面前直接的呈现了状态信息和警告指示标记，仪表盘看上去很乱，有很多文本、数字、移动的计量器、闪烁的灯和状态指示标记，但这对于操控一辆车来说都是有必要的，需要被一下子看见，而不必移动你的头和身体才能看到。隐藏一部分信息或者把一部分放到车的其他地方将会损失可用性。

关键的反馈会被忽视，app 也是同样的道理。在「邮件」app 中，小蓝点提供了有关于邮件消息的有帮助的状态信息，移除掉它可以减少杂乱、会更干净，但却极大地降低了可用性。人们必须要进入每条邮件消息才能获得那个信息，这是低效冗长的。所以，尽可能地让关键状态信息浮出水面很重要。

再来看下「时钟」app，如果把底部的「世界时钟、闹钟、就寝、秒表、计时器」隐藏到一个汉堡包菜单中，人们就要花更多的时间寻找 app 提供了什么其他功能。

当然，这里有一个平衡，界面过于密集会淹没人们，让人们特别是那些新用户做决定缓慢。所以可视性必须与其他元素进行权衡。

一致性 Consistency

一致性原则是关于用相似的方式表示相似的设计特性。如果你以前开过车，有些标识和术语你一定很熟悉。你会认出下面的标识是锁门、车窗、加油、机油、电池、前灯，你也会知道停车、驾驶、倒车这些词语在操控车辆时的意思。

一致性也应用于位置和控件的配置。我们都希望刹车在左边，油门在右边。一致性很好地改善了车辆的可用性，或者反过来说不一致会破坏可用性。所有的车都共享了一份普遍的针对于标识和术语的设计词典。所有的车的位置控制也都差不多，得益于一致性，当每次开一辆新车时不需要重新学习如何驾驶。

这是显而易见的，但一致性实际上很难实现。你必须有意识地保持一致性，你必须正确使用一致性，你要全面考虑当人们使用你的 app 时人们会有什么期待，这些期待可能大多数来源于他们使用其他 app 的经验。你可能不知道他们使用如何使用其他 app，但你可以做出一些有用的推测，也许他们使用其他和你 app 做的事情差不多的 app，很可能他们在一个平台上使用其他 app。所以你需要关注平台惯例，像是图形、术语、导航机制甚至是典型任务的普遍工作流。

下面用一个具象的例子来说明。在 iOS 上，这个用来表示动作概念的图形是一个从盒子里出来的向上的箭头，因为这个图形会普遍地与分享动作结合在一起，我们可以称之为「sharrow」。有些 app 使用了另一个不同的图形表示相似的概念，这个图形在网站和其他平台很普遍，这个图形没有任何问题，但是这不是 iOS 用户熟悉的图形。从你的目标用户的角度，最好与他们最熟悉的图形保持一致。

保持一致性会让你的 app 更方便使用。但有时我们总想做一点不一样的事情，当然那是好事情，你应该尝试新的想法，创新可能也会因此诞生。但像图标和文字标签这样简单的事情的不一致会让人们困惑。所以最好是保持一致，除非你有很坚定的理由。

关于一致性还有很重要的一点是内部一致性。内部一致性有关于设计相似样式的控件，你的 app 的图形应该有一个一致的视觉样式，你 app 中的文本应该只有几种字体、字号、颜色等等。内部一致性有助于使 app 具有内部凝聚力和整体性。当一切相互匹配，一切正好合适，人们就会对产品的完整性有更深的感受，我们会本能地认为这个设计是经过深思熟虑的，并且十分合理。保持一致需要自我控制和约束。

心智模型 Mental Model

到达酒店，你从不太透气的车上下来，进入房间走向浴室，打开水龙头的把手开关让水流出来。过了一会儿，你把手指放在水下面检查水温。水还有点凉，所以你让热水开大了一点。你又等了一会儿，水热了，你开始洗脸。

相比于一辆汽车，一个水龙头更加基础。但是在某些方面，你必须学习如何使用一个水龙头，你通过适应不同水龙头的控制开关和观察结果去学习。例如，你怎么知道哪个把手是控制热水的？因为你知道是大多数热水都由左边的把手控制。为什么你要等一会儿才去检查水温？因为你知道在调整水温和水变热之间会有延迟。单纯只看水的样子，你很难知道是冷是热，我们都有在水龙头下被烫伤的经历。现在当你每次使用水龙头时，你没有思考这么多事情，你从直觉上期待是那样。

在你的大脑中，有一个小小的可爱的水龙头模型，这个模型代表水龙头是含有不同部分和一系列功能和行为的系统，有一个喷口可以出水，有把手控制温度和流量。这些部分都有特定的配置，你的那个模型会有特定的行为，比如在调整热水和水温增加之间会有延迟。这个模型就是心智模型。你交互的每一个系统都有一个心智模型，这些心智模型十分简化，它们没有全面获取系统内部的运作。然而你使用这个系统的经验越多，你的模型就会变得越全面。

心智模型是根据个人经验建立的，并且基于不完整的事实，所以每个人的心智模型都是独一无二的。心智模型可以分为两个部分去理解。
一个是系统模型。系统模型是关于一个系统是如何工作的。对于水龙头的系统模型，它包括对两个独立的一热一冷的水源的思考。系统允许输入混合以创造一个温度范围。系统没有立即响应，改变温度可能要花一点时间，特别是刚打开水龙头时。系统模型包括对延迟和温度的理解。

另一个是交互模型。交互模型是关于如何与系统交互的。对于水龙头的交互模型就是我们用把手调整温度和水流量。
那这一切与我们的关系是怎样的？当像水龙头这样的系统匹配了我们的心智模型，我们对系统的期待就会被满足。事实发生时我们不会意识到我们的期望，我们对这个系统的认知是本能的。相反，当一个系统不符合我们的心智模型时，它就打破了我们的期待，我们就认为它不是本能的。

心智模型这个概念对于设计非常重要。在此用一个水龙头设计师的小故事来进一步说说这个设计原理。有一天水龙头设计师灵光一现，有个一个水龙头设计的新想法，不是用一个把手控制热水另一个把手控制冷水，而是用一个把手控制温度另一个控制水流量，这样当人们想调整水流量的时候就不会不小心改变温度了。现在，对于水龙头设计师，有了一个新的心智模型。但对于其他人来说，他们的心智模型与设计师的不匹配。当人们使用设计师的水龙头时，不能满足人们的期待，人们会认为是不直观的。更糟糕的是，新的水龙头的外观跟以前的太像了，但是实际行为却完全不一样。当人们以为打开了热水时，却没有水出来。期待的行为和体验到的事实间形成的落差造成了主要的可用性问题。

也许对把手样式进行改变可以表示它有了新的交互模型，或者添加一个文字说明，但这还是有问题。文字说明和微小的变化是很容易被忽视的设计线索，特别是人们对于一个系统的运作和如何操作它已经有了根深蒂固的认知时。这也是设计中的一个大问题，尝试让人们改变 app 如何运作的心智模型是很冒险的，人们越熟悉越严重，对已长期使用的产品做出改变都会让人感觉难以适应，不管这些改变有多么好多么必要。当考虑对已有 app 要做出改变时，你必须有 100% 的把握这些改变让应用的使用者用着更舒服。为了改变而改变不是一个好的理由。仔细地测试你的设计，在怀疑之下证明你的创新更好。如果你做到了，那就可以推动，人们最终会被吸引。

继续阅读

出发机场，坐上飞机，到达夏威夷，向酒店开去，到达酒店好好休息，旅程还没有结束，继续阅读核心设计原理的下半部分……

参考链接

Essential Design Principles - WWDC 2017 - Videos - Apple Developer

在 iOS 和 watchOS 上设计优雅的声音-触感体验

2019-10-04T01:22:59+08:00

触感（Haptics）吸引人们的触觉以增强与屏幕上界面交互的体验。例如，当一个 Apple Pay 交易确认时，在视觉和声音反馈之外，系统还会有一个触感反馈。触感也可以增强触摸手势和交互，如滚动一个picker/选择器或者打开一个 switch/开关。

iOS 上的触感

在支持此功能的 iPhone 设备上，你可以通过几种方式在 app 中增加触感：

使用那些由 Apple 设计的默认系统触感的标准的 UI 元素，如 switch 开关、滑条 slider、选择器 picker；
当讲得通的时候，使用一个反馈发生器（feedback generator）弹奏通知（notification）、影响（impact）、选择（selection）分类里的预置触感模式中的一个。
在需要更多控制的场景中，创作并弹奏你自己的触感模式。

当你使用系统触感时，iOS 会管理反馈的力度和行为。例如，一个开关会发出一个微弱的敲击，一个通知分类里的「success」反馈发生器会像下图一样发出触感，点击这里聆听用声音模拟的效果。

系统反馈发生器内置了下面几种触感模式：

Notification 通知
- Success（成功）：表明一个任务或者一个动作（例如打对勾或者锁定汽车）完成。
- Warning（警告）：表明一个任务或者一个动作（例如打对勾或者锁定汽车）发出了一个警告。
- Failure（失败）：表明一个任务或者一个动作（例如打对勾或者锁定汽车）失败。
Impact 影响
- Light（轻）：提供一个物理替代以补充视觉体验。例如，当一个界面划进来并到位或者两个对象发生碰撞时，人们可能会有砰的一下那种感觉。
- Medium（中）：提供一个物理替代以补充视觉体验，比上面的更重一些。例如，当一个界面划进来并到位或者两个对象发生碰撞时，人们可能会有砰的一下那种感觉。
- Heavy（重）：提供一个物理替代以补充视觉体验，比上面的再重一些。例如，当一个界面划进来并到位或者两个对象发生碰撞时，人们可能会有砰的一下那种感觉。
- Rigid（僵硬）：提供一个物理替代以补充视觉体验，比上面的清脆一些。例如，当一个界面划进来并到位或者两个对象发生碰撞时，人们可能会有砰的一下那种感觉。
- Soft（柔软）：提供一个物理替代以补充视觉体验，比上面的沉重一些。例如，当一个界面划进来并到位或者两个对象发生碰撞时，人们可能会有砰的一下那种感觉。
Selection 选择
- Selection（选择）：表明被选中对象发生了变化。例如，当滚动一个选择器 picker 的滚轮时，用户会感到轻轻的点击。这种反馈是为了通过一连串分离的值表现移动，不是做出或者确认一个选择。

无论你是否使用系统提供的触感还是自己创建，使用触感增强用户体验而不是让用户从他们的目标中分散注意力是十分重要的。

设计 iOS 上的触感

设计吸引人们触觉的界面可以把他们在物理世界熟悉的感觉带到 app 中。无论你怎样在你的 app 中产生触感，下面这些设计规范都可以帮助你给用户一个统一的和扣人心弦的体验。

在每个触感和触发器之间构建一种清晰的、有因果的关系：理想情况下，人们总是知道为什么你的 app 要产生一种触感模式。如果触感不能增强一个因果关系，那将是令人困惑的，看上去没有必要。
在你的 app 中使用触感补充其他的反馈效果：当你的 app 的视觉、听觉、触觉反馈就像物理世界那样和谐的时候，用户体验就会更加连贯一致，一切才很自然。
审慎地使用触感：例如，在提供持久价值时使用触感，如果为了增强新奇感而使用触感会让人们觉得你的 app 在耍花招。只在一小部分重要的、反映结果的交互上使用触感，在很多微不足道的交互上产生触感会淹没用户。
使用触感要保持一致性：触感反馈中的一致性可以帮助人们在某个触感模式和某个体验间形成触觉关联。例如，当一个游戏角色没能完成任何时，如果你的 app 产生了一种特定的触感模式，人们就会把那种触感模式与消极的结果关联在一起。如果你在一个积极的结果中（如完成一个关卡）使用了那种触感模式，人们会感到困惑。
避免过度使用触感：有时当触感偶尔被触发时，这种体验会刚刚好，但是当经常发生时，体验就会令人厌倦。通常情况下，避免设计那种产生太长或者重复的触感反馈的体验。最好的触感体验是开启时不会意识到，但是关闭后会想念的那种。
确保好好测试 app 中的触感：不同的人有不同的偏好设置、不同的对触感的灵敏级别感知，所以你需要在尽可能多的人身上测试触感效果。
让触感是可选的：如果用户需要的话可以让他们关闭触感，关闭后，确保人们仍然可以正常使用、享受 app。
在游戏中，考虑一种使用自定义触感增强玩家体验的方式：除了当玩家与某个控件发生交互时产生触感，你可能想要通过产生触感传达游戏内的事件。例如，触感可以增强真实体验，像是碰撞或者敲击，也可以产生微妙的体验，像是脚步的临近或者逼近的危险。
要意识到产生触感可能会影响其他的用户体验：通过设计，触感会对人们产生产生足够的物理力度，让他们感觉到设备的震动。确保触感不会扰乱相机、陀螺仪、麦克风等的用户体验。

在 iOS 13 中创建自定义的触感模式

自定义触感模式可以表现像是射出弹弓、在崎岖的小路上行驶这种事情。自定义模式可以基于用户的输入和情景动态变化。例如，当一个游戏角色从树中跳出来时玩家会感觉比角色跳入一个地方更强烈。

在 iOS 13 和之后的版本中，Core Haptics 提供了两种基本的建设模式用来生成自定义触感模式：

像是感到轻敲、脉冲这种短暂紧凑体验的短暂事件，例如在主屏幕上点击闪光灯按钮时的体验；
会感到不断震动的持续性事件，例如信息中的激光效果。

无论你选择哪种模式去产生自定义触感，你都需要控制它的锐度（sharpness）和它的强度（intensity）。

你可以把锐度当作是将触感体验抽象成能产生相符物理感觉的波形的一种方式。特定的锐度可以让你把体验的意图传达给系统。例如，你可能使用锐度值去传达一种柔软、圆滑、有机的体验，或者是一种松脆、清晰、机器驱动的体验。而强度如字面意思表示触感的力度。

通过对短暂事件和持续性事件的组合，变化锐度和强度，加入可选的听觉内容，你可以创建非常多的不同的触感体验。

watchOS 上的触感

在 Apple Watch 上，由 Taptic Engine 产生的每一个触感都会搭配一段声音，这两者在一起工作可以用连贯一致的方法传达相同的信息。

Apple Watch 根据一些特定的目的定义了一些触感，每一个触感类型都传达了特定的含义，而且只应该被传达那个含义：

Notification（通知）：告诉用户有一些重要的事情或者是不普通的事情发生了，需要引起用户的注意。当一个本机或者远程通知到达时，这个触感就会由系统发出。
Up（增加）：告诉用户有一个重要的值增加到了一个重要的门槛之上。
Down（减少）：告诉用户有一个重要的值减少到了一个重要的门槛之下。
Success（成功）：告诉用户一个动作成功完成。
Failure（失败）：告诉用户一个动作失败了。
Retry（重试）：告诉用户一个动作失败了但可能需要重试。
Start（开始）：告诉用户一个活动开始了。当开启一个计时器或者任何其他有准确起点和终点的活动时使用这个触感。这个触感之后一般都会有一个相对应的停止触感。
Stop（停止）：告诉用户一个活动结束了。当停止一个计时器或者其他已经开始的活动时使用这个触感。
Click（点击）：提供一种拨号盘点击或者有预置增量/间隔的进程的感觉。较少地使用这个触感。过度使用点击触感会削弱它的实用性，而当点击相互覆盖时会让人困惑。

设计 watchOS 上的触感

Apple Watch 上的触感不应该被 app 频繁使用，系统会阻止两个触感同时产生。

使用触感时要克制：只在为了引起对那些重要事件的注意力时使用触感。过度使用触感反馈会造成困惑或者削弱那个反馈的用处。
只为了它本来的目的使用每一个触感：每一个触感和声音都是根据状态目标而设计的。如果因为不同的目的使用了那个触感会让用户对表达的意思感到困惑。
提供视觉提示以匹配触感：更新你的界面的视觉样式或者内容以强化触发触感所表达的含义。同时提供视觉和触感反馈可以在用户的动作和结果间创造更深的连接。
在合适的时间产生触感：通常情况下，播放触感会有一段等待期。因此，最好是在执行相关任务时的第一步而不是最后一步产生触感。如果你在任务的最后一步产生触感，触感就会来得太晚，在触感和任务之间形成一种没关联的感觉。

什么是声音触感体验？

当声音的频率很低很低时，你的耳朵就无法听到，但当你把手放在扬声器上时，你还能感觉到。因此我们设计了 Taptic Engine 用来播放那些只有你自己能感受到的低频声音。在 iPhone 中，Tapic Engine 旁边就是扬声器模块。Tapic Engine 产生的触感会与扬声器发出的声音同步，得到的结果，我们就称之为声音触感体验。

因为触感意味着需要被感知，但因为这是一篇文章，所以你需要通过视觉化的触感和一些模拟的声音来想象出下面会提到的触感体验。

iOS 13 介绍的可以自定义触感体验的 Core Haptics 可以让开发者在 iPhone 上完全自由使用 Taptic Engine。你可以通过它产生自定义的震动，像下图所示的波形这样。

我们也可以创建更短更紧凑的触感，像下图这样，只有一个循环，这种我们称之为短暂事件（transient），它更加瞬时性，感觉就像一个瞬时的撞击、敲击、点击。

我们可以进一步精炼它，可以使用基本的形状来表示不同模式的触感。所以这个短暂事件就可以变成一个简单的矩形，我们可以使用 Taptic Engine 通过不同的方式调整触感体验。

首先可以调整强度或者说振幅，可以让它更加圆滑、柔软。另一个角度，可以让它更加精确、松脆。这些都可以通过 Taptic Engine 来实现。

总结下，我们可以调整强度，也可以调整另一个设计维度-锐度，从而控制两种类型的事件，一种是持续性的，一种是短暂性的。

设计指导原则

对于设计绝佳的声音触感体验，有三个设计指导原则：

因果性
和谐
实用

这些概念或者方法被贯彻使用在 Apple 产品的工作中，它们也可以帮助提升你的 app 体验。下面具体来看。

因果性 Causality

第一个是因果性，因果性是有有关于声音触感必须有用，造成它的体验必须是明显的。想象一个足球运动员踢球，在原因—脚踢球和结果-撞击的声音和感觉之间就有一个明显或者清晰的关系。

这个体验听上去和感受如何取决于交互对象的品质（鞋子的材料、足球的材料）、动作的范围（用力踢还是轻轻踢）以及环境（露天体育场或者足球场）。

因为我们太熟悉这个事情了，所以如果声音有一点不同，就会讲不通。所以当设计你的 app 的声音体验时，如果你的交互对象是一个物理对象，仔细考虑下它会是是什么感觉、听上去怎样。举个例子，设计 Apple Pay 确认时的声音-触感体验。我们希望声音和触感能够完美匹配屏幕上的动画，那个对勾。首先考虑下，你会把什么声音与付钱关联在一起，钱是什么声音，使用 Apple Pay 付钱的交互是什么？屏幕上的确认付款成功的动画是积极的。

我们从众多声音中进行了挑选，不能太轻浮、太刺耳、不严肃，要表明一个清晰的确认的感觉，最终选择了你们现在听到的那个声音。声音确定之后就是确定触感。首先想到的是模仿声音的波形，因为可以完美匹配。

但仔细体验之后，其实两个简单的点击更好。这就像两个乐器一样，一个你可以听到，一个你可以感知到，两个乐器没有必要总是弹奏相同的东西，但至少节奏是相同的。

和谐 Harmony

第二个是和谐，和谐是有关于事物通过视觉、通过声音应该感觉到的方式。在真实世界中，声音、触感、视觉是自然和谐的，因为它们有清晰的因果关系。在数字世界，我们需要手动地实现这个工作，输入和输出需要由开发者进行特别的设计。
来试着创建一个简单的模型，这里有一个小球从空中掉落并与屏幕底部发生碰撞。先来添加声音反馈，找一个与物理冲撞相匹配的声音，它需要短、精确、清晰，还需要基于撞击的速率调整声音的振幅。接下来添加添加触感，想象一下球撞到你手里的感觉，与小球撞击屏幕底部保持同步，所以我们可以选择一个高锐度的短暂事件，同时需要根据速率调整强度。最后，非常重要的是，让视觉、听觉、触觉达到同步。之后，魔法就发生了，就像是一个真的球与墙壁发生了碰撞。但当我们不让三者同步，感觉就完全不对了。所以「和谐」需要你仔细考虑、多加注意，当完成时就可以创造完美的令人愉悦的体验。

再来看 Apple Watch 数码表冠的声音触感设计在和谐上的应用。Apple Watch 上第一次出现 Taptic Engine，实现了声音和触感的精准同步。在 S4 上，触感和一个微弱的声音被添加到了表冠的旋转中，你会在手指上感受到那个尖锐、精确的触感。对于声音，我们从世界上传统手表制造商中寻找灵感，从真实世界的机器对象中寻找灵感。最后你听到了现在的那个在手腕上安静的声音。声音和触感的完美结合打造了一种机械表冠的错觉。为了匹配这种机械感觉，动画也做了调整以匹配声音和触感。

实用 Utility

第三个是实用，实用是只在你对 app 体验可以提供清晰的价值和好处时才添加声音触感反馈。要使用克制，不要因为你可以而添加声音触感。

来看一个使用了 ARKit 的 app 实例。在这个 app 中，我们在环境中放置了一个虚拟的计时器，交互会取决于和虚拟计时器的距离，通过声音触感体验以完善 AR 交互，增强用户体验中最重要的备份。靠近计时器、远离计时器会调整声音触感体验。

针对不同的元素或者 app 中的小交互克制地添加声音触感反馈，有时候只有触感没有声音也是一个好主意。寻找 app 中可能需要声音触感反馈的地方，聚焦于可以增强用户体验或者传达什么重要事情的元素，尽量保持简单。
但如果你添加的太多，这很有可能淹没用户，削弱真正重要事情的价值。

实践建议

先回顾下 Core Haptics 提供的两个建设组件，一个是短暂事件，它是敏捷的、紧凑的触感体验，像是一个点击、一个敲击。另一个是持续的触感体验，可以维持很长时间。你可以指定持续时间。

对于短暂事件，有两个设计维度你可以控制：强度和锐度，可以使用较低的锐度值创建更圆滑、柔软的体验，使用较高的锐度值创建更精确、机械化、松脆的体验。而强度改变了体验的振幅。

对于持续性事件，也有这两个设计维度，可以创建随着时间更有机的、隆隆作响的体验，或者是使用更高的锐度创建更精确、更机械化的体验。

设计声音时，记住什么样的可以与这些触感完美工作。对于一个尖锐的短暂事件，一个尖锐的鸣响可能可以完美匹配。但如果你有一个声音更顺畅，使用相同的触感与之匹配就不是好主意，一个持续性的上上下下的触感可能更合适。但这些都不是绝对的，有很多空间去探索试验。

有时你可能会发现你思考的相反一面会工作的更好，例如 Apple Watch 闹钟的例子，当声音与触感同步时是不错，但当将触感反过来，并调整时间轴，先来一段向上走的触感，然后立即切断并开始播放声音，这样形成了清晰的先有动作后有反应，声音作为触感的应答。

通过一系列的相对立的事件去传达不同类型的体验也很普遍。下面这个例子里有四个短暂事件，但人们感受后会发现通常不会感觉到第一个触感，四下点击变成了三下点击，出现了影子效果。这是一个问题也是一个机会，我们可以利用这个影响。

来看 Apple Watch 上第三方通知的声音触感实例。这是一个非常重要的通知，我们希望用户能够清晰的感知到。这就可以利用影子效果去唤醒皮肤并准备好感知接下来要发生的。在正常通知的触感前增加一个短暂的触感。

我们也可以在相似的体验之间创建完全相反的功能。在 Apple Watch 上导航向左转是下图这样，是一连串的双重敲击。

如果是导航向右转，则是下图这样，声音有点相似，但不完全相同。此时如果还是按照波形设计触感的话，那触感就没有了区别。在这个例子中，我们可以增加触感，加倍双重敲击为四重敲击。

信息中的烟花发送效果也是一个非常好的将视觉动画、声音、触感完美和谐地结合在一起的好例子，你可以去实际感受下。

除了上面的这些指导原则，还有一些思考。最好的结果会在亲手听到、看到、感受到时产生。如果你是一名动画师，要与声音或者交互设计师紧密合作，反之亦然。那是创造统一体验的最好方式。想象你第一次使用你的 app，你会想听到什么、感受到什么？然后想象你使用了 100 多次，那些声音触感体验还能帮助你听到或感受到那些东西吗？或者是已经被淹没了。尽管体验它，去掉那些不引人注目或者没用的东西。不要害怕试验，尽管尝试。

参考链接

如何设计和实现 iPad app 的多窗口功能

2019-10-02T13:25:05+08:00

在 iOS 13 及之后的版本中，iPad app 可以支持多窗口功能。例如，在一个具有文档创建功能的 iPad app 中，人们可以同时打开多个文档窗口。这篇文章会从设计和实现层面讲述 iPad 多窗口功能的触发方法、样式以及功能等主题。

注意：如果你想把你的 iPad app 带到 Mac 中去，想让 Mac 版本支持多窗口功能，那就必须在 iPad app 中支持多窗口功能。有关于把 iPad app 带到 Mac 中去，参见「把 iPad 上的 app 带到 Mac 中去（上）」和「把 iPad 上的 app 带到 Mac 中去（下）」。

从 Dock 栏拖拽 app 的图标到屏幕的一边，选择一个当前的窗口或者创建一个新的窗口；
拖拽一个对象到屏幕的一边，把它释放到系统提供的可供释放的目标上；
长按 Dock 栏上或者首页上一个 app 的图标，点击情景菜单中出现的「显示所有窗口」，再点击添加按钮；
长按一个对象直到出现一个情景菜单，其中包括在新窗口中查看对象的选项。

通常情况下，iPad app 使用两种类型的窗口。「Primary window 主要窗口」包括了多个 app 对象以及与之相关的动作，通常人们会一直与「primary window」保持交互。「Auxiliary window 辅助窗口」包含了一个对象以及与之相关联的动作，人们在关闭辅助窗口前通常会与其只交互一次。例如，在「邮件」app 中，主要窗口包括了邮箱，而一条单独的信息会展示在辅助窗口中。

支持主要窗口和辅助窗口的多窗口体验：因为主要窗口总是包含高层级的对象，人们会从打开展示了不同区域内容的多窗口中受益。例如，人们可能想要首要邮件窗口一个展示他们的收件箱，另一个展示草稿箱。正如你所期待的，多个辅助窗口让用户更容易浏览和在多个条目间工作，例如多条邮件信息。
确保一个辅助窗口自己是有用的：辅助窗口应该给人们 app 的内容和功能的额外视图。避免只是使用辅助窗口去提供主要窗口内容的选项或工具。
在辅助窗口使用一个「Done 完成」或者「Close 关闭」按钮：因为辅助窗口只包含了一个任务或对象的内容和动作，人们期望在完成时能够关闭它。不要在按钮中使用「Back 后退」来关闭窗口。你可以在按钮中使用「Back 后退」去帮助人们返回窗口中的上一个视图。

设计意图

在 iOS 12 和之前的版本中，如果你进入切换 app 界面，你会看到下面这种 app 的网格布局，你可以点击其中一个进入那个 app。

在 iOS 13 中，一切看上去还跟以前一样，但在这个界面中，不再全是一个个的应用，而是一个个的窗口。

首先来看下多窗口功能在 app 中是什么样子的，从中解答两个问题，我的 app 应该支持多窗口功能吗？如果需要支持，这些多窗口应该是怎样的？具体的我应该在哪里添加多窗口功能？它们应该怎么表现？用户是如何思考它们的？我们将通过看几个 Apple 原生应用的例子来回答上面的问题。
先来看「Safari 浏览器」，Safari 是多窗口功能的早产儿，因为在 iOS 13 之前的版本就已经基本具备了多窗口功能，下图中展示了在 iOS 12 中，Safari 通过分隔视图实现了多窗口功能。

在 iOS 13 或者 iPadOS 13 中，是下面这个样式，实际上看起来和之前没有什么不同。因为在之前，在 Safari 中能使用多窗口功能打开多个网页就已经非常重要，现在我们将多窗口功能带到了整个系统中。

具体来看，Safari 的每个窗口都是完全一样的，它们就像是另一个界面的克隆。每一个窗口都可以做 app 所有的事情，这很重要，因为在 iPad 上用户应该在他们想要的那个窗口中做任何的事情。如果人们觉得需要，还可以创建更多的窗口。但是需要注意，如果你的 app 必须依赖多窗口功能才能工作，那就有些问题了。所以说每一个窗口都是另一个窗口的克隆并不是必须的，但用户打开的第一个窗口应该可以完成所有的事情更加重要。而在 Safari 的这个例子中，每一个窗口都是一样的，在大多数的 app 中也是这样。
在 iOS 13 的 Safari 中，你可以随时从多窗口的 Split View 模式转换到 Slide Over 模式，并将屏幕边缘的窗口滑出去，以进行一会儿更加专注的工作。

第二个例子是一个基于文档的 app，Pages。在任何基于文档的 app 中，用户都会希望能够同时在不同的窗口中查看多个文档。所以你很有必要支持多窗口功能。但有一个点你需要注意，在每个窗口的左上角，有一个「文档」按钮，你可以通过这个按钮访问你想要的其他文档。这也跟 Safari 一样，每一个窗口都是一样的。当然，并不是每一个基于文档的 app 都要做成这样，但在这里，这是讲得通的。

第三个例子是「Maps 地图」，它也是只有一种多窗口类型的 app，要在这里提这个 app 的原因，是它更可以展示需要支持多窗口功能的必要性。通常情况下，你打开地图，去到某个地方然后关闭它。但当你计划你的晚上安排时，你可能想要先去吃晚饭，晚饭后再去看一个演出，在此时使用多窗口功能就很有帮助，你可以在两者之间思考并改变它们。所以我们不能确保在任何时候多窗口功能都是有用的，但我们知道有时候会用上它。

同时，多窗口功能是系统级别的。当你已经确定了要去哪里吃晚饭后，你可以关闭右边的地图，将其替换成「Notes 备忘录」app，从而去完成其他事情。

第四个例子是「Mail 邮件」，这是第一个有不同类型多窗口功能的 app。当你回复一条消息时，你可以把这个模态窗口变成一个单独的窗口，以 Slide Over 或者 Split View 的方式展示。你可以看到在单独的这个信息窗口中有一个发送按钮和一个取消按钮，你不能在这个窗口中回到上一级的邮件列表中，这种窗口是经过特殊设计的，当你点击发送或者取消按钮时，这个窗口就会关闭，关闭时会有一个过渡动画，这也可以应用在你的 app 中。

你可以通过滑动窗口底部的知识条在多个 Slide Over 的窗口中切换。

第五个例子是「Messages 信息」，它也有不同类型的多窗口。当你把一条消息拖动到屏幕边缘时，就可以开启一个单独的窗口，一个只属于那个对话的窗口。你会在窗口顶部看到一个完成按钮，点击就可以完成这个任务。在浏览一条信息时可以同时查看另一条信息作为参考是非常有帮助的。所以在这种需要另一个页面同时作为参考时，就需要支持多窗口功能。

最后一个例子是「Calendar 日历」，日历已经支持了拖放功能，但现在通过多窗口功能，你可以在不同的窗口中同时查看两个不同周的事项，你还可以从一边拖拽一个事项到另一边。所以如果你的 app 支持了多窗口的拖放功能，你也可以获得上面这个功能的强大能力。

今年我们介绍了将 iPad app 带到 Mac 上去，Mac app 都有多个窗口，如果没有多窗口功能，Mac app 会非常奇怪。但现在有了 iOS 13 的多窗口功能，这件事就变得更加顺理成章了。

那具体用户可以通过什么样的交互打开多窗口功能呢？
首先来看下系统提供了哪些交互。在 App Expose 中，右上角会有一个小按钮用来打开新的窗口，这是系统自带的功能。

另外一个就是可以通过拖拽 app 的图标到屏幕的边缘开启多窗口功能，因为当你那样操作时，就像是确切的在说我要在这里开启一个新的窗口。

再来看下用户会根据已有的东西做出哪些动作来想开启多窗口功能。用户可以直接拖拽 Safari 的某个 tab 到屏幕边缘来开启多窗口功能，这种交互系统不能自动帮你实现，但你可以通过 API 适配实现这个交互。

如果用户可以拖拽起某个对象，并且打开一个新的窗口可以讲得通的话，那用户就期望有这么一个功能，你应该去实现他。比较普遍的例子就是任何形式的「master-detail view 主要-详情视图」，比如在「Mail 邮件」中，左侧主视图中的每一个 cell 都代表着一条消息，如果点击一条消息，那就可以在详情视图中看到完整的消息。所以用户就会期望当拖起 table view 中的一条消息到屏幕边缘时可以打开一个新的窗口。

你也可以通过一个确切的动作创建一个新的窗口。在像 Safari 这样有链接的应用中，可以通过长按一个链接显示一个弹窗，在弹窗中有一个按钮，通过点击这个按钮可以在新窗口中打开链接。

用户不应该被强制使用多窗口功能，应该需要一个用户触发的确切的动作才能开启多窗口功能。

UIScene 生命周期

要在 iPadOS 中实现多窗口功能，你需要特别关注两个类：UIWindowScene 和 UISceneSession。你可能在之前已经熟悉了在 UIKit 中的 UI 是如何构建的。你有一个 Screen，然后有多个 Window，每个 Window 下又有不同的 View。

而现在，UIWindowScene 插入到了 Screen 和 Window 之间，这可以让多个 Window 属于用户界面的一个单独的实例，而不需要强制改变应用或用户界面结构太多。

从基本上来看，一个 Scene 包括了根据你的需要由系统创建的用户界面。无论用户在什么时候执行了一个拖拽动作，都会根据你的用户界面请求一个新的窗口打开。之后，如果那个 Scene 应该进入后台，不再与其发生交互，那么系统就可以决定挂起它、不再需要它、销毁这个 Scene。

当我们不需要那个 Scene 时，我们可以将其移到后台，但在 switcher 中用户知道它还在。你需要一种方法去理解什么东西实际上还在 switcher 中。那就是 UISceneSession 该出现的地方。UISceneSession 代表了一种存留的用户状态，表示用户最后进行操作的那个状态。现在，它们有了一个清晰的系统角色，这可能是一个你可以在真实的设备上与其进行交互的标准的应用界面，也可能是一个外部显示器界面。每次系统上创建一个新的窗口，你的应用就会被软件代理通知有一个新的 session 被创建。无论是通过 API 交互还是用户在 switcher 中上划，每当用户销毁/关闭掉一个窗口时，你也会被通知那个 session 被销毁。UIScene 通过你的应用的生命周期与这些 session 相连接或断开连接。

为了更好地了解这对一个 app 的生命周期的影响，这里用一个图表进一步说明。在应用中有三个 Session，它们代表着系统中三种不同的空间，在这些空间中应用正在展示它们的界面。现在，三个 session 都断开了连接，它们处于后台线之下，而此时整个 app 的状态也是在后台中，如图所示。

现在，如果我激活一个空间，一个 Session 也被激活，整个 app 也会随那个连接在一起的 Scene 进入前台活跃状态。

当我让一个 Scene 回到后台中，整个应用的状态也会随之进入后台。而如果我切换到另外两个 Scene，我的应用状态就会变成前台活跃状态。

说到 UIApplication 和 UIApplicationDelegate 两个类，我们习惯于把系统的其他界面、ApplicationDelegate 中的生命周期和 Application 对象组合在一起，现在如果还是这样就会有些不清楚。

所以我们进行进一步的拆分。Application 继续表示作为一个系统进程的系统状态，ApplicationDelegate 可以获得事件和有关于进程、事件、运行、中断的代理通知。而现在 Scene 概括了 UI 状态，SceneDelegate 可以得到在特定场景打开 URL、从后台返回到前台等等这样的通知。SceneSession 代表存留的 UI 状态。

由于上面概念上的变化，许多 API 需要进行修改，但大部分都是相似的，基本上都是从 application 到 scene 的变化。

进一步实现

之前，用户在 swticher 中会看到一个 app 的四个窗口，这也是用户自然想到的。但作为开发者，我们鼓励你把他们直接看做是 scene 和 scene session。这之间的区别是很重要的，因为用户看到的窗口只是一张截图，应用的 scene 可能并没有在你的 app 中加载，它们可以根据需要出现和关闭，而 session 对你来说是总是可用的。正因如此，我们使用 session 在程序上控制窗口。

因为多窗口功能，我们增加了新的 API，可以通过这些 API 在程序上创建新窗口、更新 app switcher 中的截图、响应用户手势或者某个文档过期等事件而关闭窗口。

下面看一些代码实例。
第一个是 requestSceneSessionActivation API，这可以让你在前台打开已有的 scene 或者创建一个新的 scene。在下面的这个例子中是打开一个新的文档。首先检查应用中是否有存在的 scene，如果有打开它，如果没有，就创建一个新的。

// Open a New Window

@IBAction func handleLongPress(forDocumentAt url: URL) {

	if let existingSession = findSession(for: url) {
		UIApplication.shared.requestSceneSessionActivation(existingSession, userActivity: nil,
options: nil)
	} else {
		let activity = NSUserActivity(activityType: “com.example.MyApp.EditDocument”)
		activity.userInfo[“url”] = url

		UIApplication.shared.requestSceneSessionActivation(nil, userActivity: activity,
options: nil)
		}

}

第二个是 requestSceneSessionRefresh API，你可以在你接到一个信息的推送通知的地方或者在像日历这样的 app 中当一个事件发生改变时使用这个 API。当你调起这个方法，UIKit 会安排一个在未来时间点的更新，那时候会连接上后台中的 scene。你将有机会更新 UI，一个新的截图被截取并且保存到之后的 app switcher 中。

// Update App Switcher Snapshot

func application(_ application: UIApplication,
	didReceiveRemoteNotification userInfo: [AnyHashable:Any],
	fetchCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void) {

	let session = findSession(for: userInfo)
	application.requestSceneSessionRefresh(session)

}

最后一个是 requestSceneSessionDestruction API，你可以使用它关闭 scene，并且可以根据语义定义关闭时的动画过渡效果。你可以在「邮件」应用中的写邮件窗口看到这个实例，当用户发送一条消息时，窗口会从上面滑出屏幕，而当用户保存所写内容为草稿时，窗口会从下面滑出并提醒用户已经保存。你也可以在你的 app 的 scene 中使用相同的动画过渡效果。

// Close a Window
func closeWindow(and action: DraftAction) {
	let options = UIWindowScene.DestructionRequestOptions()

	switch action {
	case .send: options.windowDismissalAnimation = .commit
	case .save: options.windowDismissalAnimation = .decline
	case .delete: options.windowDismissalAnimation = .standard
	}
	let session = view.window!.windowScene!.session
	UIApplication.shared.requestSceneSessionDestruction(session, options: options)

}

最佳实践

正如前面所说，我们已经从 UIApplicationDelegate 中拆分了用户界面状态和进程的生命周期责任，也拆分了 UIApplication。你可以同时看到应用的多个 scene，你可能会有一个浅色的状态栏内容，还有一个深色的状态栏内容。如果对于状态栏还是只返回一个值那就讲不通了。所以，原有基于应用的状态栏 API 被舍弃，引入了新的基于 window scene 的状态栏 API。
其他类似的 API 也是这样。
即使你现在不准备适配多窗口功能，我们也鼓励你现在就开始直接使用新的 API，因为如果你之后需要适配这个功能，就不用再花更多的功夫了。

调试建议

每一个 app 都有独一无二的挑战：你的 app 中会有许多自定义的代码，虽然已经有许多系统框架帮助你，但我们无法预测你需要做出多少改变，但一定会有。
做出改变：仔细思考过去写下的代码，适配新的生命周期，特别是适配多个 scene 的情景。
一遍一遍的测试：如果你有自动化测试，那很好，但即使通过，用户可能也会遇到 bug。找出问题最好的方式就是把玩你的 app，同时观察 app 的两个界面，快速找出问题。
更加注意多个 scene 的情景：因为现在不再只是一个界面，不再只有一个 view controller 的实例。

参考链接

把 iPad 上的 app 带到 Mac 中去（下）

2019-10-02T01:21:43+08:00

把 iPad 上的 app 带到 Mac 中去的上篇取材于 iOS HIG，从大的层面讲述了移植 app 到 Mac 中去的一些设计规范，取材于 WWDC session 的下篇将用更多的示例和图片主要围绕架构、工具栏、布局、排版、颜色、手势、触控栏、app 图标、情景化菜单、菜单栏菜单十个部分讲述更多移植的细节。

第一步：提供一个可靠的基础

你的 iPad app 应该支持自动布局功能，因为正如我们所知道的，Mac 的窗口可以被随意调整大小。

类似的，如果你的 app 支持拖放，你离出色的 Mac app 就更近了一步。我们期望 Mac 上的每一个东西都是可拖拽、可释放的。

像拖放功能一样，iPad app 在独自的窗口可以打开文档的这种多窗口能力也期望在 Mac 中实现。如果你的 iPad app 支持多窗口功能，你将会在 Mac app 中自动获得这项能力。

轻松实现

为了把 iPad app 带到 Mac 上更简单，许多 iOS 的界面和交互会自动适配成等价的 macOS 的样式。

iOS 的分隔视图（split view）会被绘制成 Mac 上的分隔视图（split view）；
系统提供的 UI 像是文件浏览器（file browser）和活动视图（activity view）会被映射到等价的样式；
iOS 上的编辑菜单（edit menu）和情景菜单（contextual menu）会被自动变成 Mac 上的情景菜单（contextual menu）；
复制和粘贴（copy and paste）、富文本编辑（text editing）、按键焦点（key focus）也同样轻松地转化到 Mac 上。

在上面这些例子中，iOS 和 macOS 之间的映射都是很直接的。然而，在 macOS 和 iOS 之间会有一些核心区别。设计一个适合每个平台的 app 需要理解和考虑到这些区别。最大、最关键的区别是 iOS 是根据触控来设计的，而 Mac 是根据键盘和鼠标输入来设计的。

为触控而设计包括提供一个更大、更容易操作到的触控目标，特别是在你到处走动时。在 Mac 上，使用触控板或者鼠标可以提供物理稳定性和更好的控制。因为光标很小，人们可以用更好的精确度瞄准和控制交互对象。

更小的控件也允许 Mac 的 UI 拥有更大的信息密度、更好的控制密度。所有的 iOS 设备都支持像是拖动（pan）、旋转（rotate）、pinch（捏合）这些的多点触控手势。有一些 Mac 的配置没有多点触控输入方式。
所以如果你的 app 中的任何交互或者任何动作需要依赖手势输入才能被执行，你就必须为 Mac 寻找替代解决方案。

当 iPhone 以竖直方向被我在手中时，把控件放在屏幕中间或者底部会让人们更容易触及到，对于横屏模式下的 iPad 也是这样。

人们倾向于紧握住一边，所以把控件放在左边或者右边会让人们更容易操作到那里。明显的，人们在使用 Mac 时不会用手拿着设备，把控件放在屏幕底部或者左右边缘没有任何人体工程学的益处。屏幕的每一块区域都和其他区域一样容易被操作到。

说到屏幕，你需要考虑你的 app 在 1x 非视网膜屏幕上的显示效果。特别关注那些文本中的图形，让它们看上去清晰可读。

交互模型和设计模式

通过以上，可以基本理解触控设备和桌面电脑的不同。但不清楚的是在 iOS 和 macOS 之间的交互模型和设计模式具体有何不同。这些不同是成功把你的 iPad app 的设计转换到 macOS 上去的关键。

架构

对于 app 的设计来说，没有什么比它的架构是怎样的还重要。一个有逻辑的、直观的 app 结构可以帮助人们发现他们寻找的，并且让导航更顺畅。iOS app 倾向于通过三种方式来组织结构。
有一些 app 使用 tab 来让信息分隔成几个一级的 tab；

有一些 app 在 table view 中展示一个一级的列表；

有一些基于文档的 app 在一级使用文档浏览器的 UI 样式。

你的 app 可以选中其中一种。简单的方法就是寻找最接近的 macOS 等价样式并使用它。
对于使用 tab 的 app，你可以在 Mac 的工具栏上使用分段控件（segmented control）。

如果你的一级导航是一个主列表，你什么都不用做，它将以同样的方式出现在 Mac 上。

文档浏览器 UI 样式的 app 也是同样如此。

从 iOS 到 macOS 上这种 app 结构的直接转换可能是正确的方法。它可以提供一个核心好处，对于那些已经熟悉你的 iOS app 的人们来说，你的 Mac 版本的 app 他们也会马上熟悉。
另一方面，你可能会错过一个简化导航的重要机会。在 Mac 上，边栏（sidebar）是一个重要的导航工具。它更容易承载大量的选项，这些选项可以被分组、被标签以帮助提供额外的情景信息、让它们更容易被用户看到。所以，如果你现在有一个 tab 样式的 app，你可以通过分段控件呈现这些 tab，也可以把它们放到边栏中。

下面这个 app 的转换看上去不太合适，因为只展示了四个选项，没有有效利用屏幕空间。但如果这四个 tab 有次级 tab，你可以把他们直接展示出来。这极大地扁平化了 app 的层级，允许人们可以直接在次级 tab 间移动。甚至可以允许用户根据需要自定义这些条目。

如前面所看到的，如果你的 app 有一个一级的列表或者 table view 用来在不同部分间导航，直接转换它。分隔视图是在 Mac 上获得边栏的方式。你只需要开启半透明的背景就好。

如果你的 app 在一级中展示了一个文档浏览的 UI 样式，你可以使用一个边栏提供对文件夹的永久访问或者展示已保存的搜索结果。

如果你使用了边栏，这里有两点需要记住。第一点，边栏让人们可以访问 app 中或者文档集合中的某些位置，但并不意味着直接展示文档或者其它类型的内容。

第二点，边栏在帮助用户理解哪个窗口或者哪个 app 拥有核心焦点时扮演了重要的角色。当当前窗口是活跃状态时，图形、选项高亮、边栏背景看上去是半透明的。当窗口变成不活跃时，这个效果就会消失。

知道哪个窗口会响应键盘输入是非常重要的，为了支持这个效果，使用一个半透明的背景。

不要用固定的颜色或者图片填充边栏。对于选项高亮状态，使用系统选择的颜色而不是一个自定义的颜色或者 app 的主题色。

通常情况下，你应该使用有虚化效果的模板图片（template image）而不是全色图片，除非真的有必要。

工具栏

工具栏（tool bar）是 Mac app 中非常常见的地方，你可能想要在你的 app 中使用一个工具栏。把控件放在工具栏上可以让它们更容易被发现。也会创造一个更稳定的用户体验。

工具栏可以创造一个从上到下的信息流，这也是 Mac app 的规范。

如果你的 iPad app 有任何的操作始终位于屏幕底部，如果在 Mac 上也这样做就会有问题。Mac 的窗口是可拖动的，Mac 窗口的底部可能会拖到屏幕外部或者 Dock 下面，因此这会导致一些可用性问题。

当把操作放置在工具栏上时，记住一个工具栏的内容不会基于 app 现在处于的位置而发生变化。如果在 app 的某个位置某个动作不可用，它们可以被置于禁用状态。如果没有任何东西被选中而被可执行，那工具栏上的操作就是被禁用的。

如果某些动作只与 app 中的某些动作相关，它们可能不适合放在工具栏上。你可以在一个操作菜单（action menu）里提供情景化相关的操作，操作菜单里的操作可以基于当前视图或者选中项动态变化。

例如，在 Finder 窗口中文件被选中，操作菜单会包括那些可以操作文件的操作；什么都没有选中时，操作菜单会包括那些操作当前文件夹的操作。操作菜单并不意味着包罗万象，所以选择好该放进哪些操作进去。

布局

Mac 的窗口比 iPad 大得多，你会拥有更大的空间进行发挥，特别是在全屏下。但要利用好所有的空间需要一个为 iPad 最优化的布局。

一些 iPad app 的布局直接放大了 iPhone 的界面，在 iPad 上看上去很糟糕，在 Mac 上特别是在全屏下看上去更糟糕。

为 iPad 和 Mac 最优化布局需要一些特别的考虑。对于两边的设备，可读内容边界可以让每一行文本不会太长以保持可读性。

把内容切分成多列可能是最大化信息密度的一个好方法。

使用分隔视图或者主要-详情视图是利用好更宽屏幕的好方法。分隔视图通过同步展示一系列对象和选中对象的详情来简化导航，这可以减少在 app 层级间不断进去出来的需要。如果在你的 app 中有一个分隔视图，不需要任何修改就可以在 Mac 中工作的很好。

让你的 app 的布局在 Mac 上工作的很好可能是为 Mac 和 iPad 识别和解决布局问题的最好方式。

排版

在 macOS 中，基准字体字号是 13pt，大多数的控件和文字标签都会是这个大小。而在 iOS 上，基准字体字号是 17pt。在 Mac 上展示一个 17pt 字号的 iOS app 会看上去不合适，文本会显得太大了。

为了保持 Mac app 之间的一致性，系统会缩放内容区域到原来的 77%。这意味着你不需要重新设计或者重新编码 Mac app。

但是这样也会在设计上带来一些复杂度。当创建 iPad app 的原型时，你会想要重新创建 77% 缩放的样式。例如在 Photoshop 中，你可以把整个内容区域放进一个智能对象，并缩放到原来的 77%。同样的处理方式也可以在 Sketch、Adobe XD 或其他设计工具中实现。

在 macOS 中，app 倾向于只使用几个不同的字体字号。而在 iOS 中，文本样式更加动态多变。文本样式（text style）提供了非常多的字号选项。使用最小的字号如「footnote」、「caption one」、「caption two」会让文本在 Mac 上不易读。即使是 Mac 上的「mini」字体样式的字号也总是很小。所以你可能需要增大一些文本的字号以让其可在 Mac 上可读。

还有最好一点需要注意，Mac 并不支持动态类型（dynamic type），Mac 会直接使用 iOS 上的「Large」样式，并将其缩放到 77%。

颜色

在 iOS 中，颜色会被用来表示元素是可交互的或者高亮选中的条目，一些 app 还会用颜色绘制内容区域和栏的背景色。而在 Mac 上，事情有一点点不同。

对于用户来说，同时打开有多个内容的多个窗口或者在桌面上打开多个文件或文件夹是非常普遍的。如果 macOS app 像 iOS app 一样大幅度使用颜色的话，用户体验就会支离破碎。

Mac 的界面应该是更加中性的。它们不应该与呈现给人们的内容相竞争。同时半透明效果会让你的 app 与 Mac 生态系统融为一体。人们很喜欢自定义自己的 Mac 桌面壁纸，半透明效果会影响这些 app 的显示效果，给用户带去一种紧密结合的体验。类似的，在 Mac 上高亮颜色也是用户的一个偏好设置。如果你的 app 使用了一个不同的颜色去高亮选中的条目，这将会很不合适，并且对用户造成困惑。

在颜色使用上，iOS 其实也正在逐渐变得像 macOS 一样。通过多任务，多个 app 同时展示会变得越来越平常。一个一致的视觉外观可以提供一种统一的用户体验。通过深色模式，人们希望更好地控制 app 在设备上的显示样式。如果 app 不能相应用户的偏好设置，这会让用户觉得 app 离群了。

描边颜色也在发挥着一部分作用，以前习惯于有一个描边颜色的 stepper 和 segemented control 在 iOS 13 中也变得更加中性。

你可能已经知道，iOS 13 上的系统颜色已经焕然一新（如果你还不知道，可以点击这里查看 iOS 13 的系统颜色新变化）。如果你在 iOS app 中使用这些颜色，它们会在 macOS 中的浅色和深色模式中被映射到对应的等价样式。

手势

iOS UIKit 中的手势将会自动映射成对应的鼠标或触控板事件。轻点会被映射成鼠标点击，长按会被映射成鼠标点击并按住，拖动会被映射成用鼠标拖动。滑动手势会被映射成在合适的方向拖动。在触控板上，可以实现捏合和旋转，但有一些小小的不同。在 iPad 上，捏合和旋转会使用触控点之间的中间点去控制对象或者旋转以及缩放。在 Mac 上，光标的位置会被用来达成这个目的。屏幕边缘滑动不会被映射到 Mac 上去。

一些手势不会被转换到 Mac 中去，例如下拉滚动视图完成刷新的这个手势就不会很好地被转换到 Mac 中去。

对于任何由手势输入触发的操作，你需要找到一个替代解决方案从而去执行相应操作，你可以使用许多栏菜单、情景化菜单或者工具栏上的按钮，抑或是上面的所有方法。
在 Mac 上你可以接收到鼠标 hover 事件，你可以利用这个去展示光标所在处的额外信息。例如，在「股票」app 中，你可以在 iOS 上通过长按股票图表显示特定时间点的价格，而在 macOS 中，鼠标悬浮在上面并滚动就可以查看不同时间点的价格。你应该利用好 hover 状态，这是一种对于人们很有用的不需要改变选择状态就可以获得信息的方式。

触控栏 Touch Bar

你可以为你的 iPad app 在 Mac 上创建触控栏功能。触控栏是一个非常好的方式用于展示情景化信息，你可以基于人们在 app 的不同区域或者选择的对象显示不同的触控栏。大多数的触控栏组件和控件都可以使用。

可以在 macOS HIG 中查看触控栏的更多内容。

App 图标

Mac app 的图标是 app 的门面。它们帮助人们分清安装的成百上千的 App，它们会出现在许多地方，dock 栏、app switcher、Launchpad、应用程序文件夹等等。默认情况下，你的 iOS app 的图标是由一个一致的圆角矩形包裹着。在 Mac 上，一个微弱的投影会被应用到图标上以保持与其他 Mac app 图标的一致。你可以阻止这个行为或者重新创建一个新图标。

我鼓励你的重新创建一个新图标。因为 Mac app 的图标如此随处可见，它值得你重新创建一个。相比于 iOS app 图标，Mac app 图标有着更多的个性。它们不是简单的用圆角矩形包裹，Mac app 的图标有着独一无二的轮廓以和其他图标区分开来。即使在很小的尺寸下，这个轮廓也可以帮助用户区分不同的 app。

在 1x 显示器上，在 Finder 中的 app 图标只有 16 像素高和宽。在这个尺寸下，每一个像素都应该斟酌使用。在最小的 app 图标尺寸创建一个像素提示性图标是一个好主意。

Mac app 的图标会被创建的更像物理真实世界的物体，许多 Mac app 图标使用 3D 软件渲染而成，所以它们有着现实的光线效果和材料质地。

如果你想往这方面考虑，，可以在 macOS HIG 中查看关于相机角度和光源的更多指导。

情景化菜单

情景化菜单是 Mac 界面的无名英雄。它让人们知道一个对象可以执行什么操作。在 Mac 上，人们期望情景化菜单无处不在。所以从逻辑上来说，你应该将情景化菜单添加到各个地方。你 app 中的任何对象都应该有一个相关的情景化菜单，包括用户最常使用的操作。

如果你为你的 iOS app 已经添加了情景化菜单，它将会自动转化为 Mac 的情景化菜单。对于编辑菜单也是这样。

无论是为 iOS 还是 macOS 设计情景化菜单，你需要遵守下面这些基本准则。

避免用太多选项淹没用户：太多的选项会让用户很难找到他想要找的操作，导致花很长时间去浏览，要将焦点放在最情景化、最相关的功能上；
保持简洁：一个单词的文字标签通常会很简洁。

传达动作：当给文字标签命名时，使用动词或者动词词组表明操作被执行后的结果；
仔细排序：命令的顺序也很重要，把最重要的放在最上面，把相关的成组摆在一起；
使用分隔线成组：使用分隔线让命令间的关系更确切，把命令分组可以帮助人们快速跳过一系列与想要做的事不相关的命令；

使用次级菜单管理菜单的复杂度：使用次级菜单可以控制菜单的长度、隐藏不相关的操作。次级菜单用一个箭头来表示。

菜单栏菜单

每一个 Mac app 都有菜单栏，菜单栏是 Mac 体验的核心，可以追溯到 1984 年。菜单栏是让电脑容易使用的核心。你可以通过下面的练习来开始设计 app 的菜单栏：写下人们在你的 app 中可以执行的所有操作，记下哪些对象会被这些操作影响到。

每一个在你 app 中的操作都应该出现在菜单栏中，这让人们更容易发现和给菜单选项分配键盘快捷方式。一旦你把所有的操作分好类，你需要找一个地方承载它们。macOS 包含一系列标准化菜单栏，如 app 菜单可以控制 app，文件菜单可以操作文件，编辑菜单可以操作内容或者文件中的对象，格式菜单可以对文本修改格式，查看菜单可以自定义窗口的外观，窗口菜单可以控制窗口，帮助菜单可以获取帮助。对于许多 app ，这些标准化菜单很有用。

然而，有时候也需要提供额外的自定义菜单。如果在你的 app 中有一系列核心对象对应一系列操作，你应该考虑在一级添加一到两个自定义菜单。例如在「邮件」app 中，有两个主要的对象类型，邮箱和邮件，对于这俩对象有一系列对应的会被执行的操作，这些操作不会在其他对象上被执行，所以可以为这些对象添加对应的菜单栏菜单。

另一方面，通过一系列工作流去组织操作也是很有帮助的。在 Keynote 中，有一系列不同的对象类型可以被添加到幻灯片中，对于它们可以执行一系列操作，如对齐、分布、锁定、成组、向前或向后移动。因为所有的这些操作影响这些对象的方式差不多，所以可以基于工作流把它们放在一个菜单中。

一旦你决定了菜单栏中包含了哪些自定义菜单，你需要在其中创建菜单。上面讲到的关于情景化菜单的设计规范同样适用于设计菜单栏菜单。
补充一点，菜单栏菜单的结构应该是稳定的，在 app 运行后不应该再添加或删除菜单。像工具栏上的菜单一样，当菜单不可执行时可以设置为禁用状态。一个稳定的菜单栏系统会帮助人们搞清楚命令在哪里，即使这些命令现在不可用。当看到一个命令不可用时，这对人们来说也提供了有用的信息。

关于菜单栏还有一点，为常用命令分配键盘快捷方式。重度键盘用户会因此感谢你，在 iPad 和 Mac 上键盘快捷方式都可使用。当分配键盘快捷方式时，总是跟随惯例。你可以在 macOS HIG 中找到一个长长的列表写明标准键盘快捷方式。当使用一个从未用过的新 app 时，可以使用你早已熟悉的键盘快捷方式得到期望的结果。

小结

Mac 提供给你一个机会，让你的 app 更加强大、更加实用、更加有效率，但是这个机会同时也包含着一些需要深思的设计抉择，并且需要一些努力。

参考链接

再说 iOS 和 macOS 深色模式

2019-09-10T23:54:59+08:00

在 iOS 13 及之后的版本中，人们可以选择使用一种全局深色的外观，它就是深色模式（Dark Mode），这也是 iOS 13 设计最大的变化。在深色模式中，系统对于所有的界面、菜单、控件都使用了深色色盘，也使用了更多的虚化效果（vibrancy）以使得与更暗的背景内容相比，前景内容能够更加显眼明亮。深色模式支持所有的辅助功能。

人们可以选择使用深色模式作为系统的默认界面样式，他们可以通过设置使设备在周围的灯光变暗时自动转换到深色模式。

将焦点放在内容上：深色模式会把焦点放在你界面的内容区域，以让内容能够显眼，而周围的 UI 能够沉浸到背景中去。
在浅色模式和深色模式下都测试你的设计：观察你的 app 的界面在两种模式下是什么样子，根据需要调整设计。在一个模式下表现良好的设计在另一个模式下可能就会有问题。
当你调整对比度和透明度等辅助功能设置使，确保你 app 的内容可以在深色模式下保持舒服的可读性：在深色模式下，你应该测试在开启增强对比度和降低透明度功能时 app 的内容，包括单独开启时的测试和都开启时的测试。你可能会发现在一些深色背景上，深色的文本可读性会比较低。你也可能发现在深色模式下打开增强对比度会导致深色文本和深色背景之间的对比度。虽然具备正常视力的人们仍然能够阅读低对比度的文本，但这样的文本可能对于视力有损伤的人们就是不可读的。

颜色

在深色模式的色盘中包括了更深的背景颜色和更浅的前景颜色，他们都经过了仔细的筛选，在保持两个模式下的一致性的前提下，也确保了良好的对比度。

使用适配当前外观的颜色：语义化颜色，像是「背景颜色」，可以自动适配当前的外观。当你需要一个自定义颜色时，添加一个颜色集合（Color Set）资源到你 app 的资源目录中，指定浅色和深色模式下的颜色变种，这样就可以适配当前的外观模式。避免使用硬编码的颜色值或者不能适配的颜色。
在所有的外观下确保充足的颜色对比度：使用系统定义的颜色确保前景和背景内容间有合适的对比度比值。对于自定义颜色，以达到 7:1 的对比度比值为目标，特别是对于小的文本。
软化白色背景的颜色：如果你必须在深色模式中对于内容使用白色背景，选择一个稍微深一点的白色，以避免背景会打亮周围的深色内容。

系统颜色

iOS 根据深色模式或者浅色模式定义了以下系统颜色，这些颜色值可能随着不断的版本迭代发生变化，所以使用系统 API 去调用这些系统颜色。

为增强可读性，系统颜色还有下面这些变种：

iOS 13 还引入了六种不透明的灰色值，虽然会用到的地方很少，但可以方便你在半透明效果不好的地方使用。比如在元素相交或者重叠时，像是网格中的线或者 bar，这些地方使用不透明的颜色更好。通常情况下还是应该使用系统颜色。

同样地，为增强可读性，有下列变种：

动态系统颜色

除了描边颜色，iOS 也根据语义对背景区域和前景内容提供了定义好的系统颜色，比如文本标签、分隔线、填充。这些颜色可以自动适配深色模式和浅色模式。
iOS 定义了两个系列的背景颜色：一个系列是「系统背景颜色」，另一个系列是「成组背景颜色」。每一个系列都包含了四个等级的变种以帮助传达信息的层级。通常情况下，在成组的 table view 上使用「成组背景颜色」，否则就使用「系统背景颜色」。

使用这两个系列的背景颜色，你可以通过下面这些方式使用不同的等级变种表现层级：

在总体视图使用一级；
在位于总体视图上的成组的内容和元素上使用二级；
在位于二级元素上的成组的内容和元素上使用三级。

对于前景内容，iOS 系统定义了下面这些颜色：

不要重新定义动态系统颜色的语义化定义：为了给人们创造一致化的体验，确保你的 app 的界面在不同的情景下都表现得没问题，应该倾向于使用动态系统颜色。
不要尝试复制动态系统颜色：动态系统颜色可能基于不同的环境变量，随着版本的迭代发生波动。使用动态系统颜色去搭配系统颜色，而是创造自定义颜色去搭配系统颜色。

图片、图标、标志颜色

iOS 13 的系统使用了 SF Symbols，它可以在深色模式下保持美观。系统也使用了经过对浅色模式和深色模式都优化了的全颜色图片。

在任何可能的地方使用 SF Symbols：使用了 SF Symbols 后，当你使用了动态颜色去给标志着色或者是增加了一层虚化效果时，标志都可以在两种模式下保持美观。
必要时，为浅色和深色模式分别设计独立的图形元素：在浅色模式中，图形使用中空的描边，而在深色模式中，图形使用实心填充的形状样式可能会更好。
确保全颜色的图片和图标显示没问题：如果在两种模式下看起来都不错，那就可以使用相同的资源。如果一个资源只在某个模式中显示没问题，那就修改资源或者为两种模式创建分别的资源。使用资源目录把两个资源组合成一个，命名成一张图片。

文本颜色

虚化效果可以使得深色背景上的文本保持良好的对比度。

对于文本使用系统提供的文本颜色：系统提供的一级、二级、三级、四级文本颜色可以自动适配浅色和深色模式。
使用系统视图绘制文本输入框和文本视图：系统视图和控件可以使你 app 的文本在所有的背景下看起来都没问题，并且可以根据虚化效果的有无自动调整适配。当你可以使用系统提供的视图去展示文本时就不要自己单独绘制文本视图。

材料

iOS 提供了材料效果（materials，也可叫 blur effects）以通过一种半透明的效果在 app 中创造深度的感觉。材料效果可以让视图和控件既暗示了背景上的内容，又不分散前景内容的注意力。为了制造这种效果，材料允许背景颜色信息穿过前景的视图，同时也会模糊背景的情景以保持可读性。

当你使用系统定义的材料效果时，你的 app 的元素会在各个情景中看起来都很好，因为这些效果可以自动适配系统的浅色模式和深色模式。

以系统使用的材料效果为指导：在任何可能的时候，比较具备相似功能的你的 app 的自定义视图和系统提供的视图，对其使用相同的材料效果。
利用好系统提供的文本、填充、图形、分隔线颜色：系统提供的颜色可以让这些元素在半透明的背景上看起来不错。
在任何可能的时候，使用 SF Symbols：当你使用动态系统颜色去给一个标志着色或者应用一个虚化效果时，标志可以在任何情景中都看起来不错。与之相对比，全颜色的图片可能不能与背景形成足够的对比度，在用在一个半透明背景的视图上时也可能不合时宜。

系统定义的材料和虚化效果

iOS 定义了你可以在指定的区域使用的多种材料，以控制前景内容和背景的视觉分隔。系统提供的材料包括浅色和深色两种变种，可以很好地匹配大多数背景。

为了让材料用在内容容器中，iOS 13 定义了四种不同透明度的材料：

SystemUltraThinMaterial
SystemThinMaterial
SystemMaterial （默认）
SystemThickMaterial

注意以下几点：

在选择材料时考虑对比度和视觉分隔：在选择使用哪种材料与虚化效果组合时，没有绝对的规则。在做出选择时考虑下面这些方面：
- 更厚的材料可以在文本和其他元素间提供更好的对比度；
- 通过在背景中提供一个内容的可见提醒，不透明度可以帮助人们记住当前的场景。

iOS 13 也为文本、填充、分隔定义了虚化值，可以与每一种材料匹配良好。通过从背景颜色中抽样、修改饱和度，虚化使 UI 元素更亮或更暗。虚化的 UI 元素可以与材料融合得更好，并增强半透明效果。

文本和填充都提供了几种等级的虚化效果，分隔线只有一个等级。等级的名字表明了元素和背景间的相对对比度，默认层级有着最高的对比度，第四等级有最低的对比度。

除了第四等级，你可以在任何材料上对文本使用下面的虚化效果值。不推荐在薄和超薄材料上使用第四等级，因为对比度太低。

label（默认）
secondaryLabel
tertiaryLabel
quaternaryLabel

你可以在任何材料上对填充使用下面的虚化效果值：

fill（默认）
secondaryFill
tertiaryFill

iOS 为分隔线定义了一个默认的虚化效果值，它可以与任何材料上都匹配地很好。

基于语义化含义选择虚化效果：避免混用这些效果，例如，不要给分隔符使用文本的虚化效果。

在 iOS 上实现 Dark Mode

使用 iOS 13 SDK 以实现对深色模式的支持；
在系统提供的功能之外，自定义 app 的外表。

颜色

在过去，每一个 UI 颜色都只有一个值，现在 UI 颜色变成了动态的。当你在一个视图上使用动态颜色作为背景颜色或者文本颜色时，UIKit 会自动地使用正确的值，当模式发生变化时，会自动更新，所以你只需要设置颜色一次就好了。

材料

在下面的例子中，背景中有一张图片，我想在上面添加一些模糊效果。首先创建一个 UIBlurEffect，并且指定样式为系统材料。然后创建一个 UIVisualEffectView ，并在这个 view 中使用前面创建好的样式。进一步确定这个 view 的尺寸和位置，把它放到背景图片上。

接下来可以在这个材料上添加一些虚化内容，虚化效果（vibrancy effect）可以让背景材料的一部分穿过。过去，这种效果只有一种样式，但现在有了多种样式：四种文本样式、三种填充区域样式、分隔线样式。我们创建一个 UIVibrancyEffect 并指定它的样式为「fill」，为了展示这个样式，我们创建另一个 UIVisualEffectView ，然后把它放进前面创建的 UIVisualEffectView 的「contenView」中。

iOS 的深色模式如何工作？

颜色

动态颜色可以在不同模式间自动切换，那颜色是怎么知道它是浅色还是深色的呢？这是通过「trait collections」来实现的。每一个 view 和 view controller 都有一个 trait collection，它可以帮助决定 view 的外观。

如果我们想解析某个特定的颜色，可以通过下面的代码实现：

let dynamicColor = UIColor.systemBackground
let traitCollection = view.traitCollection
let resolvedColor = dynamicColor.resolvedColor(with: traitCollection)

当然你也可以通过代码创建自定义的动态颜色，具体代码如下：

let dynamicColor = UIColor { (traitCollection: UITraitCollection) -> UIColor in if traitCollection.userInterfaceStyle == .dark {
return .black } else {
return .white }
}

动态颜色可以直接像其他颜色一样被直接调用，它是怎样自动解析的？如果有一个动态颜色，我请求他的 RGB 值，它就会返回一个结果。这是通过「UITrait Collection」的「current」属性来实现的。

注意在 UIKit 之外，「current trait collection」不会有一个特定值，你需要自己去解析颜色。例如在像「CA Layer」、「CG Color」这种低等级的类就无法直接理解动态颜色。下面是示例代码：

 let layer = CALayer()
 let traitCollection = view.traitCollection

// Option 1

let resolvedColor = UIColor.label.resolvedColor(with: traitCollection)
layer.borderColor = resolvedColor.cgColor

当需要调用的颜色比较多时，可以使用下面这种代码写法：

let layer = CALayer()
let traitCollection = view.traitCollection

// Option 2
traitCollection.performAsCurrent { 
	layer.borderColor = UIColor.label.cgColor 
}

还有第三种写法，注意 trait 会发生变化的情况：

let layer = CALayer()
let traitCollection = view.traitCollection

// Option 3 
let savedTraitCollection = UITraitCollection.current 

UITraitCollection.current = traitCollection 
layer.borderColor = UIColor.label.cgColor 

UITraitCollection.current = savedTraitCollection

图片

UIImageView 和 UIColor 一样会根据当前的 trait collection 决定显示哪一张图片。

但 UIImage 不会关注当前的 trait collection。如果你想自己解析某张图片，你可以通过下面的代码实现：

let image = UIImage(named: “HeaderImage”)
let asset = image?.imageAsset
let resolvedImage = asset?.image(with: traitCollection)

Trait Collection

来总结一下 trait collection 是如何工作的？它在深色模式中扮演着核心的角色。记住最重要的一点，trait collection 在你的 app 中不止一个。
Trait collection 贯穿了你的整个 app，从屏幕的根层级一直到窗口屏幕。当模式发生变化时，贯穿整个 app 的 trait collection 都会发生变化。

当 app 处于浅色模式时，你只想让 app 的某部分 UIView 或 UIViewController 处于深色模式，你可以通过下面的代码实现。

UIViewController：

class UIViewController {
var overrideUserInterfaceStyle: UIUserInterfaceStyle
}

UIView：

class UIView {
var overrideUserInterfaceStyle: UIUserInterfaceStyle
}

如果你想让整个 app 保持一种模式，你可以通过「Info.plist」的「UIUserInterfaceStyle 」去设置。

深色模式 API 更新

在 iOS 13 之前的版本中，有两种样式的状态栏：「default」和「lightContent」；而在 iOS 13 中「default」样式会根据系统外观自动变化。同样的，「UIScroll」视图的「indicator」样式也发生了同样的变化。

对于「UIActivityIndicatorView」原有的几种样式都被废弃。现在它们根据尺寸分成两种样式，颜色默认是灰色，在两种模式下都可以显示的很好，当然你也可以自定义颜色。

在绘制文本时，如果你是使用了「UILabel」、「UITextField」、「UITextView」，你只需要设置其中的文本颜色为「label color」就可以良好地适配不同外观。但如果你使用了属性字符串，那需要特别指定一个前景颜色。

let attributes: [NSAttributedString.Key: Any] = [ 
	.font: UIFont.systemFont(ofSize: 36.0) 
	.foregroundColor: UIColor.label
]

对于 app 中出现的 web 内容，同样可以适配不同外观模式。

对于 tvOS 适配深色模式和将适配了深色模式的 iPad app 带到 Mac 上去：

在 macOS 上实现 Dark Mode

待补充...

参考链接

把 iPad 上的 app 带到 Mac 中去（上）

2019-09-10T23:47:00+08:00

当你把你的 iPad 上打造的 app 带到 Mac 中去时，你就给了人们一个机会可以在具备宽大的屏幕、杰出的原生表现和充足的本地存储的 Mac 上享受你的 app。

开始之前的准备

大多数的 iPad app 都适合这种改造，但是一些依赖 Mac 上没有的 iPad 功能的 app 可能就会有些问题。例如，如果你的 app 的核心功能是需要 iPad 的陀螺仪、加速剂或者是后置摄像头，亦或是想 HeathKIt、ARKit 这种 iOS 框架，又或者是 app 的主要功能是一些有关导航的事情，那这种 app 就不适合 Mac。

对于那些没有要求只在 iPad 上才有的功能的 app，确保你的 app 可以良好运行在 Mac 上的最佳方法就是确保这些 app 也可以在 iPad 上运行良好。特别地，你的 app 应该：

支持多任务功能（multitasking）：那些运行良好的 app 在 iPad 上都会支持 Split View、Slide Over、Picture in Picture 功能以改变界面的大小，对这些功能的支持也使得 app 能够接近 Mac 用户期待的窗口可以随意调整大小的终极目标。
支持拖放（drag and drop）：当你在你的 iPad app 上支持拖放功能时，你的 app 就在 Mac 上自动获得了这项功能。
可以对键盘快捷方式，包括 macOS 通用的键盘快捷方式作出响应：即使一个键盘并不总是能操控你的 iPad app，但 iOS 和 macOS 用户会很希望使用键盘快捷方式来提供与 app 交互的效率。

针对 Mac app 考虑一些增强功能

当你使用 Mac Catalyst 去为 macOS 构建 iPad app 时，你可以自动获得 Mac 基础功能的支持，例如：

系统偏好设置；
键盘、触控板、鼠标和触控栏的输入，包括按键对焦和键盘导航；
窗口管理；
富文本交互，包括复制、粘贴、情景化编辑菜单；
文件管理。

额外的，许多系统提供的 UI 元素会从 iOS 自动地转移到 macOS。例如，你可以获得下面这些 iOS 项目的适合的 macOS 版本：

Split view 分隔视图
File browser 文件浏览器
Activity view 活动视图
Form sheet 表单
Contextual actions 情景化操作

为了确保你的 app 可以给用户一个丰富的 Mac 使用体验，增强这些基础，不仅仅是简单地在 macOS 窗口中展示 iOS UI 是非常重要的。在你深入下去更新这些特定的视图和控件之前，先熟悉平台之间的主要不同点，这样你就可以在 Mac 上创造十分合适的 app。

iOS 和 macOS 系统都根据用户使用设备的不同方式分别定义了设计模式和用户交互的惯例。例如，在 iOS 上有轻扫删除的管理，有在手持设备上为触摸屏最优化的 action sheet 命令和控件都会出现在屏幕底部的惯例。相似的，在 macOS 上有键盘快捷方式的惯例，有为键盘、鼠标、触控板交互和单独显示器最优化的菜单命令和控件都会出现在窗口顶部的惯例。

这些对适配有着最大影响的惯例和设计模式可以归纳为下面四个核心区域：

导航：许多 iOS 和 macOS 的 app 通过相似的方式组织数据，但它们使用不同的控件和视觉标记帮助人们理解和在数据间导航。
用户输入和交互：虽然 iPad 和 Mac 都可以通过许多设备接收输入信息，例如屏幕多点触控、键盘、鼠标、触控板，但是可触摸的交互形成了 iOS 的惯例，而键盘和鼠标的交互形成了 macOS 的惯例。
菜单：Mac 用户对常驻的菜单栏非常熟悉，并且期望在菜单栏的菜单中找到所有的 app 命令。另一方面，iOS 并没有一个常驻的菜单栏，iOS 用户只会在 app 的 UI 中找到 app 的命令。
内容大小：在 iPad app 的 macOS 版本中的文本看上去会跟 iOS 一样，因为 SF 字体可以在所有的平台上使用。然而，在 iOS 上的基线字体尺寸是 17pt，而在 macOS 上最通用的字体尺寸是 13pt。为了确保你的 app 的文本和交互元素可以与 macOS 环境一致，iOS 视图会自动缩小到原来的 77%。

除了适配 macOS 的交互和设计惯例，你还需要更新你的 app 的视觉设计和布局以利用好 Mac 更宽大的屏幕，并给 macOS 用户一个良好的使用体验。例如，你可能需要：

把一列内容或者操作变成多列；
在主要内容旁边展示一个查看器 UI，而不是一个 popover；
同步展示你的 app 层级中的两个层级或者更多层级。

理想情况下，从 macOS 设计惯例的角度查看 iPad app 也是一种改进 iOS 版本的方法。如果你想确保每一个版本都能与它的平台惯例保持正确，那就用这个机会重新审查你的 app 的设计。特别是如果你的 iPad app 是从 iPhone app 发展而来的，重新仔细考虑你放置视图和控件的方法，看看这里是不是有地方可以更好地利用好 iPad 的大屏幕。

适配 macOS app 结构和导航惯例

设计良好的 app 导航通过遵循平台的惯例反映数据的结构，为 app 的首要目标提供支持。为了帮助 macOS 用户在使用你的 app 时不会陌生，你需要把 iOS 的导航惯例翻译成 macOS 的等价惯例。

大多数的 iPad app 使用扁平的导航或者层级导航，有些 app 两种组合使用。扁平导航把功能区域或者数据分类作为同一等级的组展示，它们每一组都是始终可用的。例如，「音乐」和「应用商店」app 使用了扁平导航让用户可以始终访问最高层级的区域，例如资料库、为你推荐、浏览、今天、游戏。层级导航把信息以树状结构呈现，用户通过在每个视图中选择一个条目，直到抵达目的地。例如，在设置中人们可以通过「通用」→「键盘」→「文本替换」来自定义文本替换。

通常情况下，iPad app 使用下面这些 UIKit 控件来实现导航：

Tab bar 标签栏：Tab bar 通过在屏幕底部的 bar 上始终展示一个最高层级的目录来支持扁平导航；
Page control 页码控件：一个 page control 通过在屏幕底部展示一系列的圆点来表明在多个扁平页面组成的列表中当前页面的位置。
Split view 分隔视图：一个 split view 可以通过在一级视图（或者叫主视图 master view）和二级视图（或者叫详情视图 detail view）展示条目或者功能来实现层级导航。当人们在一级视图中选择一个条目，分隔视图就可以在二级视图中展示与这个条目相关联的内容。

将 iOS 上的 tab bar 转化成 macOS 的控件时需注意：

如果你在 iPad app 中使用了 tab bar，考虑使用一个 segmented control 分段控件或者在一个分隔视图控制器中使用边栏背景样式：这两种样式与 Mac 上的窗口样式有着相似的导航惯例。为了在这些条目中选择，考虑下面这些要点：
- 一个分段控件和一个标签栏可以提供相似的交互，例如互相排斥的选择，所以一个分段控件可以作为直接适配的替换选择。一个分段控件对于在每个 tab 中没有很多层级的 iPad app 是理想的，因为它可以在一个 tab 中与一个边栏搭配发挥导航的作用。
- 一个边栏展示了一个顶级条目的列表，每一个条目可以包括一个子条目的列表。使用边栏可以让导航更流畅，因为你可以让用户在边栏中看到每个 tab 的内容。边栏对于展示不会经常改变的 app 特定的或者用户特定的分类是一个好的选择。例如，在「News」 app 的边栏中，即使人们可以改变每个分类列出的条目，但「订阅中」和「建议」分类就不会经常改变。
你也可以在 app 中把分段控件和边栏组合使用。例如，你可能需要分段控件去容纳 tab，需要边栏去展示每个 tab 的内容。不管你怎么适配你的 tab bar，确保让用户可以通过 macOS 的查看菜单内，快速访问每个 tab 的内容。

将 iOS 上的 split view 转化成 macOS 的控件时需注意：

如果你在 iPad app 上使用了分隔视图，macOS 会自动将其转化成 Mac 版本的分隔视图：在两个平台上，主视图是呈现各种条目列表的好选择，例如在「邮件」应用中的邮箱列表，因为它可以既包含文本又包含图标，还支持排序和过滤功能。然而，如果你的内容层级超过两个层级，在主视图和当前详情视图之间的中间层级就会在 Mac 样式的窗口中看不见。为了确保人们可以沿路径返回，在工具栏上要包括一个后退按钮。

将 iOS 上的 page control 转化成 macOS 的控件时需注意：

如果你通过使用页码控件或者另一种方式来实现横向导航，给用户一个特定的控件可以查看页面：如果你支持这种样式的水平导航，你可以在 Mac 样式的窗口中通过在工具栏上展示一个「下一页/上一页」按钮或者在菜单栏的菜单中添加导航命令来帮助人们在页面间导航。例如，macOS 上的「股票」应用既在工具栏上展示了一个后退按钮，也在查看菜单中展示了下一个和上一个命令。

对于多窗口要注意的点：

如果你在你的 iPad app 中支持多窗口功能，那在 macOS 的版本中也会获得多窗口功能的支持。另外，许多 macOS app 让人们可以在新 tab 中打开新的文档或其他内容，而不是在新窗口中打开。例如，人们可以在 Safari 的窗口中的每个 tab 中打开不同的网页，在一个 Finder 窗口中的每个 tab 中打开不同系统路径的文件系统。当人们使用系统偏好设置去设定更喜欢 tab 而不是窗口时，系统会把相关的菜单条目动态地添加到 app 的菜单中去，例如「视图」→「显示标签栏和窗口」→「显示下一个标签」。

支持 macOS 的用户交互

「Selection persistence 持续保持选择状态」是 iOS 和 macOS 用户交互的基本不同。因为许多 macOS 用户期望只通过使用键盘来控制 app 和系统，对象的选择状态必须一直保持，人们才可以通过一连串的键盘敲击去选择一个对象，再通过一连串的敲击去执行对象。相对比的，iOS 用户期望执行一个对象时不需要选中它，所以对象没有必要一直保持选中状态。众所周知，iOS app 并不是为最优化的键盘交互而生的。

这里有一些方式，在这些方式中不同的交互惯例会影响用户体验：

macOS 用户总是会想要「下一个」和「上一个」按钮来取代 iPad或者触控板的手势，例如在页面之间轻扫。
在一个 Mac 上，人们期望使用删除键和在菜单中选择删除命令，所以在 UI 中展示一个删除按钮通常是没必要的。
iOS 用户习惯于下拉页面刷新内容，相比的，Mac 用户期望使用一个菜单命令，例如「检查新内容」。

当你把 iPad 的用户交互模式翻译成 Mac 的交互时，将聚焦点放在让用户通过遵循平台惯例的方式操作对象上。

键盘输入

为支持键盘惯例做好准备，让用户可以通过使用方向按键或者按一个字母/数字按键来改变选择对象。
如果在你的 app 中可以实现，那就利用好 Mac 用户可以同时轻松使用键盘和鼠标或者触控板这一事实。
如果你在你的 iPad app 中通过实现 UIKeyCommand 去定义命令的键盘快捷方式，你 app 的 macOS 版本会把这些快捷方式翻译成菜单。例如，你应该把每一个主要的内容显示区域都映射成键盘快捷方式，例如每一个 tab 的键盘快捷方式就是「⌘1」、「⌘2」……并把这些快捷方式展示在你 app 的 macOS 版本中的查看菜单中。

如果在你的 iPad app 的 UI 中有一个删除按钮，那就考虑从 macOS 版本中移除这个按钮，让用户可以通过删除按键或者「编辑」→「删除」菜单完成删除操作。

手势

当你的 iPad app 运行在 macOS 上时，大多数的手势可以被自动转换，例如：

注意：在 pinch 和 rotate 手势中的两个触摸点会被传送给光标下面的视图，而不是每个触摸点下面的视图。

把 app 的所有命令放到菜单中去

在一个 Mac 上，屏幕顶部的菜单栏可以让那些控制 app 和系统的命令给用户一个始终如一的位置。除了 Apple 菜单列出的总是可用的系统层级的命令，菜单栏还包含由当前 app 提供的标准菜单和自定义菜单。Mac 用户期望每一个 macOS app 可以在菜单栏中显示所有的命令。

开发手记：你必须使用 UICommand 去代表 iPad app 上的每一个命令，因此这些命令才会被放进 macOS 的菜单栏的菜单中。为了让命令支持键盘快捷方式，使用 UIKeyCommand。

因为 iPad app 在主要的 UI 中使用控件去展示命令，为每一个 app 的命令找到一个有逻辑的、直观的菜单栏位置是适配过程的核心部分。

为了设计你的 macOS 版本的 app 的菜单栏菜单，从列出人们可以执行的所有动作开始，并把它们根据标准菜单栏菜单定义的分类分组。例如：

app 名字；
文件 File；
编辑 Edit；
查看 View；
窗口 Window；
帮助 Help。

注意：大多数的 macOS app 都包含「查看」和「窗口」菜单。虽然这俩菜单会有些相似，但是它们都有不同的目的。人们使用「查看」菜单去自定义 app 窗口的外观、在不同的功能区域之间移动；使用「窗口」菜单在 app 中的一系列窗口间导航、组织和管理这些窗口。

如果你的清单中某些动作放在标准菜单栏中的菜单中讲不通的话，你可能需要添加一个自定义菜单。Mac app 总是会为那些与核心 app 对象或者核心 app 工作流相关联的命令添加一个自定义菜单栏菜单。例如，在 macOS 中的「邮件」app 中，使用了「信息」和「邮箱」菜单列出了那些操作 app 基础对象的命令。同样的，「Keynote」app 使用了「排列」菜单列出了在幻灯片上与排列对象核心工作流相关的所有命令。

在你把 app 的所有动作都分组到菜单中后，你需要用一种讲得清楚的方法在每个菜单中排列这些动作。每一个标准菜单都定义了一个推荐动作排序，所以对你支持的动作按照这个顺序排列非常重要。例如，Mac 用户期望「文件」菜单会按下面这个顺序呈现：

新建…
打开…
打开最近的文档
关闭

在一个自定义菜单栏的菜单中，你应该根据重要性、使用频率或者你 app 中讲得清楚的其他机制排序这些动作。菜单栏菜单也可能包含子菜单和分隔线，以让动作按逻辑方式被分组。

当然，对于你的菜单中所有的常见命令支持键盘快捷方式也很重要，这样使用键盘的 Mac 用户和 iPad 用户都可以从中受益。除了为标准菜单条目创建键盘快捷方式，你也可以为自定义条目创建快捷方式。

情景化菜单

情景化菜单可以帮助人们发现那些不需要打开菜单栏菜单就能在某个对象上执行的动作。如果你在 iPad app 上支持情景化菜单，系统会自动把它们转化为 macOS 版本的情景化菜单。

为了给 Mac 用户创造最佳用户体验，为支持情景化菜单寻找额外的空间。例如，如果人们可以在 app 中对一个对象执行一些常用的动作，那就添加一个列出这些动作的情景化菜单。你也可以对代表一个对象的视图添加情景化菜单，例如，在「Finder」中的文件夹对象就支持情景化菜单，其提供了像是「在新标签中打开」、「重命名」、「复制」这些动作。

视觉设计考量

当运行到 macOS 上时，为了让你的 iPad app 也会看起来运行良好，仔细在下面这些视觉设计领域考虑平台间的不同。

布局

Mac 用户期望将 app 的窗口大小从全屏一直调整到 app 允许的最小尺寸。为了支持这种无限可调整大小的类型，也是为了利用好 Mac 宽带的屏幕，那就使用「regular width」和「regular height」的 size class 尺寸等级，必要时考虑把窗口内容区域中的元素重新排列成并排排列。

尽可能地适配一个从上到下的布局：macOS app 会把最重要的动作和内容放到靠近窗口顶部的地方。如果你的 iPad app 在工具栏或者导航栏上有控件，那么把这些控件放到 app 的 macOS 版本中的窗口工具栏上。
考虑把 iPad app 主要 UI 中的控件移动到 macOS 窗口中的工具栏上：当然，也把与这些控件相关联的命令列在 macOS app 的菜单栏的菜单中。
特别注意：在 macOS 中，工具栏上的按钮总是可见的，但当前的情景可能使这些按钮不可用。而在 iOS 中，工具栏上的按钮总是可用的，但当前情景可能没有工具栏。例如，如果你的 iPad app 只在一个 tab 中有工具栏按钮，那 macOS 版本的 app 中应在其他的 app 中也展示这个按钮，只不过要将其设置为不可用状态。为了避免让用户疑惑，在工具栏上使用一个「齿轮」按钮会更好，因为在尺寸按钮的菜单中的条目会根据当前 app 的选择发生变化。
从屏幕左边或者右边，重新放置按钮：在 iPad 上，把按钮放在屏幕的居中靠左或者居中靠右的位置上会帮助用户可以更容易点击，但是在 Mac 上，工程效率学的考虑不需要了。你可能想要把控件重新放在内容区域的顶部或底部，抑或是放在你 macOS app 窗口的工具栏上。

颜色

在两个平台上使用系统的选中颜色：通常情况下，iOS 用颜色去给按钮描边着色、表明被选中状态，但是在 macOS 中，人们期望使用系统偏好设置去选择他们想要的被选中颜色和按钮颜色。

为 iOS 背景所设计的动态系统颜色会自动映射成合适的 macOS 等价颜色，如下表所示：

其他定义的语义化颜色，如系统颜色、文字标签颜色、分隔线颜色，会映射到相似名字的 macOS 颜色。

不要在 tab rows 中给按钮着色：在你的 iPad app 中，你会通过着色表明那个在 tab rows 中的按钮是活跃状态，但是在 macOS 中，在 tab rows 中被着色的按钮会看上去不到位不合适。

文字排版

虽然系统提供的自动缩放功能可以让你在所有的平台上不需要指定不同的字体大小值，这个功能一般都有一个不错的结果，但在每一种情况下你可能不会得到最好的结果。

确保 small 类型在 Mac 上是可读的：为在 iPad 上使用的一些最小字体尺寸做出增加做好准备，在 macOS 上的所有文本都应该保持可读性。当然，需要注意在 macOS 上不支持动态类型。

自定义图标和图形

创建一个 macOS 版本的 app 图标：好的 macOS app 图标明显与好的 iOS app 图标不同。例如，macOS app 图标可以是非矩形形状，图标可以被歪曲或者旋转。默认情况下，macOS 会在 iOS app 的图标上增加一层投影，让其在 Mac 上更合适，但是最好是设计一个特定的 Mac app 图标。
如果有必要的话，创建平台特定的图形：如果你的 iPad app 使用了以某种方式提及了操作平台的自定义图形，那就需要创造一个新的适合于 Mac 的图形。Xcode 提供了一个分离的资源目录，你可以在 iPad app 中使用它存放特定的 macOS 图形。

偏好

如果你的 app 在 iOS 的「设置」中提供了 app 的设置选项，macOS 会自动在 app Mac 版本的偏好设置窗口中显示这些选项。默认情况下，macOS 会在偏好设置窗口中为 iOS 设置中的每个条目添加一个工具栏按钮，所以要给这些条目匹配一个标准的系统偏好设置按钮和标题。

正如 Mac 用户所期望的，当用户在你 app 的菜单中选择「偏好设置」菜单时你的偏好设置窗口就会出现。然而，这里有一些方法可以改进 app 设置条目的展示，让 app 的偏好设置体验更像 Mac：

自定义每个条目的工具栏图标：因为 macOS 会对你的 app 的设置条目自动使用标准的系统偏好设置图标，人们就必须阅读每个工具栏按钮的标题以区分多个条目。为了改进这个体验，为每个设置条目提供一个自定义的图标。
让macOS 用户更容易理解开关控件：不像 iPad app，当用户在系统偏好设置中使用一个开关做出改变时，一个 macOS app 总是会展示一个确认弹窗。另外，在 iOS 设置中的开关可以展示一小部分的文本信息以告诉用户这个开关会如何影响用户体验。在 app 的 Mac 版本中，你可以与 macOS 开关一起提供一段简短的描述，你可以在用户使用开关改变设置时在确认弹窗中指定一段内容去展示。

继续阅读

本篇文章主要取材于 iOS HIG，从大的层面讲述了移植 app 到 Mac 中去的一些设计规范，点击这里继续阅读把 iPad 上的 app 带到 Mac 中去（下），下篇取材于 WWDC session，将用更多的示例和图片主要围绕架构、工具栏、布局、排版、颜色、手势、触控栏、app 图标、情景化菜单、菜单栏菜单十个部分讲述更多移植的细节。

参考链接

Sign in with Apple 的设计准则和功能实现

2019-09-05T23:05:36+08:00

在你的 app 或者网站上展示一个「Sign in with Apple」按钮意味着人们可以只通过他们已经拥有的 Apple ID 进行登录或注册，跳过填写个人信息、确认电子邮箱和选择密码的部分。Sign in with Apple 通过给用户一个一致的、他们可以信任的登录体验提供了一个全新的、更加隐私的方式以简化和加快登录 app 和网站的过程，也方便了用户不需要记住多个账户和密码。在你需要请求用户的名字和电子邮箱的地方，用户可以选择对他们的真实电子邮箱进行保密，而提供一个独一无二的、随机的、可收发邮件的电子邮箱地址。
Sign in with Apple

Sign in with Apple 让人们通过 Face ID 或者 Touch ID 完成授权变得简单，并且内建了两步验证以增加安全层级。Apple 不会通过 Sign in with Apple 的活动在 app 中收集用户的个性化资料和他们的具体活动。
Sign in with Apple 提供了反欺骗的特性，它可以通过机器学习和其他信息提供给开发者一个新用户是真实人类还是需要进一步观察的标志。

What's New

2020-03：
- 进一步明确了 Sign in with Apple 按钮在 iOS、macOS、tvOS、watchOS 和 Web 端不同平台上的样式区别；
- 增加了对创建一个自定义的 Sign in with Apple 按钮（左对齐 logo 样式、只有 logo 样式）的描述。

设计帐户注册和登录流程

让用户登录只为了交互有价值的信息：例如，人们可能需要创建一个账户来让 app 可以提供个性化的体验、在 app 中访问额外的功能或者同步数据，如果你的 app 不需要基于账户的功能，那就不需要让用户登录。
在你的所有 app 和网站中考虑使用 Sign in with Apple：为了一个一致性的登录体验，推荐你在你 app 覆盖的所有苹果平台和网站上使用 Sign in with Apple。
登录的请求越往后越好：当用户还没做什么有用的事情就被强制登录时，人们可能会放弃使用 app。在向用户发出请求并让用户提供信息前给用户一个熟悉你 app 的机会。例如，一个流媒体播放 app 在需要登录播放内容前可以先让用户看看 app 提供了什么内容。
在任何可能的时候，直到用户要做出购买决定时再让用户创建账户：如果你的服务支持访客结算系统，在交易完成之后处理好结算过程，并可以给用户一个快速创建账户的机会。
向用户解释清楚登录的好处以及如何注册你的服务：如果你的 app 需要登录账户，那就在登录界面上给用户展示一个清晰友好的说明，描述清楚为什么需要登录以及登录的好处。还有，记住并不是每一个使用你 app 的人在一开始就有一个账户。
注册账户时只收集必要的信息：如果只是为了创建一个独一无二的用户标识符，那就不需要收集用户的名字和电子邮箱信息。

Sign in with Apple 按钮

Apple 提供了几种「Sign in with Apple」按钮，你可以使用它们以让用户注册或者登录账户。如果有需要，你可以创建一个自定义的按钮以提供 Sign in with Apple 功能。

突出展示「Sign in with Apple」按钮：确保 Sign in with Apple 按钮不比其他的登录按钮小，避免出现滚动才能看到按钮的情况。

使用系统提供的按钮

当你使用系统提供的 API 创建一个 Sign in with Apple 按钮时，你可以获得下面这些好处：

一个确保使用了 Apple 提供的标题、字体、颜色、样式的按钮；
当你改变按钮样式时，按钮的内容可以保证保持一个理想的比例；
自动翻译按钮上的文字为设备指定的语言；
支持配置按钮的圆角半径以匹配你的 UI 样式（在 iOS、macOS、Web 不同环境下）；
一个系统提供的替代文本标签，可以让「旁白/VoiceOver」描述出按钮。

系统提供了按钮标题的几种变种样式。根据你的内容运行的平台，选择适合你的登录体验的术语样式，并在你的所有界面中一致地使用。
下面的几种按钮标题在 iOS、macOS、tvOS 中都可用，「Sign in with Apple」和「Continue with Apple」在 Web 端中可用：

对于 watchOS，系统提供了一种按钮标题： Sign in

取决于不同的平台，系统最多提供三种 Sign in with Apple 按钮的外观样式：白色（White）、带描边的白色（White with Outline Rule）、黑色（Black）。根据你要展示按钮处的 UI 背景选择最适合的外观。

白色

白色外观样式在所有平台和 Web 端可用。在可以提供足够对比度的深色或者彩色背景上使用白色外观样式。

带描边的白色

带描边的白色外观样式在 iOS、macOS 和 Web 端可用。在白色或者不能与白色按钮填充形成足够对比度的浅色背景上使用带描边的白色外观样式。不要在深色或者太饱和颜色的背景上使用，因为黑色描边会让视觉上变杂乱，可以使用白色外观样式与深色背景形成对比。

黑色

黑色外观样式在所有平台和 Web 端上可用。在白色或者可以提供足够对比度的浅色背景上使用黑色外观样式。不要在黑色或者深色的背景上使用。

与其他平台上的黑色 Sign in with Apple 按钮不同的是，watchOS 平台上的按钮使用的填充颜色并不是完全的黑色。为了与 Apple Watch 的纯黑色背景形成对比，watchOS 的按钮使用了系统定义的深灰色外观样式。

按钮尺寸和位置

调整圆角半径以与 app 中的其他登录按钮样式相匹配：默认情况下，Sign in with Apple 有一个圆角半径。在 iOS、macOS 和 Web 端，你可通过改变这个半径值让按钮变成圆角矩形或者药丸形状。

在 iOS、macOS 和 Web 端，保证最小按钮尺寸和按钮周围的边距：取决于不同的地区，按钮的标题长度可能会发生变化。使用下面推荐的指导值。

创建一个自定义的 Sign in with Apple 按钮

如果你的布局需要，你可以为 iOS、macOS 或者 Web 端创建一个自定义的 Sign in with Apple 按钮。例如，如果你支持多种登录方法，你可能需要展示一些使用了左对齐 logo 的按钮或者只展示一个 logo 的按钮。

Apple 的设计资源提供了可下载的 Apple logo 资源文件，你可以使用它们创建自定义的左对齐 logo 的 Sign in with Apple 按钮或者只展示一个 logo 的 Sign in with Apple 按钮。Logo 文件包含 PNG、SVG 和 PDF 格式，对于两种类型的按钮资源文件都提供了两种外观样式。下面是黑色和白色的只展示一个 logo 的按钮资源文件示例，为了保持可见，每一个都添加了一个背景：

所以可下载的 logo 文件都包括了为了在按钮容易放置 logo 的边界间距：

左对齐 logo 资源文件包括了竖直边界间距，以确保 logo 和按钮之间有正确的比例；水平边界间距，以在 logo 和按钮的左边界以及标题间提供一个最小边界。
只有 logo 的资源文件包括了竖直和水平边界间距，以确保 logo 和按钮之间有正确的比例。

只使用从 Apple 设计资源下载的 logo 资源文件。遵循下面的指导准则创建和放置可下载的 logo 资源文件：

不要使用 Apple logo 本身作为一个按钮；
logo 资源文件的高度要和按钮的高度相匹配；
不要切割 logo 资源文件；
不要增加竖直边界间距；
不要在 logo 资源文件中使用自定义的颜色。

左对齐 logo 样式的按钮

基于按钮的高度选择 logo 资源文件的格式：因为 SVG 和 PDF 是矢量图形格式，你可以使用这些文件创建任何高度的按钮。只在按钮高度是 44pt（iOS 中默认和推荐的按钮高度）时使用 PNG 格式。左对齐 logo 资源文件包含小、中、大不同尺寸，你可以根据你展示的所有注册按钮匹配不同的 logo 尺寸。
对于按钮标题（ Sign in with Apple、Sign up with Apple、Continue with Apple）使用系统字体：为了看上去正确无误，你自定义按钮的标题和按钮高度应该和系统提供的按钮使用相同的比例。特别的，标题的字体尺寸应该是按钮高度的 43%，换句话说，按钮的高度应该是标题字体尺寸的 233%，取最接近的整数。下面是两个例子：

保持按钮标题的大小写样式不变：按钮标题的所有样式第一个单词（即 Sign 和 Continue）和 Apple 要大写，其他字母要小写。不要改变这种样式，如在标题中把每一个字母都大写。
让标题和 logo 在按钮内保持垂直对齐：为了做到这样，让标题和按钮的中间保持垂直对齐，然后添加 logo 图片，确保它的高度与按钮高度相匹配。因为 logo 图片包括顶部和底部的边界间距，在按钮中垂直对齐标题可确保标题、logo 和按钮保持正确对齐。
如有必要，插入 logo：如果你需要让 Apple logo 与其他 logo 水平对齐，你可以在 logo 的左边插入。
在按钮标题和按钮的右侧边界间保持一个最小的边界值：边界值最小应该为按钮宽度的 8%。
保持最小按钮尺寸和按钮四周的边界值：取决于不同的地区，按钮的标题长度可能会发生变化。使用下面推荐的指导值。

只有 logo 样式的按钮

基于按钮的尺寸选择 logo 资源文件的格式：像左对齐 logo 样式的按钮的资源文件一样，只有 logo 样式的按钮的可下载的资源文件也有 SVG、PDF、PNG 三种格式。对于任何尺寸的按钮，使用基于矢量的 SVG 和 PDF 格式；对于 44pt × 44pt 大小的按钮，使用 PNG 格式。
不要在只有 logo 的图片中增加水平边界间距：只要 logo 样式的 Sign in with Apple 按钮总是 1:1 比例，资源文件已经在四周包括了正确的边界间距。
使用一个遮罩去改变默认的只有 logo 的图片的矩形形状：例如，你可能想要使用一个圆形或者圆角矩形去展示所有的只有 logo 样式的登录按钮。不要为了减少内建的边界间距切割 Apple 提供的资源文件或者只使用 logo 本身，避免包括额外的边界间距。

在按钮四周保持一个最小边界值：边界值最小应该为按钮高度的 1/10。

实现 Sign in with Apple

纵览

当用户点击 Sign in with Apple 按钮后，用户会看到一个根据你 app 要求提供的信息而填好了信息的表单显示在屏幕上，像是名字和电子邮箱。用户可以在提供原始电子邮箱或者一个新的由 Apple 提供的邮箱之间做出选择。当用户点击继续按钮后，就完成了登录。你的 app 也会获得一个独一无二、固定 ID、用户的名字以及一个可以让用户收到邮件的电子邮件地址，不再需要用户做收取验证邮件、点击验证链接这样的事。

当用户在一台新的设备上登录时，一个轻轻的点击就可以登录之前的用户并开始使用你的 app。

Sign in with Apple 为你的 app 提供了一套流线化的账户设置体验，不需要填写复杂的表格，只需要轻轻一点。用户从 App Store 使用他的 Apple ID 下载了 app，在 app 中也顺其自然地通过 Sign in with Apple 完成登录。开发者也获得了一个已验证并且可以让用户收到邮件的邮箱，即使用户隐藏了自己的真实邮箱，提供的新的邮箱收取的邮件也可以通过 Apple 的转发服务转到用户的真实邮箱，同样用户也可以使用这个新的邮箱进行邮件回复。

Apple 也可以在使用 Sign in with Apple 登录时，通过机器学习和其他获取的信息告诉开发者这个用户是真实的还是未知的。如果是真实的，你就不需要再判断，尽管给这个用户良好的使用体验，如果是未知的，那可能是一个真人用户，也可能是一个机器人。

让 Sign in with Apple 与你的 app 结合

分成下图的四个部分：按钮、授权、鉴权、处理变动。先展示 Sign in with Apple 按钮，接着配置和执行授权的请求，在用户看到 Sign in with Apple 按钮并通过 Face ID/Touch ID 完成确认后，授权的结果会返回给 app。这时你需要与 Apple ID 服务器确认结果并在你的 app 中创建一个新用户。最后，凭据状态可能会发生变化，你的 app 需要处理处理好这些变化状态。

Button 按钮

只需要几行代码，你就可以把 AuthorizationAppleIDButton 添加到你的 app 中。具体代码如下：

// Add “Sign in with Apple” button to your login view

func setUpProviderLoginView() {
 let button = ASAuthorizationAppleIDButton()
 button.addTarget(self, action: #selector(handleAuthorizationAppleIDButtonPress),for: .touchUpInside)
 self.loginProviderStackView.addArrangedSubview(button)
}

Authorization 授权

利用几行代码，你就可以初始化一个 Apple ID 授权请求。具体的代码如下：

// Configure request, setup delegates and perform authorization request

@objc func handleAuthorizationButtonPress() {
 let request = ASAuthorizationAppleIDProvider().createRequest()
 request.requestedScopes = [.fullName, .email]

 let controller = ASAuthorizationController(authorizationRequests: [request])

 controller.delegate = self
 controller.presentationContextProvider = self

 controller.performRequests()
}

Verification 鉴权

在授权后，app 如果鉴权成功会从凭据中获得一系列信息，如果用户中断了过程或者发生了错误需要有错误处理的逻辑。具体的代码如下：

func authorizationController(controller _: ASAuthorizationController, didCompleteWithAuthorization authorization: ASAuthorization) {
 if let credential = authorization.credential as? ASAuthorizationAppleIDCredential {
 let userIdentifier = credential.user
 let identityToken = credential.identityToken
 let authCode = credential.authorizationCode
 let realUserStatus = credential.realUserStatus

 // Create account in your system
 }
}

func authorizationController(_: ASAuthorizationController, didCompleteWithError error: Error) {
 // Handle error
}

对于凭据中的信息，userID 是一个独一无二、稳定的、团队范围内的用户识别符，你可以在不同的平台中使用它获取用户信息，它是与你的开发者账户绑定的。鉴权数据包括身份 token 和授权 code，token 的生命周期很短，可以与 Apple ID 服务器交换新的 token。可选的，系统还会返回你请求的账户信息，比如名字和电子邮箱。最后是一个之前提到的真实用户指示标志。

Handling Changes 处理变动

你的用户可能会在你的 app 中停止使用 Apple ID 登录，可能会在设备中登出。授权服务框架提供了一个快速 API 供开发者获取相关状态。具体的代码如下：

let provider = ASAuthorizationAppleIDProvider()
provider.getCredentialState(forUserID: "currentUserIdentifier") { (credentialState, error) in
 switch(credentialState){
 case .authorized:
     // Apple ID Credential is valid
 case .revoked:
     // Apple ID Credential revoked, handle unlink
 case .notFound:
     // Credential not found, show login UI
 default: break
 }
}

NotificationCenter 也可以发出通知，告诉 app 用户的凭据状态已经失效。当失效时，在设备上退出登录，进一步可以引导用户重新登录。具体代码如下：

// Register for revocation notification
let center = NotificationCenter.default
let name = NSNotification.Name.ASAuthorizationAppleIDProviderCredentialRevoked
let observer = center.addObserver(forName: name, object: nil, queue: nil) { (Notification) in
 // Sign the user out, optionally guide them to sign in again
}

用户使用 Sign in with Apple 在你的 app 中注册了用户，他可能还会在其他设备上使用你的 app 或者需要重新登录。当第一次进入 app 时，系统会告诉用户曾经使用 Apple ID 注册了用户，经过 Face ID 检查后就可以完成登录。

同时，通过相同的 API，iCloud 钥匙串也可以实现此功能。你需要同时支持这两种登录请求。

当用户已存在时，具体的代码如下：

///Prompts the user if an existing iCloud Keychain credential or Apple ID credential exists.

func performExistingAccountSetupFlows() {
 // Prepare requests for both Apple ID and password providers.
 let requests = [ASAuthorizationAppleIDProvider().createRequest(),
 ASAuthorizationPasswordProvider().createRequest()]

 // Create an authorization controller with the given requests.
 let authorizationController = ASAuthorizationController(authorizationRequests: requests)
 authorizationController.delegate = self
 authorizationController.presentationContextProvider = self
 authorizationController.performRequests()
 }

判断是通过 Apple ID 凭据登录还是 iCloud 钥匙串登录的具体代码如下：

func authorizationController(controller _: ASAuthorizationController, didCompleteWithAuthorization authorization: ASAuthorization) {
 switch authorization.credential {
 case let credential as ASAuthorizationAppleIDCredential:
     let userIdentifier = credential.user
     // Sign the user in using the Apple ID credential
case let credential as ASPasswordCredential:
     // Sign the user in using their existing password credential
 default: break
 }
}

跨平台

在浏览器中，你也可以通过 JS SDK 实现用户熟悉的登录窗口，通过输入 Apple ID 和密码完成登录。其 API 与原生的相似。

特别的，在 Safari 浏览器上，点击网页上的 Sign in with Apple 按钮会直接定向到一个原生的像 Apple Pay 一样的表单，用户可以通过 Touch ID 授权快速完成登录。

Best Practices

Sign in with Apple 新的审核规范

2019 年 9 月 12 日 Apple 针对 Sign in with Apple 发出通知，更新了 App Store 审核规范，提供了 app 什么时候该使用 Sign in with Apple 的标准。从现在开始，所有的新 app 必须遵守这个规范，对于已经存在的 app 和 app 更新的最后期限是 2020 年 4 月。对于在 web 上和其他平台上使用，Apple 也提供了相应规范。

App Store 审核规范

对于仅使用了第三方登录或者社交登录服务（例如 Facebook 登录、Google 登录、Twitter 登录、LinkedIn 登录、Amazon 登录、微信登录）设置或者授权用户的主要账户的 app，必须也提供「Sign in with Apple」作为一个同等的选项。用户的主要账户是指他们在 app 中建立的用来识别他们自己、登录、访问某些功能和相关服务的账户。

你的 app 只使用了你公司自己的账户设置和登录系统；
你的 app 是一个要求用户使用已有的教育或企业账户登录的教育、企业、商业 app；
你的 app 通过政府或者行业支持的公民身份识别系统或者电子 ID 来授权用户；
你的 app 是特定的第三方服务的客户，用户被要求登录他们的电子邮件、社交媒体或其他第三方账户才能访问他们的内容。

网站和其他平台上的使用规范

如果在你的已上架 App Store 的 app 中使用了 Sign in with Apple，我们推荐在任何相关的网站或者其他平台的 app 上通过调用 Apple JS 来提供 Sign in with Apple 功能。

在下面这些情况下，网站或者 app 可能不适合使用 Sign in with Apple：

违反任何法律或者是在其他方面不能遵守任何法律要求的；
提供下面的服务或交易的：
- 香烟和烟草产品；
- 枪、武器或者弹药；
- 非法药品或者不合法的处方药品；
- 给用户造成安全风险的项目；
- 被用于参加非法活动的项目；
- 色情作品；
- 假冒或失窃商品。
主要提供或出售毒品用具或者面向性的用品和服务；
宣扬基于种族、年龄、性别、性别认同、族裔、宗教信仰或性取向的仇恨、暴力或排斥；
参与任何类型的诈骗；
侵犯他人的知识产权、宣传权、隐私权；
以虚假或贬损的方式展示 Apple 和它的产品。

除了允许用户自愿地设置一个账户和登录你的 app 或服务，不得通过 Apple API 为了其他目的使用 Sign in with Apple。

参考链接

设计绝佳的 Siri 捷径 - Siri 捷径从设计到构建（中）

2019-10-11T01:45:33+08:00

上篇文章通过一步步深入 SiriKit 的细节，讲述了 SiriKit 可以让 app 发挥的领域以及引出了 Siri 捷径的多种类型和各种设计规范。这篇文章将用一个实际的例子一步步地从细节上去设计 app 的 Siri 捷径。
通常情况下，Siri 捷径（Siri Shortcuts）是在 iOS 上把你的 app 的功能在更多地方带到更多用户面前的一个好方法。

来看一下你的 app 的捷径可能会出现的地方以从中获得有帮助的信息。当用户在你的 app 中做了什么事情，你告诉了系统，系统就可以预测用户下次想做那个动作时，自动建议这个捷径。这些捷径可以出现在锁屏和搜索中。
在下图中，这个捷径让你快速开始一个你平时会在一天中的这一刻进行的锻炼。

如果一个用户通过分配一个自定义词组，添加了一个捷径到 Siri，他们可以通过他们的声音在任何时候调起它。在这里，这个捷径让他们预订日常晚餐。

另一个捷径配合 Siri 的应用是不需要操作、不需要看着就可以获取信息。对于你的 HomePod 来说，如果你有一个交通 app 的捷径，你可以说「公共汽车时刻表」，Siri 就会从 app 中读出公共汽车的时刻表信息。

你也可以让你 app 的功能作为一个多步骤捷径的一部分。在这里，这个捷径控制了你晚上回家时的行动安排，在到家时预订汤，开车时播放喜欢的音乐并展示最快的路线。

所以，看看这些例子，我们可以看到捷径可以加速你 app 频繁使用、有用的动作。呈现可以看一眼就获得的信息或者使用你的声音或者作为强大的多步骤捷径的一个部分，你的 app 可以与其他 app 一起配合工作。

这篇文章将会聚焦于如何让捷径利用好 iOS 13 新的 Siri 能力。

选择功能

首先，来看看如何优选 app 的功能以利用好 Siri 捷径。为了实现它，我们以一个名字为「SoupChef」的 app 为例，它可以让你预订各种各样的汤品，你可以选择自取或者送货上门。来看下创造一个 SoupChef 的捷径的设计过程。

先列出 app 能做到的所有事情。当做完这个时，开始想想一个用户可能会重复用声音去做的事情。在 SoupChef 中，你可能会像浏览汤的菜单、定一个汤、检查订单状态或者查看过去的订单。

让我们一个个来看下这些功能。
浏览菜单一个需要许多结构信息且不能很好地翻译成声音的视觉活动。它需要滚动、点击、导航。随着一次次调用，它提供的信息可能不会经常改变。它更像是一个结束，而不是一个有价值的动作。所这个功能可能不适合作为一个捷径。

检查用户状态可能是用过想通过声音触发的功能，从 Siri 中获得一个快速的信息总结。但是它也是只在用户预定完后的很少的时间才能够用得到。所以，这个可能只在送餐时间很长时时或者有多个阶段时，才合适让用户转化其为一个捷径。

查看过去的订单也是一个可以考虑的功能，但是对于我来说，我并不会经常去查看。所以也不适合作为一个捷径。

预定汤品是一个非常有价值的活动。实际上，也是你的 app 中最重要的活动。如果一个用户有一个最喜欢的汤品，你可以想象得到他会经常订购它。所以，我们可以把它作为捷径的最佳候选人。

总结一下，一个可以好好利用的解决应该是有价值的或者说可重复的，它可以不依赖视觉和点击只通过声音就能完成，它可以在许多场景中被调起，因此捷径可以不只是在很短的窗口时间内才会被用到。

发现捷径

现在，我们已经知道了我们想要用户通过捷径能够重新订购汤品，我们进一步来看看如何让这个捷径在你的 app 中可被发现。
我们提供了一个标准的「添加到 Siri」按钮，这让用户容易看到 app 中哪个功能可以被转化成为一个 Siri 捷径。

但注意使用时仔细思考一下，不要像下图这样，把添加到 Siri 按钮放到你的主菜单的每一个条目上。即使按钮本身再漂亮，像这样重复使用也很难看，而且在这里相关性也不足，用户不太可能在第一个开始的地方就尝试下订单，并且这些按钮挡住了路，有些条目可能是用户之前根本没订购过的，目前建议他们重新订购毫无意义。

解决方案是寻找你可以把它放置在一个聚焦一些的 UI 的地方的机会，在那里你会得到一个清晰的信号，用户可能想要重复做些什么事情。例如，在用户订购完什么东西之后展示一个添加到 Siri 按钮可能会更好。这里的逻辑是，如果一个用户发现之前订购的汤品很不错，那他就更可能想要再次订购。而且在这里，你也没有打断用户任何想要做的事，因为它们已经订购完成，所以这是一个好机会。

为了让添加到 Siri 按钮更适合你的 app 的视觉外观，你可以自定义按钮的圆角半径。你可以基于用户的浅色模式或深色模式设置自动让按钮的外观变化。

如果上面说的这些变种还是不能满足你的要求，按钮的样式始终不适合你的 app，你可以自己创造一个，但你应该重复添加到 Siri 按钮的所有功能。标准的添加到 Siri 按钮在配置好后会展示用户设置的捷径短语。这是一个提醒用户他们可以说什么来运行捷径的好方法。

点击按钮会显示一个标准的模态窗口，它允许用户编辑或者删除捷径。

如果你想在你的 app 中有一个集中的位置列出所有的你的捷径，那就可能因为太多而不能在每行都显示添加到 Siri 按钮，所以解决方案是使用标准的 UIKit 元素就好。只要确保当一个用户设置了一个捷径后，像添加到 Siri 一样，你应该展示用户为捷径设置的那个短语。点击按钮也会弹出一个模态窗口，同样地可以编辑或者删除捷径。

假如用户第一次设置捷径，当用户点击添加到 Siri 按钮后，他们会看到添加到 Siri 模态窗口，在这里用户可以选择哪个短语用来触发捷径。在 iOS 13 中，你的 app 可以预置一个你自己选择的捷径。如果你提供了短语参考，大多数用户将可能会直接用那个，所以确保你提供了一个好的默认短语。在上面的例子中，「预定汤品」是一个好的、简短的、可以记住的短语，用户可能想要由衷地用作捷径的短语。

来看另一个例子，「检查公共汽车时刻表」。这看起来像是一个明智的短语，考虑到它相对比较短，这里有充足的机会用户可能会忘记某个单词或者换掉某个单词，他们可能会说「查看公共汽车时刻表」或者是「35 路公共汽车时刻表」。虽然 Siri 可以尽可能地把这些与短语匹配，但用户仍可能在想到更长的短语时有更多的创意。所以，这可能不是一个最好的建议的短语。

解决方案是，让它足够简短，只需要三两个词语，尝试把它限制到一个合适的名词内或者是一个动词、一个对象。这会减少用户打乱单词顺序或者使用不同的介词的机会。

一个用户想要设置一个捷径用来订购西红柿汤，但是如果用户想要捷径每次做的事都不太一样该怎么办，比如订购一个不同的汤品。在 iOS 13 中，用户可以点击执行命令下的具体动作并且通过点击每一个选项来自定义多少信息被预置到捷径中。

用户可以选择让某些选项置空，比如汤的类型。当用户这样做的时候，Siri 会向代表 app 向用户询问缺失的信息。

现在，理想情况下一个捷径会有比较少的交互。毕竟，它应该为用户经常要做的事情提速。所以当你呈现添加到 Siri 模态窗口时，内置的动作应该包括尽可能多的信息，以让运行捷径时只需要一两个点击就能完成。在下面图示的例子中，这个捷径可以直接到最后的确认步骤，因为一切都已经指定好了。

但如果用户让每一个选项都置空，想通过 Siri 的交互指定所有的订单细节会怎样？让我们来看看我们如何设计一个完整的通过 Siri 订购汤品的交互。

设计交互

先考虑一下为了订购汤品你需要知道什么信息？比如汤品的类型，是自取还是送货上门，如果选择送货上门送达的位置是什么？如果选择自取你要何时在哪里自取？

要开始考虑订单和你可能收集这些信息的方法，你应该把你 app 的交互看做是你的用户和 Siri 之间的一个对话。一种视觉化这种对话的方式是使用脚本，这对快速记下一段对话的路径很有用。

当然，这里不会只有一条路径，你应该写下所有对话可能去的路径。例如，一个用户说了一个你的 app 没有提供的选项，这时 Siri 应该告知用户这个情况。

准备许多脚本作为设计规范可能不灵便，所以在过程的结束，你可能需要通过一些这样的形式来结束：一个包含所有对话中可能的状态和转换的流程图。现在这里有一些特别的方式让 Siri 可以呈现选择、处理用户输入，我们直接来看你拥有并可以直接使用的对话模式。
第一个模式是「提示」，这个是你从用户那里收集有价值的信息最开放的方式。

你应该把提示写作一个问题，组织好用词以让用户可以有好的反应。当一个用户说了对 app 意味着多重含义的事情时，你可以呈现一个选项列表让用户确定他们说的是哪一个，这叫做消除歧义提示。

你也可以最小化消除歧义提示，通过更早地呈现选项列表在对话中添加额外的步骤。注意用户说了捷径短语「订购汤品」，直接看到了列表，如果这里只有有限的几个选项可以选择的话，你应该使用列表而不是自由形式的提示。确保你的提示对话可以鼓励用户从列表中做出选择。以词语「哪一个」开头的问题在这里就效果很好。

当在没有显示屏的情况下使用捷径时，Siri 会把选项读出来，像是在使用 AirPods 时或者在 HomePod 上或者当用户使用「Hey Siri」时，Siri 会直接把提供在视觉 UI 中的选项读出来。

但你可以想象得到那会很冗长，特别是有很多相似选项的时候。为了改善这个体验，你可以在每个选项中添加发音标记以让 Siri 特定的读出你的选项。像下面这个例子，用户想要面条汤，菜单里提供了两种，不是直接说牛肉面条汤和蔬菜面条汤，而是只需要问需要牛肉的还是蔬菜的。所以考虑只读出可以区分不同条目的那些细节。

对话是双向的，你还需要考虑用户可能会说什么。用户可能不会使用你标记选项的那个词，为了控制每个选项回复时的自然语言变种，你应该给 Siri 提供与选项相同含义的同义词。这样当用户直接说牛肉时就可以直接匹配到牛肉面条汤。

在挑选这些同义词时，你也应该记住你的问题的用词会影响用户答复的方式。所以如果你有一种更随意的方式描述选项，比如带肉的或蔬菜的，你应该确保你能识别出用户会向 Siri 重复那种措辞。

如果用户提供了一个你想要额外确认的答复，比如一个后果很严重的值，你可以提供一个参数确认提示。但是谨慎地使用，只在真正的例外情况时使用，因为这会拖慢用户流程。

使用参数确认提示的一个替代方案是如果你的 app 有自己的可以预测用户会想要什么的逻辑，你可以把最可能的预测呈现给用户，他们可以直接确认他而不需要再提供额外的细节。或者他们也可以否定它，你就可以回到一个更加开放的提示去。如果你可以猜测到用户想要的，这是让你的捷径交互更快的好方式。

在流程的结束，考虑使用一个应用到整个流程的确认提示，特别是操作会带来很严重的结果时。在这一步，你可以确认与决定相关的所有要执行的动作细节，比如通过一个你可以完全自定义的视觉的用户界面确认价格、送达时间等信息。注意对于订购类的动作，系统也会要求用户确认。所以如果你的 app 属于那个类别，你应该提供优秀的确认体验。

但是记住你的捷径可能被一个用户在没有看屏幕时所运行，所以你可以提供只要声音的对话体验。在这种情况下，我们提供了额外的对话帮助用户做出选择。这种额外对话的目的就是提供那些不能通过视觉 UI 展现出来的信息。可以把这个额外对话看做是你会在显示屏上显示的最重要信息的语音等价物。

最后来看下你的答复。Siri 会表明动作的状态。你可以在这里提供一个视觉 UI 总结来描述额外的细节，像是谁会派送你的汤品以及最新的估计派送时间。而在这里我们只说「好的，订好了」，因为我们还通过 UI 展示了额外的信息。

对于只有声音的体验来说，你应该指定一个更具描述性的对话。同样把这个额外的对话看作是你会在显示屏上显示的答复 UI 上的最重要信息的语音等价物。

当你在思考你的确认和答复对话时，你应该记住你需要为捷径选择一个分类。你可以在 Xcode 中定义捷径时，选择一个最接近你的捷径功能的分类。在 SourChef 的例子中，订购分类是最适合的。

在确认提示中，Siri 将会基于你选择的分类自动提出问题。所以不要包括在自定义的确认对话中包括问题。

在答复对话中，Siri 将会根据分类提供状态信息。你的自定义对话将会被添加到 Siri 提供的对话之后。

声音交互也应该是尽可能健壮的，避免强制用户打开 app 手动执行。例如，如果一个参数值无效，你应该提供清晰的错误信息，Siri 之后会自动地重新询问用户。

你还应该首先避免自己陷入这种情况，如果你呈现了一个选项列表，确保你没有呈现任何运行时你已经知道是无效的选项。你还应该考虑到深入挖掘用户潜力的机会。用户可能在捷径中包含像是送达位置的值，通常是他们的家，所以他们会习惯于不跟 Siri 说他们的送达位置。有一天他们可能在离家很远的地方使用捷径，你应该检查那个情况，并提示用户应该是一个不同的位置。

不管是什么原因，用户可能想要继续在你的 app 中运行捷径，他们只需要轻点 UI 中的任何地方就可以做到。所以当你呈现一个 UI 时，记住整个区域都应该是一个可以打开你的 app 的大的按钮。所以不要绘制看上去是可以独立可交互的元素。确保用户点击那里时，你的 app 可以带着用户已经提供的所有信息跳转到正确的位置，并把信息正确显示在 app 中。

我们鼓励你在写对话时花点时间，这不是一些快速展示从而获得一些需要展示的东西，这是最后要提交的产品。记住在声音交互中，语言就是用户的界面。所以你应该把 Siri 捷径交互中的每一个词看得像 app 中的每一个像素一样尊重和重要。

不要太过礼貌或者加入太多个性化的内容。想要订购汤品的用户在运行这个捷径的每一次都会听到这段非必要的对话，那很烦人。如果怀疑的话，那就做个测试，听听 Siri 讲你的对话，在听了三次、十次之后是什么感觉。如果让人心烦，那可能是一个你应该降低你的对话的冗长度的好信号。

对话应该是准确的、中立的，表达出你想要响应的类型。

不要在对话中包括你的 app 的名字。你的 app 会通过对话和答复 UI 被属性化、视觉化，有时 Siri 自己会在必要的时候添加你的 app 的名字。所以不要自己添加它。不用担心，你的品牌是安全的。

相似的，你不应该在对话中包含用户的名字。Siri 有时可能会在 HomePod 上讲出用户的名字以确认身份。如果你的 app 也这样做，那就重复、烦人了。所以把用户的名字拿掉。

避免使用第一人称，因为不是 Siri 而是你的 app 在执行动作。这之间有微妙的差别，但很重要。在 Siri 的声音中说「我」或者「我们」，用户可能会认为 Siri 会更好地理解你的 app 的能力，并可能尝试一些你的 app 和 Siri 都不理解的动作。解决方法是用中立的方式呈现选项，使用像是「这里有几个选项」的词语。

总结

捷径可以提升你 app 中最可以被重复的功能，你应该使用添加到 Siri 按钮确保用户知道可以从你的 app 中把什么功能转化成一个捷径。你应该让 Siri 的交互有逻辑、清晰、健壮。在写对话时应该仔细慎重的进行思考。

参考链接

Android 10 的深色主题应用

2019-09-04T13:37:34+08:00

从 Android 10 开始，系统引入了「Dark Theme 深色主题」功能，app 不仅可以在默认的浅色主题模式下浏览，也可以在新的深色主题下浏览。
深色主题简而言之就是在深色的界面上展示低亮度的 UI。

Usage 用法

深色主题在主要的 UI 之间展示了深色的界面，它是默认浅色主题的一个补充。
深色主题减少了屏幕发出的亮度，但仍然满足最小对比度。它通过减少眼部压力、适应当前光照条件、让在黑暗环境中使用屏幕更便利来改善视觉效率。当然也节省了电量，对于 OLED 屏幕通过关掉所有的黑色像素的发光来从中受益。

Principles 原则

Darken with grey 使用灰色来变暗：使用深灰色而不是纯黑色来表现环境中的海拔感和空间感。

Color with accents 强调色：在深色主题中使用有限的强调色，大部分的空间都应该是深色的界面。

Conserve engery 节省能量：在需要注意效率的设备上，比如 OLED 屏幕，通过减少浅色像素的使用来节省电量。

Enhance accessibility：要考虑到那些特殊的使用深色主题的用户，比如视力障碍人士，通过符号可访问性的颜色对比度标准来实现。

Properties 特性

Contrast 对比度：深色的界面和纯白色的文本有至少 15.8:1 的对比度；
Depth 深度：在更好的层级上，组件在表现深度时应使用更浅的界面颜色；
Desaturation 去饱和：主要颜色（Primary Colors）应该去饱和，以满足 WCAG 至少 4.5:1 的 AA 标准；
Limited color 限制颜色使用：大的界面使用深色的界面颜色，限制使用强调色。

Anatomy 结构

深色主题的 UI 主要使用深色的表面，一点点强调色。为了保持一个高标准的可用性，界面只会散发出一点点光。

下图是一个界面的颜色示例：

Background (0dp elevation surface overlay)
Surface (with 1dp elevation surface overlay)
Primary
Secondary
On background
On Surface
On Primary
On Secondary

Behavior 行为

深色主题可以通过使用一个控件被开启或关闭。

为了显眼，可以使用一个 icon 来触发深色主题的开启和关闭；
如果为了不那么显眼，可以使用菜单或者设置里的一个开关来控制。

下图是在 top app bar 上设置了一个按钮开关：

下图是在一个弹出菜单中设置了选项：

下图是在 app 的设置中设置了一个开关：

Properties 属性

深色主题应使用深灰色而不是纯黑色作为组件的首要表面颜色（primary surface color）。深灰色的表面更容易表示更大范围的颜色、海拔、深度，因为它更容易在灰色上看清除阴影。
深灰色的表面也减少了眼部的压力，在深灰色表面上的浅色文本比在黑色表面上的浅色文本有更低的对比度。

推荐的深色主题表面颜色是「#121212」。

Elevation 海拔

在深色主题中，组件具有与浅色主题相同的海拔层级和阴影。然而，在深色主题中，不同的海拔层级表示方法不再与以前完全一样。
表面的海拔层级越高（就像离光源越近），表面应该变得越亮，可以查看动态展示↗。

深色主题的表面通过在组件表面上放置一层半透明的白色遮罩（overlay）来展现。

在表面上的遮罩也使得更容易区分组件之间的海拔层级，以看到阴影。遮罩在表面和阴影之间增加了对比度，使每个表面的边缘更明显，可以查看动态演示↗

这些表面遮罩的值为保证最大可读性来设计，同时也确保不同海拔层级之间能够看得清。

遮罩表明了在组件之间的不同海拔层级。

对于主要颜色和次要颜色，不要在使用这些颜色的表面上使用海拔层级遮罩。在深色主题中，阴影仍然是深色以保证投影的准确度。

Accessibility and contrast 可访问性和对比度

深色主题的表面必须足够暗以能够展示白色文本。在文本和背景之间至少应该达到 15.8:1 的对比度。在更高海拔层级（更浅颜色）的表面上，文本应该至少满足 WACG 的 4.5:1 的 AA 对比度要求。

对于那些对电量使用有效率要求的 UI 来说可以使用纯黑色，一些设备（比如配备 OLED 屏幕的可穿戴设备）可以通过关闭像素点来显示黑色从而解压电量，可以查看动态演示↗。

UI application UI 应用

Theme colors 主题颜色

深色主题应该避免使用过饱和的颜色，因为它们与深色表面放在一起不会通过 4.5:1 的最低对比度要求。过饱和的颜色也会造成光学上的振动，增加眼部压力。去饱和的颜色是更好的选择。

Primary color 主要颜色

主要颜色是在你的 app 中的屏幕和组件中最频繁使用的。Material Design 深色主题一般使用主要颜色的 200 色调变种作为基线，这个变种可以在任何海拔高度的表面通过至少 4.5:1 的对比度要求。

具有浅色表面的组件可以使用深色主题主要颜色的某个变种。

Secondary color 次要颜色

次要颜色被用来强调 UI 中的选择部分。在深色主题中，次要颜色也要去饱和以满足至少 4.5:1 的对比度要求。、

Accnet color 强调色

在深色主题中，深色表面几乎占据了 UI 的全部。强调色可以让元素显眼，它们应该被单独应用与需要被强调的核心元素，比如文字或按钮。

可以使用「色盘生成器 color palette generator」来生成颜色主题，它会根据你自定义的主要颜色和次要颜色生成从深色到浅色的一系列颜色变种。你可以从中选择你要用在深色主题中的颜色。

Brand colors 品牌颜色

为了保持品牌辨识度，品牌颜色可以在深色主题中保持饱和度，但应用内的品牌元素应该有所限制，比如只有一两个，例如 logo 或者品牌按钮。通过单独使用品牌颜色，元素可以在层级中保持显眼。

The dark theme baseline palette 深色主题基线色盘

深色主题颜色应该被应用与各个深色主题的 UI，包括下面这些部分

颜色：主要颜色、次要颜色、主要颜色变种；
表面：背景和组件；
状态：比如错误状态；
内容：文字排版、图标排版。

在浅色主题和深色主题下不同组成部分颜色的变化：

错误颜色用来表示错误状态。

通常情况下用于文字排版和图标排版的「On colors」表示在其他主题颜色表面上使用的颜色，比如主要颜色上、次要颜色上、表面颜色上、背景颜色上、错误颜色上。默认情况下，深色主题的「On colors」是白色和黑色。

当浅色文本出现在深色背景上时，一般遵照下面的准则：

高层级强调：87% 不透明度；
中层级强调：60% 不透明度；
不可用文本：38% 不透明度。

Custom application 自定义应用

使用较大比例屏幕的组件，比如 app bar、backdrop，可以使用表面颜色作为深色主题的颜色。

当深色主题中需要一个浅色表面时，浅色可以被用在组件表面以突出层级关系。举个例子，深色主题的 snackbar 为了突出显示就可以有一个浅色的表面。因此你可以应用浅色主题的 Surface color 和 On Surface color。

States 状态

「状态」在视觉上通过使用遮罩表达了组件或不可交互元素的状态。在深色主题中，状态也应该使用与浅色主题一样的遮罩值，它们调整后可以满足 AA 的对比度要求。
有两种类型的容器：一种使用「Surface」填充色，另一种使用「Primary」填充色。

Surface Containers

Surface containers 使用「Surface」颜色作为填充色，使用文本或 icon 的颜色作为遮罩颜色。

Primary Containers

Primary containers 使用「Primary」颜色作为填充色，使用白色作为遮罩颜色。

不可用状态

不可用状态的组件都使用 12% 不透明度的白色作为描边颜色和填充颜色，38% 不透明度的白色作为内容颜色，比如文本或 icon。

参考链接

Dark theme - Material Design

向远公园 | Step Park

订阅 Apple Music 该选哪个区？——中美坡港台日六大地区全对比（第二版）

目录

第二版序

第二版更新概要

新增

更新

删除

正文开始~

在线曲库

版权分割

儿童不宜内容？

法律法规影响

功能差异

广播电台

朋友

全球 Top 100 歌单

电视与影片

iTunes Store & iTunes Match

类似艺人

音乐向导

曲库语言&内容推荐

曲库语言逻辑

内容推荐

多平台使用

多 Apple ID 使用

订阅付费

价格对比

付款方式

顺畅使用

总结

全新 iPhone 12 发布，再谈 iPhone 屏幕尺寸

目录

iPhone 12 系列屏幕的变化

6.1 寸 iPhone 12

5.4 寸 iPhone 12 mini

iPhone 12 Pro 系列屏幕的变化

6.1 寸 iPhone 12 Pro

6.7 寸 iPhone 12 Pro Max

放大显示功能

内容显示数量

Size Class

iPhone 12/iPhone 12 Pro 上的 App 适配实例

总结

参考文章

从第一代 iPhone 细数到 iPhone 12，iPhone 屏幕尺寸进化历程背后的 app 设计哲学

目录

iPhone 起源：从 3.5 寸的小屏幕开始

从第一代 iPhone 到 iPhone 4s

脱离像素密度：Point 点的诞生

iPhone 非全面屏时代：屏幕尺寸渐大渐多

4 寸、4.7 寸、5.5 寸全面开花

屏幕不断被放大的产物：放大显示功能

适配不同尺寸屏幕的布局工具：Auto Layout

iOS 、iPadOS 生态下的重要武器：Size Class

iPhone 转向全面屏时代：不规则屏幕的出现

全面屏的 5.8 寸、6.1 寸、6.5 寸

适应屏幕新变化：Safe Area

OLED 屏的影响：支持深色模式

更长更大的屏幕下的交互变化

新的大标题导航栏

新的菜单样式

全面屏的放大显示

展望未来 iPhone

旗舰 iPhone 12 会是什么样？

5.4 寸 iPhone 12 由 4 寸 iPhone SE 第一代进化而来

屏幕显示的内容数量较少

刘海变窄变小？

超旗舰 iPhone 12 Pro 又会是什么样？

iPhone 屏幕还会怎么变？

总结

为 iOS 14 设计全新的小组件

目录

小组件新的变化

小组件的基本特性

一目了然

高相关性

个性化

设计小组件

小组件的构想