Введение

Потоки позволяют Вам решить две хитрых проблемы:

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

  Этот подход может быть полезным даже в одноядерной системе (как имеет место для всех текущих устройств на iOS). В частности, если Ваш поток вычисления тратит некоторую часть своего блокированного времени (например, ожидая диска I/O), можно использовать многократные потоки, чтобы сделать полезное вычисление на одном потоке, в то время как блокируется другой поток.

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

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

• периодическое выполнение — Запуск потока только для выполнения кода периодически никогда не является хорошей идеей. Необходимо использовать NSTimer вместо этого.

• объединяясь в сеть — На типичном устройстве на iOS, CPU намного быстрее, чем сеть так при запуске потока, чтобы сделать сети синхронно, тот поток проведет большую часть своего блокированного времени. Лучший подход должен использовать асинхронный сетевой APIs, предоставленный iOS.

Как только Вы решили, что является надлежащим решить Вашу проблему с потоками, необходимо выбрать полную структуру кода. Общий подход должен использовать API NSThread непосредственно, или возможно использовать в своих интересах Какао -performSelectorInBackground:withObject: метод. Однако, очень просто столкнуться с проблемами с ними механизм. Первый раздел этого technote (Потоки И Их проблемы) описывает некоторые из тех проблем, именно так можно получить ощущение того, почему настолько важно быть тщательным с потоками. Следующий раздел (NSOperation К Спасению!) описывает, как можно использовать NSOperation для рассмотрения тех проблем простым и надежным способом. Наконец, последний раздел (Полезные советы NSOperations) предлагает некоторые полезные советы для использования NSOperation эффективно.

Потоки и их проблемы

Предположите, что у Вас есть приложение, выводящее на экран список чисел с общим количеством наверху. Фактически, Вы не должны воображать это, можно просто смотреть на Пример кода 'ListAdder', в частности создававшийся для этого technote. Рисунок 1 показывает основной UI.

Такое приложение могло бы иметь класс контроллера представления со свойством, которое является списком чисел, представленных как непостоянный массив. Перечисление 1 показывает, как это могло бы быть объявлено.

Перечисление 1  объявление массива чисел

@interface ListAdderViewController () [...]  @property (nonatomic, retain, readonly ) NSMutableArray *   numbers;  [...]  @end

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

Перечисление 2  , Повторно вычисляющее на потоке

// ---- Broken Code ---- Do Not Use ---- Broken Code ---- Do Not Use ----

- (void)recalculateTotalUsingThread
{
    self.recalculating = YES;
    [self performSelectorInBackground:@selector(threadRecalculateNumbers) withObject:self.numbers];
}

- (void)threadRecalculateNumbers
{
    NSAutoreleasePool *     pool;
    NSInteger               total;
    NSUInteger              numberCount;
    NSUInteger              numberIndex;
    NSString *              totalStr;

    pool = [[NSAutoreleasePool alloc] init];
    assert(pool != nil);

    total = 0;
    numberCount = [self.numbers count];
    for (numberIndex = 0; numberIndex < numberCount; numberIndex++) {
        NSNumber *  numberObj;

        // Sleep for a while. This makes it easiest to test various problematic cases.

        [NSThread sleepForTimeInterval:1.0];

        // Do the mathematics.

        numberObj = [self.numbers objectAtIndex:numberIndex];
        assert([numberObj isKindOfClass:[NSNumber class]]);

        total += [numberObj integerValue];
    }

    // The user interface is adjusted by a KVO observer on recalculating.

    totalStr = [NSString stringWithFormat:@"%ld", (long) total];
    self.formattedTotal = totalStr;
    self.recalculating = NO;

    [pool drain];
}

// ---- Broken Code ---- Do Not Use ---- Broken Code ---- Do Not Use ----

Этот код имеет многочисленные проблемы. Первый довольно очевиден: конец -threadRecalculateNumbers применяет результаты к пользовательскому интерфейсу. При этом это заканчивает тем, что вызвало UIKit на вторичном потоке. Поэтому другие части программы используют наблюдение значения ключа (KVO) для наблюдения recalculating свойство и перезагрузка табличное представление соответственно. Если Вы изменяетесь recalculating на вторичном потоке этот код заканчивает тем, что вызвал UIKit на не позволяющемся вторичном потоке.

Решение той проблемы относительно просто. Перечисление 3 показывает замену для -threadRecalculateNumbers с фиксацией.

Перечисление 3  , Повторно вычисляющее на потоке, второй попытке

// ---- Broken Code ---- Do Not Use ---- Broken Code ---- Do Not Use ----

- (void)threadRecalculateNumbers
{
    NSAutoreleasePool *     pool;
    NSInteger               total;
    NSUInteger              numberCount;
    NSUInteger              numberIndex;
    NSString *              totalStr;

    pool = [[NSAutoreleasePool alloc] init];
    assert(pool != nil);

    total = 0;
    numberCount = [self.numbers count];
    for (numberIndex = 0; numberIndex < numberCount; numberIndex++) {
        NSNumber *  numberObj;

        // Sleep for a while. This makes it easiest to test various problematic cases.

        [NSThread sleepForTimeInterval:1.0];

        // Do the mathematics.

        numberObj = [self.numbers objectAtIndex:numberIndex];
        assert([numberObj isKindOfClass:[NSNumber class]]);

        total += [numberObj integerValue];
    }

    // Update the user interface on the main thread.

    totalStr = [NSString stringWithFormat:@"%ld", (long) total];
    [self performSelectorOnMainThread:@selector(threadRecalculateDone:) withObject:totalStr waitUntilDone:NO];

    [pool drain];
}

- (void)threadRecalculateDone:(NSString *)result
{
    // The user interface is adjusted by a KVO observer on recalculating.

    self.formattedTotal = result;
    self.recalculating = NO;
}

// ---- Broken Code ---- Do Not Use ---- Broken Code ---- Do Not Use ----

Так, мы сделаны, правильно? Неправильно! В то время как этот код решает упомянутую выше проблему, это все еще имеет другие проблемы. Одна такая проблема касается numbers свойство. Это - непостоянный массив, и код теперь получает доступ к массиву на одном потоке (вторичный поток), потенциально видоизменяя массив на другом (основной поток). Так, что происходит, если основной поток изменяется numbers выстройте, в то время как повторно вычисляет вторичный поток? Плохие вещи. Вообразите этот сценарий:

1. Пользователь добавляет элемент. Это запускает длинный перерасчет на потоке A.

2. Короткое время спустя перед потоком A завершается, пользователь тогда удаляет элемент. Это запускает другой длинный перерасчет на потоке B.

Теперь вспомните к основному циклу перерасчета. Для удобства это воспроизводится в Перечислении 4 со всем посторонним срезанным материалом.

Перечисление 4  разделенный вниз цикл перерасчета

NSUInteger              numberCount;
NSUInteger              numberIndex;

numberCount = [self.numbers count];
for (numberIndex = 0; numberIndex < numberCount; numberIndex++) {
    NSNumber *  numberObj;

    numberObj = [self.numbers objectAtIndex:numberIndex];
    total += [numberObj integerValue];
}

Как Вы видите, код сначала получает количество числа элементов в массиве, затем выполняет итерации по этому многих элементов. Если пользователь удаляет элемент из numbers массив после вторичного потока инициализировал numberCount, этот код в конечном счете получит доступ к элементу от конца массива и катастрофического отказа.

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

Перечисление 5  , Повторно вычисляющее на потоке, третьей попытке

// ---- Broken Code ---- Do Not Use ---- Broken Code ---- Do Not Use ----

- (void)recalculateTotalUsingThread
{
    NSArray *       immutableNumbers;

    self.recalculating = YES;

    immutableNumbers = [[self.numbers copy] autorelease];
    assert(immutableNumbers != nil);
    [self performSelectorInBackground:@selector(threadRecalculateNumbers:) withObject:immutableNumbers];
}

- (void)threadRecalculateNumbers:(NSArray *)immutableNumbers
{
    NSAutoreleasePool *     pool;
    NSInteger               total;
    NSUInteger              numberCount;
    NSUInteger              numberIndex;
    NSString *              totalStr;

    pool = [[NSAutoreleasePool alloc] init];
    assert(pool != nil);

    total = 0;
    numberCount = [immutableNumbers count];
    for (numberIndex = 0; numberIndex < numberCount; numberIndex++) {
        NSNumber *  numberObj;

        // Sleep for a while. This makes it easiest to test various problematic cases.

        [NSThread sleepForTimeInterval:1.0];

        // Do the mathematics.

        numberObj = [immutableNumbers objectAtIndex:numberIndex];
        assert([numberObj isKindOfClass:[NSNumber class]]);

        total += [numberObj integerValue];
    }

    totalStr = [NSString stringWithFormat:@"%ld", (long) total];
    [self performSelectorOnMainThread:@selector(threadRecalculateDone:) withObject:totalStr waitUntilDone:NO];

    [pool drain];
}

// ---- Broken Code ---- Do Not Use ---- Broken Code ---- Do Not Use ----

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

1. Пользователь добавляет набор элементов к списку. Это начинает перерасчет, занимающий много времени (потому что время вычисления пропорционально длине массива). Это вычисление работает на потоке A.

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

3. Поток B завершает и применяет свои результаты к пользовательскому интерфейсу. Пользовательский интерфейс теперь показывает корректное число.

4. Поток A завершает и применяет свои результаты к пользовательскому интерфейсу. Это оставляет пользовательский интерфейс, показывающий устаревшие результаты.

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

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

• ориентированное на многопотоковое исполнение освобождение — при выполнении какого-либо потокового кода в объектах UIKit (таких как контроллер представления) существует шанс что объект -dealloc метод вызовут на вторичном потоке. Это плохо (в смысле Охотников за привидениями того слова), особенно в чем-то как контроллер представления, где -dealloc метод обычно выпускает объекты UIView, и следовательно мог бы вызвать их -dealloc метод для работы вторичного потока. Можно узнать больше об этой проблеме и ее решениях в проблеме Освобождения.

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

NSOperation к спасению!

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

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

1. Инициализируйте работу с неизменной копией данных, это должно выполнить свою работу.

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

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

Используя отдельный NSOperation объект решает много проблем с общим потоковым кодом:

• можно хранить вспомогательные данные, связанные с работой как свойства объекта NSOperation

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

• объект NSOperation является дескриптором, которым можно отменить работу

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

NSOperation также имеет много других полезных функций:

• Каждая работа выполняется очередью работы (NSOperationQueue). У каждой очереди есть максимальное количество операций, которые она выполнит параллельно (maxConcurrentOperationCount), обычно известный как ширина очереди. Эти значения по умолчанию ширины к значению, это подходяще для устройства, на котором Вы работаете, но можно установить его в значение, это подходяще для задачи под рукой. Например, можно гарантировать, что операции сериализируются (выполняемый по одному) путем установки ширины очереди в 1. Или, если Ваши операции поражают сеть, можно использовать ширину очереди для ограничения числа параллельных сетевых операций.

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

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

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

Остальная часть этого раздела описывает, как Пример кода 'ListAdder' использует NSOperation для реализации асинхронного перерасчета.

@interface AdderOperation : NSOperation  - (id)initWithNumbers:(NSArray *)numbers;  // only meaningful after the operation is finished  @property (copy,   readonly ) NSString * formattedTotal;  @end

- (id)initWithNumbers:(NSArray *)numbers
{
    assert(numbers != nil);
    self = [super init];
    if (self != nil) {
        self->_numbers = [numbers copy];
        assert(self->_numbers != nil);
    }
    return self;
}

- (void)main
{
    NSUInteger      numberCount;
    NSUInteger      numberIndex;
    NSInteger       total;

    // This method is called by a thread that's set up for us by the NSOperationQueue.

    assert( ! [NSThread isMainThread] );

    // Do the heavy lifting (-:

    total = 0;
    numberCount = [self.numbers count];
    for (numberIndex = 0; numberIndex < numberCount; numberIndex++) {
        NSNumber *  numberObj;

        // Check for cancellation.

        if ([self isCancelled]) {
            break;
        }

        // Sleep for a second. This makes it easiest to test cancellation 
        // and so on.

        [NSThread sleepForTimeInterval:1.0];

        // Do the mathematics.

        numberObj = [self.numbers objectAtIndex:numberIndex];
        assert([numberObj isKindOfClass:[NSNumber class]]);

        total += [numberObj integerValue];
    }

    // Set our output properties base on the value we calculated. Our client 
    // shouldn't look at these until -isFinished goes to YES (which happens when 
    // we return from this method).

    self.formattedTotal = [self.formatter stringFromNumber:[NSNumber numberWithInteger:total]];
}

@interface ListAdderViewController () [...]

@property (nonatomic, retain, readonly ) NSOperationQueue * queue;
@property (nonatomic, retain, readwrite) AdderOperation *   inProgressAdder;

[...]

@end

@implementation ListAdderViewController

[...]

- (id)init
{
    self = [super initWithStyle:UITableViewStyleGrouped];
    if (self != nil) {
        [...] 

        self->_queue = [[NSOperationQueue alloc] init];
        assert(self->_queue != nil);

        [...] 
    }
    return self;
}

[...]

@end

- (void)recalculateTotalUsingOperation
{
    // If we're already calculating, cancel that operation.

    if (self.inProgressAdder != nil) {
        [self.inProgressAdder cancel];
    }

    // Start up a replacement operation.

    self.inProgressAdder = [[[AdderOperation alloc] initWithNumbers:self.numbers] autorelease];
    assert(self.inProgressAdder != nil);

    [self.inProgressAdder addObserver:self 
        forKeyPath:@"isFinished" 
        options:0 
        context:&self->_formattedTotal
    ];

    [self.queue addOperation:self.inProgressAdder];

    // The user interface is adjusted by a KVO observer on recalculating.

    self.recalculating = YES;
}

- (void)observeValueForKeyPath:(NSString *)keyPath 
    ofObject:(id)object 
    change:(NSDictionary *)change 
    context:(void *)context
{
    if (context == &self->_formattedTotal) {
        AdderOperation *    op;

        // If the operation has finished, call -adderOperationDone: on the main thread to deal 
        // with the results.

        // can be running on any thread
        assert([keyPath isEqual:@"isFinished"]);
        op = (AdderOperation *) object;
        assert([op isKindOfClass:[AdderOperation class]]);
        assert([op isFinished]);

        [self performSelectorOnMainThread:@selector(adderOperationDone:)
            withObject:op 
            waitUntilDone:NO
        ];
    } [...]
}

- (void)adderOperationDone:(AdderOperation *)op
{
    assert([NSThread isMainThread]);

    assert(self.recalculating);

    // Always remove our observer, regardless of whether we care about 
    // the results of this operation.

    [op removeObserver:self forKeyPath:@"isFinished"];

    // Check to see whether these are the results we're looking for. 
    // If not, we just discard the results; later on we'll be notified 
    // of the latest add operation completing.

    if (op == self.inProgressAdder) {
        assert( ! [op isCancelled] );

        // Commit the value to our model.

        self.formattedTotal = op.formattedTotal;

        // Clear out our record of the operation. The user interface is adjusted 
        // by a KVO observer on recalculating.

        self.inProgressAdder = nil;
        self.recalculating = NO;
    }
}

if (op == self.inProgressAdder) {     [... do something with inProgressAdder ...]     self.inProgressAdder = nil; }

@interface AdderOperation : NSOperation
{
    [... instance variables elided ...]
}

- (id)initWithNumbers:(NSArray *)numbers;

// set up by the init method that can't be changed

@property (copy,   readonly ) NSArray *         numbers;
@property (assign, readonly ) NSUInteger        sequenceNumber;

// must be configured before the operation is started

@property (assign, readwrite) NSTimeInterval    interNumberDelay;

// only meaningful after the operation is finished

@property (assign, readonly ) NSInteger         total;
@property (copy,   readonly ) NSString *        formattedTotal;

@end

@interface AdderOperation ()

// only accessed by the operation thread

@property (retain, readwrite) NSNumberFormatter *   formatter;

// read/write versions of public properties

@property (assign, readwrite) NSInteger             total;
@property (copy,   readwrite) NSString *            formattedTotal;

@end

Полезные советы NSOperations

Этот раздел содержит набор общих полезных советов для использования NSOperation.

- (IBAction)buttonAction:(id)sender
{
    #pragma unused(sender)
    [self performSelectorInBackground:@selector(recalculate) withObject:nil];
}

- (void)recalculate
{
    while ( ! self.cancelled ) {
        [... calculate ...]
    }
}

- (void)viewWillDisappear:(BOOL)animated
{
    [super viewWillDisappear:animated];
    self.cancelled = YES;
    // race starts here
}