iOS 9设计规范 中文版 完整版

译者注：本文译自苹果官方人机界面指南 iOS Human Interface Guidelines (2015年10 月21日)，由腾讯ISUX设计师翻译整理，非发文者一人之作。译文首发于ISUX博客，如在阅读过程中发现错误与疏漏之处，欢迎不吝指出。后续章节会陆续更新，敬请期待。

3.1 3D触摸(3D Touch)

3D Touch 给 iOS 9 用户提供了一个新的交互维度。在所支持3DTouch的设备上，人们可以通过按压应用的图标去快速选择应用定制的操作。在应用内，人们可以使用多种按压操作去获取一个项目的预览，可以在独立的视图里打开一个项获取相关操作。(了解更多在你的代码中如何添加3D Touch支持，参阅 Adopting 3D Touch on iPhone .)

3.1.1 轻压和重压(Peek and Pop)

轻压让用户可以在不离开他们当前环境的情况下预览一个项和执行相关操作。支持轻压的该项会在轻压后给出一个小矩形视图作为反馈。

在Safari中的一个轻压视图

在Safari轻压中的快速操作

轻压(Peek)：

• 当用户按压在一个支持轻压的项上时出现轻压，用户手指抬起后会消失
• 当用户在轻压视图下再更加重一点的按压称之为重压，重压可以查看该项的详细视图
• 当用户在轻压视图中向上滑动，可以提供与该项相关的快速操作

当用户轻轻按压在屏幕，支持轻压的这个项会展示一个你提供的矩形视图，示意可以进行下一步交互操作。那个视图应该够大，这样才能让用户手指不会混淆内容，这个视图应该足够细节，这样可以让用户选择是否去更加重一点按压从而转换到轻压视图。

重要

你在应用中始终如一提供轻压和重压的体验是至关重要的。如果你在有些地方支持轻压和重压，在某些地方不支持，用户有可能认为你的应用或者他们的设备出现了问题。

使用轻压去为该项提供一个生动的，内容丰富的预览。当轻压能够给用户提供关于该项的足够信息，从而帮助他们扩展当前的任务，这样做是最好的。例如，在用户决定好是在Safari中打开信息中的网页还是分享这个链接给朋友之前，用户可以使用轻压预览信息中URL的页面。在表单视图中，轻压可以给用户提供一个行项的详细内容。

为每个轻压提供重压。虽然一个轻压可以提供给用户所需要的大部分信息，但是你应该可以让用户过渡到重压，从而让用户放开当前正在进行的任务，转移专注力到该项上来。重压的内容应该与用户点击该项后的内容一致。

不要为同样一个项授予轻压和编辑菜单(Edit menu)两个功能。当同一个项的这两个功能都启用的时会很混乱。(获取更多编辑菜单信息，参看 Edit Menu.)

在轻压操作里，避免展现类似按钮的界面元素。如果用户抬起手指去点击像按钮的元素，轻压会消失。

如果可能，提供轻压快捷操作。 在轻压里，用户可以向上滑动去显示该项的相关操作。例如，Mail里的轻压快捷操作包括回复全部，转发和删除信息。并不是每个轻压都需要快捷操作，但是如果你已经为该项提供定制的点击并长按的操作，那么最好在轻压里提供相同的操作从而替代点击并长按操作。(注意在网页视图中，轻压快速操作是自动提供的。)

不要将轻压作为唯一开启该项的指定操作的方式。不是每一个设备都支持轻压和重压，一些用户可能选择关掉3D Touch, 因此在你的应用中去寻找其他方式实现轻压的功能是非常重要的。当你的应用在较旧的设备上运行时，可以把轻压的快捷操作映射到一个视图里，让用户通过点击并长按获得。

3.1.2 主屏幕快捷操作(Home Screen Quick Actions)

主屏幕快捷操作可以在主屏幕给用户呈现方便的、有用的、应用特定的操作。

Camara的主屏幕快捷操作

Mail的主屏幕快捷操作

主屏幕快捷操作：

• 当用户在主屏幕采用比点击且长按更重的按压，按压在应用图片上时，出现屏幕快捷操作
• 它会显示一个你提供的短标题，一个图标和可选的副标题
• 它不支持其他定制的内容
• 它可以随着你应用的更新，更新显示的信息

使用主屏幕快捷操作去开启引人注目的、高价值的任务。例如，Maps可以让用户不需要打开Maps，通过在当前位置附近搜索就可以获得回家的方向。一个应用至少需要把一个有用的任务放在主屏幕快捷操作里；你可以提供最多四个快捷操作。

避免使用主屏幕快捷操作去减少应用里导航的内容。如果用户访问你应用的重要区域非常困难和耗时，那么首先去修改你的应用的导航，这样做是可以让所有用户都获益的。接着，可以去为有用的深层次链接提供主屏幕快捷操作，从而开启这些有用的、创造性的任务。

不要把主屏幕快捷操作作为通知用户的一种方式。iOS用户期望以其他方式接收应用中的信息(更多信息参看 Notifications)。

为主屏快捷操作提供一个简洁的标题(可有副标题)和一个模板的图标。标题应该直接传达这个操作的结果；例如，“回家的方向”，“新建联系人”，和“新建信息”。你也可以提供一个副标题给用户更多上下文信息。例如，Mail使用一个副标题在主屏快捷操作的重要位置去告诉用户有未读信息。 不要把你的应用名字或者无关的信息放在标题和副标题里，同时要考虑到使用本地化的用语。

保持标题的简洁不会被切断从而帮助用户快速理解操作是非常重要的。如果你提供的副标题一行显示不全，系统会截断；如果你没有副标题，系统会把一行展示不完全的长标题以两行展现。

你可以从很多系统提供的模板图标中选择图标，你也可以创作定制的模板图标。更多关于图标尺寸、内边距和定位的详细引导信息，可以下载主屏快速操图标模板 https://developer.apple.com/design/downloads/Quick-Action-Guides.zip。更多关于设计模板图标的信息，参看Template Icons。

系统会自动安排图标在快速操作列表中的位置是在左侧或者在右侧，这依赖于你的应用的图标在用户主屏幕的位置。(摒除图标在列表中的位置，在自左向右的语言中文字总是左对齐。)这里有主屏快捷操作的多种展现方式的例子。

3.2 Live Photos

Live Photos 让用户在丰富的声音和动作环境下，捕捉和再现他们喜爱的回忆。从iOS 9开始，相机(Camera)应用可以捕捉附加的内容(拍照之前和结束后的声音和额外的画面)为传统的、静止的图片增加生活气息。在iOS9.1及之后的版本中，你的应用可以让用户享受和分享Live Photos。这个指引可以帮助你给用户提供更好的体验。

在不支持Live Photo的环境中，把Live Photo像传统照片一样展示。不要在支持Live Photos的环境中，自定一种与Live Photo相似的体验。

不要分开展现Live Photo的附加画面和声音。要让用户在不同的应用中体验Live Photos时，有一致的视觉呈现和交互方式。把Live Photo拆分开展现是一个很坏的体验。

确保用户可以区分Live Photo 和传统静止图片。在用户分享照片时，帮助他们做好区分是特别重要的。最好在用户查看一个LivePhoto的时候，展现一点移动作为提示。万一这个提示没有起到作用，你可以在LivePhoto上展示一个系统提供的标记。LivePhoto不要展现一个像视频里回放按钮的界面元素。

注意

上图这种情况，不支持像照片应用里全屏浏览滑动切换照片时的显示的

把用户所做的调整应用到Live Photo的所有帧中。如果你的应用可以让用户为照片添加滤镜或者调整，应确保它可以作用于整个LivePhoto中。如果你不支持调整用户想分享的LivePhoto的所有内容，要让他们知道可以以传统照片的方式分享。 让用户在决定分享前，可以预览这个Live Photo的所有内容。如果你的应用UI可以让用户选择照片分享，要为他们提供一个把Live Photo作为传统照片分享的方式。 如果你使用系统提供的标记，应该把它放在每个LivePhoto上同样的位置。标记可以放在一个不会影响用户查看照片的角落。确保在你的应用中采用一致的方式添加标记，这样可以让用户依靠它去识别LivePhoto。iOS有两种方式提供标记：

• 覆盖。这种覆盖的方式包含一个阴影，适合覆盖在照片上
• 纯色。这种纯色的方式(无阴影)可以被用来创建一个可调色的图片模板
• iOS也提供了很多纯色标记，其中，图片上一个删除线代表现在的LivePhoto被当做是一个传统的照片

在用户下载一个Live Photo的时候给他们一个好的体验。尤其重要的是，用户需要知道他们正在下载的是一个LivePhoto，他们需要知道什么时候可以播放它。如果你为一个Live Photo展示一个未播放的进度指示器，确保这个指示器与你的应用中其他的下载体验一致。

3.3 钱包(Wallet)

Wallet应用是帮助用户查看和管理各种数字化票券的，他们是一些物理个体的数字展现，例如登机牌、优惠券、会员卡、奖励卡和各种票。Wallet也可以让人们添加他们的信用卡、借记卡和储值卡结合Apple Pay使用。你可以在应用中创建一个票券，分发给用户，并且在有更改时进行更新。使用PassKit框架可以方便地用自定义内容来收集一个票券和使用户票券库中的票券。(想要学习Passbook技术的核心概念和PassKit接口的使用方法，请参考Passbook Programming Guide。)以下几点可以帮助你创建一个用户乐意保留并使用的票券。

设计一个在各个设备上呈现很好票券。当你选择一个票券的样式——比如登机牌，优惠券，票据，奖励卡或者通用的票券——你会获得一个特别的布局和一系列区域去处理(更加详细关于不同票券的样式，参看Pass Style Sets the Overall Visual Appearance)。这个系统在各个设备上合理展示你的票券，所以正确使用票券的区域是非常重要的。例如，在Apple Watch上，条状图(strip)和缩略图(thumbnail)图片是不显示的，所以你不希望把基本的信息放到这些元素里。更多Apple Watch票券的布局，参看Designing Passes for Apple Watch.

使用合适的票券区域展现文本。在你的票券中使用允许VoiceOver的用户获取票券中的所有信息的区域，保持你的票券外观的一致性。避免将文本嵌入图片或使用自定义的字体也是一个很好的方法，因为不是所有的图标会展示到所有的设备上，这样对用户来说阅读这样的文字会有困难。

避免使用识别一个设备的语言。你不能预料到哪些用户将会查看你的票据的设备，因此你不想使用可能在一个特别设备上不起作用的语言。比如，文字告诉用户“滑动去查看”内容，当这个发生在Apple Watch上将会不起作用。

尽可能，不要只是简单复制已有的物理票券。Wallet 已经建立了有美感的设计，票券也都配合这种设计以看起来更好。所以不要只是复制物理票券的外观，抓住这次机会设计一个符合Wallet 组成和功能的干净简洁的票券样式。

对放在票券正面的信息精挑细选。用户期望扫一眼票券就能快速获得他们需要的信息，所以票券正面的信息应该是整洁且易读的。如果有用户可能会需要的额外信息，将它们放到票券的背面要比挤在正面好得多。注意，Apple Watch上的票券没有背面。

通常情况下，避免使用纯白色背景。通常，一个好看的票券应该使用鲜艳的纯色背景或者使用强烈的，充满活力的图片作为背景。当然，在设计背景时还要确保内容的可读性。

在商标文本区域显示你的公司名称。所有票券的商标文本区域的文字都使用了统一的字体。为了避免和其他票券发生冲突，还是建议您在商标文本区域输入文字，不要使用自定义字体。

使用白色的公司商标。商标图片放置在票券左上角公司名称的旁边。最好提供一个白色的，单色的，不包含文字的商标。如果你想要增强商标的效果，又想要与文字风格匹配的话，可以增加一个在y轴方向上有1像素偏移，有1像素模糊和透明度为35%的黑色阴影效果。

如果可以的话，使用矩形的条形码。类似于PDF417这样的长方形条形码比正方形二维码更适合票券的布局。如下右图所示，正方形的二维码会使两边有空白区域并且会在垂直方向上使上下方内容变得拥挤。为性能去优化图片。因为用户通常会通过电子邮件或者Safari接收票券，所以让下载的越快越好是非常重要的。为了提高用户体验，使用能满足视觉效果的最小的图片文件。

在合适的时候更新票券以增强其效用。即使一个票券代表的是一个并不会改变的物理实体，数字的票券也可以通过映射真实世界的一些事件来提供更好的用户体验。例如，当某个航班延误时你可以更新登机牌上的信息，这样用户就能够通过查看电子登机牌来获得当前的信息。

3.4 苹果的移动支付平台(Apple Pay)

Apple Pay是苹果公司面向iOS移动设备推出的一种简单、安全、个人的移动支付方式。当用户在购买实体商品和服务时时，可以使用Apple Pay快速、安全地提供个人联系方式、收货地址以及付款信息。通过用Apple Pay支付，用户无需每次购物都要创建账号或填一遍个人信息。Apple Pay显著加快了支付流程，有助于消除前期的各种信息登记，进而为用户的“无障碍”选购过程提供更好的体验。欲了解更多信息，请参阅 Apple Pay Programming Guide. Apple Pay的用户界面非常清晰、简洁高效、低调。它包含三个界面元素，各出现在不同的上下文情境中。按钮。Apple Pay的按钮用来告诉用户，他们可以在当前的情境下(比如商品页面)完成购买。当用户点击了Apple Pay的按钮，立即显示支付上拉菜单(见下文) 开始帮助用户完成支付流程。用户通过“设置Apple Pay”的选项Apple Pay的相关银行卡信息绑定操作。通过调用PKPaymentButton API口可以找到这两个按钮(想要了解更多信息，请查阅PKPaymentButton Class Reference)。有关使用Apple Pay支付按钮的更多详情，请参阅Identity Guidelines.Apple Pay支付标识。当用户需要在授权支付之前选择付款方式并敲定其他信息时，他们期望看到Apple Pay的支付标识。Apple Pay的支付标识应该同其他付款方式以相同或类似的格式显示。支付上拉菜单。在用户提交订单以及完成相关支付之前，Apple Pay会显示一个包含了联系方式、收货地址以及与结账相关付款信息的支付上拉菜单。尽管用户依然可以在支付上拉菜单里做些微调，比如选择不同的送货方式，但他们不用做出重大改变或输入其他信息。当用户看到该支付上拉菜单，他们应该能够立即完成交易并授权付款。

对于可以使用Apple Pay付费的用户，Apple Pay的用户界面应当始终显示。如果用户的移动设备支持Apple Pay，并且他们已经激活了相关可用的银行卡因此可以通过将Apple Pay设为默认支付方式来满足用户的期望。

如果用户无法使用Apple Pay服务，就不要显示任何Apple Pay的用户界面。如果用户使用的设备不支持Apple Pay，仍强行将其作为一个支付方式选项，可能会对用户造成混淆。但是，如果用户使用的设备是支持Apple Pay，但没有绑定任何信用卡或借记卡，你可以在界面中显示“设置Apple Pay”的按钮。

当用户点击了Apple Pay的按钮，立即显示支付上拉菜单。当用户决定使用Apple Pay来结账时，如果还要迫使用户经历额外步骤，会使支付流程显得复杂，增加不必要的矛盾，并可能会让用户感到沮丧受挫。当用户点击了Apple Pay按钮，不要显示其他警告或模态对话框视图。如果用户可以提供像打折或促销代码之类的信息，请在用户点击Apple Pay按钮之前找到一种方式来接收该信息。

Apple Pay按钮与其他可见的支付按钮应保持相同的尺寸大小或更大。将Apple Pay按钮放置在醒目的位置，可以帮助用户轻松找到它。使用Handoff功能帮助用户完成在Apple Watch上发起的购买。 Apple Watch佩戴者可以在商店完成支付，但他们无法完成由Apple Watch第三方应用程序调用的支付行为。当Apple Watch佩戴者发起了由第三方应用程序调用的支付行为，则显示一条消息告诉他们请在iPhone上完成支付。为了更好的用户体验，还可以使用Handoff功能深层链接到你的iOS应用程序上，并立即显示包含预设好的相应付款信息的支付上拉菜单。

有关使用Apple Pay支付按钮以及Apple Pay支付标识的更多信息指南，请参阅 Apple Pay Identity Guidelines.

3.4.1 自定义支付上拉菜单 (Customizing the Payment Sheet)

根据完成交易付款所需要了解的信息，以及所要传达给用户关于本次购物的信息，来自定义Apple Pay支付上拉菜单所要显示的内容。

支付上拉菜单仅显示对完成交易付款有必要的信息。如果Apple Pay支付上拉菜单显示了些无关的信息，用户可能会感到困惑或焦虑。举个例子，如果商品是在线交付或通过电子方式完成，需要联系人的电子邮件地址是有意义的，而不是收货地址。在这种情况下，要求收货地址可能给用户产生会有什么东西将意外被派件到家中或公司的错觉，或许还可能导致他们对个人隐私被访问产生不必要的担忧。

支付上拉菜单允许用户可以选择更换送件或取件方式。用户可以从你在支付上拉菜单中设定的几种交付方式中随意选择一种。通过用文本标签控件、报价以及可选的第二行预计到达日期，来具体描述一种收货方式。另外，你还可以设定交付方式为“派件”或“取件”，让用户指定一个可接收快递送货上门或需要运输服务取件的位置。

使用并排项来描述周期性付款和一些购买费用的小计。 并排项包含了一个标签文本和花费数值。并排项被用来：

• 表明用户授权一个定期付款项目，比如“每月订阅 $19.99”
• 告知用户关于额外费用，比如“礼品包装 $5.00”和“税费 $4.53”
• 显示优惠券或折扣信息带来的减价，比如“周五特价 -$2.00”
• 描述某个项目需要按实际计费，比如运输服务“时间&距离 …”

不要用并排项来显示所要购买的商品的构成清单。

创建并排项标签时，尽可能显示在同一行。并排项标签应该具体、容易理解。如果行条目标签字符数过长，那么很难让你的用户一看就懂。

商户名称需要紧紧跟随在同一行的“Pay”字符后面作为一个整体。确保所使用的商户名称以及相应的开销支出，必须与用户检查自己的信用卡或银行对账单时的数据保持一致。这一点很重要，因为它有助于用户确信他们的开销支出是无误的。如果你的应用程序只是作为中间媒介，而不是最终的商户支付，请明确向用户表明这个具体说明“付款给 最终的商户名称(通过 你的应用程序名称)。

如果总价花费在支付授权时还不明确，请向用户传达有可能会有额外费用的信息。举个例子，一次汽车旅程从支付授权时刻起到驶向最终目的地，它的开销报价可能会受行车距离或时间的影响变化。或者，一个客户可能想要给点小费在商品已派件之后。对于这样的情况，在支付上拉菜单中给予一个非常明确的解释说明是很有必要的。当你使用一个并排项来配置最终总价的更新信息时，总价金额会自动显示为“总价待定”。另外，如果你是预授权支付一个具体金额的订单，确保支付上拉菜单准确地反映了这一信息。

3.4.2 简化结账流程(Streamlining the Checkout Process)

Apple Pay使得购物变得快速、简单，对此人们会欣然接受的。更少的步骤和更少的需要用户手动输入的信息，使得整个结账流程更好。

始终使用Apple Pay的最新数据信息。假设用户一直保持Apple Pay个人信息的完整性和时刻更新，那么不要依赖于任何先前收集的信息。即使你以前已收集过用户的联系方式、交付方式和支付信息，也要在结账时获取来自Apple Pay的最新信息。在结账环节，尽量避免用户输入本可以从Apple Pay获取的任何信息。

使用Apple Pay加快购买。对于单个商品项目的购买，让用户只需通过点击商品页面上的Apple Pay支付按钮，即可显示支付上拉菜单并进行即时结算。购买单个商品时，无需采取额外的步骤，也无需将商品添加到购物车，用户喜欢在应用程序中体验到这种便利性。对于多个商品被添加到购物车中会使用相同的交付方式被送到相同地址的情况，一旦用户有意向支付时，会通过显示支付上拉菜单的快速结账流程来支持。

在显示支付上拉菜单前需提前收集好赎回代码或促销代码。因为在Apple Pay支付上拉菜单中没有办法输入这些代码，请务必在显示支付上拉菜单之前收集好相关代码。

如果人们可以将购买的商品派送到不同地方，或以不同的速度发货，请在显示支付上拉菜单之前提前收集好该信息。对于这种极端情况，你需要在显示支付上拉菜单之前得到发货信息，因为在支付上拉菜单中没有办法来指定多种交付方式和地址。一般情况下，在支付上拉菜单中务必收集到交付方式和地址信息。

显示订单确认页面或致谢页面。在交易完成时，通过使用订单确认页，以这种直接的用户体验来显示关于商品能派送到的预计时间以及用户如何跟进订单状态的信息。

如果合适的话，请在你的订单确认页上提到Apple Pay。尽管在你的确认页面上提到Apple Pay不是必要的，如果你愿意选，可以使用其中的一种格式：

• “Visa 1234(Apple Pay)”
• “用Apple Pay已完成付款”

3.5 研究型应用程序(Research Apps)

研究型应用程序可以让苹果用户充分利用iOS移动设备的便利性，参与到各种研究性学习中来。通过调用开源代码ResearchKit，使用预设的几种界面视图和转场动画，可以很轻易为你的研究和参与者自定义一个美观易用的研究型应用程序，这些资源都可以在苹果的开源代码ResearchKit项目中调用。要想了解如何使用ResearchKit来为你的研究开发一个研究型应用程序，请查阅researchkit.org.

重要

这些规范准则仅供参考之用，并不构成任何法律意见。对于与你的研究型应用程序发展以及任何法律适用的相关建议，你应该向律师咨询。

通常情况下，一个研究型应用程序是由ResearchKit定制化的界面视图以及应用程序本身具体设定的界面视图组成，可归纳为三种主要的体验：

• 参与者的就位培训(Onboarding)
• 研究性调查(Study-specific investigation)
• 管理条目信息(Management items)

设计你的研究型应用程序时务必要遵循以下每个部分的规范准则，将有助于你的用户参与者感到舒服和保持参与感。

3.5.1 参与者的就位培训(Onboarding)

就位培训的体验包含了一系列向潜在参与者介绍研究内容以及征询他们同意的环节。完成这些以后，参与者通常不会再重新访问这些就位培训的内容环节：

你应该按如图所示的这个顺序呈现就位培训的各个体验环节，也就是按介绍指引、适任、知情同意，以及授权访问数据。

创建一个具有号召性用语的介绍指引。指引环节应该帮助人们了解更多关于你的研究以及告诉他们如何成为一名参与者。指引环节最好也能向那些现有的参与者提供快捷登录的入口以便继续正在进行的研究。尽快确认招募的用户是否合格。适任环节呈现在指引环节之后、知情同意环节之前(如果参与者并不适合该研究则没有必要让其查看知情同意环节)。请确认所呈现的适任资质要求对于你的研究来说是必要的。请使用简单、直白的语言描述这些要求，并让用户可以很容易就输入相关信息。在得到参与者的同意之前，确保他们已充分了解你的研究内容。ResearchKit有助于让知情同意流程显得简洁、友好，同时还允许将你同意的任何法律规定或由机构审查委员会和伦理审查委员会所设定的规定纳入其中。(如果你的应用程序涉及到进行人体生物学相关的研究，必须确保你的应用程序符合现有的苹果应用商店规范指南，并获得参与者的许可。)通常情况下，知情同意环节包含了：

• 说明这项研究是如何工作的
• 确保参与者了解研究内容以及各自的责任
• 获得参与者的许可

将冗长的同意书分解成易理解消化的小节。每个小节可以只覆盖研究内容的一个方面，比如数据采集、数据应用、潜在好处、可能的风险、时间承诺、如何撤出等等。每个小节请使用简洁、直白的语言来说明一个高度概括的内容。如果有必要，提供一个查看详情的按钮便于参与者了解该小节更详细的解释。应该让他们在同意参与之前，就查看完全部知情同意内容。通过一个小测验来测试参与者的理解情况是有意义的。在获得参与者允许的情况下，你可以选择向每个参与者询问相同的问题。你的研究必须获得参与者的同意，如果合适，还可以收集一些联系人信息。参与者同意参与研究后，他们需要提供个人签名以及联系方式，最后会收到一个确认对话框。对于这些信息记录，大多数的研究型应用程序会向参与者电邮一份PDF格式的同意书。

参与者需要对这个确认自愿参与研究的告警对话框给予响应

参与者可以提供他们的个人签名在知情同意流程中

如果你需要访问参与者的设备或数据必须得到他们的许可。必须解释清楚你的研究型应用程序为什么需要访问他们的位置信息、健康应用程序或其他数据，并且确保避免向参与者索要对你研究并非至关重要的数据。同样地，如果你需要向参与者发送通知提醒也要获得参与者的许可。

让参与者准备授权访问数据，比如健康应用程序的数据

让参与者自己选择他们愿意与你共享的数据

3.5.2 具体研究的调查(Study-Specific Investigation)

为了从参加者获得数据输入，你的研究可能会使用情况调查、活动任务，或两者的组合。根据你的研究的体系结构，参与者可能会在每个环节多次或仅需完成一次交互即可。

问卷调查的设计应该能让参与者专注参与其中。 ResearchKit可以很容易就呈现多种答案类型的调查问题，比如对错、多选、日期和时间、比例计算，以及开放式文本填写。当你使用ResearchKit的界面视图来创建一项调查，请遵循以下准则，来保证好的用户体验：

• 告诉参与者总共有多少道问题，以及完成调查预计需要花费的时间
• 每屏只呈现一道问题
• 显示给参与者当前调查的进度
• 调查应该尽可能简短。几个简短的调查往往好于一个冗长的调查
• 对于需要额外解释的问题，问题描述请用标准字体大小，然后解释文字用略小的字体大小
• 调查结束时要告知参与者

ResearchKit提供了许多用于调查环节的可自定义界面视图。这里有一些样例。3使得活动任务容易理解。活动任务需要参与者参与到一次活动中来，比如对着麦克风语音、手指在屏幕上完成点击、行走散步，以及执行一次记忆力测试。请按照以下几点准则来鼓励参与者执行活动任务，并给与他们成功的绝佳机会：

• 请用简洁易懂的语言来描述如何执行本次任务。
• 如果任务必须在特定的时间或特定情况下进行，请务必明示。
• 确保参与者可以分辨出任务何时结束。

以下是ResearchKit所支持的两个活动任务样例。

3.5.3 管理条目信息(Management Items)

ResearchKit提供了个人档案的界面视图来让参与者可以管理他们的个人信息。此外，创建一个可以激励用户并能让他们追踪他们在研究中的进度的界面视图是个不错的选择。在大多数情况下，参加者应该能够随时访问这两个模块。

使用个人档案来帮助参与者管理个人信息和与你研究相关的数据。个人档案界面视图允许参与者在研究进程期间可以编辑相应数据，比如体重或睡眠习惯，并且可以提醒他们即将到来的活动任务。你同样可以在个人档案中给予参与者一种简单的方式离开该研究、查看知情同意书，以及查看该应用程序的隐私政策。使用仪表盘概览视图来激励参与者，并呈现进度。一个概览视图可以让你与参与者对信息一览无余并鼓励他们继续参与。如果你的研究内容合适的话，你可以使用该概览视图给予参与者丰富的反馈，比如每日进度、每周评估、具体活动的结果，以及同其他参与者的汇总结果进行对比。

3.6  应用扩展(App Extensions)

应用扩展可以延伸应用的使用范围。当用户使用其他应用时，应用扩展使得用户仍能使用你应用的核心功能。举个例子，当人们在Safari中浏览网页时，他们可以使用你的分享扩展来发送一张图片或一篇文章到你的社交网站上。或者当使用Photos(照片)应用时，人们可能会使用你的图片编辑扩展来为一张图片加上一个滤镜效果。(在这些场景中，Safari和照片应用承载用户使用扩展的场景，因而被称为宿主应用(host apps)。)

你需要提交包含应用扩展的完整iOS应用到App Store(包含扩展的应用被称为容器应用(containing app))。在你的容器应用中启用扩展之后，人们就可以在使用其他应用时，使用扩展来执行快速任务。例如，在邮件中浏览某个商品时，人们可以不用离开邮件应用就使用你的动作扩展来把商品添加到购物清单中。 表 22-1 列举了可以多个创建的iOS应用扩展类型。

应用扩展类型	人们使用扩展来做…
今天部件(Today widget)	在通知中心中获得快速更新或者在今天视图中快速完成任务
分享(Share)	发送到网站或者和他人分享内容
动作(Action)	通过另一个应用的上下文信息来操作或查看内容
图片编辑(Photo Editing)	使用照片应用编辑图片或视频
文档提供者(Document Provider)	进入和管理文档库
自定义键盘(Custom keyboard)	替换iOS系统键盘

以下指南适用于所有类型的应用扩展，针对特定类型应用扩展的指南请参阅后续章节。(如果想了解如何开发、调试和发布一个扩展，请参阅App Extension Programming Guide.)

确保是单任务。应用扩展并不是应用的精简版，它帮助用户在有全局目标的上下文中完成狭义范围内的有限任务。例如，动作扩展可以为用户提供一种不同的方式来查看当前内容。

保证用户的交互是有限和流畅的。好的应用扩展应该只需几步点击就可以帮助人们完成任务，这样他们就能尽快回到之前的场景中。例如，分享扩展只需一次点击即可完成一张图片的分享。

将容器应用及其应用扩展的名称保持一致。一个容器应用中如果有多个扩展，需要使用不同的名称，你需要确保用户能够理解你的扩展和应用之间的关系。人们会在很多不同的情况下遇到扩展，如果他们当下没有认出来，那么他们就未必会信任这些扩展。

大部分情况下，复用容器应用的图标。显示用户熟悉的图标是获得用户信任的另一种方式。请注意，对于动作扩展来说，你应该使用单色版本的容器应用图标(详见分享和动作扩展)。

重要：和设计图标和图形一样，不要重复使用iOS的图标和图片，不要为苹果的产品和设计再设计一套图片。

避免在扩展上显示模态视图。很多扩展默认以模态视图来显示，所以应避免再叠加模态视图。尽管有时候用户可能会在扩展上遇到警告框，但是在设计扩展的流程时，应避免出现模态视图。

3.6.1 今天部件(Today Widgets)

人们会在通知中心的今天区域中查看今天部件(Today widgets)。因为人们会设置今天区域以显示他们最关注的信息，所以在此进行设计可以有效帮助你的部件在这些用户最重要的信息中占据一席之地。设计与通知中心风格一致的外观。当使用通知中心的默认边距和背景时，你的今天部件就会给用户以统一的体验。为获得最佳的结果，你应该重点关注你的内容而不是背景或者其他的，尤其应该避免绘制一片纯色背景。

注意：

iOS会自动在自定义的部件内容上方显示应用的图标和标题(图标会显示在标题前面的空白处)。

将部件内容与标题对齐。当你的部件内容与标题对齐时，人们就可以很简单地浏览今天视图中他们想要的部件。遵守今天视图中的边距规范，并将内容约束在如图的部件内容区内。  一般情况下，使用白色的系统字体来显示文本。在通知中心默认背景下白色文字会看起来较好。对于二级文本，可以使用系统提供的vibrant外观样式(查看notificationCenterVibrancyEffect了解更多)。

提供通知中心式的体验。人们访问通知中心来获取简要的更新或者执行一个非常简单的任务，所以今天部件最好只显示适量的信息和进行有限的互动，特别是：

• 避免用户在部件中需要滚动或纵向移动来查看全部的信息。部件可以通过纵向扩展来显示更多的信息，但若部件的高度超过通知中心的高度就不是一种好的体验了，因为这样会干扰其他部件的查看
• 避免使用横向扫动或拖曳，因为这会干扰在通知中心进行导航
• 尽可能使用户只需一步操作就完成任务或打开你的应用(注意，在今天部件中键盘是不可用的)
• 优化性能以便人们可以即刻获得有用的信息。可以考虑在本地缓存信息，以便当有更新时就可显示最近信息。人们只希望在今天视图中花很少的时间，如果部件使用内存不当，iOS就可能会终止它

在适当情况下，让人们点击你的今天部件来打开你的应用。因为今天部件提供了专一的体验，所以就能有效引导人们去到你的应用以获取更多信息或功能。最好不要显示“打开应用”按钮，而是应该让你的整个今天部件都可被点击来打开应用。你也可以让用户点击部件中的UI对象，以打开你的应用并跳转到关于此UI对象的视图中。举个例子，日历部件显示了今天的事件，如果用户想要获得某个事件的更多信息，他们可以点击部件中的事件来打开日历应用进行查看。

注意：

虽然从部件打开应用的方式对用户来说还不错，但继续在部件中提供有用且及时的信息依然是很重要的。人们可不一定会欣赏一个功能只是打开应用的今天部件。

如果可能，在今天部件中让人们知道他们需要登录来获取有用的信息。如果你的今天不见需要人们登录查看信息，展示一个信息去鼓励他们登录和解释什么样的内容将会被呈现。例如，如果你的时间部件即将到来的预约是用户登录后展现的，你可能需要让用户“登录我的应用去查看即将到来的预约”。

不要制作一个今天不见需要打开除了你自己应用外的应用。一个模拟iOS主屏的行为的时间部件不会为你的用户提供有用的功能。

3.6.2 分享和动作扩展(Share and Action Extensions)

人们通过点击应用中的动作按钮(Action button)来使用分享和动作扩展。在通过动作按钮显示的动作视图控制器(activity view controller)中，动作扩展被列在底部，分享扩展被列在动作扩展之上。人们可以使用更多（More）按钮来管理显示在动作视图控制器中的分享和动作扩展。分享或动作扩展通常被认为是在当前用户场景下用来输入内容之用。例如，当在Safari中阅读一篇文章时，用户可能会点击动作按钮并使用一个分享扩展来发送这篇文章到分享网站上，也可能会使用一个动作扩展来查看这篇文章的翻译。

注意：

在动作视图控制器中，iOS只会显示支持当前内容类型的动作扩展。例如，当用户当前内容是视频时，iOS就不会显示支持文本的动作扩展。

尽可能在分享扩展中使用系统提供的UI。系统所提供的撰写视图控制器 (compose view controller) 提供给用户一种一致的体验，并能自动支持一些常用任务，例如预览和确认标准项，同步内容，查看动画，以及完成一封邮件。欲知更多关于使用系统提供的撰写视图控制器，请参见 App Extension Programming Guide中的Share.

如果上传需要一定时间，那就应考虑在分享扩展的容器应用中显示上传进度。无论分享的文件有多大，人们都期待在点击扩展中的发送或分享按钮后，能立即返回他们之前的场景。你需要让进度状态随时更新，但是人们不想每次上传完毕后都收到通知，并且也无法自动重启扩展。在这种场景下，在容器应用中显示上传进度是一种解决方案，这样容器应用就可以在后台处理任务，并在遇到问题时发送通知。

动作扩展使用单色的应用图标。( 不同的是，分享扩展则应该使用其容器应用的彩色应用图标。) 要为动作扩展设计图标时，你可能需要从创建一个应用图标的模版开始着手。如有需要，可以专注图标所特有的元素来进行简化设计。

如果你在容器应用中提供了多个动作扩展，那么最好为他们设计一套图标，且确保这套图标中的每一个看起来都与容器应用的图标是有关联的。

3.6.3 图片编辑扩展(Photo Editing Extensions)

当人们在照片(Photos)中查看图片或视频时，可以使用图片编辑扩展。一般来说，图片编辑扩展能帮助用户筛选图片或进行一些其他的图片或视频编辑。在用户确认之后，编辑后的内容就会出现在照片应用中。

照片应用提供了一个模态视图来显示图片编辑扩展的自定义UI。当用户在确认对图片或视频的编辑时选择了取消(你必须要在代码上保证存在这个行为)，照片应用还可以显示一个确认视图。

避免在图片编辑扩展中使用导航栏。如图所示，承载扩展的模态视图已经包含了导航栏，若再增加另一个导航栏，既会占据更多你的界面空间，还会使用户产生困扰。(照片应用默认会以全屏高度来显示你的视图，所以你的内容会出现在内建的导航栏之下。)    如果可以，让用户能够预览编辑结果。尽可能让用户在关闭扩展返回照片应用之前看到他们编辑的成果。

3.6.4 文档提供者扩展(Document Provider Extensions)

文档提供者扩展帮助人们在其他各种应用中查阅你的应用所管理的文档。在宿主应用(host app)中，文档采集视图控制器(document picker view controller)会显示你的扩展所提供的UI(想要了解更多有关文档采集视图控制器的内容，请查阅UIDocumentPickerViewController Class Reference).

注意：

文档提供者扩展由两个不同的部分组成：文档采集视图控制器扩展和文件提供者扩展。文档采集视图控制器扩展包括了你的自定义UI，文件提供者扩展实现对文件的访问。为了简单起见，本节所使用的术语文档提供者扩展(Document Provider extension)是为了表述扩展中文档采集视图控制器部分的UI和体验。

避免在文档提供者扩展中使用导航栏。iOS会显示扩展的自定义UI，而自定义UI又包含在文档采集视图控制器中基于导航栏的界面之中。所以，在内建导航栏之下再显示第二个导航栏会使用户感到困惑，并且还会占据原本你的内容区域。(文档采集视图控制器默认会以全屏高度来显示你的视图，所以你的内容会出现在内建的导航栏之下。)

3.6.5 自定义输入法(Custom Keyboards)

人们在整个系统中使用带有自定义输入法的输入法扩展来替换iOS的自带输入法。在启用输入法扩展之后，除了受保护的文本区域(例如密码输入区)和手机键盘区(例如联系人中的电话号码区)外，当人们点击任何文本输入区域后就能使用自定义输入法。

为用户提供明显的方式来切换输入法。人们对于iOS的输入法切换按钮很熟悉，他们会期望在你的输入法中也有类似的体验。

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应用可以使用通知来让人们知道一些有趣的事情是什么时候发生的，例如：

• 收到一条消息
• 事件即将发生
• 有新的数据可下载了
• 某些状态发生了变化

在iOS8及之后的版本中，应用可以定义用户在通知中的操作。例如，用户可以在待办事项应用的通知中就标记该事项已完成，而无需额外打开应用。 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编程接口，你需要在不打扰到用户的情况下解决大多数不同版本之间的冲突问题。但在有些情况下，你需要尽可能早地检测出冲突问题来避免用户在错误版本上浪费太多时间。你需要设计一种自然的方式来告诉用户有冲突存在，接着给用户提供方便的方式来区分不同版本以及做出决策。

确保在搜索中包括用户在云端的信息。使用iCloud的用户趋向于认为云端的信息是普遍可访问的，所以他们会期望搜索结果中也有云端的信息。如果你的应用允许用户搜索他们的信息，确保你使用了将搜索扩展到iCloud账户的接口。

3.12 HealthKit

在iOS 8及之后的版本中，使用HealthKit构建的应用可以利用从健康应用中获取的数据为用户提供更强大、更完整的健康及健身服务。在用户允许的情况下，应用可以通过HealthKit来读写健康应用(用户健康相关数据的存储中心)中的数据。

举例来说，用户可以允许营养应用从健康应用中获取体重及活动数据，用于告诉他们为了达到既定目标一天应该消耗多少卡路里。这个营养应用还可以通过HealthKit更新健康应用上实际消耗的卡路里数据，让用户能更容易地跟踪他们的健康计划的进展。想要了解如何将HealthKit整合进你的应用中，请参阅HealthKit Framework Reference.

下面的指南能够帮助你设计出让人信任且喜爱的健康类应用：

当且仅当你有令人信服的理由时才去访问健康应用中的数据。HealthKit是为了专注于健康及健身服务的应用而设计的。如果一个应用请求获取与其不相关的健康信息，用户不太可能会放心地将个人数据提供给这个应用。因此，你需要确保用户能够理解你的应用需要获取他们某些具体的个人健康数据的原因，并告诉他们共享这些数据的好处。

避免在用户还不知道用途前就向他们请求访问私人健康数据。当用户能够看到当前的任务和你需要访问的数据的关联性时，会更乐意给予你访问权限。举例来说，当用户在给一个减肥应用填写资料时，让他允许你访问健康应用中储存的体重数据是合理的。但如果那个减肥应用在启动时就立即提出访问体重数据的请求，用户更可能会选择拒绝分享该个人数据。

使用系统提供的用户界面来请求访问用户的数据。当用户想要向应用授予访问他们的数据的权限时，一般会期望看到如下图所示的系统权限许可列表。为了确保给用户提供良好的用户体验，应避免在应用的其他页面中重复使用权限许可列表上的信息。而是应该在权限列表中添加些自定义信息来说明为什么你的应用需要访问特定的数据(参阅HKHealthStore Class Feference可获取更多信息)的原因。确保这些信息简洁且能清晰地说明你的应用是如何利用健康应用中的数据，以及收集这些数据的好处。

注意：当用户决定停止与你的应用共享数据时，让他们可以在系统设置中即可完成变更，而不需要通过你的应用界面。

不要在你的应用界面中使用健康应用的图标、图片或者截图。和苹果所有的系统设计一样，这些图像都是受到版权保护的，不应该在你的应用中出现。

不要在你的应用中使用“HealthKit”这个专用术语。HealthKit是代表能够获取健康应用中储存的数据的技术框架的专用技术术语。如果你需要向用户解释你的应用和健康应用中的数据的联系，请使用“健康应用”这个用语。例如，你可以说你的应用“将保存信息至健康应用中”或“所使用的数据是从健康应用中获取的”。

3.13 应用内购买服务(In-App Purchase)

应用内购买服务使得用户可以在你的应用中、你所设计的商店中购买到数字产品。

例如，用户可以做这些事：

• 将一个应用从基础版本升级到高级版本。
• 每月订阅新内容。
• 购买虚拟商品，比如游戏中的等级或道具。
• 购买并下载新的书籍。

你可以使用StoreKit框架以嵌入的方式将商店添加到你的应用中，并且用来支持应用内购买服务。当用户进行购买时，StoreKit会连接到应用商店进行安全支付，然后再告知你的应用以便它可以提供用户已购买的商品。

重要:应用内购买服务只提供支付功能，其他功能由你自己提供，例如向用户展示商品，解锁内置功能，从你自己的服务器上下载内容等等。当然，你所提供的所有商品都必须在应用商店注册过。

想要了解关于在应用中添加商店的技术要求，请查看In-App Purchase Programming Guide.想要了解更多关于应用内购买的商业需求信息，请查看App Store Resource Center.当然，你还应该查看相关许可协议来确定你的应用可以出售哪些商品以及如何提供商品。

遵循以下几点规范，可以帮助你设计出用户喜欢的购买体验。

将商店的使用体验优雅地集成到你的应用中。在展示商品和处理交易时，给用户提供一种熟悉、一致的体验。你一定不希望用户在访问你的商店时感觉像是进入别的应用。

使用简单明了的标题和说明。最好能让用户在扫过一组项目时，可以快速发现感兴趣的内容。文案上不要截断隐晦，简单直白的语言和标题更容易让用户理解你所要展示的商品。

不要更改默认的确认对话框。当用户购买一个商品时，StoreKit会提供一个确认对话框(如上图所示)。这个确认对话框可以帮助用户避免买错东西，所以不要修改它。

3.14 游戏中心(Game Center)

游戏中心给用户提供玩游戏、组织多人在线游戏以及其他更多功能。玩家可以使用内置的游戏中心应用来注册账户、发现新游戏、添加好友、浏览玩家排名和战绩。

作为一名游戏开发人员，你可以使用GameKit应用接口来发布分数和战绩到游戏中心的服务器上，在你的游戏页面中显示玩家排名，帮助用户找到其他玩家。想要了解如何将游戏中心集成到你的应用中，请查看Game Center Programming Guide.

遵循以下几点规范，有助于你的应用给用户提供好的游戏中心体验。

不要使用自定义的用户界面来提示用户登录到游戏中心。如果用户在未登录到游戏中心的情况下打开了一个需要启用游戏中心的应用，系统会自动提醒他们去登录。所以没必要自定义一个登录界面，而且有可能还会让用户感到困惑。

一般情况下，使用标准的游戏中心界面。在少数情况下，可能自定义游戏中心的界面是合理的，但是这样做会有让用户感到困惑的风险。标准的游戏中心界面对于iOS和OS X的用户是熟悉的，而且它会给用户一种置身于一个庞大游戏社区的感觉。

允许用户关闭语音聊天。有些用户可能不想在进入游戏时就自动开启语音聊天，而且大多数用户希望在特定情境下可以关闭语音聊天。

3.15 iAd富媒体广告(iAd Rich Media Ads)

如果你允许你的应用中出现广告，那么你可以通过用户浏览或者点击这些广告获得收益。(如图所示，这个底部预留位置就是用来放置iAd横幅广告。)

通过iAd网络你可以在你的用户界面中以特定的视图投放一则广告。最初，这种视图可以用来承载目标横幅广告，起到引导用户进入查看全面广告详情的作用。当用户点击该横幅广告时，广告就会执行预先设定的动作，例如播放一段影片、展示可交互的内容，或者启动Safari打开目标网页。该动作所展示的内容可以遮挡住你当前的用户界面，或者使你的应用转换到后台运行。

有三种类型的横幅广告供你在应用中使用：标准(standard)、中等矩形(medium rectangle) 和全屏(full screen)。所有类型的横幅虽然在外观和行为上存在差异，但都提供同样的功能，就是引导用户进入广告。

标准横幅(standard banner)占用屏幕较少的空间，通常从始至终都可见。你可以选择在应用的哪些页面展示标准横幅，并在给这些页面设计布局时预留出空间。

所有的iOS应用都可以展示标准横幅。你可以使用ADBannerView类中的广告视图来显示标准横幅广告。

中等矩形横幅 (medium rectangle banner) 的行为同标准横幅类似，同样也可以选择展示中等矩形横幅的位置。

中等矩形横幅只能在iPad的应用中使用。你可以使用ADBannerView类中的广告视图来显示中等矩形横幅广告。

全屏横幅 (full screen banner) 会占用屏幕的大部分甚至是全屏空间，并且通常只在应用程序流的特定时间或特定位置显示。你可以选择使用模态视图来显示横幅广告，或者用独立页来展示可滚动的广告内容。(在下面的示例中，应用提供了一种杂志阅读的体验，通过翻页离开或回到全屏广告页面。)

你可以使用ADInterstitialAd类中的广告视图在你的应用中显示全屏横幅广告。

iAd框架包含了所有类型的横幅广告，并且会在右下角显示iAd的标识。iAd框架的设计固定在屏幕底部时看起来效果最佳。

为了保证广告无缝植入，并且要提供最好的用户体验，可以遵循以下几点规范。

将标准横幅广告视图尽量放置在屏幕底部或底部附近。这个位置的差别取决于屏幕底部是否包含栏(bar)以及是什么样的栏。

栏	标准横幅的位置
屏幕底部没有栏	屏幕底部
屏幕任何地方都没有栏	屏幕底部
有工具栏(toolbar)或标签栏(tab bar)	底部栏的上方

将中等矩形横幅广告视图放置在不会干扰内容的地方。和标准横幅一样，中等矩形横幅也最好放置在屏幕底部或底部附近。放在底部附近也能减少干扰用户的可能性。

当用户体验存在中断时请使用模态视图来展示全屏横幅广告。如果你的应用中有自然中断或情景转换，用模态样式来展示会更合适。当你使用模态样式来展示全屏横幅时(通过用presentFromViewController实现)，用户要么进入广告，要么关闭它。出于这个原因，当用户有做出转变的预期时 (比如完成了一个任务后) 用模态视图的形式来展示比较好。

应用的界面视图进行转场切换时不要使用模态样式展示全屏横幅。如果用户在使用你的应用时会频繁的进行屏幕切换操作，例如杂志翻页或翻阅一些画册图片合集，此时使用非模态的形式会更合适。当你使用非模态来显示全屏横幅时(通过使用presentInView实现)，可以在用户界面中保留栏 (bar) 使得用户可以通过应用中的控件进入或退出广告。同其他横幅广告一样，点击全屏横幅广告也会触发iAd体验，但是如果条件允许的话，你的应用也可以对横幅广告区域支持其他手势操作 (比如拖动或滑动)。

确保使用合适的动画效果来显示和隐藏非模态的全屏横幅视图。例如，杂志阅读应用可以用和杂志翻页一样的动画效果。

确保横幅广告在应用中出现的时间和位置是合理的。用户只有在不觉得广告会打扰他们正常的工作流程时才有可能去体验iAd.这点对于游戏这样的沉浸式应用尤其重要：你肯定不想将横幅放置在影响用户玩游戏的位置。

避免将横幅放置在用户只会一扫而过的页面。最好不要将横幅广告放置在用户会快速略过的页面，比如用户正要深入挖掘或前往他们所关注的内容。通常用户在一个页面停留至少1、2秒后才有可能会点击广告。

尽可能的支持双向展示横幅广告。最好让用户在使用应用时不必旋转设备就能浏览广告。当然，支持双向也能给你的广告提供更大的展示区域。想要了解如何确保转换方向时横幅广告能正常响应，请查看iAd Programming Guide.

不要让标准或中等矩形横幅广告滚出屏幕。如果你的应用需要滚动来展示更多内容，确保横幅广告一直固定在它的位置上。

当用户浏览或与广告进行交互时，暂停那些吸引用户注意力或需要操作的活动。当用户选择浏览广告时，他们不想因此错过应用中正发生的事件，也同样不想让应用打断广告体验。一个好的经验方法是像应用程序转入后台运行那样暂停当前活动。

除非有特殊情况，否则不要中断广告。一般情况下，当用户浏览并与广告进行交互时，应用还是会继续运行并接收事件，所以也有可能突然出现一个事件需要获得用户的注意力。然而，需要打断广告的场景其实非常少。有一种情景是有的应用会提供互联网语音协议服务(VoIP).在这种应用中，有电话接入时可能会取消正在运行的广告。

注意:取消广告可能会对应用能接受的广告类型以及能获取的收益有不好的影响。

3.16 无线打印 (AirPrint)

用户可以通过AirPrint无线打印应用中的内容，还可以使用打印中心应用检查打印任务。

你可以利用内置的支持程序来打印图片和PDF文件，或者可以使用特定的打印程序接口来完成自定义的格式设置和渲染设置。iOS可以处理打印机的发现、任务排序以及在指定打印机上执行打印任务。

通常来讲，用户想要打印文件的时候，只需要点击应用中的标准动作按钮(Action button)。当他们在界面视图中选择了要打印的项目后，可以接着选择打印机，设置打印属性，最后点击打印按钮开始打印。

打印中心应用是一个只有在处理打印任务时才可见的后台系统应用，用户可以用它来查看打印任务。用户可以在打印中心浏览当前打印队列，查看某个打印任务的详情，还可以取消某个任务。

只需添加少量代码就可以支持基本打印功能 (想要了解在代码中添加打印功能，请查看Drawing and Printing Guide for iOS).想要确保好的打印体验，可以遵循以下几点规范：

使用系统提供的动作按钮。用户对系统提供的按钮的含义和行为都很熟悉，所以尽可能的使用系统动作按钮。如果你的应用没有工具栏或导航栏，那就要另当别论了。在这种情况下，你就需要自己设计一个可以出现在应用主界面的打印按钮，因为动作按钮只能在工具栏和导航栏中使用。

在当前情境下打印操作是基本功能时才显示打印项(Print item).如果当前情境并不适合打印，或者用户并不想打印，就不要在由动作按钮显示的视图中将打印项显示出来。

合适的话，给用户提供更多打印选项。例如，让用户设置打印页码范围或打印份数。

如果用户不能打印，则不要显示特定的打印用户界面。在向用户展示有打印项的界面前，确保用户的设备是支持打印的。想要了解如何在代码中实现，请查看UIPrintInteractionController Class Reference.

3.17 访问用户数据(Accessing User Data)

位置服务允许应用获取用户当前大致的地理位置，设备指向的方向以及用户移动的方向。其他系统服务，例如通讯录、日历、备忘录和相册等，同样也允许应用访问用户存储在里面的数据。

虽然获取了用户数据的应用能带来一定的方便，但还是需要为用户提供维持信息私密性的功能。例如，用户喜欢应用自动给内容加上位置标签，或者可以找到附近的好友，但用户也需要能在不想分享位置的时候关闭这些功能。(想要学习如何给应用增加获取位置功能，请参阅Location and Maps Programming Guide.)

以下几点可以帮助您以用户不反感的方式获取用户数据。

确保使用户理解分享私人数据的原因。如果没有明显的需要，用户自然会对私人信息的请求感到怀疑。为了避免用户反感，确保在用户使用明显需要个人信息的功能时再进行提醒。例如，即使没有打开位置服务用户也可以使用地图，但是在用户使用定位或导航功能时就会有提醒。

应用需要个人信息的原因不明显时向用户做出解释。你可以在提醒框中给出文字性的描述，例如“这个应用需要访问你的通讯录”或者“是否允许应用获取你的地理位置？”。这些文案最好明确且有礼貌以让用户无压力的理解为什么需要访问他们的信息。

讲述原因的文案应该遵循以下原则：

• 不要包含你的应用名称，因为系统提供的提醒框已经包含了。
• 清楚地描述你的应用为什么需要这些数据。如果可以的话，你也可以解释不会用这些数据做什么。
• 使用以用户为中心的术语并且进行本地化。
• 在易于理解的情况下越短越好。尽可能避免超过一句话。
• 使用句式大小写(sentence-style capitalization).(句式大小写指的是第一个单词大写，除了专有名词和专有形容词以外的词都小写。)

只有当你的应用没有用户数据就无法提供基础服务时，才在一开始就征求用户的许可。如果你的应用在知道了用户私人信息后才能提供主要功能是显而易见的话，用户不会因此觉得烦扰。

避免在用户选择需要数据的功能之前调用触发提醒框的程序。这样，就可以避免用户疑惑为什么在使用不需要私人数据的功能时有请求提醒。(注意，检查用户位置服务的设置并不会触发提醒。)

检查位置服务的设置来避免触发没必要的提醒。你可以使用核心位置的程序接口来实现(想要学习如何做，请参阅Core Location Framework Reference).使用这些知识，可以尽可能地在使用需要位置信息的功能时才进行提醒，或者完全避免提醒。

3.18 快速查看(Quick Look)

通过使用Quick Look，用户可以在你的应用内预览文件，即使你的应用是打不开这个文件的。举例来说，你可以允许用户预览一些从网站上下载或从其他来源获得的文件。

想要学习如何在应用中加入Quick Look文件预览功能，请参阅Document Interaction Programming Topics for iOS.

在你的应用内预览文件之前，用户可在你定制的视图中查看该文件的信息。例如，用户从一封邮件中下载了附件之后，邮件应用(Mail)会在邮件中使用定制的视图展示文件的图标、标题和大小。用户可以通过点击它来预览文件。

你可以在应用中用一个新的视图来展示文件预览，或者使用全屏模态视图。展示的形式取决于你的应用运行在什么设备上。

在iPad上使用模态视图来显示文件预览。iPad的大屏幕适合在一个方便用户离开的沉浸式环境中展示文件预览。缩放操作(zoom transition)很适合展示预览。

在iPhone上使用专用的视图，最好是导航视图来显示文件预览。这样可以使用户在应用情境中通过导航进入文件预览，不至于迷失。虽然也可以在iPhone应用中使用模态显示，但不推荐这样做。(注意缩放操作在iPhone上并不适用。)

另外要注意的是，在导航视图中显示文件预览意味着允许Quick Look在导航栏上放置特定的预览控件。(如果你的视图中包含工具栏，Quick Look会将预览控件放在工具栏上。)

3.19 声音(Sound)

无论声音在你的应用中是主要体验的一环，还是锦上添花的元素，你都需要知道用户对声音表现的期望以及与如何满足这些期望。

3.19.1 理解用户期望(Understand User Expectations)

人们可以使用设备控件来调整声音，他们还可能使用有线或无线的耳机和听筒。人们也会对于他们的行为如何作用于他们听到的声音有各种各样的期望。虽然你可能会发现有一些期望很让人意外，但它们都会遵循用户控制的原则，即应是用户而非设备掌控听到声音的时机。

用户会依据需要将设备静音：

• 避免被突兀的音效打断，比如手机铃声和信息接收音等
• 避免听到用户操作所产生的副产品的声音，比如键盘或其他反馈音、偶然的声音或应用启动的声音
• 避免听到那些在玩游戏时非必要出现的声音，如音效和配乐

例如，在剧院中，用户将他们的设备调至静音以避免打扰剧院中的其他人。在这一情境下，用户仍然希望能在他们的设备上使用应用，但他们不希望被无预期或突兀的声音所打断，如手机铃声或新消息音。

当用户操作的明确目的就是听到声音时，铃音/静音开关(或静音开关)不会屏蔽这些操作所产生的声音。例如：

• 在仅有媒体播放功能的应用中的进行媒体播放是不会被静音的，因为播放媒体是用户明确期望的。
• 闹钟不能被静音，因为闹钟是用户明确设定使用的。
• 语言学习应用中的音效素材不能被静音，因为用户进行了明确的操作希望听到它。
• 音频对话应用中的对话不被静音，因为用户打开这个应用的唯一目的就是进行音频对话。

用户使用设备音量调节按键可调节他们的设备所能发出的所有声音的音量，包括歌曲、应用音效和设备声音。不管铃声/静音(或静音)的开关在什么位置，用户都能使用音量调节按键屏蔽所有声音，使用音量调节按键调节应用当前所播放的音频时同样调整了全局系统的音量，铃声音量除外。

对于iPhone：当没有音频播放时使用音量键可以调整铃声音量。

用户使用耳机的目的在于能够私密地收听声音以及解放他们的双手。不管这些配件是有线的还是无线的，用户对这个体验都有特定的期待。

当用户插入耳机或连接无线音频设备时，他们期望能以私密的状态继续收听当前播放的音频。因此，他们希望应用能够不中断地继续播放当前正在播放的音频。

当用户拔出耳机或断开与无线设备的连接时(抑或设备超出范围或关闭时)，他们不希望他们刚刚收听的内容被自动地与他人分享。因此，他们希望正在播放音频的应用暂停播放，让他们能够在自己想要继续播放的时候再开启。

3.19.2 定义应用的音频行为(Define the Audio Behavior of Your App)

如果必要的话，你可以通过调整相关的、独立的音量水平以在你的应用中制造最好的混音输出效果。但最终音效输出的音量也应该能由系统音量控制，可以通过音量键或音量滑块进行调节。这意味着应用的音频输出的控制权仍然归属在用户手中。

确保你的应用能适时地显示音频路径选择。(音频路径(audio route)是指音频信号的电子通路，例如从设备到耳机或是从设备到扬声器。)即使人们没有物理性的插入或拔出音频设备，他们也仍希望能选择其他不同的音频路径。为了实现这一诉求，iOS能自动显示可让用户选择输出音频路径的控件(使用MPVolumeView类能允许这个控件显示在你的应用中)。由于选择不同的音频路径是用户主动的行为，用户期望当前播放的音频能继续不中断。

如果你需要显示音量滑块，在使用MPVolumeView类时，确保使用的是系统提供的可用的音量滑块。注意，当正在使用的音频输出设备不支持音量控制时，音量滑块会被合适的设备名称所替代。

如果你的应用只产生一些与其功能无必要关系的界面音效时，(尽量)使用系统音效服务(System Sound Services)。系统音效服务是一种能产生警示音、界面音效和发出振动的iOS技术；它不适合任何其他用途。当你使用系统音效服务(System Sound Services)来产生音效时，你不能干涉你的音频与设备的音频的交互方式，也不能干涉它处理干扰和设备配置变化的方式。想了解如何使用这一技术，请参阅Audio UI Sounds (SysSound)中的范例项目。

如果音效在你的应用中扮演重要的角色，使用音频会话服务(Audio Session Services)或是AVAudioSession类。这些程序接口不产生音效；相反，它们会帮助你了解你的音频应该如何与设备的音频进行交互以及如何响应设备配置的干扰与变化。

对于iPhone：无论你使用什么样的技术来制作音频，无论你如何定义来它的行为，电话总是可以中断当前运行的应用。这是因为任何应用都不应该阻止人们接收来电。

在音频会话服务(Audio Session Service)中，音频会话(audio session)执行了你的应用与系统之间音频中介的功能。音频会话中最重要的方面之一就是类目(category)，它定义了你的应用的音频行为。

为了实现音频会话服务带来的好处并提供用户期望的音频体验，你需要选择可以完美描述应用音频行为的类目(category)。具体情况取决于你的应用只在前台播放音频还是也要在后台播放音频。在你做这一选择的时候，遵循以下这些原则：

• 依据其语义而非精确的行为来选择音频会话类目。通过选择目的清晰的类目，你可以确保你的应用能表现得符合用户期望。除此之外，当以后行为的精确集合被重新定义时，它可以为你的应用提供最佳的机会使其合理运行。
• 在极少数情况下，可以添加属性到音频会话中以修正一个类别的标准行为。一个类别的标准行为代表多数用户的期望，因此在你改变那个行为之前你应该仔细地考虑。例如，你可以添加闪避(ducking)属性以确保你的音频声音能比其他所有的音频都大(除了电话音频)，如果这就是用户所期望的。(欲了解更多关于音频会话属性的内容， 请参见的Fine-Tuning the Category。)
• 依据设备当前的音频环境来考虑你的类目选择。这应该是合理的，举个例子，用户可以在使用你的应用的同时听其他音频而非你的配乐。如果要这样做，须确保避免当你的应用启动时，迫使用户停止收听当前的内容或要需要额外地在两者之间做出选择。
• 通常情况下，避免在你的应用运行时改变类目。改变类目的首要依据是你的应用是否需要在不同的时机支持录音和播放。在这种情况下，更好的选择是依据需要在录音类目与播放类目之间转换，而非同时选择播放和录音类目。这是因为选择录音类目可以确保正在录音时不会听到提示音，比如收到信息的提示音。

表35-1列举了你可以使用的音频会话类目。不同的类目可以允许通过铃声/静音开关或静音开关(或设备锁)来实现静音、与其他的音频混合或者控制应用在后台播放。(欲了解编程界面上所呈现的类目和属性的准确名称，请参见Audio Session Programming Guide.)

表35-1 音频会话类目及其相关行为

类目	意义	静音	混合	后台播放
个人环境	声音增强了应用的功能且应该静音其他音频	支持	不支持	不支持
环境	声音增强了应用的功能但不应该静音其他音频。	支持	支持	不支持
播放	声音对应用来说很重要且可以与其他音频混合。	不支持	不支持(默认)支持(当“与其他音频混合”属性被添加时)	支持
录音	音频是用户记录的。	不支持	不支持	支持
播放和录音	声音代表音频输入与输出，按顺序地或同时地。	不支持	不支持(默认)支持(当“与其他音频混合”属性被添加时)	支持
音频处理	应用执行硬件辅助音频编码(不播放或录音)。	不适用	不支持	支持*

*如果你选择音频处理类目并且你希望在后台运行音频进程，你需要在完成音频处理之前防止你的应用被暂停。欲了解如何实现这一功能，参见《iOS应用编程指南》中的执行长时间运行的后台任务。

以下是一些示例情境，其中指示了如何选择音频会话类目以提供用户喜欢的音频体验。

情境1：一个帮助人们学习新语言的教育类应用。你需要提供：

• 用户点击特定控件时播放反馈音效
• 当用户想听到正确发音的示例时播放字词的录音

在这个应用中，声音对于主要功能是十分重要的。人们使用这个应用来听他们正学习的语言的词语与短语，因此即使当设备锁定或者被调至静音时也要能播放声音。因为用户需要清晰地听到声音，他们会期望其他他们可能播放的音频都被静音。

为了满足用户对于该应用所期望的音频体验，你应该使用播放(Playback )类目。虽然这一类目可以被定义为与其他音频混合，但该应用应该使用默认的行为以确保其他的音频不会干扰那些用户明确选择听到的教育性内容。

场景2：网络协议电话(VoIP)应用。你需要提供：

• 接收音频输入的能力
• 播放音频的能力

在该应用中，声音对于主要功能是十分重要的。人们经常会在使用另一个应用时使用该应用与他人进行交流。用户期望能在他们将设备调至静音或设备被锁定时接听电话，他们希望在来电期间其他音频被静音。他们也希望应用在后台运行时也能继续打电话。

为了满足用户对于该应用所期望的音频体验，你应该使用播放和录音(Play and Record)类目，并且你要确保只有在你需要时才会激活你的音频会话，以便用户可以在打电话过程中使用其他音频。

场景3：允许用户在不同任务中操作角色的游戏。你需要提供：

• 不同的游戏运行音效
• 配乐

在该应用中，声音会在很大程度上提升用户体验，但对于主任务并没有那么重要。而且，用户可能会希望能在玩游戏时静音或听他们乐单中的歌曲而不听游戏配乐。

最好的策略是在你的应用启动时确定用户是否在收听其他音频。不要要求用户选择他们是要收听其他音频或是你的音效。而应该使用音频会话功能中的AudioSessionGetProperty来请求kAudioSessionProperty_OtherAudioIsPlaying属性的状态。依据所请求的答案，你可以选择环境(Ambient)或是个人环境(Solo Ambient)类目(这两种类目都允许用户静音玩游戏)：

• 如果用户正在听其他音频，你应该假设他们想要继续听并且不想被强迫收听游戏音效。在这种情境下，你最好选择环境(Ambient)类目。
• 如果用户在你的应用启动时没有在收听其他音效，你最好选择个人环境(SoloAmbient)类目。

情境4：一个为用户到达目的地提供准确、实时导航指示的应用。你需要提供：

• 路途中每一步的语音指示
• 一些反馈音效
• 支持用户继续收听他们自己的音频的能力

在该应用中，无论应用是否是在后台运行，语音导航指示都表现为主要任务。基于这一原因，你最好使用播放(Playback)类目，它允许你的音频在设备被锁定、静音或是在后台运行时仍可以播放。

你可以通过添加kAudioSessionProperty_OverrideCategoryMixWithOthers属性来实现允许人们在使用你的应用时收听其他音频。但是你也想要确保用户在他们正在播放其他音频时能听到语音提示。你可以为音频会话添加kAudioSessionProperty_OtherMixableAudioShouldDuck属性来确保你的音频比其他音频的声音更大( iPhone上的电话音频除外)。这些设置允许应用在后台运行时也可以恢复音频会话，可以确保用户能获得实时更新的导航。

情境5：一个允许用户上传文本和图片到网站上的博客应用。你需要提供：

• 简短的启动音效文件
• 伴随用户行为产生的各式各样的短音效(例如当邮件被上传后播放的音效)
• 发送失败时播放的提示音

在该应用中，声音提升了用户体验，但也不是必需的。主任务与音频并没有关系，用户也不是必须要通过收听声音才能成功使用应用。在这一情境中，你最好使用系统声音服务来产生声音。这是因为这个应用中所有声音的音频情境都符合本技术想要达到的目的，也就是说应制作符合用户所期待的、能通过设备和铃声/静音(或静音)开关来调节的界面音效和提示音。

3.19.3 管理音频中断(Manage Audio Interruptions)

有时候，当前播放的音频会被来自于不同应用的音频所打断。举个例子，在iPhone上，来电会持续中断当前应用的音频。在多任务情境中，这种音频中断的频率可能会很高。

为了提供用户喜欢的音频体验，iOS系统依赖于你能做到下面几点：

• 识别可能会引起应用中断的音频类型
• 当应用在音频中断结束后继续运行时进行合理地反馈

每个应用需要识别会引起音频中断的类型，但不是每个应用都需要决定如何在音频中断结束后进行反馈。这是因为多数类型的应用应在音频中断结束后恢复音频。只有那些主要或部分由媒体播放组成(以及提供媒体播放控制)的应用，才必须用额外的步骤来决定什么是合适的反馈。

从概念上讲，基于中断当前音频的音频类型以及中断结束后用户所期望的特定的应用反馈方式，有两种类型的音频中断：

• 可恢复性中断是(resumable interruption)被用户视为临时穿插在他们的主要聆听体验中的音频引起的。

在可恢复性中断结束后，有媒体播放控件的应用应该恢复它被中断前的任务，无论是继续播放音频还是保持暂停。没有媒体播放控件的应用则应该恢复播放音频。

举个例子，试想用户在iPhone上使用应用播放音乐时，在播一首歌的中间来了一个网络电话。用户接起了电话，期望在他们通话时播放的应用能静音。在通话结束后，用户希望播放的应用自动恢复播放歌曲，因为音乐而非电话才是他们的主要聆听体验，而他们在电话接入前也没有暂停音乐。另一方面，如果用户在电话接入前暂停了音乐播放，他们会希望电话结束后音乐仍保持暂停。

其他能引起可恢复性中断的应用的例子还有那些具备闹钟、音频提示(例如语音方向指示)或其他间歇性音频功能的应用。

• 不可恢复中断(nonresumable interruption)是由那些被用户视为首要听觉体验的音频所引起的，比如媒体播放产生的音频。在不可恢复中断结束后，显示媒体播放控件的应用不应该恢复播放原来的音频。而没有媒体播放控件的应用应该恢复播放音频。例如，假设用户正在收听一个音乐播放应用(音乐应用1)，此时另一个音乐播放应用(音乐应用2)打断了它。用户终止后决定收听音乐应用2一段时间。在退出音乐应用2之后，用户不想要音乐应用1自动恢复播放，因为此时他们主动将音乐应用2作为首要的听觉体验。

下面的指南可以帮助你决定当一个音频中断后如何继续以及提供什么信息:

确定由你的应用引起的音频中断的类型。在你的音频结束时，你可以通过以下任意一种方式去禁用你的音频会话来做到这一点：

• 如果你的应用引起了一个可恢复性中断，使用AVAudioSessionSetActiveFlags_NotifyOthersOnDeactivation标识禁用你的音频会话。
• 如果你的应用引起了一个不可恢复中断，不用任何标识就可以禁用你的音频会话。

无论提供与否，标识会在适宜的情况下允许iOS系统赋予被中断的应用自动恢复播放它们的音频的能力。

决定是否应该在一个音频中断结束后恢复音频。你应依据你应用中所提供的音频体验来做这一决断。

• 如果你的应用给用户呈现了用于播放或暂停音频的媒体播放控件，你需要在一个音频中断结束后检查AVAudioSessionInterruptionFlags_ShouldResume标识，如果你的应用接受应该恢复(Should Resume)标识，你的应用应该：
• 恢复播放音频(你的应用被打断时在主动播放音频)
  ·不恢复播放音频(你的应用被打断时没有在主动播放音频)
• 如果你的应用没有呈现任何用户可用于播放或暂停音频的媒体播放控件，你的应用无论是否有“应该恢复”标识，都始终应在音频中断结束后恢复之前播放的音频。例如，播放配乐的游戏应该在被中断后自动恢复播放配乐。

3.19.4 适时处理媒体远程控制事件(Handle Media Remote Control Events, if Appropriate)

当人们使用iOS媒体控制器或辅助控制器(如耳机线控)时，应用要能响应远程控制。使你的应用能接收来自于你的用户界面之外的输入，无论你的应用当前是在前台还是后台播放音频。

应用可以在播放媒体的过程中，通过后台向支持Airplay的硬件(如Apple TV)发送视频。这样的应用可以接收通过远程控制事件实现的用户输入行为，因此用户可以控制处于后台运行状态的应用中的视频播放。除此之外，这类应用在后台运行时也能恢复被中断的音频。

当一个媒体播放应用在后台播放音频或视频时，尤其需要合理响应媒体远程控制事件。

当你的应用在后台运行时，为了满足与播放媒体特权相关的责任，要确保遵循以下这些原则：

限制你的应用接收远程控制事件的次数。例如，当你的应用可以帮助用户阅读内容、搜索信息或是收听音频时，它只有在用户处于音频场景中时才应该接收远程控制事件。当用户脱离音频情境时，你应该放弃接收事件的能力。如果你的应用允许用户在支持AirPlay的设备上播放音视频，它应该在媒体播放期间都可以接收远程控制事件。遵循这些原则能使用户在你的应用中处于非媒体情境中时，通过耳机控制获得另一个应用的媒体体验。

尽可能地使用系统原生的控件以提供AirPlay支持。当你使用MPMoviePlayerController类实现AirPlay播放功能时，你可以利用标准的控件使用户可以选择当前范围内支持AirPlay的硬件。或者你可以使用MPVolumeView类来显示用户可选择的支持AirPlay的音频或视频设备。用户习惯于这些标准控件的外观和行为，因此他们可以理解如何在你的应用中使用它们。

不要改变事件的用途，即使这个事件在你的应用中没有意义。用户期望iOS系统的所有应用媒体控制和辅助控制能有功能上的统一。你不必实现你的应用所不需要的那些事件，但你所实现的事件必须产生符合用户期望的结果。如果你重新定义一个事件的意义，你会使用户困惑并冒险把他们带入一个未知的状态，他们只能通过退出你的应用来逃离。

3.20 VoiceOver

VoiceOver增加了对盲人、弱视用户以及一些有特定学习困难的用户的可用性。

为了确保VocieOver的用户能使用你的应用，你需要在你的用户界面中提供一些有关视图和控件的描述信息。对VoiceOver的支持不需要你改变你用户界面内的任何视觉设计。

当你完全遵照标准的方式使用标准的用户界面元素时，几乎不(即使有也很少)需要增加额外的工作。你的用户界面越趋向定制化，你就越需要提供更多的信息来保证VoiceOver能准确的描述你的应用。

增加你的iOS应用对VoiceOver用户的可用性，可以扩大你的用户基础并帮助你进入新的市场。支持VoiceOver也可以帮助你遵守由主流群体所制定的可用性指导准则。

3.21 路线选择(Routing)

地图可以显示到达用户目的地的可选路线：

当人们想要获得关于某条路线的更多交通信息时，地图也可以显示能提供路线选择的应用列表(包括安装在设备上的应用也包括应用商店中的应用)。

路线选择应用可以提供当前选择的路线有关的信息。人们希望路线选择应用能够快捷、易用，特别是保证准确性。依据本章提供的指导原则能帮你为用户提供他们可信任的交通信息和他们期望的用户体验。

重要：地图能依据人们选择的路线给他们提供驾车和步行的指示。路线选择应用可以提供交通信息，它着重于使用交通工具(如公交车、火车、地铁、渡船、自行车、行人、穿梭巴士等)的模型替代实物逐步地指示方向。

如果你的应用不能提供用户指定的路线的交通信息，那么不要将你的应用定位为路线选择应用。

实现你的应用所承诺的功能。当人们在交通列表里看到你的应用时，他们认为它可以帮助其到达目的地。但是如果你的应用不能提供所选路线的信息，或者它没能涵盖它看似应该涵盖的那些种类的交通信息，人们就不会愿意给它第二次机会。准确的表达出你的应用的能力是十分重要的；否则，你的应用会看起来像是在故意误导用户。

在你的路线选择应用中，有两种主要的方式可以给用户信心：

• 尽可能准确的定义你所支持的地理区域。例如，如果你的应用能帮助人们获得巴黎的公交线路的信息，那你所支持的地区应该是巴黎，不是法兰西岛，也不是法国。
• 明确你所支持的交通信息类型。举个例子，如果你专攻于地铁信息，不要暗示你仿佛支持所有的轨道交通类型

注意：虽然准确的报告你所支持的地区可能意味着会减少你的应用在交通信息列表里的出现次数，但这么做却可以帮助用户更加信任它。

为易用性合理组织界面。易用性对于路线规划应用来说特别重要，因为用户常常会在极具挑战性的情况下使用它们——例如在明亮的阳光下、在昏暗的车厢内抑或是在颠簸的旅程中，或在非常紧急的情况下。要确保你的文字在任何光照条件下都能容易的阅读，确保按钮即使在并不平稳的旅程中也能易于准确点击。

专注于路线。虽然辅助信息会很有用，但你的应用应该专注于为用户提供逐步的指示以便他们能据此到达目的地。特别要强调的是，你要让用户知道他们处于哪一步，并知道如何到达下一步。你可以提供额外的数据(比如时间表或系统地图)，但不要让这些数据比交通信息还重要。

为路线的每一步提供信息。永远不要让用户感觉被你的应用所遗弃。即使在可以准确的报道你所支持的地区时，你也不能假定用户已经抵达的路线中的第一个交通节点或是最后一个交通节点就是他们目的地点。为了控制这一情况，首先就是测量起点到终点距离。如果距离足够短，要提供从用户当前位置到第一个交通节点及从最后一个交通节点到用户目的地的步行方向指示。如果步行不是一个合理的选择，尝试描绘用户的其他选项。如果必要的话，你可以给用户提供打开地图，获取这部分路线的步行或驾车方向指示的方式。

当用户从地图应用切回你的应用时，不要要求他们重复输入信息。如果用户从地图应用切入(你的应用)时，你已经获知了他们中意的起点与终点，因此你可以在应用打开时直接呈现适合的交通信息。如果用户从主屏幕中开启你的应用，要为他们提供简洁的方式用以输入路线详情。

显示图文并茂的交通信息。地图页面可以帮助人们以更大的、实物性的视角查阅他们完整的线路；清晰的步骤可以帮助人们专注于他们抵达目的地所需采取的必要行动。最好可以同时支持这两个任务并能让用户便捷地进行切换。

注意：无论以什么格式，最重要的是显示与用户线路相关的相同的交通信息。例如，如果路线中包含五个步骤，在地图和路线列表页中必须描绘相同的五步。

当你的应用被从交通列表中选中时，需要以显示完整的线路做为良好的开始(包括在地图页面中显示始于或抵达交通节点的步行路线)。地图页面可以为用户提供他们旅途的多步骤的总览，并能展示适于周遭地理环境的路线。

用附加信息丰富地图页面。人们期望你的应用中的地图可以表现的与他们使用过的其他地图相似。除了用户能放大和缩小以外，你还应该显示用户所需的那些注释信息。例如，你应该显示图钉用以代表用户当前的位置、目的地以及沿路的转乘点或重要的节点。

确保避免只显示一个单独的图钉，因为对用户来说，如果没有额外的背景，很难理解它代表什么。欲了解在你的应用中使用地图页面的更多信息，请参阅Map View.

尽可能地整合静态地图页面，例如在地图视图中加入地铁系统地图等。一个很好的实现方法就是在地图页面覆盖静态图片，以便用户可以看到他们的路线及他们的当前位置是如何与更大的交通系统相关联的。

注意：如果你决定让应用显示一个静态的地图图片，要确保使用高分辨率的图片以保证用户在缩放时维持高质量的显示。

给用户提供不同的方案来挑选多样的交通选择。很多因素会影响人们交通的选择，例如不同的时间段，天气以及他们携带东西的多少，所以提供简洁的不同交通方式的对比是十分重要的。例如，你要能让用户可以依据开始或结束的时间、需要步行的数量、沿途停下的次数抑或转乘的次数或所需的不同的交通类型等来挑选交通方式。不管你显示多种交通选择的顺序如何，确保用户能立即分辨出这些选项的不同之处。

考虑使用推送通知为人们提供与路线相关的重要信息。尽可能的让人们了解交通情况信息的变化，以便他们可以据此调节自己的计划。例如，如果火车晚点或者巴士路线临时停滞，人们可能会需要选择不同的交通路线到达目的地。而在一条不同步骤的站点之间相隔很长距离的交通路线中，人们会希望在他们的交通工具将要抵达行程中的下一部分时能获得通知。

3.22 编辑菜单(Edit Menu)

用户能呼出一个编辑菜单来完成诸如在文本视图、网页或图片视图中的剪切、粘贴以及选择操作。

你可以通过调整一些菜单的行为使用户对你应用中的内容有更多的控制权。举个例子，你可以：

• 列举出适用于当前情境的标准菜单的命令
• 在菜单显示前判定菜单的位置，以避免你应用的用户界面中的重要信息被遮盖
• 定义当用户双击展开菜单时会被默认选中的对象

你不能改变菜单本身的颜色和形状。

欲了解如何在代码中实现这些行为的相关信息，请参阅Copy, Cut, and Paste Operations.

为了确保编辑菜单在你的应用中的表现符合用户期望，你应该：

显示在当前情境下合理的命令。例如，当没有对象被选择的时候，菜单中不应该包括复制或剪切(命令)，因为这些命令是针对选择(的内容)而操作的。相似地，如果有对象被选择的时候，菜单中不应该包括选择(命令)。如果你在自定义页面中支持编辑菜单，你就有责任确保菜单中显示的命令切合当前的情境。

依据你的页面布局调节菜单显示。iOS依据可获得的空间大小选择在插入点的上方或下方来放置菜单指针以显示编辑菜单，这样用户就能看到菜单命令是如何与内容相关的。在必要的情况下，你可以通过程序在菜单显示之前决定它的位置，这样可以避免用户界面中的重要信息被遮挡。

支持两种手势来调用菜单。虽然点击和长按手势是用户呼起编辑菜单的首选方式，但他们也可以在文本页面中通过双击一个单词来选择该单词并同时呼起菜单。如果你在自定义页面中支持菜单，确保它能支持两种手势。除此之外，你可以定义用户双击时默认的选择对象。

避免在你的用户界面中创建和编辑菜单中功能相同的按钮。例如，使用编辑菜单让用户进行复制操作远比提供一个复制按钮要好，因为用户将会想知道为什么在你的应用中会有两种方法做同样的事。

如果静态文本的选择对用户来说是有用的，那么可以考虑使用它。用户可能想要复制图片的标题，但他们不可能想复制选项卡的标签或是屏幕的标题，比如“账户(Account)”。在文本页面内，文字的选择应该是默认设置的。

不要使按钮标题可选择。如果按钮的标题是可选择的，用户很难在不激活按钮的情况下呼出编辑菜单。通常来说，像按钮这样操作的元素不需要是可选择的。

将对撤销与重做的支持与对复制与粘贴的支持组合到一起。人们经常希望在他们改变主意的时候能撤销最近的操作。由于编辑菜单在它操作执行的时候是不需要确认的，你应该给用户提供撤销或重做这些操作的机会。

如果你需要创建自定义的编辑菜单项，需要像下面展示的这个例子一样遵循这些指导原则：

创建直接作用于用户选择的包含编辑、修改或其他操作的编辑菜单。人们期望在当前的情境内用标准的编辑菜单项操作文本或对象，那么你的自定义菜单项最好能有相似的表现。

将自定义项列在所有系统提供的项的后面。不要将你的自定义项与系统提供的项混置在一起。

保持自定义菜单项的数量在合理的范围内。你不应该用太多选择迷惑你的用户。

使用简洁的名称命名你的自定义菜单项并确保名称能准确的描述命令的作用。通常，项的名字应该是一个可以描述行为如何执行的动词。虽然你通常会使用单个的大写单词作为名字，但如果你必须使用一个短语(作为名字)时，就应使用标题式大写短语。(简洁的、标题性的大写词就是将除了文章、四字及四字以下的并列连词与介词之外的单词都大写。)

3.23 撤销与重做(Undo and Redo)

用户通过摇晃设备触发撤销操作，显示提醒框让他们可以：

• 撤销他们刚才输入的内容
• 重做先前撤销的输入
• 取消撤销操作

你可以通过在你的应用中定义出更通用的方式来支持撤销操作：

• 允许用户撤销或重做的行为
• 在你的应用的哪种情形下晃动手势是用于撤销操作的
• 支持多少步的撤销

欲了解如何用代码实现这一行为，请参阅Undo Architecture.如果在你的应用中支持撤销和重做，请遵循以下准则以提供好的用户体验:

为用户提供简洁的描述性短语使其能准确的获知他们正在撤销或重做的内容。iOS系统自动提供了“撤销”和“重做”的字符串(包括词语后面的空格)作为撤销警示按钮的标题，但你需要提供一或两个词语用于辅助描述用户的重做或撤销操作。例如，你可能提供文本的“命名”或“地址更改”之类的词语用以创建像“撤销命名”或“重新更改地址”这样的按钮标题。(要注意，在提醒框中，“取消”按钮是不能改变或移除的)。

避免提供的文本过长。太长的按钮标题容易被断章取义并且很难被用户解读。由于这个文本用于按钮的标题中的，要使用标题样式的大写形式并且不能添加标点。

避免过度使用摇晃手势。即使你能程式化地设定你的应用将摇晃事件作为用户激活撤销操作的途径，你也在冒着混淆用户视听的风险，因为他们也可能使用摇晃执行另一个不同的操作。分析你应用中的人机交互以避免创建那些用户无法可靠地预测摇晃手势结果的场景。

如果撤销和重做在你的应用中是基础性的任务，尽量使用系统原生的撤销与重做按钮。记住摇晃手势是用户触发撤销与重做操作的主要方式，而如果提供两种不同方式完成同样的任务则会使用户困惑。如果你认为很有必要提供直观专有的撤销与重做操作，你可以在导航栏中放置系统原生的按钮。(欲了解更多关于这些按钮的信息，参见Toolbar and Navigation Bar Buttons).

将撤销与重做能力与用户当下的情境进行清晰地关联，而非过早地介入情境。仔细考虑你允许进行撤销与重做操作的情境。通常来说，用户期望他们的改变和操作可以立即被有效的执行。

3.24 键盘和输入页面(Keyboards and Input Views)

在iOS8与之后的系统中，你可以创建自定义的键盘扩展内容来替代系统的原生键盘。欲了解更多关于管理应用内扩展(包括键盘)的信息，请参阅APP Extensions；欲了解如何开发自定义的键盘扩展内容的信息，请参阅Custom Keyboard.

在合适的情况下，你9也可以在你的应用内设计自定义的输入页面来替代系统原生的屏幕键盘。例如，Numbers(译者注：iWork中的电子表单应用程序)中提供了多种输入页面，这些页面设计使数量、日期和其他值的输入能简单高效地完成。

如果你提供自定义输入页面，确保它的功能对于来用户来说是清晰易懂的。

你也可以提供自定义的输入辅助视图，这种视图通常表现为显示在键盘(或你的自定义输入页面)上方的一个独立元素。例如，在某些情境中，Numbers会显示一个输入辅助视图用以帮助用户执行针对电子表格中的值的标准或自定义计算。

当用户在你的输入页面中敲击自定义控件时，使用标准的键盘敲击声提供声音反馈。欲了解在代码中如何使用这一声音，请参阅UIDevice Class Reference中的playInputClick章节

注意：标准的敲击音效只适用于当前屏幕上的自定义输入页面。人们可以在设置-声音中关闭所有的键盘音效(包括你的自定义输入页面中的那些)。

本章英文原文访问地址：iOS Human Interface Guidelines1

本章中文翻译PDF1下载：点击下载

本章英文原文访问地址：iOS Human Interface Guidelines2
本章中文翻译PDF2下载：点此下载

点击下方的分页按钮查看第四章：