Является ли звук основной частью пользовательского опыта Вашего приложения или дополнительного улучшения, необходимо знать, как пользователи ожидают, что звук будет вести себя и как оправдать те надежды.

Поймите пользовательские ожидания

Люди могут использовать управление устройствами для влияния на звук, и они могли бы использовать соединенные проводом или беспроводные гарнитуры и наушники. У людей также есть различные ожидания того, как их действия влияют на звук, который они слышат. Несмотря на то, что Вы могли бы счесть некоторые из этих ожиданий удивлением, они все следуют за принципом контроля за работой пользователей в этом, пользователь, не устройство, решает, когда является надлежащим услышать звук.

Переключатель Users их устройства к тихому, когда они хотят:

• Избегите прерываться неожиданными звуками, такими как телефонные вызывные тональные сигналы и звуки входящего сообщения

• Избегите слышать звуки, которые являются побочными продуктами пользовательских действий, такими как клавиатура или другие звуки обратной связи, несущественные звуки или звуки запуска приложения

• Избегите слышать игровые звуки, которые не важны для использования игры, таковы как звуковые эффекты и звуковые дорожки

Например, в театре пользователи переключают свои устройства на тихий, чтобы избежать беспокоить других людей в театре. В этой ситуации пользователи все еще хотят быть в состоянии использовать приложения на их устройствах, но они не хотят быть удивленными звуками, которые они не ожидают или явно запрашивают, такие как вызывные тональные сигналы или новые звуки сообщения.

Кольцевое/тихое (или Тихий) переключатель не заставляет замолчать звуки, следующие из пользовательских действий, исключительно и явно предназначающихся для создания звука. Например:

• Воспроизведение носителей в приложении только для носителей не заставлено замолчать, потому что воспроизведение носителей явно требовал пользователь.

• Предупреждение Часов не заставлено замолчать, потому что будильник был явно поставлен пользователем.

• Звуковой клип в изучающем язык приложении не заставлен замолчать, потому что пользователь принял явные меры для слушания его.

• Разговор в аудио приложении чата не заставлен замолчать, потому что пользователь запустил приложение в единственной цели наличия аудио чата.

Пользователи используют кнопки громкости устройства для корректировки объема всех звуков, которые их устройства могут играть, включая песни, звуки приложения и звуки устройств. Пользователи могут использовать кнопки громкости для подавления шумов любого звука, независимо от позиции Кольцевого/тихого (или Тихий) переключатель. Используя кнопки громкости для корректировки в настоящее время играющего аудио приложения также корректирует полный системный том, за исключением громкости звонка.

Пользователи используют гарнитуры и наушники, чтобы услышать звуки конфиденциально и освободить их руки. Независимо от того, соединены ли эти аксессуары проводом или беспроводная связь, у пользователей есть определенные ожидания пользовательского опыта.

Когда пользователи включают гарнитуру или наушники, или соединяются с беспроводным аудиоустройством, они намереваются продолжать слушать текущее аудио, но конфиденциально. Поэтому они ожидают приложение, в настоящее время играющее аудио, чтобы продолжать играть без паузы.

Когда пользователи отключают гарнитуру или наушники или разъединение от беспроводного устройства (или устройство выходит из диапазона или выключает), они не хотят автоматически совместно использовать то, что они слушали с другими. Поэтому они ожидают приложение, в настоящее время играющее аудио для приостановки, позволяя им явно перезапустить воспроизведение, когда они готовы.

Определите аудио поведение своего приложения

Если необходимо, можно скорректировать относительные, независимые уровни громкости для создания лучшего соединения в аудиовыходе приложения. Но объемом заключительного аудиовыхода должен всегда управлять системный том, корректируется ли это кнопками громкости или регулятором громкости. Это означает, что управление аудиовыходом приложения остается в руках пользователей, где оно принадлежит.

Гарантируйте, что Ваше приложение может вывести на экран аудио средство выбора маршрута, в подходящих случаях. (Аудио маршрут является электронной трассой для звуковых сигналов, такой как от устройства до наушника или с устройства на динамики.) Даже при том, что люди физически не включают или отключают беспроводное аудиоустройство, они все еще ожидают быть в состоянии выбрать различный аудио маршрут. Для обработки этого iOS автоматически выводит на экран управление, позволяющее пользователям выбирать выходной маршрут аудио (используйте MPVolumeView класс, чтобы позволить управлению отображать в Вашем приложении). Поскольку выбор различного аудио маршрута является инициируемым пользователями действием, пользователи в настоящее время ожидают играть аудио для продолжения без паузы.

Если необходимо вывести на экран регулятор громкости, несомненно, будут использовать предоставленный системой регулятор громкости, доступный, когда Вы используете MPVolumeView класс. Обратите внимание на то, что, когда в настоящее время активное устройство аудиовыхода не поддерживает регулятор громкости, регулятор громкости заменяется надлежащим именем устройства.

Если Ваше приложение производит только звуковые эффекты UI, которые не важны для его функциональности, используют System Sound Services. System Sound Services является технологией iOS, производящей предупреждения, и UI звучит и вызывает вибрацию; это является неподходящим в любой другой цели. При использовании System Sound Services для создания звука, Вы не можете влиять, как Ваше аудио взаимодействует с аудио на устройстве, или как это должно реагировать на прерывания и изменения в конфигурации устройства. Для демонстрационного проекта, демонстрирующего, как использовать эту технологию, посмотрите Аудио Звуки UI (SysSound).

Если звук играет важную роль в Вашем приложении, используйте Аудио Сеансовые службы или AVAudioSession класс. Эти интерфейсы программирования не производят звук; вместо этого, они помогают Вам экспресс, как Ваше аудио должно взаимодействовать с аудио на устройстве и реагировать на прерывания и изменения в конфигурации устройства.

В Аудио Сеансовых службах аудио сеанс функционирует как посредника для аудио между Вашим приложением и системой. Один из самых важных фасетов аудио сеанса является категорией, определяющей аудио поведение Вашего приложения.

Чтобы понять преимущества Аудио Сеансовых служб и предоставить аудио пользователям опыта ожидают, необходимо выбрать категорию, лучше всего описывающую аудио поведение приложения. Дело обстоит так, ли Ваше приложение играет аудио на переднем плане только или может также играть аудио в фоновом режиме. Следуйте этим инструкциям, поскольку Вы делаете этот выбор:

• Выберите аудио категорию сеанса на основе ее семантического значения, не ее точного набора способов поведения. Путем выбора категории, цель которой ясна, Вы гарантируете, что Ваше приложение ведет себя согласно ожиданиям пользователей. Кроме того, если точный набор способов поведения усовершенствован в будущем, это дает Вашему приложению лучшую возможность работы должным образом.

• В редких случаях добавьте свойство к аудио сеансу для изменения стандартного поведения категории. Стандартное поведение категории представляет то, что ожидает большинство пользователей, таким образом, необходимо будет рассмотреть тщательно перед изменением того поведения. Например, Вы могли бы добавить ныряющее свойство, чтобы удостовериться, что Ваше аудио громче, чем все другое аудио (кроме телефонного аудио), если это - то, что пользователи ожидают от Вашего приложения. (Для узнавания больше об аудио свойствах сеанса посмотрите Подстройку Категории.)

• Рассмотрите базирование Вашего выбора категории на текущей аудиосреде устройства. Если, например, пользователи могут использовать Ваше приложение при слушании другого аудио вместо к звуковой дорожке, это могло бы быть целесообразным. Если Вы делаете это, несомненно, избегут вынуждать пользователей прекратить слушать свою музыку или делать явный выбор звуковой дорожки, когда запускается Ваше приложение.

• В целом избегите изменять категории, в то время как работает Ваше приложение. Если Ваше приложение должно поддерживать запись и воспроизведение в разное время, основная причина изменения категории состоит в том. В этом случае может быть лучше переключиться между Рекордной категорией и категорией Воспроизведения по мере необходимости, чем выбрать категория Record и Play. Это вызвано тем, что выбор Рекордной категории гарантирует, что никакие предупреждения — такие как входящее предупреждение текстового сообщения — не будут звучать, в то время как запись происходит.

Таблица 31-1 перечисляет аудио категории сеанса, которые можно использовать. В то время как приложение в фоновом режиме, различные категории позволяют звукам быть заставленными замолчать переключателем Ring/Silent или Silent (или блокировка устройства), смешаться с другим аудио или играть. (Для фактической категории и имена свойства, поскольку они появляются в интерфейсах программирования, см. Аудио Руководство по программированию Сеанса.)

* при выборе категории Обработки аудиоданных и Вы хотите выполнить обработку аудиоданных в фоновом режиме, необходимо препятствовать тому, чтобы приложение приостановило, прежде чем Вы будете закончены с обработкой аудиоданных. Чтобы изучить, как сделать это, посмотрите Реализующие Продолжительные Фоновые задачи.

Вот некоторые сценарии, иллюстрирующие, как выбрать аудио категорию сеанса, обеспечивающую аудио опыт, который ценят пользователи.

Сценарий 1: образовательное приложение, помогающее людям выучить новый язык. Вы обеспечиваете:

• Звуки обратной связи, играющие, когда пользователи касаются определенных средств управления

• Записи слов и фраз, играющих, когда пользователи хотят услышать примеры корректного произношения

В этом приложении звук важен для основной функциональности. Люди используют это приложение для слушания слов и фраз на языке, который они учат, таким образом, звук должен играть, даже когда устройство блокирует или переключается на тихий. Поскольку пользователи должны услышать звуки ясно, они ожидают другое аудио, которое они могли бы играть, чтобы быть заставленными замолчать.

Для создания аудио пользователей опыта ожидают для этого приложения, Вы использовали бы категорию Воспроизведения. Несмотря на то, что эта категория может быть усовершенствована, чтобы позволить смешиваться с другим аудио, это приложение должно использовать поведение по умолчанию гарантировать, что другое аудио не конкурирует с образовательным содержанием, которое пользователь явно принял решение услышать.

Сценарий 2: приложение Передачи речи по протоколу IP (VoIP). Вы обеспечиваете:

• Возможность принять аудиовход

• Возможность играть аудио

В этом приложении звук важен для основной функциональности. Люди используют это приложение для передачи с другими, часто в то время как они в настоящее время используют различное приложение. Пользователи ожидают быть в состоянии получить вызовы, когда они переключили свое устройство на тихий, или устройство заблокировано, и они ожидают, что другое аудио будет тихо на время вызова. Когда приложение будет в фоновом режиме, они также ожидают быть в состоянии продолжать вызовы.

Для создания ожидаемого пользовательского опыта для этого приложения Вы использовали бы Игру и Рекордную категорию, и Вы, несомненно, активируете Ваш аудио сеанс только при необходимости в нем так, чтобы пользователи могли использовать другое аудио между вызовами.

Сценарий 3: игра, позволяющая пользователям вести символ через различные задачи. Вы обеспечиваете:

• Различные звуковые эффекты геймплея

• Музыкальная звуковая дорожка

В этом приложении звук значительно улучшает пользовательский опыт, но не важен для основной задачи. Кроме того, пользователи, вероятно, будут ценить способность играть в игру тихо или при слушании песен в их музыкальной библиотеке вместо к игровой звуковой дорожке.

Лучшая стратегия состоит в том, чтобы узнать, слушают ли пользователи другое аудио, когда запускается Ваше приложение. Не просите, чтобы пользователи выбрали, хотят ли они слушать другое аудио или слушать Вашу звуковую дорожку. Вместо этого используйте Аудио функцию Сеансовых служб AudioSessionGetProperty запрашивать состояние kAudioSessionProperty_OtherAudioIsPlaying свойство. На основе ответа на этот запрос можно выбрать Ambient, или категории Solo Ambient (обе категории позволяют пользователям играть в игру тихо):

• Если бы пользователи слушают другое аудио, необходимо предположить, что они хотели бы продолжать слушать и не будут ценить быть вынужденным слушать игровую звуковую дорожку вместо этого. В этой ситуации Вы выбрали бы Окружающую категорию.

• Если пользователи не слушают никакое другое аудио, когда Ваше приложение запускается, Вы выбрали бы Сольную Окружающую категорию.

Сценарий 4: приложение, предоставляющее точные, инструкции навигации в реальном времени месту назначения пользователя. Вы обеспечиваете:

• Разговорные направления для каждого шага поездки

• Несколько звуков обратной связи

• Возможность к пользователям продолжать слушать их собственное аудио

В этом приложении разговорные инструкции навигации представляют основную задачу, независимо от того, является ли приложение в фоновом режиме. Поэтому Вы использовали бы категорию Воспроизведения, позволяющую Вашему аудио играть, когда устройство заблокировано или переключено на тихий, и в то время как приложение в фоновом режиме.

Чтобы позволить людям слушать другое аудио, в то время как они используют Ваше приложение, можно добавить kAudioSessionProperty_OverrideCategoryMixWithOthers свойство. Однако Вы также хотите удостовериться, что пользователи могут услышать разговорные инструкции выше аудио, которое они в настоящее время играют. Чтобы сделать это, можно применяться kAudioSessionProperty_OtherMixableAudioShouldDuck свойство к аудио сеансу к гарантирует, что Ваше аудио громче, чем все в настоящее время аудио игры, за исключением телефонного аудио на iPhone. Эти настройки позволяют приложению повторно активировать свой аудио сеанс, в то время как приложение в фоновом режиме, который гарантирует, чтобы пользователи получили обновления навигации в режиме реального времени.

Сценарий 5: ведущее блог приложение, позволяющее пользователям загружать свой текст и графику к веб-сайту. Вы обеспечиваете:

• Короткий звуковой файл запуска

• Различные короткие звуковые эффекты, сопровождающие пользовательские действия (такие как звук, играющий, когда сообщение было загружено),

• Предупредительный звук, играющий, когда регистрация перестала работать

В этом приложении звук улучшает пользовательский опыт, но это не важно. Основная задача не имеет никакого отношения к аудио, и пользователи не должны слышать звуки для успешного использования приложения. В этом сценарии Вы использовали бы System Sound Services для создания звука. Это вызвано тем, что аудио контекст всего звука в приложении соответствует намеченной цели этой технологии, которая должна произвести звуковые эффекты UI и предупредительные звуки, повинующиеся блокировке устройства и Кольцевому/тихому (или Тихий) переключатель в способе, которым ожидают пользователи.

Управляйте прерываниями звука

Иногда, в настоящее время игра аудио прервана аудио из различного приложения. На iPhone, например, входящий телефонный вызов прерывает аудио текущего приложения на время вызова. В многозадачной среде частота таких прерываний звука может быть высокой.

Для обеспечения аудио опыта, пользователи ценят, iOS полагается на Вас к:

• Идентифицируйте тип прерывания звука, которое может вызвать Ваше приложение

• Ответьте соответственно, когда Ваше приложение продолжается после того, как прерывание звука заканчивается

Каждое приложение должно идентифицировать тип прерывания звука, которое это может вызвать, но не каждое приложение должен определить, как ответить до конца прерывания звука. Это вызвано тем, что большинство типов приложений должно ответить до конца прерывания звука путем возобновления аудио. Только приложения, которые являются прежде всего или частично носители, воспроизводят приложения — и которые обеспечивают, управление воспроизведением носителей — должно предпринять дополнительный шаг для определения надлежащего ответа.

Концептуально, существует два типа прерываний звука, на основе типа аудио, это делает прерывание и способ, которым пользователи ожидают, что определенное приложение ответит, когда закончится прерывание:

• resumable прерывание вызывается аудио, которое пользователи просматривают как временный перерыв в их основном опыте слушания.

  После того, как resumable прерывание заканчивается, приложение, выводящее на экран средства управления для воспроизведения носителей, должно возобновить то, что это делало, когда прерывание произошло, играет ли это аудио или остается приостановленным. Приложение, не имеющее управления воспроизведением носителей, должно продолжить играть аудио.

  Например, рассмотрите пользователя, слушающего приложение для воспроизведения музыки на iPhone, когда вызов VoIP поступит посреди песни. Пользователь отвечает на вызов, ожидая, что приложение воспроизведения будет тихо, в то время как они говорят. После концов вызова пользователь ожидает, что приложение воспроизведения автоматически продолжит играть песню, потому что музыка — не вызов — составляет их основной опыт слушания, и они не приостановили музыку, прежде чем поступил вызов. С другой стороны, если бы пользователь приостановил воспроизведение музыки, прежде чем вызов поступил, они ожидали бы, что музыка останется приостановленной после того, как заканчивается вызов.

  Другими примерами приложений, которые могут вызвать resumable прерывания, являются приложения, играющие предупреждения, аудио подсказки (такие как разговорные направления движения), или другое неустойчивое аудио.

• nonresumable прерывание вызывается аудио, которое пользователи просматривают как основной опыт слушания, такой как аудио от, носители воспроизводят приложение.

  После того, как nonresumable прерывание заканчивается, приложение, выводящее на экран управление воспроизведением носителей, не должно продолжать играть аудио. Приложение, не имеющее управления воспроизведением носителей, должно продолжить играть аудио.

  Например, рассмотрите пользователя, слушающего приложение воспроизведения музыки (музыкальное приложение 1), когда различное приложение воспроизведения музыки (музыкальное приложение 2) прервет. В ответ пользователь решает слушать музыкальное приложение 2 в течение некоторого промежутка времени. После выхода из музыкального приложения 2 пользователь не ожидал бы, что музыкальное приложение 1 автоматически продолжит играть, потому что они сознательно сделали музыкальное приложение 2 их основным опытом слушания.

Следующие инструкции помогают Вам решить, какую информацию предоставить и как продолжать после того, как прерывание звука заканчивает.

Идентифицируйте тип прерывания звука Ваше вызванное приложение. Когда аудио закончено, Вы делаете это путем деактивации аудио сеанса одним из следующих двух способов:

• Если Ваше приложение вызвало resumable прерывание, деактивируйте свой аудио сеанс с AVAudioSessionSetActiveFlags_NotifyOthersOnDeactivation флаг.

• Если Ваше приложение вызвало nonresumable прерывание, деактивируйте свой аудио сеанс без любых флагов.

Обеспечивание или не не обеспечение, флаги позволяют iOS предоставлять прерванным приложениям возможность продолжить играть их аудио автоматически, в подходящих случаях.

Определите, необходимо ли возобновить аудио, когда заканчивается прерывание звука. Вы базируете это решение об аудио пользовательском опыте, который Вы обеспечиваете в своем приложении.

• Если Ваше управление воспроизведением носителей отображений приложения необходимо проверить, которое люди используют для игры или аудио паузы AVAudioSessionInterruptionFlags_ShouldResume отметьте, когда закончится прерывание звука.

  Если Ваше приложение получает флаг Should Resume, Ваше приложение должно:

  • Продолжите играть аудио, если Ваше приложение активно играло аудио, когда это было прервано

  • Не продолжают играть аудио, если Ваше приложение активно не играло аудио, когда это было прервано

• Если Ваше приложение не выводит на экран управления воспроизведением носителей, которое люди могут использовать для игры или аудио паузы, Ваше приложение должно всегда продолжать ранее играть аудио, когда прерывание звука заканчивается, независимо от того, присутствует ли флаг Should Resume.

  Например, игра, играющая звуковую дорожку, должна автоматически продолжить играть звуковую дорожку после прерывания.

События Носителей дескриптора Дистанционного управления, в подходящих случаях

Когда люди используют управления средой iOS или средства управления аксессуаром, такие как средства управления гарнитурой, приложения могут получить события дистанционного управления. Это позволяет Вашему приложению принимать ввод данных пользователем, не проникающий через Ваш UI, играет ли Ваше приложение в настоящее время аудио на переднем плане или в фоновом режиме.

В то время как воспроизведение продолжается, приложения могут отправить видео в Поддерживающие трансляцию аппаратные средства — такие как Apple TV — и переход к фону. Такое приложение может принять ввод данных пользователем через события дистанционного управления, так, чтобы пользователи могли управлять воспроизведением видео, в то время как приложение в фоновом режиме. Кроме того, этот тип приложения может также повторно активировать аудио сеанс после прерывания, в то время как это в фоновом режиме.

Приложение воспроизведения носителей, в частности должно соответственно реагировать на события носителей дистанционного управления, особенно если оно играет аудио или видео, в то время как это в фоновом режиме.

В то время как Ваше приложение в фоновом режиме, убедиться следовать этим инструкциям, встретить ответственность связалось с полномочием игры носителей:

Ограничьте приемлемость своего приложения для получения событий дистанционного управления ко временам, когда она будет целесообразна. Например, если Ваше приложение помогает пользовательскому содержанию чтения, поиск информации, и слушайте аудио, это должно принять события дистанционного управления только, в то время как пользователь находится в аудио контексте. Когда пользователь оставляет аудио контекст, необходимо оставить возможность получить события. Если Ваше приложение позволяет пользователям играть аудио или видео на Поддерживающем трансляцию устройстве, это должно принять события дистанционного управления на время воспроизведения носителей. После этих инструкций позволяет пользователям использовать носители различного приложения — и управлять им со средствами управления гарнитурой — когда они находятся в контекстах неносителей Вашего приложения.

Как можно больше, используйте предоставленные системой средства управления для предложения поддержки AirPlay. Когда Вы используете MPMoviePlayerController класс для включения воспроизведения AirPlay можно использовать в своих интересах стандартное управление, позволяющее пользователям выбирать AirPlay-enabled device, который в настоящее время находится в диапазоне. Или можно использовать MPVolumeView класс для отображения Поддерживающих трансляцию аудиоустройств или видеоустройств, из которых могут выбрать пользователи. Пользователи приучены к появлению и поведению этих стандартных средств управления, таким образом, они будут знать, как использовать их в Вашем приложении.

Не повторно имейте целью событие, даже если событие не имеет никакого значения в Вашем приложении. Пользователи ожидают, что управления средой iOS и средства управления аксессуаром будут последовательно функционировать во всех приложениях. Вы не должны обрабатывать события, в которых не нужно Ваше приложение, но события, которые Вы действительно обрабатываете, должны привести к пользователям опыта, ожидают. При переопределении значения события Вы смущаете пользователей и рискуете вести их в неизвестное состояние, из которого они не могут выйти, не выходя из Вашего приложения.