处理常见任务

如果您具有使用桌面计算机或便携式计算机应用程序的经验，那么您会发现iPhone应用程序处理很多常见任务的方式与它们不同。本节从人机界面的角度描述了这些常见任务；关于代码实现的技术细节，请参考iPhone应用程序编程指南。

启动

iPhone应用程序应能够迅速启动，从而用户可以立即开始使用它们。启动时，iPhone应用程序应该：

• 指定适当的状态栏样式（关于可用样式的信息请参考“状态栏”一节）。

• 显示一幅酷似应用程序初始屏幕的启动图像。这减少了用户感知到的应用程序的启动时间。要了解更多有关的信息，请参考“启动图像”。

• 避免显示“关于”窗口，启动画面，也不要提供任何其他类型的妨碍用户立即使用应用程序的体验。

• 默认情况下，在屏幕上纵向启动应用程序。如果您打算让应用程序只能在屏幕横向时使用，则无论设备当前的方向如何，都在屏幕上横向启动应用程序。如果必要的话，要允许用户将设备旋转为横向。

  仅横向显示的应用程序应该支持两种“横向”—不论“主页”按钮在屏幕右侧还是左侧，都能够正常显示应用程序。如果设备本身已经被横向放置，则这种仅横向显示的应用程序就按照设备的方向启动。否则，在默认情况下，仅横向显示的应用程序在启动时，“主页”按钮只能在应用程序的右方。

• 将您的应用程序恢复到最后一次运行时的状态。

停止

当用户打开另一个应用程序或使用设备自身功能（比如电话）时，iPhone应用程序必需终止。要特别注意的是，应用程序的终止不需要用户点击应用程序关闭按钮或在菜单上选择“退出”操作。iPhone应用程序应该：

• 随时准备接收退出或终止通知。因此，要尽可能快并且在合理情况下经常保存用户数据。

• 当应用程序终止时，尽可能详细地保存它的当前状态。例如，如果您的应用程序能够显示滚动的数据，则应该保存当前的滚动位置。

iPhone应用程序不应该直接通过代码退出，因为这样做会使用户觉得应用程序崩溃了。但是，可能有些时候，外部环境会阻止您的应用程序正常运行。处理这种情况的最好方法是让屏幕显示醒目的内容，在屏幕上描述该问题并向用户提出解决问题的建议。这样做会在以下两方面对用户有所帮助：

• 它提供了反馈信息，告诉用户您的应用程序没有出现错误，使用户放心。

• 它能够控制用户行为，让他们决定是采取一些纠正的行动来继续使用您的应用程序，还是按下“主页”按钮来打开另一个应用程序。

如果在一些特定的环境中，您的应用程序只是部分功能无法正常工作，那么在用户想要激活该功能时，您可以在屏幕上显示信息或警告。虽然警告在设计上不具备太大的灵活性，但如果您可以保证以下几点，它也可以成为一种很好的选择：

• 非常简洁地描述当前情况

• 提供一个执行纠正动作的按钮

• 仅当用户试图访问无法正常工作的功能时显示警告

和所有的警告一样，用户越少看到它们，就说明它们越有效。关于创建警告的更多信息请参考“使用警告”。

管理设置或配置选项

iPhone应用程序可以向用户提供设置功能，使用户可以根据自己的喜好来设置应用程序行为或配置选项，从而改变应用程序的一些功能。可设置的应该是一些用户设置一次后很少（如果有的话）改变的信息，比如帐户名称。用户可以在内置的“设置”程序中查看特定应用程序的设置。配置选项是一些用户可能想要经常改变的值，比如在列表中显示的分类的类型；配置选项应该由应用程序本身提供。

您应该把设置和配置选项看作是互斥的。也就是说，您不应该在您的应用程序中同时提供设置和配置选项。

iPhone应用程序最好不要求用户指定任何设置。这样用户无需提供设置信息就可以立即使用这些应用程序。为了在您的应用程序中实现这一点，您可以采用以下这些设计决策：

• 使您的解决方案满足80%用户的需求。当您采用这样的设计时，大多数用户不需要提供设置信息，因为您的应用程序已经按照大部分用户所预期的行为进行了设置。可以不考虑那些只有少数用户需要的功能和大部分用户仅需使用一次的功能。

• 从其他途径获取尽可能多的信息。如果您可以用到任何用户在内置应用程序或设备设置中提供的信息，那么您可以向操作系统查询这些信息的值；不要让用户再次输入它们。

• 如果您必须向用户请求设置信息，请在应用程序内部提示用户输入信息。然后立即将这一信息存储在您的应用程序的设置中。这样，用户在开始使用您的应用程序之前，就不会被迫退出应用程序而先打开“设置”界面。如果用户稍后需要更改这些信息，他们可以随时在您的应用程序的设置中进行更改。

如果用户想要打开“设置”程序，就必须首先退出您的应用程序，而您应该不鼓励用户采取这样的行为。系统并没有提供支持这一行为的图标或控件，而且建议您也不要为此创建自定义的图标或控件。如果您决定一定要在您的iPhone应用程序中提供设置，请参考iPhone应用程序编程指南中的“设置程序包”一节，了解如何在您的代码中实现对这些功能的支持。

与设置不同，由于用户会选择从新资源或以不同布局来查看信息，因此配置选项很可能经常发生改变。对于这些选项所做的更改，您可以动态地作出响应，因为用户不需要离开您的应用程序来访问它们。

您可以在主用户界面或屏幕的背面提供配置选项。具体使用哪一种技术更合理取决于该选项代表的是不是主要功能以及用户对其进行更改的频率。

例如，“日历”程序允许用户以日，星期和月为单位查看他们的时间表。这些选项本来可以在屏幕的背面提供给用户，但是查看日历的不同部分是程序的主要功能，并且用户可能会频繁改变所关注的焦点。

再举一个例子，“天气”程序的主要功能是显示一个城市的当前天气状况和6天之内的天气预报。虽然让用户能够选择是以摄氏还是华氏为单位显示温度也很重要，但是用户不太可能经常改变这个选项，因此，将它放在主用户界面中并不合理。在“天气”屏幕的背面提供温标选项，就显得既方便又不突兀。

支持复制和粘贴

iPhone OS提供了编辑（或粘贴板）菜单，它支持在文本视图，Web视图和图像视图中的“剪切”，“复制”，“粘贴”，“选择”和“全选”操作。一种向用户显示该菜单的方法是，首先用户触摸并按住设备屏幕直到出现放大的视图（该视图允许用户将插入点或选择点移动到正确的位置），然后放开。如果当前的上下文支持这种菜单，则当用户抬起手指时它就会出现。菜单中的“选择”操作可以选择视图中的单词或应用程序定义的项。用户可以通过拖动当前所选区域的把手来扩大他们选择的内容。在内容被选中之后，菜单就会根据情况显示“剪切”，“复制”或“粘贴”。

您可以调整编辑菜单的某些行为以适应您的应用程序。（要了解更多关于如何用编码实现这些行为的信息，请参考iPhone应用程序编程指南中的“复制和粘贴操作”一节。）例如，您可以指定菜单中显示的操作，您可以改变菜单出现的位置。但是，您不能控制菜单本身的颜色和形状。

编辑菜单中可见的操作在当前上下文都是有意义的。例如，如果没有任何内容被选中，菜单中不会包含“复制”或“剪切”操作，因为这些操作要作用于被选中的内容。同样，如果有内容被选中，菜单则不包含“选择”操作。如果您要在一个自定义视图中支持编辑菜单，您应该确保菜单所显示的操作适用于当前上下文。请注意，您不能在菜单中显示自定义的操作。

UIKit会根据可用空间的大小，在插入点或被选中内容的上方或下方显示编辑菜单，并放置菜单指针，以便用户可以看到菜单操作是如何与当前内容相关联的。您可以通过编程的方式，在菜单出现之前决定它的位置，因此，在必要的情况下，您可以防止应用程序的用户界面中的重要部分被菜单遮住。

请注意，虽然“触摸并按住”这个操作是向用户显示编辑菜单的主要方式，但是用户也可以通过双击文本视图中的一个单词来选中它，同时显示出菜单。如果您要在自定义视图中支持菜单，那么您应该对这两种操作都做出响应。此外，您可以定义在用户双击时默认被选中的对象。

如果一个按钮执行的是编辑菜单中已有的操作，则要避免创建这样的按钮。例如，要让用户执行复制操作的话，使用编辑菜单比向用户提供“复制”按钮更好，因为用户会很困惑，为什么在您的应用程序中要有两种方式来完成同样的事情。

您可以启用对静态文本的选择，但是应该仅当静态文本显示对用户有用的内容时才这样做。例如，用户有可能想要复制一幅图像的标题，但是他们可能不想复制一个标签项或屏幕标题的标签，比如“帐户”。在文本视图中，默认应该是按单词选取的。

按钮的标题应该是不可以被选中的，因为很难不触发按钮的点击事件并显示出编辑菜单。一般来说，具有按钮行为的元素不需要被选中。

如果您在自己的应用程序中支持“剪切”，“复制”和“粘贴”操作，您也应该支持撤销和重做（在“支持撤销和重做”介绍）。这是因为编辑菜单不需要在动作执行前进行确认，而且如果用户改变了主意，他们总是希望能够撤销最近的操作。

支持撤销和重做

iPhone OS在文本视图中为用户提供了撤销和重做的能力。用户通过摇晃设备发起撤销动作，设备会显示一个警告，允许用户撤销他们刚才的输入，重做先前未完成的输入或取消撤销操作。

UIKit允许您在自己的应用程序中以一种更通用的方式支持撤销（有关如何在代码中实现这一行为的信息，请参考撤销架构）。您可以指定：

• 用户可以撤销和重做的操作

• 您的应用程序应该何时将一个摇晃事件理解为触发撤销

• 支持多少层的撤销

为了给您的应用程序中的撤销和重做功能提供出色的用户体验，您应该：

• 提供简短的描述性的语言精确地向用户描述他们正在撤销或重做的内容。UIKit自动采用字符串“撤销”和“重做”作为撤销警告按钮的标题，但是您需要提供一至两个单词来描述用户可以撤销和重做的动作。（请注意，“取消”按钮不能被改变。）例如，您可以提供文本“删除姓名”或“地址变更”来创建如“撤销删除姓名”或“重做地址变更”这样的的按钮标题。

  一定要避免提供过长的文本：过长的按钮标题会被截断，并且用户很难解读。此外，由于文本位于按钮的标题中，因此要使用标题式的大写方式，而且不要添加标点。（简单地说，标题式的大写方式是指每个单词都大写，但冠词，并列连词和四个或四个字母以下的介词除外。）

• 避免重载摇晃操作。即使您可以通过编程来制定您的应用程序何时将一个摇晃事件理解为触发撤销，但是如果摇晃可以用来执行另一个动作，用户会感到迷惑。

  摇晃操作是用户期望的发起撤销和重做的主要方式，但是在适当情况下，您也可以在导航栏中包含系统提供的“撤销”和“重做”按钮。如果在您的应用程序环境中，明确地显示一个专用按钮来执行这些功能非常重要，则您可以采取这种做法，但这种情况很不常见。

• 考虑您允许撤销和重做的动作所处的环境。一般来说，用户希望他们所做的更改和执行的动作能够立即生效。撤销和重做功能应该尽可能明确地关联到用户当前所处的环境，而非先前的环境。

启用推送通知

当您的应用程序注册了“苹果推送通知服务”时，您可以在有新数据到来时向用户发出警告，即使您的应用程序没有运行。当设备收到的消息是发给一个没有运行的应用程序时，它可以通过以下方式通知用户：

• 在应用程序的主屏幕图标上更新一个 标记

• 播放警告声音

• 显示一条警告消息

或者您可以组合使用以上方式。用户的反应可能是启动应用程序来处理新数据，或者仅仅是注意到有新数据到来就可以了。（要了解如何在代码中处理推送通知，请阅读苹果推送通知服务编程指南。）

内置的设置程序中的“通知”部分为每一个注册了“苹果推送通知服务”的应用程序提供推送通知的设置。针对每一个应用程序，iPhone OS都可以让向用户设置是否允许标记，声音和警告消息。

您应该花一些时间来思考哪种类型的事件更能让通知引起用户的注意。通知应该向用户提供有用的，可操作的信息，这些信息是用户即使在没有使用您的应用程序时也想要得到的。

当您确定了用户可能关心的事件之后，您还应该让用户决定每种事件应该产生什么类型的通知（如果有通知的话）。如果用户无法定制您的应用程序的推送通知，那么用户可能会被他们不感兴趣的通知所打扰 。

用户可以选择他们想要接收的通知的类型，因此以下三种类型您应该全部支持：

• 标记。 标记是一种对用户打扰最小的方式，它告诉用户有新的他们可能感兴趣的内容出现。标记是一个红色的小椭圆形，出现在主屏幕图标的右上角。您对于标记的外观没有任何控制权，它仅包含数字，不包含字母和标点符号。

  标记适用于告诉用户有多少项有待他们查阅。例如，标记中的数字表示的可能是未读的消息数，新分配的任务数，或当前有多少个远程玩家正在进行游戏。

• 声音。 您可以提供自定义的警告声音，也可以使用内置的警告声音。如果您创建了自定义的声音，一定要保证它简短，独特并且制作专业。（要了解有关自定义声音的技术要求，请参考苹果推送通知服务编程指南中的“准备自定义警告声音”一节。）请注意，当有通知被投递时，您不能强制使设备振动；用户能够控制收到警告时是否伴有振动。

  如果通知到达本身就为用户提供了足以采取行动的信息，在这种情势下，采用一种容易辨识的声音是非常适合的。例如，一个协同任务管理系统在成员的任务完成时可能会伴随着一段独特的声音。仅仅是听到这种声音，用户就知道任务已经完成了。

• 警告。 警告是一种通知用户有新内容时最打扰用户的一种方式。在警告的顶端显示您的应用程序的名称，在它下面是您发送的消息，在警告底部有一至两个按钮。如果您指定了两个按钮，则警告会在左侧显示“关闭”按钮，右侧显示“查看”按钮（用户点击“查看”按钮可以在解除警告的同时启动您的应用程序）。如果您只指定了一个按钮，则警告只显示一个“确定”按钮。“关闭”按钮和“确定”按钮都会关闭警告而不会打开您的应用程序。

  警告会打断用户的工作流程，因此最好谨慎地使用它，并且只用它来投递有关某事件的简短的，重要的消息。特别地，一定要避免在您的警告消息中包含任何广告内容。

保证应用程序的可用性

一个易于使用的应用程序应该允许有障碍的用户在辅助程序或设备的帮助下可以成功使用。iPhone OS设备包含许多功能，使所有用户都可以更加方便地使用该设备，比如可视化语音邮件，缩放以及语音控制功能。您无需在应用程序中采取任何动作，用户可以直接获益于这些功能。

有了VoiceOver，事情就变得不一样了。VoiceOver是苹果公司一项创新性的屏幕阅读技术，它让用户无需看到屏幕，就可以控制他们的设备。为了确保VoiceOver用户可以充分地使用您的应用程序，您可能需要提供一些关于用户界面中视图和控件的自定义信息。

幸运的是，在默认情况下，UIKit控件和视图是易于访问的，因此，当您以完全标准的方式使用这些标准元素时，您只有很少的额外工作要做（如果有的话）。用户界面的自定义程度越高，您需要提供的自定义信息就越多，以便VoiceOver可以正确地向具有视觉障碍的用户描述您的应用程序。

让您的iPhone应用程序易于被VoiceOver用户访问是非常正确的做法。这种做法还可以增加您的用户群，并有可能帮助您满足由各主管机构创建的可用性准则。

提供搜索功能并显示搜索结果

UIKit提供了搜索栏控件，您可以使用它显示一致的启动搜索的界面，但要您需要在您的应用程序中实现搜索功能。（要了解有关搜索栏的更多信息，请参考“搜索栏”；要了解有关在代码中处理搜索结果的更多信息，请参考UISearchDisplayController类参考。）为了确保搜索拥有实用而方便的用户体验，请花一些时间考虑如何实现搜索过程以及如何显示其结果。

一般来说，您应该：

• 为您的数据建立索引，以便随时进行搜索。

• 实时过滤本地的数据，一旦用户开始输入，您就显示结果，并且随着用户继续输入而逐步缩小结果范围。

• 如果可能的话，在用户输入时也同时过滤远程数据，但是，如果这部分的响应时间有可能将搜索结果的计算推迟1-2秒钟以上，一定要经过用户的允许。

• 在列表上面显示搜索栏或者在列表内显示索引。

• 避免为搜索打开一个标签页，除非它是您应用程序中的主要功能，应该被标识为一个不同的模式。

虽然实时过滤数据通常能够产生出色的用户体验，但这并不总是可行的。如果无法实时过滤数据，您可以在用户在键盘上点击“搜索”按钮之后再开始搜索过程。如果您要这样做，一定要提供有关搜索进度的反馈信息，以便让用户知道搜索进程没有停止。一种方法就是尽快显示文本结果，并为那些可能需要更长时间检索的数据显示占位符内容。

例如，在YouTube中，用户点击“搜索”按钮发起视频的搜索。如果网络连接速度很慢，YouTube会先显示“载入中……”消息和旋转的活动指示符，让用户知道搜索正在进行。然后，YouTube会显示一个结果列表，其中，每一行填写搜索的文本结果（比如视频的标题和收视率），以及带有虚线轮廓的立方体自定义图像。随着用户浏览视频标题的列表，下载完的视频缩略图会逐步替换掉原来的虚线立方体。像这样，在更多的数据仍在下载时向用户显示部分搜索结果，能够及时地为用户提供有用的信息。

如果您处理的数据可以归类于多个不同的类别，您可以提供一个范围栏。范围栏包含至多4个范围按钮，每个按钮代表一种分类。例如，“邮件”程序提供了一个范围栏，允许用户将他们的搜索集中在邮件的发件人，收件人或主题字段，或者将搜索范围扩大至包含所有的字段。如果范围栏能够帮助用户集中他们的搜索，或者能够大大减小搜索结果的数量，请您考虑使用范围栏控件。（要了解如何在您的代码中实现范围栏，请参考UISearchBar类参考。）

使用用户的位置信息

用户喜欢能够自动使用他们的物理位置对内容进行标记的功能，或者查找当前在附近的朋友。用户同时也希望当他们不想与他人分享自己的位置时能够禁用这些功能。用户可以通过“设置” > “一般”中的“位置服务”设置来选择同意（或拒绝）系统范围内对他们的物理位置的访问。

如果用户关闭了位置服务，而随后使用的应用程序功能需要获知他们的位置，则用户会看到一个警告，此警告告诉他们必须改变他们的首选项设置才能使用此功能。该警告不允许用户在应用程序的内部做此更改；相反，他们必须进入设置应用程序改变他们的首选项设置。这样可以确保用户充分意识到他们正在授予整个系统使用他们位置信息的权限。

为了让用户知道他们为什么要打开位置服务，您最好只在用户试图使用一项显然需要获知他们当前位置的功能时，才显示警告。例如，当位置服务关闭时，用户仍然可以使用地图应用程序，但是，当他们访问发现并跟踪其当前位置的功能时，会看到警告。

如果位置服务处于关闭状态，iPhone OS会在您的应用程序第一次试图访问位置信息时显示警告。Core Location框架为您提供了一种获取用户偏好设置的方法，使您避免不必要或不适当地触发警告。（要了解关于这个编程接口的更多信息，请参考Core Location框架参考。）

知道了用户的偏好设置信息，您就可以尽可能准确地为需要位置信息的功能触发警告，或是完全地消除警告。

• 如果您的应用程序在没有这些信息的情况下无法执行它的主要功能，您最好在用户启动应用程序时尽快让他们看到警告。用户不会为此感到困扰，因为他们明白应用程序的主要功能依赖于知晓他们的位置。

• 如果用户的位置不是您应用程序基本功能的一部分，您可以选择简单地限制那些用到位置信息的功能。例如，当位置服务关闭时，相机应用程序会自动关闭将用户的位置添加到他们所拍摄的照片的功能。但应用程序并不会阻止用户拍照，除非他们改变偏好设置的选项，这是因为“将位置信息添加到照片”只是一个附加功能，而不是基本功能。

• 如果某项功能需要位置信息才能工作，一定要避免在用户实际选择该功能之前执行任何编程调用触发警告。（获取用户偏好设置信息的调用不会触发警告。）这样，您就可以避免让用户感到奇怪，为什么您的应用程序在用户做一些看似不需要位置信息的事情时，想要得到他们的位置信息。

处理方向的变化

用户可以随时旋转iPhone OS设备，并且他们期望正在浏览的内容做出适当的调整。在您的iPhone应用程序中，请务必：

• 注意加速度表的值（关于加速度表和加速度表编程接口参考的更多信息，请阅读iPhone应用程序编程指南）。如果合适的话，您的应用程序应该对所有的设备方向变化做出响应。

• 如果您的应用程序用户界面的某一部分只在一个方向上显示内容，则该区域只适于在此方向上出现，而且不需要对设备方向的变化做出响应。例如，当用户选择一个iPod视频来观看时，无论当前设备方向如何，该视频都横向显示。这向用户表明，要旋转设备以便更好地观看该视频。该例中最重要的一点是，iPod没有提供“旋转”按钮；相反，用户知道要旋转设备，因为视频是横向显示的。

  让用户旋转设备来正确地浏览应用程序用户界面中需要特定方向的部分。避免创建新的控件或定义新的操作，告诉用户旋转设备。

• 利用一步操作就能改变方向的过程，完成更顺畅且往往更快的旋转。但是，如果您的屏幕布局非常复杂，当发生方向变化时，您可以选择执行一种淡入淡出的转换。要了解如何在您的代码中支持一步操作过程，请参考UIViewController类参考。

• 用户经常因为想要“看到更多”而将他们的设备旋转为横向。如果您只是按比例放大屏幕的内容，则无法满足用户的期望。相反，您应该重新打包文本行，而且如果必要的话，重新安排用户界面的布局，以便更多的内容填充到屏幕当中。

使用声音

用户期望iPhone OS设备具有非常美妙的声音，无论是操作系统的声音（比如铃声和警告声），还是应用程序的声音（比如媒体播放，环境声音和配乐）。此外，用户还希望设备发出的声音能够遵从他们的偏好和目的。

用户决定声音的音量，以及他们是否想要听到这些声音。但是有些时候，即使当前的设置表明用户更倾向于静音，他们还是希望听到某些声音。例如，用户总是期望听到他们设置的警告声。从本质上讲，用户想要听到他们期待听到的声音，而不愿听到他们不期待的声音。

为了帮助您顺应这样的需求，iPhone OS提供了一些编程接口，您可以用来：

• 描述您应用程序的声音应该如何与设备上的其他声音保持一致。

• 确保应用程序的声音能够按照用户的期望进行播放。

在您决定如何处理应用程序中的声音之前，您需要了解，当用户调整设备控件和使用外部设备（如耳机和耳麦）时，他们期望应用程序和设备如何运作。

振铃/静音切换—用户的期望

如果用户希望做到以下几点，他们可以使用“振铃/静音”切换将他们的设备静音：

• 避免被意外的声音打扰，比如电话铃声和来信提示音。

• 避免听到用户操作的附带声音，比如键盘或其它反馈的声音，偶然的声音或应用程序启动的声音。

• 避免听到游戏的声音，包括附带的声音和配乐，它们并不是使用游戏程序所必需的。

例如，在剧场中，用户会将他们的设备切换至静音状态，以免打扰到剧场中的其他人。在这种情况下，用户仍然想要使用他们设备上的应用程序，但他们不想被不期望的或没有明确要求的声音吓到，比如铃声或新消息提示音。

但是，对于旨在产生声音的用户动作，“振铃/静音”切换不会消除它们产生的声音。例如：

• 媒体应用程序中的媒体播放不会被“振铃/静音”切换静音，因为媒体播放是用户明确请求的。

• 时钟应用程序的警告不会被“振铃/静音”切换静音，因为此警告是用户明确设置的。

• 语言学习程序中的音效素材不会被“振铃/静音”切换静音，因为用户采取明确行动想要听到它。

• 语音聊天程序中的会话不会被“振铃/静音”切换静音，因为用户启动此类应用程序的唯一目的就是进行语音聊天。

这种行为遵循用户控制的原则，因为是由用户（而不是设备）来决定听到用户明确请求的声音是否合适。

音量按钮—用户的期望

用户使用设备的音量按钮来调节设备播放的所有声音的音量，包括歌曲，应用程序的声音和设备的声音。这意味着用户可以随时使用音量按钮关闭任何声音，无论“振铃/静音”切换的当前状态如何。

在某些情况下，应用程序适宜在其界面为用户提供音量设置功能。例如，YouTube显示了一个音量滑动器，用户可以用它调整正在观看的视频的音量。尽管YouTube正在运行，用户可以交替使用此滑动器和音量按钮来调整视频的音量。这是因为在应用程序运行时，滑动器起到音量按钮代理的作用：滑动器同时作用于应用程序的音量和整个系统的音量（铃声音量除外）。

如果您需要显示音量滑动器，当您使用MPVolumeView类时一定要使用系统提供的滑动器。请注意，如果当前激活的音频输出设备不支持音量控制（比如A2DP设备），音量滑动器将被相应的设备名称取代。

使用音量按钮调整应用程序当前播放的音频，也会同时调整整个系统的音量（铃声音量除外）。（在当前没有播放任何音频时，使用音量按钮调整铃声的音量。）

这种行为遵循用户控制的原则，因为用户可以随时决定设备发出的声音应该有多大。

有时候，应用程序可能需要调整相对和绝对音量级，以便在其音频输出中产生最佳的混合。但是，最终的音频输出的音量应该始终受到系统音量的控制，无论它是通过音量按钮还是音量滑动器进行调整的。这就意味着，对应用程序音频输出的控制仍然掌握在它所归属的用户的手中。

耳机和耳麦—用户的期望

用户插入耳机和耳麦就可以获得私人的声音体验并且解放他们的双手。在使用和不使用附件的情况下，用户对应用程序的行为有着不同的期望。

当用户插入耳机和耳麦时，他们是打算继续听当前的声音，只是转为私下收听。因此，他们希望当前正在播放音频的应用程序继续播放此音频。

当用户拔下耳机和耳麦时，他们不想自动将正在收听的内容分享给他人。因此，他们希望当前正在播放音频的应用程序暂停播放，让他们准备好之后显式地重新开始播放。

无线音频—用户的期望

用户非常喜欢无线耳机的便捷，比如蓝牙A2DP设备。人们使用无线耳机和耳麦的理由与使用有线耳机和耳麦的理由是一样的：他们想要私下听到声音，并希望解放他们的双手。

用户对无线耳机的用户体验也有着非常类似的期望：

• 当用户连接到无线音频设备时，他们打算继续听到当前的声音，只是转为私下收听。在这种情况下，他们希望音频能够继续播放。

• 当用户断开无线设备时（或者当设备超出作用范围或关闭时），他们不想自动将正在收听的内容分享给他人。在这种情况下，他们希望暂停正在播放的音频，让他们准备好之后显式地重新开始播放。

即使用户没有实际地插入或拔出无线音频设备，他们仍然希望能够选择一个不同的音频通道。为了解决这个问题，iPhone OS自动显示了一个控件，让用户选择音频输出路线。由于选择不同的音频通道是用户发起的动作，所以用户希望正在播放的音频继续播放。

定义应用程序的音频行为

如果声音能够增强用户体验或应用程序的功能，或者是用户体验或应用程序功能必不可少的一部分，您需要决定您的音频应该如何与设备的音频环境保持一致，以及应该如何响应用户的动作。例如，你需要决定：

• 当设备锁定或切换至静音时，您的音频是否应该继续播放。

• 您的音频是否应该与当前正在播放的其他音频混合在一起（比如iPod中的歌曲）。

• 您的应用程序是否需要顺序或并行地同时处理音频输入和输出。

• 您的音频是否应该在中断后自动恢复播放。

要控制应用程序的音频在这些情况下应该如何表现，请使用“音频会话服务”或AVAudioSession类。这些编程接口不能产生声音；它们可以帮助您说明您的音频应该如何与设备上的音频进行交互，以及如何响应中断和设备配置中的变化。音频会话服务管理采用AV基础框架，音频队列服务，OpenAL和I/O音频单元等技术产生的声音。

音频会话是您应用程序和系统之间的音频中介。从用户体验的角度来看，音频会话最重要的一个方面就是定义应用程序的音频行为的类别。

为了提供良好的音频用户体验，应选择能最好地描述应用程序音频的类别。一定要基于类别的语义做出选择，而不是其行为的确切集合。这将确保您的应用程序能够按照用户的期望运转。此外，如果日后该类别的行为集合被重新修订，它也能最大限度地保证您的应用程序正常工作。

在极少数情况下，您可能需要通过为音频会话添加属性，来增强或改进某个类别的标准行为。例如，您可以添加kAudioSessionProperty_OtherMixableAudioShouldDuck属性，以确保您应用程序的音频比所有其他音频（电话音频除外）更响亮。如果能够在其他音频播放的同时听到您应用程序的音频对用户来说很重要的话，您可以这样做。但是，您应该注意，一个类别的标准行为代表了大多数用户的期望，所以您应该在添加属性完善此行为之前，认真仔细地考虑一下。要了解有关音频会话属性的更多内容，请参考音频会话编程指南中的“微调类别”一节。

您可以根据设备当前的音频环境选择您的类别。举个例子，如果用户可以在收听其他音频（不是您提供的配乐）的同时使用您的应用程序，您可能想要这样做。如果这对于您的应用程序来说行得通，一定要避免强迫用户停止收听他们的音乐，或是在您的应用程序启动时强迫用户做出明确的配乐选择。要了解如何做到这一点，参考“小结”中的场景2。

当应用程序正在运行时，您也可以改变音频会话的类别，虽然很少有必要这样做。这样做的主要原因是，应用程序需要在不同的时刻支持录音和播放。在这样的应用程序中，更好的做法是根据需要在Record类别和Playback类别之间进行切换，而不是选择Play和Record类别。这是因为选择Record类别，会使警告（比如来信警告）在录音正在进行时没有声音。

表4-1列出了您可以使用的音频会话类别。iPhone OS默认为音频会话分配了Solo Ambient类别。

小结

下面是一些场景，它们说明了如何选择音频会话类别，以提供用户期望的音频体验。

场景 1. 假设您正在开发一个教育应用程序，帮助人们学习一门新的语言。您需要提供在用户点击特定控件时播放的反馈声音；并提供在用户想要听到正确的发音示例时播放的单词和短语的录音。

在这个应用中，声音对于应用程序的主要功能来说是必不可少的。人们使用该应用程序，收听他们所学语言中单词和短语的发音，所以，即使当“振铃/静音”切换设置为静音或设备锁定时，也应该播放应用程序的声音。由于用户需要清楚地听到发音，因此，他们希望其他正在播放的音频被静音。

为了产生用户期望的音频体验，您应该使用Playback类别。虽然您可以改进这一类别，以便与其他音频（如表4-1中所述）进行混合，但是这个应用程序应该使用默认的行为，以确保其他音频不会与用户明确选择要收听的学习内容发生竞争。

场景 2. 假设您正在开发一个游戏，让用户控制屏幕上的人物完成许多不同的任务。您需要提供各种各样的游戏音效和一段游戏配乐。

在这个应用中，声音会大大提升用户的体验，但它并不是主要任务必不可少的一部分。此外，用户很可能希望能够在静音状态下玩游戏，或者一边听音乐库中的歌曲（而不是游戏的配乐）一边玩游戏。

最好的策略是，要了解当您的应用程序启动时用户是否正在收听其他音频。不要让用户选择是否想要听其他的音频或您应用程序的配乐。相反，要使用“音频会话服务”的AudioSessionGetProperty功能，查询kAudioSessionProperty_OtherAudioIsPlaying属性的状态。根据查询的结果，您可以选择Ambient类别或Solo Ambient类别（这两个类别都允许用户在静音状态下玩游戏）：

• 如果用户正在收听其他音频，您应该假设他们想要继续收听，而不想被迫收听游戏的配乐。在这种情况下，您应该选择Ambient类别。

• 如果当您的应用程序启动时，用户没有收听任何其他音频，应选择Solo Ambient类别。

场景 3. 假设您正在开发一个应用程序，为用户提供准确，实时的到达所选目的地的导航指示。您需要为行程中的每一步提供语音指导，以及一些反馈声音。此外，您认为用户希望在使用应用程序的同时，能够听到他们自己的音频。

在这个应用中，语音导航指示代表了程序的主要任务。基于这个原因，您应该使用Playback类别，它让您的音频在设备锁定或“振铃/静音”切换设置为静音时仍能播放。

为了让人们在使用您应用程序的同时，收听其他的音频，您可以添加kAudioSessionProperty_OverrideCategoryMixWithOthers属性。但是，您也想要确保用户可以在当前正在播放的音频之上，听到应用程序的语音指令。要做到这一点，您可以将kAudioSessionProperty_OtherMixableAudioShouldDuck属性应用到音频会话。这可以确保您的音频比目前播放的所有音频（除了电话音频）更加响亮。

场景 4. 假设您正在开发一个博客应用程序，允许用户向中心网站上传他们的文字和图片。您可能有一个简短的启动声音文件，各种各样简短的声音效果（比如当用户完成上载时播放的声音），以及当上载失败时播放的警告声音。

在这个应用中，声音会提升用户的体验，但它只是附加的。程序的主要任务与音频无关，用户不需要听到任何声音，也能成功使用该应用程序。在这种情况下，您可以使用“系统声音服务”产生声音。这是因为应用程序中所有声音的音频上下文都符合这一技术的目的，也就是要产生用户期望的，遵从设备锁定和“振铃/静音”切换的用户界面音效和警告声音。

提供选项

iPhone OS包含一些帮助用户做出选择的元素。当您需要在应用程序中提供选项时，您应该使用这些选择方法，因为用户已经熟悉了它们的行为。一般来说，您不应该试图复制在桌面计算机应用程序中看到的选择控件的外观和行为，比如应用程序菜单或一组单选按钮。iPhone OS提供了以下元素，您可以用来向用户提供选项：

• 列表（即表格视图）。用户点击列表中的某一行选择一项。列表几乎适合于显示任何数量的选项。有关在应用程序中使用表格视图的方法的详细信息，请参考“表格视图”。

• 选择器，包括日期和时间选择器。用户转动选择器的转轮，直到每个转轮显示出值的相应部分，比如包含年，月，日的日历日期。要了解有关在您的iPhone应用程序中使用选择器的更多信息，请参考“日期和时间选择器”和“选择器”。

• 开关控件。用户将开关控件从一侧滑动至另一侧，显示出两个值之一。开关控制的设计意图是在列表的内部提供一个简单的选项。有关开关控件的更多信息，请参考“开关控件”。

提供许可协议或免责声明

如果您随同iPhone应用程序提供了终端用户的许可协议（或EULA），App Store会显示该协议，以便用户在使用您的应用程序之前可以阅读它。

如果可能的话，尽量避免要求用户在第一次启动您的应用程序时，表示他们同意您的终端用户许可协议。这样用户能够立即享用您的应用程序。但是，即使这是首选的用户体验，它可能无法在所有情况下都行得通。如果您必须在您的应用程序中显示许可协议，请尝试采用一种与您的用户界面相一致的方式，这样可以将给用户造成的不便降到最低。

同样，如果您需要提供免责声明，一定要平衡好业务需求与良好的用户体验。如果可以的话，在您的应用程序描述或EULA中提供您的免责声明，以便它可以用在App Store中。

---