译者注：本文译自苹果官方人机界面手册iOSHumanInterfaceGuidelines(2015年10月21日)，由腾讯ISUX设计师翻译整理，非发文者一人之作。译文首发于ISUX博客，如在阅读过程中发觉错误与偏颇之处，欢迎不吝强调。后续章节会相继更新，敬请期盼。
3.12HealthKit
在iOS8及以后的版本中，使用HealthKit建立的应用可以借助从健康应用中获取的数据为用户提供更强悍、更完整的健康及瑜伽服务。在用户准许的情况下，应用可以通过HealthKit来读写健康应用(用户健康相关数据的储存中心)中的数据。
举例来说，用户可以容许营养应用从健康应用中获取体重及活动数据，用于告诉她们为了达到既定目标三天应当消耗多少千卡。这个营养应用还可以通过HealthKit更新健康应用上实际消耗的千卡数据，让用户能更容易地跟踪她们的健康计划的进展。想要了解怎样将HealthKit整合进你的应用中，请参阅HealthKitFrameworkReference.
下边的手册还能帮助你设计出让人信任且喜爱的健康类应用：
当且仅当你有令人信服的理由时才去访问健康应用中的数据。HealthKit是为了专注于健康及瑜伽服务的应用而设计的。假如一个应用恳求获取与其不相关的健康信息，用户不太可能会放心地将个人数据提供给这个应用。为此，你须要确保用户才能理解你的应用须要获取她们个别具体的个人健康数据的缘由，并告诉她们共享那些数据的用处。
防止在用户还不晓得用途前就向她们恳求访问私人健康数据。当用户才能看见当前的任务和你须要访问的数据的关联性时，会更愿意给与你访问权限。举例来说，当用户在给一个减重应用填写资料时，让他准许你访问健康应用中存储的体重数据是合理的。但若果那种减重应用在启动时就立刻提出访问体重数据的恳求，用户更可能会选择拒绝分享该个人数据。
使用系统提供的用户界面来恳求访问用户的数据。当用户想要向应用授予访问她们的数据的权限时，通常会期望见到如右图所示的系统权限许可列表。为了确保给用户提供良好的用户体验，应防止在应用的其他页面中重复使用权限许可列表上的信息。而是应当在权限列表中添加些自定义信息来说明为何你的应用须要访问特定的数据(参阅HKHealthStoreClassFeference可获取更多信息)的缘由。确保那些信息简约且能清晰地说明你的应用是怎样借助健康应用中的数据，以及搜集这种数据的益处。
注意：当用户决定停止与你的应用共享数据时，让她们可以在系统设置中即可完成变更，而不须要通过你的应用界面。
不要在你的应用界面中使用健康应用的图标、图片或则截图。和苹果所有的系统设计一样，这种图象都是深受版权保护的，不应当在你的应用中出现。
不要在你的应用中使用“HealthKit”这个专用术语。HealthKit是代表才能获取健康应用中存储的数据的技术框架的专用技术术语。假如你须要向用户解释你的应用和健康应用中的数据的联系，请使用“健康应用”这个用语。诸如，你可以说你的应用“将保存信息至健康应用中”或“所使用的数据是从健康应用中获取的”。
3.13应用内选购服务(In-AppPurchase)
应用内选购服务促使用户可以在你的应用中、你所设计的商店中订购到数字产品。
比如，用户可以做这种事：
你可以使用StoreKit框架以嵌入的形式将商店添加到你的应用中，但是拿来支持应用内选购服务。当用户进行订购时，StoreKit会联接到应用商店进行安全支付，之后再告知你的应用便于它可以提供用户已订购的商品。
重要:应用内选购服务只提供支付功能，其他功能由你自己提供，比如向用户展示商品，解锁外置功能，从你自己的服务器上下载内容等等。其实，你所提供的所有商品都必须在应用商店注册过。
想要了解关于在应用中添加商店的技术要求，请查看In-AppPurchaseProgrammingGuide.想要了解更多关于应用内选购的商业需求信息，请查看AppStoreResourceCenter.其实，你还应当查看相关许可合同来确定你的应用可以转让什么商品以及怎样提供商品。
遵守以下几点规范，可以帮助你设计出用户喜欢的订购体验。
将商店的使用体验柔美地集成到你的应用中。在展示商品和处理交易时，给用户提供一种熟悉、一致的体验。你一定不希望用户在访问你的商店时觉得像是步入别的应用。
使用简单明了的标题和说明。最好能让用户在扫过一组项目时，可以快速发觉感兴趣的内容。文案上不要截断委婉，简单直白的语言和标题更容易让用户理解你所要展示的商品。
不要修改默认的确认对话框。当用户订购一个商品时，StoreKit会提供一个确认对话框(如上图所示)。这个确认对话框可以帮助用户防止买错东西，所以不要更改它。
3.14游戏中心(GameCenter)
游戏中心给用户提供玩游戏、组织多人在线游戏以及其他更多功能。玩家可以使用外置的游戏中心应拿来注册帐户、发现新游戏、添加好友、浏览玩家排行和战绩。
作为一名游戏开发人员，你可以使用GameKit应用插口来发布分数和战绩到游戏中心的服务器上，在你的游戏页面中显示玩家排行，帮助用户找到其他玩家。想要了解怎样将游戏中心集成到你的应用中，请查看GameCenterProgrammingGuide.
遵守以下几点规范，有助于你的应用给用户提供好的游戏中心体验。
不要使用自定义的用户界面来提示用户登入到游戏中心。假如用户在未登入到游戏中心的情况下打开了一个须要启用游戏中心的应用，系统会手动提醒她们去登陆。所以没必要自定义一个登陆界面，并且有可能就会让用户倍感困扰。
通常情况下，使用标准的游戏中心界面。在少数情况下，可能自定义游戏中心的界面是合理的，而且这样做会有让用户倍感疑惑的风险。标准的游戏中心界面对于iOS和OSX的用户是熟悉的，并且它会给用户一种置身于一个庞大游戏社区的觉得。
容许用户关掉语音聊天。有些用户可能不想在步入游戏时就手动开启语音聊天，但是大多数用户希望在特定情境下可以关掉语音聊天。
3.15iAd富媒体广告(iAdRichMediaAds)
假如你容许你的应用中出现广告，这么你可以通过用户浏览或则点击那些广告获得利润。(如图所示，这个顶部预留位置就是拿来放置iAd条幅广告。)
通过iAd网路你可以在你的用户界面中以特定的视图投放一则广告。最初，这些视图可以拿来承载目标条幅广告，起到引导用户步入查看全面广告详情的作用。当用户点击该条幅广告时，广告都会执行预先设定的动作，比如播放一段电影、展示可交互的内容，或则启动Safari打开目标网页。该动作所展示的内容可以遮挡住你当前的用户界面，或则使你的应用转换到后台运行。
有三种类型的条幅广告供你在应用中使用：标准(standard)、中等圆形(mediumrectangle)和全屏(fullscreen)。所有类型的条幅似乎在外形和行为上存在差别，但都提供同样的功能，就是引导用户步入广告。
标准条幅(standardbanner)占用屏幕较少的空间，一般从始至终都可见。你可以选择在应用的什么页面展示标准条幅，并在给那些页面设计布局时预留出空间。
所有的iOS应用都可以展示标准条幅。你可以使用ADBannerView类中的广告视图来显示标准条幅广告。
所有的iOS应用都可以展示标准条幅。你可以使用ADBannerView类中的广告视图来显示标准条幅广告。
中等圆形条幅(mediumrectanglebanner)的行为同标准条幅类似，同样也可以选择展示中等圆形条幅的位置。
中等圆形条幅只能在iPad的应用中使用。你可以使用ADBannerView类中的广告视图来显示中等圆形条幅广告。
全屏条幅(fullscreenbanner)会占用屏幕的大部份甚至是全屏空间，但是一般只在应用程序流的特定时间或特定位置显示。你可以选择使用模态视图来显示条幅广告，或则用独立页来展示可滚动的广告内容。(在下边的示例中，应用提供了一种刊物阅读的体验，通过翻页离开或回到全屏广告页面。)
你可以使用ADInterstitialAd类中的广告视图在你的应用中显示全屏条幅广告。
iAd框架包含了所有类型的条幅广告，而且会在右下角显示iAd的标示。iAd框架的设计固定在屏幕顶部时看上去疗效最佳。
为了保证广告无缝植入，而且要提供最好的用户体验，可以依循以下几点规范。
将标准条幅广告视图尽量放置在屏幕顶部或顶部附近。这个位置的差异取决于屏幕顶部是否包含栏(bar)以及是哪些样的栏。
栏
标准条幅的位置
屏幕顶部没有栏
屏幕顶部
屏幕任何地方都没有栏
屏幕顶部
有工具栏(toolbar)或标签栏(tabbar)
顶部栏的上方
将中等圆形条幅广告视图放置在不会干扰内容的地方。和标准条幅一样，中等圆形条幅也最好放置在屏幕顶部或顶部附近。置于顶部附近也能降低干扰用户的可能性。
当用户体验存在中断时请使用模态视图来展示全屏条幅广告。假如你的应用中有自然中断或情境转换，用模态款式来展示会更合适。当你使用模态款式来展示全屏条幅时(通过用presentFromViewController实现)，用户要么步入广告，要么关掉它。出于这个缘由，当用户有作出转变的预期时(例如完成了一个任务后)用模态视图的方式来展示比较好。
应用的界面视图进行转场切换时不要使用模态款式展示全屏条幅。假如用户在使用你的应用时会频繁的进行屏幕切换操作，比如刊物翻页或翻阅一些彩页图片合辑，此时使用非模态的方式会更合适。当你使用非模态来显示全屏条幅时(通过使用presentInView实现)，可以在用户界面中保留栏(bar)促使用户可以通过应用中的控件步入或退出广告。同其他条幅广告一样，点击全屏条幅广告也会触发iAd体验，并且假如条件容许的话，你的应用也可以对条幅广告区域支持其他手势操作(例如拖动或滑动)。
确保使用合适的动漫疗效来显示和隐藏非模态的全屏条幅视图。诸如，刊物阅读应用可以用和刊物翻页一样的动漫疗效。
确保条幅广告在应用中出现的时间和位置是合理的。用户只有在不认为广告会打搅她们正常的工作流程时才有可能去体验iAd.这点对于游戏这样的沉溺式应用尤其重要：你肯定不想将条幅放置在影响用户玩游戏的位置。
防止将条幅放置在用户只会一扫而过的页面。最好不要将条幅广告放置在用户会快速略过的页面，例如用户正要深入挖掘或抵达她们所关注的内容。一般用户在一个页面逗留起码1、2秒后才有可能会点击广告。
尽可能的支持单向展示条幅广告。最好让用户在使用应用时毋须旋转设备能够浏览广告。其实，支持单向也能给你的广告提供更大的展示区域。想要了解怎样确保转换方向时条幅广告能正常响应，请查看iAdProgrammingGuide.
不要让标准或中等圆形条幅广告滚粗屏幕。假如你的应用须要滚动来展示更多内容，确保条幅广告仍然固定在它的位置上。
当用户浏览或与广告进行交互时，暂停这些吸引用户注意力或须要操作的活动。当用户选择浏览广告时，她们不想因而错过应用中正发生的风波，也同样不想让应用打断广告体验。一个好的经验方式是像应用程序转到后台运行那样暂停当前活动。
除非有特殊情况，否则不要中断广告。通常情况下，当用户浏览并与广告进行交互时，应用还是会继续运行并接收事件，所以也有可能忽然出现一个风波须要获得用户的注意力。但是，须要打断广告的场景虽然十分少。有一种情境是有的应用会提供互联网语音合同服务(VoIP).在这些应用中，有电话接入时可能会取消正在运行的广告。
注意:取消广告可能会对应用能接受的广告类型以及能获取的利润有不好的影响。
3.16无线复印(AirPrint)
用户可以通过AirPrint无线复印应用中的内容，还可以使用复印中心应用检测复印任务。
你可以借助外置的支持程序来复印图片和PDF文件，或则可以使用特定的复印程序插口来完成自定义的格式设置和渲染设置。iOS可以处理复印机的发觉、任务排序以及在指定复印机上执行复印任务。
一般来讲，用户想要复印文件的时侯，只须要点击应用中的标准动作按键(Actionbutton)。当她们在界面视图中选择了要复印的项目后，可以接着选择复印机，设置复印属性，最后点击复印按键开始复印。
复印中心应用是一个只有在处理复印任务时才可见的后台系统应用，用户可以用它来查看复印任务。用户可以在复印中心浏览当前复印队列，查看某个复印任务的详情，还可以取消某个任务。
只需添加少量代码就可以支持基本复印功能(想要了解在代码中添加复印功能，请查看DrawingandPrintingGuideforiOS).想要确保好的复印体验，可以依循以下几点规范：
使用系统提供的动作按键。用户对系统提供的按键的涵义和行为都很熟悉，所以尽可能的使用系统动作按键。假如你的应用没有工具栏或导航栏，那就要另当别论了。在这些情况下，你就须要自己设计一个可以出现在应用主界面的复印按键，由于动作按键只能在工具栏和导航栏中使用。
在当前情景下复印操作是基本功能时才显示复印项(Printitem).假如当前情景并不适宜复印，或则用户并不想复印，就不要在由动作按键显示的视图上将复印项显示下来。
合适的话，给用户提供更多复印选项。诸如，让用户设置复印页脚范围或复印份数。
假如用户不能复印，则不要显示特定的复印用户界面。在向用户展示有复印项的界面前，确保用户的设备是支持复印的。想要了解怎样在代码中实现，请查看UIPrintInteractionControllerClassReference.
3.17访问用户数据(AccessingUserData)
位置服务容许应用获取用户当前大致的地理位置，设备指向的方向以及用户联通的方向。其他系统服务，比如通信录、日历、备忘录和相册等，同样也容许应用访问用户储存在上面的数据。
尽管获取了用户数据的应用能带来一定的便捷，但还是须要为用户提供维持信息通透性的功能。诸如，用户喜欢应用手动给内容加上位置标签，或则可以找到附近的好友，但用户也须要能在不想分享位置的时侯关掉这种功能。(想要学习怎样给应用降低获取位置功能，请参阅LocationandMapsProgrammingGuide.)
以下几点可以帮助您以用户不讨厌的方法获取用户数据。
确保使用户理解分享私人数据的诱因。若果没有显著的须要，用户自然会对私人信息的恳求倍感怀疑。为了防止用户厌烦，确保在用户使用显著须要个人信息的功能时再进行提醒。诸如，虽然没有打开位置服务用户也可以使用地图，并且在用户使用定位或导航功能时才会有提醒。
应用须要个人信息的诱因不显著时向用户作出解释。你可以在提醒框中给出文字性的描述，比如“这个应用须要访问你的通信录”或者“是否容许应用获取你的地理位置？”。这种文案最好明晰且有礼貌以让用户无压力的理解为何须要访问她们的信息。
述说缘由的文案应当遵守以下原则：
只有当你的应用没有用户数据就难以提供基础服务时，才在一开始就征询用户的许可。假如你的应用在晓得了用户私人信息后才会提供主要功能是显而易见的话，用户不会因而认为纷扰。
防止在用户选择须要数据的功能之前调用触发提醒框的程序。这样，就可以防止用户疑问为何在使用不须要私人数据的功能时有恳求提醒。(注意，检测用户位置服务的设置并不会触发提醒。)
检测位置服务的设置来防止触发没必要的提醒。你可以使用核心位置的程序插口来实现(想要学习怎么做，请参阅CoreLocationFrameworkReference).使用这种知识，可以尽可能地在使用须要位置信息的功能时才进行提醒，或则完全避开提醒。
3.18快速查看(QuickLook)
通过使用QuickLook，用户可以在你的应用内预览文件，虽然你的应用是打不开这个文件的。举例来说，你可以容许用户预览一些从网站上下载或从其他来源获得的文件。
想要学习怎样在应用中加入QuickLook文件预览功能，请参阅DocumentInteractionProgrammingTopicsforiOS.
在你的应用内预览文件之前，用户可在你订制的视图中查看该文件的信息。比如，用户从一封电邮中下载了附件以后，短信应用(Mail)会在电邮中使用订制的视图展示文件的图标、标题和大小。用户可以通过点击它来预览文件。
你可以在应用中用一个新的视图来展示文件预览，或则使用全屏模态视图。展示的方式取决于你的应用运行在哪些设备上。
在iPad上使用模态视图来显示文件预览。iPad的大屏幕适宜在一个便捷用户离开的沉溺式环境中展示文件预览。缩放操作(zoomtransition)很适宜展示预览。
在iPhone上使用专用的视图，最好是导航视图来显示文件预览。这样可以使用户在应用情景中通过导航步入文件预览，不至于迷失。其实也可以在iPhone应用中使用模态显示，但不推荐这样做。(注意缩放操作在iPhone上并不适用。)
另外要注意的是，在导航视图中显示文件预览意味着容许QuickLook在导航栏上放置特定的预览控件。(假如你的视图中包含工具栏，QuickLook会将预览控件置于工具栏上。)
3.19声音(Sound)
无论声音在你的应用中是主要体验的一环，还是锦上添花的元素，你都须要晓得用户对声音表现的期望以及与怎样满足这种期望。
3.19.1理解用户期望(UnderstandUserExpectations)
人们可以使用设备控件来调整声音，她们还可能使用有线或无线的麦克风和扬声器。人们也会对于她们的行为怎么作用于她们看见的声音有各类各样的期望。其实你可能会发觉有一些期望很让人意外，但它们还会遵守用户控制的原则，即应是用户而非设备掌控看到声音的时机。
用户会根据须要将设备静音：
比如，在戏院中，用户将她们的设备调至静音以防止打搅戏院中的其他人。在这一情景下，用户一直希望能在她们的设备上使用应用，但她们不希望被无预期或突兀的声音所打断，如手机铃声或新消息音。
当用户操作的明晰目的就是看到声音时，铃音/静音开关(或静音开关)不会屏蔽那些操作所形成的声音。诸如：
用户使用设备音量调节键盘可调节她们的设备所能发出的所有声音的音量，包括歌曲、应用音质和设备声音。不管铃声/静音(或静音)的开关在哪些位置，用户都能使用音量调节键盘屏蔽所有声音，使用音量调节键盘调节应用当前所播放的音频时同样调整了全局系统的音量，铃声音量除外。
对于iPhone：当没有音频播放时使用音量键可以调整铃声音量。
用户使用麦克风的目的在于能否私密地收听声音以及解放她们的手掌。不管这种配件是有线的还是无线的，用户对这个体验都有特定的期盼。
当用户插入麦克风或联接无线音频设备时，她们期望能以私密的状态继续收听当前播放的音频。为此，她们希望应用才能不中断地继续播放当前正在播放的音频。
当用户拔出麦克风或断掉与无线设备的联接时(甚或设备超出范围或关掉时)，她们不希望她们刚才收听的内容被手动地与别人分享。为此，她们希望正在播放音频的应用暂停播放，让她们才能在自己想要继续播放的时侯再开启。
3.19.2定义应用的音频行为(DefinetheAudioBehaviorofYourApp)
假如必要的话，你可以通过调整相关的、独立的音量水平以在你的应用中制造最好的混缩输出疗效。但最终音质输出的音量也应当能由系统音量控制，可以通过音量键或音量滑块进行调节。这意味着应用的音频输出的控制权一直归属在用户手中。
确保你的应用能适时地显示音频路径选择。(音频路径(audioroute)是指音频讯号的电子通路，比如从设备到麦克风或是从设备到音箱。)虽然人们没有化学性的插入或拔出音频设备，她们也仍希望能选择其他不同的音频路径。为了实现这一诉求，iOS能手动显示可让用户选择输出音频路径的控件(使用MPVolumeView类能容许这个控件显示在你的应用中)。因为选择不同的音频路径是用户主动的行为，用户期望当前播放的音频能继续不中断。
假如你须要显示音量滑块，在使用MPVolumeView类时，确保使用的是系统提供的可用的音量滑块。注意，当正在使用的音频输出设备不支持音量控制时，音量滑块会被合适的设备名称所取代。
假如你的应用只形成一些与其功能无必要关系的界面音质时，(尽量)使用系统音质服务(SystemSoundServices)。系统音质服务是一种能形成警示音、界面音质和发出震动的iOS技术；它不适宜任何其他用途。当你使用系统音质服务(SystemSoundServices)来形成音质时，你不能干涉你的音频与设备的音频的交互方法，也不能干涉它处理干扰和设备配置变化的形式。想了解怎样使用这一技术，请参阅AudioUISounds(SysSound)中的范例项目。
假如音质在你的应用中饰演重要的角色，使用音频会话服务(AudioSessionServices)或是AVAudioSession类。这种程序插口不形成音质；相反，它们会帮助你了解你的音频应当怎样与设备的音频进行交互以及怎样响应设备配置的干扰与变化。
对于iPhone：无论你使用哪些样的技术来制做音频，无论你怎么定义来它的行为，电话总是可以中断当前运行的应用。这是由于任何应用都不应当制止人们接收来电。
在音频会话服务(AudioSessionService)中，音频会话(audiosession)执行了你的应用与系统之间音频中介的功能。音频会话中最重要的方面之一就是类目(category)，它定义了你的应用的音频行为。
为了实现音频会话服务带来的益处并提供用户期望的音频体验，你须要选择可以完美描述应用音频行为的类目(category)。具体情况取决于你的应用只在前台播放音频还是也要在后台播放音频。在你做这一选择的时侯，遵守以下这种原则：
表35-1列出了你可以使用的音频会话类目。不同的类目可以容许通过铃声/静音开关或静音开关(或设备锁)来实现静音、与其他的音频混和或则控制应用在后台播放。(欲了解编程界面上所呈现的类目和属性的确切名称，请参见AudioSessionProgrammingGuide.)
表35-1音频会话类目及其相关行为
类目
意义
静音
混和
后台播放
个人环境
声音提高了应用的功能且应当静音其他音频
支持
不支持
不支持
环境
声音提高了应用的功能但不应当静音其他音频。
支持
支持
不支持
播放
声音对应拿来说很重要且可以与其他音频混和。
不支持
不支持(默认)支持(当“与其他音频混和”属性被添加时)
支持
录音
音频是用户记录的。
不支持
不支持
支持
播放和录音
声音代表音频输入与输出，按次序地或同时地。
不支持
不支持(默认)支持(当“与其他音频混和”属性被添加时)
支持
音频处理
应用执行硬件辅助音频编码(不播放或录音)。
不适用
不支持
支持*
*假如你选择音频处理类目而且你希望在后台运行音频进程，你须要在完成音频处理之前避免你的应用被暂停。欲了解怎样实现这一功能，参见《iOS应用编程手册》中的执局长时间运行的后台任务。
以下是一些示例情景，其手指示了怎样选择音频会话类目以提供用户喜欢的音频体验。
情景1：一个帮助人们学习新语言的教育类应用。你须要提供：
在这个应用中，声音对于主要功能是非常重要的。人们使用这个应拿来听她们正学习的语言的词句与句子，因而虽然当设备锁定或则被调至静音时也要能播放声音。由于用户须要清晰地听见声音，她们会期望其他她们可能播放的音频都被静音。
为了满足用户对于该应用所期望的音频体验，你应当使用播放(Playback)类目。其实这一类目可以被定义为与其他音频混和，但该应用应当使用默认的行为以确保其他的音频不会干扰这些用户明晰选择看到的教育性内容。
场景2：网路合同电话(VoIP)应用。你须要提供：
在该应用中，声音对于主要功能是极其重要的。人们时常会在使用另一个应用时使用该应用与别人进行交流。用户期望能在她们将设备调至静音或设备被锁定时接听电话，她们希望在来电期间其他音频被静音。她们也希望应用在后台运行时也能继续打电话。
为了满足用户对于该应用所期望的音频体验，你应当使用播放和录音(PlayandRecord)类目，但是你要确保只有在你须要时就会激活你的音频会话，便于用户可以在打电话过程中使用其他音频。
场景3：容许用户在不同任务中操作角色的游戏。你须要提供：
在该应用中，声音会在很大程度上提高用户体验，但对于主任务并没有这么重要。并且，用户可能会希望能在玩游戏时静音或听她们乐单中的歌曲而不听游戏配乐。
最好的策略是在你的应用启动时确定用户是否在收听其他音频。不要要求用户选择她们是要收听其他音频或是你的音质。而应当使用音频会话功能中的AudioSessionGetProperty来恳求kAudioSessionProperty_OtherAudioIsPlaying属性的状态。根据所恳求的答案，你可以选择环境(Ambient)或是个人环境(SoloAmbient)类目(这两种类目都容许用户静音玩游戏)：
情景4：一个为用户抵达目的地提供确切、实时导航指示的应用。你须要提供：
在该应用中，无论应用是否是在后台运行，语音导航指示都表现为主要任务。基于这一缘由，你最好使用播放(Playback)类目，它容许你的音频在设备被锁定、静音或是在后台运行时仍可以播放。
你可以通过添加kAudioSessionProperty_OverrideCategoryMixWithOthers属性来实现容许人们在使用你的应用时收听其他音频。并且你也想要确保用户在她们正在播放其他音频时能看到语音提示。你可以为音频会话添加kAudioSessionProperty_OtherMixableAudioShouldDuck属性来确保你的音频比其他音频的声音更大(iPhone上的电话音频除外)。这种设置容许应用在后台运行时也可以恢复音频会话，可以确保用户能获得实时更新的导航。
情景5：一个容许用户上传文本和图片到网站上的博客应用。你须要提供：
在该应用中，声音提高了用户体验，但也不是必需的。主任务与音频并没有关系，用户也不是必需要通过收听声音能够成功使用应用。在这一情景中，你最好使用系统声音服务来形成声音。这是由于这个应用中所有声音的音频情景都符合本技术想要达到的目的，也就是说应制做符合用户所期盼的、能通过设备和铃声/静音(或静音)开关来调节的界面音质和提示音。
3.19.3管理音频中断(ManageAudioInterruptions)
有时侯，当前播放的音频会被来自于不同应用的音频所打断。举个事例，在iPhone上，来电会持续中断当前应用的音频。在多任务情景中，这些音频中断的频度可能会很高。
为了提供用户喜欢的音频体验，iOS系统依赖于你能做到下边几点：
每位应用须要辨识会导致音频中断的类型，但不是每位应用都须要决定怎样在音频中断结束后进行反馈。这是由于多数类型的应用应在音频中断结束后恢复音频。只有这些主要或部份由媒体播放组成(以及提供媒体播放控制)的应用，才必须用额外的步骤来决定哪些是合适的反馈。
从概念上讲，基于中断当前音频的音频类型以及中断结束后用户所期望的特定的应用反馈形式，有两种类型的音频中断：
在可恢复性中断结束后，有媒体播放控件的应用应当恢复它被中断前的任务，无论是继续播放音频还是保持暂停。没有媒体播放控件的应用则应当恢复播放音频。
举个事例，试想用户在iPhone上使用应用播放音乐时，在播一首歌的中间来了一个网路电话。用户接起了电话，期望在她们通话时播放的应用能静音。在通话结束后，用户希望播放的应用手动恢复播放歌曲，由于音乐而非电话才是她们的主要倾听体验，而她们在电话接入前也没有暂停音乐。另一方面，假如用户在电话接入前暂停了音乐播放，她们会希望电话结束后音乐仍保持暂停。
其他能造成可恢复性中断的应用的事例还有这些具备闹铃、音频提示(比如语音方向指示)或其他间歇性音频功能的应用。
下边的手册可以帮助你决定当一个音频中断后怎样继续以及提供哪些信息:
确定由你的应用导致的音频中断的类型。在你的音频结束时，你可以通过以下任意一种方法去禁用你的音频会话来做到这一点：
无论提供与否，标示会在适合的情况下容许iOS系统赋于被中断的应用手动恢复播放它们的音频的能力。
决定是否应当在一个音频中断结束后恢复音频。你应根据你应用中所提供的音频体验来做这一决断。
3.19.4适时处理媒体远程控制风波(HandleMediaRemoteControlEvents,ifAppropriate)
当人们使用iOS媒体控制器或辅助控制器(如麦克风线控)时，应用要能响应远程控制。使你的应用能接收来自于你的用户界面之外的输入，无论你的应用当前是在前台还是后台播放音频。
应用可以在播放媒体的过程中，通过后台向支持Airplay的硬件(如AppleTV)发送视频。这样的应用可以接收通过远程控制风波实现的用户输入行为，因而用户可以控制处于后台运行状态的应用中的视频播放。除此之外，这类应用在后台运行时也能恢复被中断的音频。
当一个媒体播放应用在后台播放音频或视频时，尤其须要合理响应媒体远程控制风波。
当你的应用在后台运行时，为了满足与播放媒体特权相关的责任，要确保遵守以下这种原则：
限制你的应用接收远程控制风波的次数。比如，当你的应用可以帮助用户阅读内容、搜索信息或是收听音频时，它只有在用户处于音频场景中时才应当接收远程控制风波。当用户脱离音频情景时，你应当舍弃接收风波的能力。假如你的应用容许用户在支持AirPlay的设备上播放音视频，它应当在媒体播放期间都可以接收远程控制风波。遵守这种原则能使用户在你的应用中处于非媒体情景中时，通过麦克风控制获得另一个应用的媒体体验。
尽可能地使用系统原生的控件以提供AirPlay支持。当你使用MPMoviePlayerController类实现AirPlay播放功能时，你可以借助标准的控件使用户可以选择当前范围内支持AirPlay的硬件。或则你可以使用MPVolumeView类来显示用户可选择的支持AirPlay的音频或视频设备。用户习惯于这种标准控件的外形和行为，为此她们可以理解怎样在你的应用中使用它们。
不要改变风波的用途，虽然这个风波在你的应用中没有意义。用户期望iOS系统的所有应用媒体控制和辅助控制能有功能上的统一。你何必实现你的应用所不须要的这些风波，但你所实现的风波必须形成符合用户期望的结果。假如你重新定义一个风波的意义，你会使用户困扰并冒险把她们带入一个未知的状态，她们只能通过退出你的应拿来逃出。
3.20VoiceOver
VoiceOver降低了对盲人、弱视用户以及一些有特定学习困难的用户的可用性。
为了确保VocieOver的用户能使用你的应用，你须要在你的用户界面中提供一些有关视图和控件的描述信息。对VoiceOver的支持不须要你改变你用户界面内的任何视觉设计。
当你完全遵循标准的方法使用标准的用户界面元素时，几乎不(虽然有也极少)须要降低额外的工作。你的用户界面越趋于多样化，你就越须要提供更多的信息来保证VoiceOver能确切的描述你的应用。
降低你的iOS应用对VoiceOver用户的可用性，可以扩大你的用户基础并帮助你步入新的市场。支持VoiceOver也可以帮助你遵循由主流群体所拟定的可用性指导准则。
3.21路线选择(Routing)
地图可以显示抵达用户目的地的可选路线：
当人们想要获得关于某条路线的更多交通信息时，地图也可以显示能提供路线选择的应用列表(包括安装在设备上的应用也包括应用商店中的应用)。
路线选择应用可以提供当前选择的路线有关的信息。人们希望路线选择应用能否快捷、易用，非常是保证确切性。根据本章提供的指导原则能帮你为用户提供她们可信任的交通信息和她们期望的用户体验。
重要：地图能根据人们选择的路线给她们提供开车和步行的指示。路线选择应用可以提供交通信息，它注重于使用交通工具(如公汽车、火车、地铁、渡船、自行车、行人、穿梭巴士等)的模型代替实物逐渐地指示方向。
假如你的应用不能提供用户指定的路线的交通信息，这么不要将你的应用定位为路线选择应用。
实现你的应用所承诺的功能。当人们在交通列表里看见你的应用时，她们觉得它可以帮助其抵达目的地。并且假如你的应用不能提供所选路线的信息，或则它没能囊括它看似应当囊括的这些种类的交通信息，人们就不会乐意给它第二次机会。确切的抒发出你的应用的能力是非常重要的；否则，你的应用会看上去像是在故意欺骗用户。
在你的路线选择应用中，有两种主要的形式可以给用户信心：
注意：尽管确切的报告你所支持的地区可能意味着会降低你的应用在交通信息列表里的出现次数，但如此做却可以帮助用户愈发信任它。
为易用性合理组织界面。易用性对于路线规划应拿来说非常重要，由于用户经常会在极具挑战性的情况下使用它们——例如在明亮的阳光下、在狭小的车箱内甚或是在颠簸的旅程中，或在特别紧急的情况下。要确保你的文字在任何光照条件下都能容易的阅读，确保按键虽然在并不平稳的旅程中也能便于确切点击。
专注于路线。尽管辅助信息会很有用，但你的应用应当专注于为用户提供逐渐的指示便于她们能据此抵达目的地。非常要指出的是，你要让用户晓得她们处于哪一步，并晓得怎样抵达下一步。你可以提供额外的数据(例如时间表或系统地图)，但不要让那些数据比交通信息还重要。
为路线的每一步提供信息。永远不要让用户觉得被你的应用所丢弃。虽然在可以确切的报导你所支持的地区时，你也不能假设用户早已前往的路线中的第一个交通节点或是最后一个交通节点就是她们目的地点。为了控制这一情况，首先就是检测起点到终点距离。倘若距离足够短，要提供从用户当前位置到第一个交通节点及从最后一个交通节点到用户目的地的步行方向指示。假如步行不是一个合理的选择，尝试勾勒用户的其他选项。假如必要的话，你可以给用户提供打开地图，获取这部份路线的步行或开车方向指示的形式。
当用户从地图应用切回你的应用时，不要要求她们重复输入信息。假如用户从地图应用切入(你的应用)时，你早已获知了她们中意的起点与终点，因而你可以在应用打开时直接呈现适宜的交通信息。假如用户从主屏幕中开启你的应用，要为她们提供简约的方法用以输入路线详情。
显示图文并茂的交通信息。地图页面可以帮助人们以更大的、实物性的视角查阅她们完整的线路；清晰的步骤可以帮助人们专注于她们到达目的地所需采取的必要行动。最好可以同时支持这两个任务并能让用户方便地进行切换。
注意：无论以哪些格式，最重要的是显示与用户线路相关的相同的交通信息。诸如，假如路线中包含五个步骤，在地图和路线列表页中必须描画相同的五步。
当你的应用被从交通列表中选中时，须要以显示完整的线路做为良好的开始(包括在地图页面中显示源于或前往交通节点的步前路线)。地图页面可以为用户提供她们旅途的多步骤的总览，并能展示易于周遭地理环境的路线。
用附加信息丰富地图页面。人们期望你的应用中的地图可以表现的与她们使用过的其他地图相像。不仅用户能放大和缩小以外，你还应当显示用户所需的这些注释信息。诸如，你应当显示图钉用以代表用户当前的位置、目的地以及沿路的转乘点或重要的节点。
确保防止只显示一个单独的图钉，由于对用户来说，假如没有额外的背景，很难理解它代表哪些。欲了解在你的应用中使用地图页面的更多信息，请参阅MapView.
尽可能地整合静态地图页面，比如在地图视图中加入轻轨系统地图等。一个挺好的实现方式就是在地图页面覆盖静态图片，便于用户可以看见她们的路线及她们的当前位置是怎样与更大的交通系统相关联的。
注意：假如你决定让应用显示一个静态的地图图片，要确保使用高帧率的图片以保证用户在缩放时维持高质量的显示。
给用户提供不同的方案来选购多样的交通选择。好多诱因会影响人们交通的选择，比如不同的时间段，天气以及她们携带东西的多少，所以提供简约的不同交通形式的对比是极其重要的。比如，你要能让用户可以根据开始或结束的时间、需要步行的数目、沿途停下的次数甚或转乘的次数或所需的不同的交通类型等来选购交通形式。不管你显示多种交通选择的次序怎样，确保用户能立刻鉴别出这种选项的不同之处。
考虑使用推送通知为人们提供与路线相关的重要信息。尽可能的让人们了解交通情况信息的变化，便于她们可以据此调节自己的计划。诸如，假如列车晚点或则巴士路线临时停滞，人们可能会须要选择不同的交通路线抵达目的地。而在一条不同步骤的站点之间相隔很长距离的交通路线中，人们会希望在她们的交通工具即将前往行程中的下一部分时能获得通知。
3.22编辑菜单(EditMenu)
用户能呼出一个编辑菜单来完成例如在文本视图、网页或图片视图中的剪切、粘贴以及选择操作。
你可以通过调整一些菜单的行为使用户对你应用中的内容有更多的控制权。举个反例，你可以：
你不能改变菜单本身的颜色和形状。
欲了解怎样在代码中实现这种行为的相关信息，请参阅Copy,Cut,andPasteOperations.
为了确保编辑菜单在你的应用中的表现符合用户期望，你应当：
显示在当前情景下合理的命令。比如，当没有对象被选择的时侯，菜单中不应当包括复制或剪切(命令)，由于这种命令是针对选择(的内容)而操作的。相像地，若果有对象被选择的时侯，菜单中不应当包括选择(命令)。假如你在自定义页面中支持编辑菜单，你就有责任确保菜单中显示的命令切合当前的情景。
根据你的页面布局调节菜单显示。iOS根据可获得的空间大小选择在插入点的上方或下方来放置菜单表针以显示编辑菜单，这样用户能够看见菜单命令是怎样与内容相关的。在必要的情况下，你可以通过程序在菜单显示之前决定它的位置，这样可以防止用户界面中的重要信息被遮挡。
支持两种手势来调用菜单。其实点击和长按手势是用户呼起编辑菜单的首选方法，但她们也可以在文本页面中通过双击一个词组来选择该词组并同时呼起菜单。假如你在自定义页面中支持菜单，确保它能支持两种手势。除此之外，你可以定义用户双击时默认的选择对象。
防止在你的用户界面中创建和编辑菜单中功能相同的按键。诸如，使用编辑菜单让用户进行复制操作远比提供一个复制按键要好，由于用户将会想晓得为何在你的应用中会有两种方式做同样的事。
假如静态文本的选择对用户来说是有用的，这么可以考虑使用它。用户可能想要复制图片的标题，但她们不可能想复制选项卡的标签或是屏幕的标题，例如“账户(Account)”。在文本页面内，文字的选择应当是默认设置的。
不要使按键标题可选择。假如按键的标题是可选择的，用户很难在不激活按键的情况下呼出编辑菜单。一般来说，像按键这样操作的元素不须要是可选择的。
将对撤消与重做的支持与对复制与粘贴的支持组合到一起。人们常常希望在她们改变主意的时侯能撤消近来的操作。因为编辑菜单在它操作执行的时侯是不须要确认的，你应当给用户提供撤消或重做这种操作的机会。
假如你须要创建自定义的编辑菜单项，须要像下边展示的这个事例一样遵守这种指导原则：
创建直接作用于用户选择的包含编辑、修改或其他操作的编辑菜单。人们期望在当前的情景内用标准的编辑菜单项操作文本或对象，这么你的自定义菜单项最好能有相像的表现。
将自定义项列在所有系统提供的项的前面。不要将你的自定义项与系统提供的项混置在一起。
保持自定义菜单项的数目在合理的范围内。你不应当用太多选择蒙蔽你的用户。
使用简约的名称命名你的自定义菜单项并确保名称能确切的描述命令的作用。一般，项的名子应当是一个可以描述行为怎么执行的副词。其实你一般会使用单个的小写词组作为名子，但假如你必须使用一个句子(作为名子)时，就应使用标题式小写句型。(简约的、标题性的小写词就是将不仅文章、四字及四字以下的并列连词与动词之外的词组都小写。)
3.23撤消与重做(UndoandRedo)
用户通过晃动设备触发撤消操作，显示提醒框让她们可以：
你可以通过在你的应用中定义出更通用的方法来支持撤消操作：
欲了解怎样用代码实现这一行为，请参阅UndoArchitecture.若果在你的应用中支持撤消和重做，请遵守以下准则以提供好的用户体验:
为用户提供简约的描述性词组使其能确切的得知她们正在撤消或重做的内容。iOS系统手动提供了“撤销”和“重做”的字符串(包括成语旁边的空格)作为撤消警示按键的标题，但你须要提供一或两个成语用于辅助描述用户的重做或撤消操作。比如，你可能提供文本的“命名”或“地址修改”之类的词句用以创建像“撤销命名”或“重新修改地址”这样的按键标题。(要注意，在提醒框中，“取消”按钮是不能改变或移除的)。
避开提供的文本过长。太长的按键标题容易被断章取义而且很难被用户评析。因为这个文本用于按键的标题中的，要使用标题式样的小写方式而且不能添加标点。
防止过度使用摇动手势。就算你能程式化地设定你的应用将摇动风波作为用户激活撤消操作的途径，你也在冒着混淆用户视听的风险，由于她们也可能使用摇动执行另一个不同的操作。剖析你应用中的人机交互以防止创建这些用户难以可靠地预测摇动手势结果的场景。
假如撤消和重做在你的应用中是基础性的任务，尽量使用系统原生的撤消与重做按键。记住摇动手势是用户触发撤消与重做操作的主要方法，而假如提供两种不同方法完成同样的任务则会使用户困扰。假如你觉得很有必要提供直观专有的撤消与重做操作，你可以在导航栏中放置系统原生的按键。(欲了解更多关于这种按键的信息，参见ToolbarandNavigationBarButtons).
将撤消与重做能力与用户当下的情景进行清晰地关联，而非过早地介入情景。仔细考虑你容许进行撤消与重做操作的情景。一般来说，用户期望她们的改变和操作可以立刻被有效的执行。
3.24按键和输入页面(KeyboardsandInputViews)
在iOS8与以后的系统中，你可以创建自定义的按键扩充内容来代替系统的原生按键。欲了解更多关于管理应用内扩充(包括鼠标)的信息，请参阅APPExtensions；欲了解怎么开发自定义的按键扩充内容的信息，请参阅CustomKeyboard.
在合适的情况下，你9也可以在你的应用内设计自定义的输入页面来代替系统原生的屏幕按键。诸如，Numbers(译者注：iWork中的电子表单应用程序)中提供了多种输入页面，这种页面设计使数目、日期和其他值的输入能简单高效地完成。
假如你提供自定义输入页面，确保它的功能对于来用户来说是清晰易懂的。
你也可以提供自定义的输入辅助视图，这些视图一般表现为显示在鼠标(或你的自定义输入页面)上方的一个独立元素。比如，在个别情景中，Numbers会显示一个输入辅助视图用以帮助用户执行针对电子表格中的值的标准或自定义估算。
当用户在你的输入页面中敲打自定义控件时，使用标准的按键敲打声提供声音反馈。欲了解在代码中怎样使用这一声音，请参阅UIDeviceClassReference中的playInputClick章节
注意：标准的敲打音质只适用于当前屏幕上的自定义输入页面。人们可以在设置-声音中关掉所有的按键音质(包括你的自定义输入页面中的这些)。
本章英语原文访问地址：iOSHumanInterfaceGuidelines
本章英文翻译PDF下载：点此下载
