Почему воспроизведение звука через AV Foundation блокирует пользовательский интерфейс при медленном соединении?

Question

Я использую AV Foundation для воспроизведения файла MP3, загруженного по сети, с кодом, практически идентичным приведенному здесь примеру воспроизведения: Собираем все вместе: Воспроизведение видеофайла с использованием AVPlayerLayer , кромебез прикрепления слоя для воспроизведения видео.Я пытался заставить мое приложение реагировать на пустой буфер воспроизведения при медленном сетевом соединении.Для этого я планировал использовать наблюдение значения ключа в свойстве playBufferEmpty объекта AVPlayerItem, но в документации не было сказано, возможно ли это.Я подумал, что это возможно, потому что свойство status можно наблюдать (и это пример выше), даже если в документации этого не сказано.

Итак, в попытке создать условия, когда буфер будет пуст,Я добавил код на сервер для сна в течение двух секунд после подачи каждого 8k фрагмента файла MP3.К моему большому удивлению, это привело к тому, что пользовательский интерфейс моего приложения (обновленный с помощью NSTimer) полностью зависал на длительные периоды, несмотря на то, что в профилировщике практически не используется процессор.Я попытался загрузить дорожки в другую очередь с помощью dispatch_async, но это не помогло вообще.

Даже без сна на сервере я заметил, что загрузка потоков с использованием AVPlayerItem не позволяет обновлять пользовательский интерфейс длякороткое время, что поток загружается.Я не понимаю, почему медленная загрузка файлов должна блокировать отзывчивость пользовательского интерфейса.Любая идея, почему это происходит или что я могу с этим поделать?

Answer 1

Хорошо, проблема решена.Похоже, передача AVURLAssetPreferPreciseDurationAndTimingKey в параметрах URLAssetWithURL: options: вызывает замедление.Это также происходит только тогда, когда к свойству duration AVURLAsset или некоторому другому свойству, связанному с синхронизацией потока, обращаются из селектора, запускаемого NSTimer.Так что, если вы можете избежать опроса информации о времени, эта проблема может не затронуть вас, но это не вариант для меня.Если точное время не запрашивается, задержка все равно составляет от 0,75 секунды до 1 секунды, но это все.

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

Так что теперь, без «точного времени и продолжительности», длительность ресурса постоянно равна 0,0,даже когда он полностью загружен.Я также могу ответить на мою первоначальную цель создания KVO на AVPlayerItem.isPlaybackBufferEmpty.Кажется, что KVO в любом случае будет бесполезным, поскольку свойство начинается с «НЕТ», меняется на «ДА», как только я запускаю воспроизведение, и продолжает оставаться «ДА», даже если мультимедиа воспроизводится несколько минут подряд.Документация говорит об этом свойстве:

Указывает, использовало ли воспроизведение все буферизованные носители и что воспроизведение будет остановлено или остановлено.

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