каковы разные способы вызова моего метода в отдельном потоке?

<p>у меня есть какой-то метод расчета данных (пусть это будет «mymethod:»), и я хочу переместить вызов в другой поток, потому что я не хочу блокировать основные функции пользовательского интерфейса. итак, начал делать некоторые исследования о том, как вызвать мой метод в другом потоке. насколько я вижу, в настоящее время есть много разных способов сделать это. вот список:</p><p>а) с использованием чистых потоков (доступно с ios 2.0): </p><pre><code>[nsthread detachnewthreadselector:@selector(mymethod:) totarget:self withobject:\_myparamsarray]; </code></pre><p>б) с помощью простого ярлыка (доступно с ios 2.0). доступно из унаследованного nsobject, но метод также принадлежит классу nsthread:</p><pre><code>[self performselectorinbackground:@selector(mymethod:) withobject:\_myparamsarray]; </code></pre><p>c) использование нового подхода к очередям grand central dispatch (доступно с ios 4.0):</p><pre><code>dispatch\_async(dispatch\_get\_global\_queue(0, 0), ^ { [self mymethod:\_myparamsarray]; }); </code></pre><p>d) каким-то образом, используя некоторые классы, такие как nsoperation, nsblockoperation или nsoperationqueue, хотя и не уверен, как именно это сделать (некоторый пример приветствуется) </p><p>в настоящее время я использовал случай "b", но мне было интересно узнать о плюсах и минусах и других связанных с этим предложениях. </p><p>обновление: e) также найден другой способ выполнения подобных вещей с потоками - <a href="https://developer.apple.com/library/mac/#documentation/cocoa/conceptual/multithreading/runloopmanagement/runloopmanagement.html#//apple\_ref/doc/uid/10000057i-ch16-sw1">выполнить циклы</a> . вот выдержка из документов apple:</p><blockquote> <p>цикл выполнения - это цикл обработки событий, который используется для планирования работы и координации приема входящих событий. цель цикла выполнения состоит в том, чтобы сохранить ваш поток занятым, когда есть работа, и перевести ваш поток в спящий режим, когда его нет.</p> </blockquote><p>имхо, более или менее вы имеете дело с одной и той же задачей - как вызвать ваш метод в отдельном потоке для его асинхронной операции. </p><p>обновление 2: уже был некоторый опыт работы с nsinvocationoperation и nsoperationqueue, и имхо, это довольно удобно. согласно документам apple, gcd и nsoperations являются предпочтительным способом реализации многопоточности. а также, nsoperations работает на gcd, начиная с ios 4.0. короче говоря, вы создаете экземпляр nsivocationoperation (как вызов вашего метода), затем создаете экземпляр nsoperationqueue и добавляете вызов в очередь. nsoperationqueue достаточно умен, вы можете создать несколько объектов nsivocationoperation (обернуть ваши вызовы методов) и их в nsoperationqueue. в остальном уверен. nsoperationqueue определяет, сколько параллельных потоков необходимо для выполнения вызовов (nsinvocationoperation), и обрабатывает его для вас. он может выполнить первый вызов в потоке a, затем второй в потоке b, третий в потоке c и далее в потоке b, так что вам не нужно об этом беспокоиться. но если вы хотите, вы можете сказать, как максимальные потоки nsoperationqueue может использовать для выполнения вызовов (например, 1), но мне это не нужно. по умолчанию все задачи выполняются не в главном потоке, поэтому очереди операций по умолчанию асинхронны. кроме того, если вы хотите выполнять вызовы методов (каждый из которых заключен в отдельный nsinvocationoperation) в строгой очереди, вы можете добавить зависимости и, таким образом, nsoperationqueue сохранит порядок вызова метода. вот пример:</p><pre><code>// wrap your method call into nsinvocationoperation object nsinvocationoperation *currentoperation = [[nsinvocationoperation alloc] initwithtarget:self selector:@selector(yourmethodcall) object:nil]; // \_sharedoperationqueue is a shared nsoperationqueue // get all executing operations from the queue and get the last operation \_lastoperation = [[\_sharedoperationqueue operations] lastobject]; // check if \_lastoperation is not nil if (\_lastoperation) { // if not then add dependency, so the calls would be performed in a queue [currentoperation adddependency:\_lastoperation]; } // say - execute my method (operation) [\_sharedoperationqueue addoperation:currentoperation]; \_lastoperation = currentoperation; // mark as last operation for adding dependency to the next operation // the queue will retain invocation operation so you will release [currentoperation release]; ..... you can create another nsinvocationoperation and add it to the queue.... </code></pre><p>что касается runloop, тем не менее иногда вы сталкиваетесь с ними, например, при запуске/планировании таймера или при установлении соединений nsurl. имхо, цикл выполнения можно сравнить с очередью задач, выполняемых в одном потоке. imho, runloop - это указатель на поток, который работает как очередь: у него есть задачи, которые могут генерировать события, и они будут помещены в конец очереди в этом потоке. по умолчанию все задачи в вашем приложении выполняются в одном цикле выполнения - в одном потоке. я говорю, что это указатель, потому что, когда ваше приложение генерирует события, тогда приложение должно знать, куда поместить это событие (сенсорное событие или обратный вызов другого делегата) для выполнения. конечно, вы должны прочитать о runloops для более подробной информации, потому что это только мои мысли.</p>

<p>обычно вы предпочитаете подход gcd.</p><p>это проще, когда речь идет о синхронизации/блокировке, чем чистые потоки (nsthread - pthread), и это может быть более точным с точки зрения производительности.</p><p>при использовании чистых потоков проблема заключается в том, что у вас могут быть проблемы с производительностью, в зависимости от количества доступных ядер/процессоров.</p><p>например, если у вас только одно ядро, создание множества потоков может замедлить работу вашего приложения, поскольку центральный процессор будет тратить большую часть своего времени на переключение с одного потока на другой, сохранение стека, регистров и т.д.</p><p>с другой стороны, если у вас есть много доступных ядер, может быть неплохо создать много разных потоков.</p><p>вот где gcd помогает, так как он управляет этим для вас. он создаст соответствующее количество потоков на основе доступных системных ресурсов, чтобы гарантировать оптимальное использование и соответствующим образом запланировать ваши действия.</p><p>однако по этой причине задачи, запускаемые с помощью gcd, могут не выполняться в режиме реального времени.</p><p>поэтому, если вам действительно нужно, чтобы отдельная задача выполнялась немедленно, используйте явные потоки. в противном случае используйте gcd.</p><p>надеюсь, что это поможет вам : )</p><p><strong>правка</strong></p><p>примечание о <code>performselectorinbackground</code>: он просто создает новый поток. так что в принципе нет разницы с подходом nsthread.</p><p><strong>правка 2</strong></p><p>nsoperation связанные вещи немного по-другому. в mac os x они реализованы с использованием gcd начиная с версии 10.6. предыдущие версии используют темы.</p><p>на ios они реализованы только с использованием потоков.</p><p><strong>ссылка</strong></p><p>все это очень хорошо объяснено в <a href="http://developer.apple.com/library/mac/#documentation/general/conceptual/concurrencyprogrammingguide/introduction/introduction.html#//apple\_ref/doc/uid/tp40008091">руководстве по программированию параллелизма</a> . в нем рассматриваются gcd и потоковые подходы, с большим количеством деталей об использовании и реализациях.</p><p>если вы еще не прочитали это, вы должны посмотреть.</p>

<p>вот обновленный ответ на этот старый вопрос. операции nso теперь реализованы с помощью libdispatch для mac и ios. они были в течение некоторого времени. предпочтительным способом вызова другого потока является один из libdispatch или nsoperations. основная идея, которую нужно иметь в виду, это «качество обслуживания» или «qos». qos - это что-то, назначенное потоку, и когда вы назначаете его в очередь отправки и nsoperationqueue или nsoperation, вы, по сути, говорите: «я хочу, чтобы это выполнялось в потоке с назначенным qos». особый случай - основная нить.</p><p>могут быть случаи использования nsthread, но у меня их давно не было.</p>