iOS 9人机界面指南：iOS 技术 (HomeKit、多任务、通知、社交媒体以及iCloud)
本篇目录
3.7 HomeKit
3.8 多任务处理(Multitasking)
3.9 通知(Notifications)
3.10 社交媒体(Social Media)
3.11 iCloud
相关阅读
iOS 9人机界面指南(二)：设计策略
iOS 9人机界面指南：iOS 技术 (3D Touch、Live Photos、Wallet以及Apple Pay)
3.7 HomeKit
通过HomeKit，用户能够方便地在家中使用iOS设备上的智能家居应用来操控家中相关联的设备(无论这些设备制造商是谁)。最好的智能家居应用集成HomeKit和iOS系统来帮助用户：
-
创建家居环境、房间和区域
-
添加、寻找和移动家居设备(如灯泡或温度调节装置)
-
定义能够使一组多个家居设备响应的行为
-
管理用户
-
用Siri来操控他们的家居设施
想要了解如何在你的应用中使用HomeKit，可参阅 HomeKIt Developer Guide。下面的指南可以帮助你做出一个容易上手、令人愉悦的智能家居程序。
不要想当然地认为你的设备会是用户所设置的首个设备。你的应用除了能让用户很容易就能创建家居环境、房间和区域，还需要让用户能方便地将你的设备接入之前已经设置好了的区域中。
让添加新设备变得简单。不要强迫用户在添加设备之前注册账号。最好让你的应用能自动发现新的设备并将他们显著地展示在用户界面上。确保所展示的信息足够充分让用户可以轻易辨识出该家居设备。
帮助用户辨认他们正在调节的设备。给用户一个能够帮助他们从物理属性辨认设备的控制器。例如，你可以让用户通过闪一下灯泡来确认他们正在调节的是他们想要调节的那个。
让用户能够通过多种方式来搜寻设备。当天的时间、季节和用户当前的位置会在特定的时刻成为判别某些设备是否重要的影响因素。因此，你的应用应该允许用户能在家中按类型、名称、或者位置的方式来搜寻设备。
为家中已接入的设备提供推荐的操作集。操作集允许用户设定在某种情景下让多个家居设备按照特定的方式行动。例如，一个“离开”操作集可以将房屋内的温度调低、关闭电灯和锁上所有房门。你的应用可以向用户推荐一些已经设定好了的操作集或者让用户创建自定义操作集。当用户能够基于房间或区域去创建自定义操作集时，让用户可以从你推荐的设备列表中进行选择，通常能使用户获得更好的体验。
使用友好的交谈式语言让你的应用平易近人、易于使用。智能家居概念可能会懵到用户，应避免使用他们可能不理解的缩写和技术术语。例如，HomeKit是指代API的专用技术术语，它就不应该在你的应用中使用。
注意：如果你是苹果MFi认证许可商，请访问MFi门户网站查看设备包装的命名及消息通知的规则。
与Siri互动。通过Siri，使用一个简单的陈述句就能控制执行复杂的操作。Siri能够识别操作集、房屋、房间和区域的名称，并且能够理解像“Siri，把前门关了”、“Siri，把楼上的灯关了”和“Siri，把多媒体房的温度调高一点”这样的陈述。遵循以下准则能帮助你为用户提供使用Siri操控设备时的良好体验：
-
使用Siri能够识别的功能名称，而非设备名称。一个设备可能提供多种功能(例如，一个既有风扇功能又有照明功能的风扇吊灯)，因此，帮助用户区分这些功能是很重要的。最佳方案是让用户在一系列不包含公司名称及型号的限定的名称中进行选择，并且允许他们以后编辑。你所推荐的名称应该使用规范的、容易理解的词语来描述功能，并可选择是否包含家中的位置信息，例如“客厅灯”或者“车库门”。你还可以让用户指定一种控制插座开关的通用口令，例如“Siri，把灯关了”，来控制所有的灯具和其相关的设备
-
当用户配置操作集的时候，告诉用户如何通过Siri去操控它。举个例子，当“电影”这个操作已经确认配置完毕时，让用户知道他可以通过跟Siri说“Siri，把家调成电影模式”这样的话来激活这个操作。 注意，当用户单独对Siri说出某操作的名称时，同样也能激活那个操作。Siri能够识别系统预置以及用户自定义的操作集，这些已配置的操作集至少包含一项操作。
帮助用户设置触发机制。在iOS9中，HomeKit支持触发机制：当满足特定的时间、地点或其他设备的行为的条件时激活操作的方式。比如用户可以设置一个当太阳落山且车库门打开时，就打开厨房灯操作的触发机制。设置一个包含多个项目的条件关系容易使人感到混乱，因此，将你的设置界面做得简单易用至关重要。举例来说，使用与人们平常说话一样的表达方式来展示项目、属性和逻辑，就更容易使人理解。
3.8 多任务处理(Multitasking)
多任务处理让人们在屏幕上(在合适的iPad模式上)查看多个应用，可以在最近使用的应用之间进行快速切换。在iOS9,中，人们可以使用多任务处理UI(下图所示)去选择最近使用的应用。
能否在多任务处理中处理好取决于能否在设备中与其他应用和谐共存。从更高的层面来说，这意味着所有的应用都应：
-
仔细调整资源使用避免占用太多CPU，内存，屏幕空间和其他资源
-
处理好中断或来自其他应用的声音
-
停止和重启，即快速平滑地从后台切换到前台
-
不在前台时应恪守己任
下述指南细则可以帮助你的应用在专注应用切换的多任务处理中取得成功。更多合格的iPad模式下关于多任务环境中运行的信息，参阅 Adopting Multitasking Enhancements on iPad.
准备好被打断，并恢复。多任务处理增加了后台应用中断你的应用的可能性。其他特性，诸如广告出现和更快的应用切换，也会造成更频繁地打断。越快速和越精确地保存应用当前状态，人们就可以越快地重新运行应用，并从之前离开的页面继续使用。你可以通过利用UIKit的状态保存和恢复来为用户提供无缝的重新开始的体验(查看 Preserving Your App’s Visual Appearance Across Launches 了解更多信息)。
确保你的UI可以处理两倍高度的状态栏。两倍高度的状态栏会在诸如通话、录音和共享等过程中出现。在未作处理的应用中，状态栏的额外高度会引起布局问题，如UI被向下挤压或者被遮住。在多任务处理环境中，使两倍高状态栏显示正常是格外重要的，因为它可能会出现在更多的应用当中。
准备好暂停需要人们注意或主动参与的活动。例如，如果你的应用是一款游戏或媒体观看应用，你需要确保你的用户从应用切换走时，不会丢失任何内容或事件。当人们切换回游戏或媒体播放器时，他们希望能继续之前的体验，就好像他们从未离开过应用。
确保音频行为合适。当你的应用正在运行时，多任务处理会使得其他媒体活动更可能地同时进行，也会有更多可能性使你的音频不得不暂停，并恢复处理中断。查看声音来帮助你确保你的音频能满足人们的期望，并与设备中的其他音频和平共处。
适度使用本地通知。应用可以在特定时间发送本地通知，无论应用是在暂停中还是运行中亦或是根本就没有运行。为了达到最好的用户体验，应避免用过多的通知来骚扰人们，并遵循通知中创建通知内容的指南。
必要时，在后台完成用户的任务。当人们开始一个任务时，他们通常会期望即使已经从应用中切换走了任务仍能够完成。如果你的应用在执行用户任务途中，并且这个任务不需要额外的用户交互，那么你就应该在应用挂起之前就在后台完成任务。
3.9 通知(Notifications)
通知为人们提供即时的重要信息和功能。人们能在多种情况下收到通知，例如在锁屏界面中，或者在使用应用时，或者访问通知中心时。 通知中心有两种视图：通知(Notifications )和今天(Today)。
今天视图显示了一组可编辑的部件。今天部件是一个应用扩展，显示了少量及时和重要的信息或功能，这些信息或功能则是由用户所关注的应用所提供。举例来说，日历部件只显示了今天的事件。点击日历部件中的一个事件可以唤起日历应用，并打开该事件，用户接下来可以编辑该事件或管理其他的事件。想要了解更多关于设计今天部件的内容，请参见今天部件。
通知视图会显示用户感兴趣的应用所发出的最近通知。用户可以在设置(Settings)中来设置是否在通知中心显示该应用的通知。 iOS应用可以使用通知来让人们知道一些有趣的事情是什么时候发生的，例如：
-
收到一条消息
-
事件即将发生
-
有新的数据可下载了
-
某些状态发生了变化
在 iOS 8 及之后的版本中，应用可以定义用户在通知中的操作。例如，用户可以在待办事项应用的通知中就标记该事项已完成，而无需额外打开应用。 iOS定义了两种类型的通知。
-
本地通知(local notification)由应用安排待发送，最终通过iOS发送到同一设备中，无论该应用当前是否正在后台运行。例如，日历或待办事项应用可以安排一条本地通知来提醒人们一个即将到来的会议或者日期。
-
远程通知(remote notification)(也称为推送通知(push notification))是由应用的远程服务器通过苹果推送通知服务来发送的，这类通知最终会被推送到所有安装了该应用的设备。例如，一款在线竞技类的游戏，用户可以和其他玩家竞赛的，可以更新所有玩家的最新状态。
注意：应用扩展可能会要求远程通知必须发送到它的容器应用。在这种场景下，容器应用常常会在后台运行来处理通知。想要了解更多关于应用扩展的内容，请参见应用扩展。
如果当你的应用正在后台运行时收到了本地或远程的通知，你就应该以你的应用所特有的方式将信息传达给你的用户。 为了确保用户能够自定义他们的通知体验，你应该尽可能多地支持以下的通知类型：
-
横幅(Banner)
-
警告框(Alert)
-
小气泡(Badge)
-
声音(Sound)
注意：在iOS8及之后的版本中，你必须对所有你想发送给用户的通知类型进行注册。当你第一次进行注册动作时，用户会遇到一个警告框，他们可以在其中操作来决定允许或拒绝所有来自你的应用的通知。不管用户选择的结果是什么，他们应始终能访问应用的设置来更改此项设置，或者设置他们想要接收的通知类型。
横幅(banner)是一个小而透明的视图，会出现在屏幕顶部并在几秒后消失。用户还可以看到在锁屏当中的横幅以及在通知中心中以通知形式出现的横幅。在横幅中，iOS会显示通知的内容和应用的小图标(欲了解更多关于小图标的内容，请参见 App Icon)。用户点击横幅来隐藏显示并切换到发送通知的应用。
除了默认的点击动作之外，当用户轻扫横幅时,你还可以定义两个动作按钮。点击通知动作按钮来隐藏横幅的显示并启动你的应用(可能是在后台)来执行动作。
通知警告框是显示在屏幕上的标准警告框视图，需要用户操作后才会隐藏。当用户点击Options按钮后，你需要提供并显示通知消息以及任何一个默认动作，或最多四个特定动作。警告框的背景样式不能做修改。 当用户点击警告框中的一个默认或自定义动作按钮时，iOS会同时隐藏警告框并运行你的应用(可能是在后台)。点击关闭或确定按钮会隐藏警告框而不打开应用。
小气泡(badge)是一个显示未读通知数量的红色小圆(小气泡显示在应用图标的右上角)。小气泡的大小和颜色不能做修改。 横幅、警告框和小气泡这三种通知都可以使用自定义或系统提供的声音。
在通知中谨慎使用具破坏性的动作。要确定用户有足够的上下文来避免意想不到的后果。为了帮助用户区分你所定义的破坏性动作，iOS会用红色来显示它。有时候，在应用执行破坏性动作之前，应该请求用户进行确认。举个例子，如果在锁屏的横幅(banner)中提供了一个破坏性动作，那么就应确保只有设备的主人才能执行该动作(你需要在代码上实现这一需求)。
为每个动作按钮提供自定义标题。创建一个简短的标题来描述清楚将要发生的动作。例如，游戏可能会使用“Play”作为标题来表明，点击这个按钮会打开应用来进行游戏。确保标题：
-
使用标题样式的大小写(title-style capitalization)
-
足够简短，能不被截断地显示在按钮内(也应确保测试各种语言文字的标题显示正常)
不要为同一个事件重复发送通知。用户可以选择处理通知项；通知项在用户未处理前会一直显示。如果为同一事件重复发送通知，通知中心列表中会满是通知，用户就有可能会关闭你的应用的通知。
不要在通知消息中包含你的应用名称。自定义信息会在警告框和横幅中显示，也会在通知中心中以通知的形式显示。你无需在自定义信息中显示你的应用名称，因为iOS会在显示信息的同时自动显示应用名称。 为了使本地或远程通知信息更有作用，你应该：
-
专注于信息而不是用户的行为。避免告诉人们点击哪个按钮或如何打开你的应用
-
足够简短，一两行就可以显示完整。较长的信息对于用户来说很难进行快速阅读，也会造成在警告框中需要滚动才能查看完整
-
使用句式大小写(sentence-style capitalization)，并配以合适的结束语句符号。可能的时候，可以使用一个整句
注意：如有必要，iOS会缩短你的消息以便能在各种通知发送样式下显示；为了最好的效果，你不应主动缩减你的消息。
保持小气泡的内容是最新的。当用户注意到新信息时，即时更新小气泡非常重要，这样用户就不会觉得收到了额外的通知。注意，当小气泡为0时也会移除通知中心中所有对应的通知项。
重要：不要使用小气泡做通知以外的用途。记住，用户能够关闭应用的小气泡，所以你无法确定他们一定能看到小气泡中的内容。
当收到通知时，提供用户可以选择听到的音效。当人们没有在看屏幕的时候，可以通过音效获取他们的注意。例如，日历应用可能会在显示警告框的同时播放一个音效来提醒人们一个即将到来的事件。再如，协作任务管理应用可能会在小气泡更新时播放一个音效来告知某个远程协同的同事已经完成了某个任务。
你可以提供自定义的音效，或者使用内置的警告音。如果你创建了自定义音效，请确保它是简短的、有特色的并且是经由专业制作的。(想要了解更多关于音效的技术需求，请参阅 Local and Remote Notification Programming Guide中的 Preparing Custom Alert Sounds )注意，当通知发送后，你无法以编程方式来触发设备的震动，因为用户对于警告框是否伴随震动拥有支配权。
3.10 社交媒体(Social Media)
人们会期望在任何场景下都可以使用他们喜爱的社交媒体帐号。iOS以人们喜欢的方式将社交媒体的交互与你的应用进行了整合。
注意：当用户点击动作按钮时，他们会得到一个如上图的动作视图控制器。想要了解更多关于这个视图控制器的内容，请参见Activity View Controller。
动作视图控制器的中间一行显示了用户启用的和系统提供的分享应用扩展。想要了解更多关于设计分享扩展的内容，请参见 Share and Action Extensions。
考虑在你的应用中为用户提供一种简便的方式来撰写邮件。用户有可能会启用分享扩展以便能在任何地方都可以发送内容。但是你也可以使用系统提供的撰写视图控制器来呈现给用户，他们可以在其中进行编辑操作。你可以在显示给用户进行编辑之前，预先加载具有自定义内容的撰写视图(在你呈现给用户之后，只有用户可以编辑这些自定义内容)。想要了解更多关于社交框架(Social framework)的编程界面，包括 SLComposeViewController 类，请参见Social Framework Reference.
如果可能，避免要求用户登录进入一个社交媒体账户。社交框架(Social framework)会和帐号框架(Accounts framework)一起来支持一个单点登录模式，所以你可以获得授权来访问用户的帐号，而无需要求他们来重新授权。如果用户还没有登录进入一个帐号，你可以显示UI来让他们进行登录。
3.11 iCloud
iCloud可以让用户随时随地用不同的设备访问他们想要的内容。将iCloud集成到应用中，用户不用进行同步操作就可以在不同场景下使用不同的设备访问并编辑私人信息。
为了提供这种体验，你可能需要重新检查你的应用中现有的信息，尤其是用户自建内容的存储、访问和展示方式。想要了解如何使用iCloud，请参考 iCloud Design Guide.
iCloud用户体验的一个基本方向是透明性：理想情况下，用户不需要知道他们的信息存储在什么地方，也不需要去思考当前浏览的信息是哪个版本的。以下几点可以帮助你创建用户期望的iCloud体验。
如果可能，让用户方便地在你的应用中启用iCloud。在iOS设备上，用户可以在设置中登录iCloud账户，因此多半用户会期望应用可以自动启用iCloud。但是如果你觉得用户可能需要自主选择是否使用你应用的云服务，你可以在用户第一次进入应用时提供一个简单的选项来进行设置。大多数情况下，这个选项应该为：是否将所有内容上传到云端。
尊重用户的iCloud空间。一定要记住iCloud空间是用户花钱买来的有限资源。你应该使用iCloud来存储用户自己创建和可理解的信息，避免将可再生的应用资源和内容存储在云端。同样要记住，当用户登录了iCloud账户时，你的应用的文件夹内容也会自动备份到云端。所以为了节省用户云端空间，你最好只挑选必要的信息存储于文件夹中。
避免让用户自己选择在iCloud上存储哪些文件。一般地，用户会期望他们在意的所有信息都能够通过iCloud访问到。实际上大多数用户都不需要进行个人文件存储的管理，所以你的应用也可以不用考虑这个问题。为了提供更好的用户体验，你可能想要重新构建处理和展示内容的方式，这样就可以给用户提供更多的文件管理功能。
决定哪种类型的信息需要存储在云端。除了存储用户自建的文件和内容，你还可以存储少量的其他信息在云端，例如用户当前的状态，用户的偏好设置等等。你可以使用iCloud的关键值存储来保存这类信息。例如，用户使用你的应用看了一个杂志，你可以使用iCloud的关键值存储来保存用户浏览到的位置，这样用户在别的设备上重新打开这个杂志时就能从上次离开的地方继续浏览了。
如果你使用iCloud的关键值存储来保存用户的偏好设置，确保用户在每个设备上都是想这样设置的。例如，有些偏好设置在工作环境中比在家里要更好用。在某些情况下，将偏好设置保存在应用服务器上要比保存在云端更合理，这样偏好设置就不会受iCloud的限制。
确保iCloud无法使用时应用的行为是合理的。例如，用户退出iCloud账户，关闭应用的iCloud或者进入飞行模式时，iCloud都是无法使用的。在这些情况下，用户都进行了某些操作来禁止iCloud服务，所以你的应用可以不用再进行提醒。但是，需要告诉用户在打开iCloud之前，当前做的修改在其他设备上都无法看到。
避免给用户创建“本地”文件的选项。不管你的应用是否支持iCloud，都不应该给用户提供因设备而区分的文件系统。相反，你应该希望用户关注通过iCloud访问文件的普适性。
在合适的时候自动更新信息。最好不需要用户来确认他们正在访问的是最新的内容。但是，也需要在用户设备存储空间和带宽限制之间做出平衡。如果你的用户要使用非常大的文件，那么让他们自己选择是否要从云端下载一个更新的文件可能更合适。如果需要这样做的话，可以设计一种方式来指出当前在云端有一个该文件的最新版本。当用户选择更新时，如果下载时间较长最好给用户明显的反馈。
告知用户删除某文件的后果。当用户从有iCloud服务的应用上删除文件的时候，这个文件同样会从用户的iCloud账号和其他设备上删除。所以最好在执行删除操作之前告知用户删除的后果，让用户进行确认。
必要时尽可能早地告知用户冲突问题。使用iCloud编程接口，你需要在不打扰到用户的情况下解决大多数不同版本之间的冲突问题。但在有些情况下，你需要尽可能早地检测出冲突问题来避免用户在错误版本上浪费太多时间。你需要设计一种自然的方式来告诉用户有冲突存在，接着给用户提供方便的方式来区分不同版本以及做出决策。