Поток убивается ОС - PullRequest
       1

Поток убивается ОС

6 голосов
/ 08 ноября 2011

В настоящее время я программирую приложение, которое извлекает кадры из фрагмента ролика. Я разработал его так, чтобы извлечение выполнялось в отдельном потоке, чтобы предотвратить зависание приложения. Сам процесс извлечения занимает много ресурсов, но отлично работает при использовании в симуляторе. Тем не менее, есть проблемы при создании его для iPad. Когда я выполняю другое действие (я говорю, чтобы мой AV-проигрыватель проигрывал, пока я извлекаю кадры), поток неожиданно перестает работать, и я считаю, что его убивают.

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

Вот мои вопросы: 1. Как я могу определить, почему / почему моя нить остановилась? 2. Если это действительно из-за чрезмерной обработки, что мне делать? Мне действительно нужно, чтобы это действие было реализовано.

Вот какой-то код, который я использую: Чтобы создать тему:

[NSThread detachNewThreadSelector:@selector(startReading) toTarget:self withObject:nil];

Я выложу любую необходимую вам информацию, Большое спасибо!

Обновление Я использую GCD сейчас, и он заполняет темы для меня. Однако ОС все еще убивает потоки.

Я точно знаю, когда это происходит. когда я рассказываю свою [AVplayer play]; это убивает нить.

Эта проблема возникает только на реальном iPad, а не на симуляторе

Ответы [ 3 ]

1 голос
/ 19 ноября 2011

Мне кажется, что вы пытаетесь декодировать два видеоклипа одновременно. Из-за аппаратного характера декодирования iPad, он может поддерживать только один процесс декодирования за раз. Когда вы играете новый предмет, старый будет отменен. Это объясняет, почему он работает в симуляторе, а не на устройстве.

Что касается решения, вы можете переключиться на чистый программный декодер, такой как libav (GPL) или CoreAVC SDK (коммерческий). Таким образом, вы не будете мешать HW-декодеру для воспроизведения.

0 голосов
/ 18 ноября 2011

В разделе «Установка размера стека потока» в Руководстве по программированию потоков Apple, стр. 27 написано:

В iOS и Mac OS X v10.5 и более поздних версиях выделите и инициализируйте NSThread объект (не используйте detachNewThreadSelector: toTarget: withObject: метод)

Несмотря на то, что на странице 22 говорится, что detachNewThreadSelector - это один из способов создания потоков с использованием NSThread.

И на странице 23 приведен пример того, как запустить ваш поток:

NSThread* myThread = [[NSThread alloc] initWithTarget:self selector:@selector(myThreadMainMethod:) object:nil];
[myThread start];

Согласно руководству, которое создаст отдельный поток в вашем приложении. Попробуйте создать свою ветку таким образом и посмотрите, перестанет ли ОС прерывать вашу ветку.

Для справки вот ссылка на руководство

http://developer.apple.com/library/ios/iPad/#documentation/Cocoa/Conceptual/Multithreading/CreatingThreads/CreatingThreads.html#//apple_ref/doc/uid/10000057i-CH15-SW2

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

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

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

Избегайте общих структур данных

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

Что, я думаю, вы можете сделать это в своем приложении. В дополнение к выполнению того, что упомянул Дункан, «не предоставляйте ресурсы непосредственно объекту AVPlayer, а вместо этого предоставьте экземпляр AVPlayerItem», создавайте отдельные экземпляры для каждого из ваших потоков, один экземпляр AVPlayerItem для потока проигрывателя и один экземпляр AVPlayerItem для вытяжная нить.

0 голосов
/ 13 ноября 2011

Когда что-то работает в симуляторе и не работает на устройстве, одно очевидное объяснение - это проблема ограничения ресурсов. Но иногда симулятор не может точно симулировать и другие аспекты функционирования устройства. Поэтому я задавался вопросом, может ли быть какая-либо другая интерпретация ситуации. Одна возможность пришла мне в голову, что это может быть конкуренция за ограниченный актив - доступ к AV-активу - это означает, что когда вы начинаете играть на нем, он больше не доступен для обработки (и по какой-то причине ошибка в симуляторе не отображает это ограничение.)

В Руководстве по программированию AV Foundation в разделе «Воспроизведение активов» Apple заявляет:

Хотя в конечном итоге вы хотите воспроизвести актив, вы не предоставляете ресурсы непосредственно объекту AVPlayer. Вместо этого вы предоставляете экземпляр AVPlayerItem. Элемент проигрывателя управляет состоянием представления актива, с которым он связан. Элемент проигрывателя содержит дорожки элементов проигрывателя - экземпляры AVPlayerItemTrack - которые соответствуют дорожкам в активе.

Эта абстракция означает, что вы можете играть на данном активе, используя разных игроков одновременно, но каждый игрок по-разному воспроизводит их. Используя дорожки элементов, вы можете, например, отключить определенную дорожку во время воспроизведения (возможно, вы не захотите воспроизводить звуковой компонент).

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

Может хвататься за соломинку. Но может привести куда-нибудь.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...