Постановка задачи

Необходимо иметь возможность писать собственные блоковые объекты либо использовать блоковые объекты с классами из iOS SDK.

 

Решение

Просто необходимо понимать базовую разницу между синтаксисом блоковых объектов и синтаксисом классических функций языка C. Эта разница рассматривается в подразделе «Обсуждение» данного раздела.

 

Обсуждение

Блоковые объекты могут быть либо встраиваемыми, либо записываемыми как отдельные блоки кода. Начнем с объектов второго типа. Предположим, у нас есть метод языка Objective-C, принимающий два целочисленных значения типа NSInteger и возвращающий разницу двух этих значений в форме NSInteger. Разница получается в результате вычитания одного значения из другого:

— (NSInteger) subtract:(NSInteger)paramValue

from:(NSInteger)paramFrom{

return paramFrom — paramValue;

}

Очень просто, правда? Теперь преобразуем этот код Objective-C в классическую функцию языка C, обеспечивающую такую же функциональность. Это еще на шаг приблизит нас к пониманию синтаксиса блоковых объектов:

NSInteger subtract(NSInteger paramValue, NSInteger paramFrom){

return paramFrom — paramValue;

}

Как видите, синтаксис функции на C значительно отличается от синтаксиса аналогичной функции на языке Objective-C. Теперь рассмотрим, как можно написать ту же функцию в виде блокового объекта:

NSInteger (^subtract)(NSInteger, NSInteger) =

^(NSInteger paramValue, NSInteger paramFrom){

return paramFrom — paramValue;

};

Прежде чем перейти к детальному описанию синтаксиса блоковых объектов, приведу еще несколько примеров. Предположим, что у нас есть функция на языке C, принимающая параметр типа NSUInteger (беззнаковое целое число) и возвращающая строку типа NSString. Вот как данная функция реализуется на C:

NSString* intToString (NSUInteger paramInteger){

return [NSString stringWithFormat:@"%lu",

(unsigned long)paramInteger];

}

Чтобы научиться форматировать строки с применением системонезависимых указателей формата на языке Objective-C, ознакомьтесь с String Programming Guide in the iOS Developer Library (Руководство по программированию строк в библиотеке разработчика iOS). Адрес документа на сайте Apple: https://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/Strings/Articles/formatSpecifiers.html .

Блоковый объект, эквивалентный данной функции языка C, показан в примере 7.1.

Пример 7.1. Образец блокового объекта, определенного в виде функции

NSString* (^intToString)(NSUInteger) = ^(NSUInteger paramInteger){

NSString *result = [NSString stringWithFormat:@"%lu",

(unsigned long)paramInteger];

return result;

};

Простейший независимый блоковый объект — это блоковый объект, возвращающий void и не принимающий никаких параметров:

void (^simpleBlock)(void) = ^{

/* Здесь реализуется блоковый объект. */

};

Блоковые объекты инициируются точно так же, как и функции на языке C. Если у них есть какие-либо параметры, то вы передаете их так, как и в функции C. Любое возвращаемое значение можно получить точно так же, как и возвращаемое значение функции на языке C. Вот пример:

NSString* (^intToString)(NSUInteger) = ^(NSUInteger paramInteger){

NSString *result = [NSString stringWithFormat:@"%lu",

(unsigned long)paramInteger];

return result;

};

— (void) callIntToString{

NSString *string = intToString(10);

NSLog(@"string = %@", string);

}

Метод callIntToString языка Objective-C вызывает блоковый объект intToString, передавая этому блоковому объекту в качестве единственного параметра значение 10 и помещая возвращаемое значение данного блокового объекта в локальную переменную string.

Теперь, когда мы знаем, как писать блоковые объекты в виде независимых блоков кода, рассмотрим передачу блоковых объектов как передачу параметров методам языка Objective-C. Чтобы понять смысл следующего примера, нужно прибегнуть к определенным абстракциям.

Предположим, у нас есть метод Objective-C, принимающий целое число и выполняющий над ним какое-либо преобразование. Такое преобразование может меняться в зависимости от того, что еще происходит в программе. Мы уже знаем, что у нас будет целое число в качестве ввода и строка в качестве вывода, но сам процесс преобразования поручим блоковому объекту — а этот объект может быть иным при каждом вызове метода. Следовательно, в качестве параметров данный метод будет принимать и целое число, которое необходимо преобразовать, и тот блок, который будет выполнять преобразование.

Для блокового объекта воспользуемся тем же блоковым объектом intToString, который мы реализовали в примере 7.1. Теперь нам нужен метод на языке Objective-C, который будет принимать в качестве параметра беззнаковое целое число, а в качестве еще одного параметра — блоковый объект. С беззнаковым целым в качестве параметра все просто, но как сообщить методу, что он должен принимать блоковый объект того же типа, к которому относится блоковый объект intToString? Сначала определяем псевдоним сигнатуры блокового объекта intToString (с помощью ключевого слова typedef) и таким образом сообщаем компилятору, какие параметры должен принимать блоковый объект:

typedef NSString* (^IntToStringConverter)(NSUInteger paramInteger);

Объявление typedef просто сообщает компилятору, что блоковые объекты, принимающие в качестве параметра целое число и возвращающие строку, можно представлять с помощью обычного идентификатора, называемого IntToStringConverter. Итак, пойдем дальше и напишем метод на Objective-C, который будет принимать в качестве параметров и целое число, и блоковый объект типа IntToStringConverter:

— (NSString *) convertIntToString-NSUInteger)paramInteger

usingBlockObject-IntToStringConverter)paramBlockObject{

return paramBlockObject(paramInteger);

}

Теперь требуется просто вызвать метод convertIntToString:, сопровождаемый объектом на наш выбор (пример 7.2).

Пример 7.2. Вызов блокового объекта в другом методе

— (void) doTheConversion{

NSString *result = [self convertIntToString:123

usingBlockObject: intToString];

NSLog(@"result = %@", result);

}

Теперь, когда мы немного разбираемся в независимых блоковых объектах, поговорим о встраиваемых блоковых объектах. В только что рассмотренном методе doTheConversion мы передавали методу convertIntToString: usingBlockObject: в качестве параметра блоковый объект intToString. Что если бы у нас не было в распоряжении готового блокового объекта, который можно было бы передать этому методу? На самом деле это не доставило бы нам никаких проблем. Как уже упоминалось, блоковые объекты — это функции первого класса и их можно создавать во время исполнения. Рассмотрим альтернативную реализацию метода doTheConversion (пример 7.3).

Пример 7.3. Блоковый объект, определенный в виде функции

— (void) doTheConversion{

IntToStringConverter inlineConverter = ^(NSUInteger paramInteger){

NSString *result = [NSString stringWithFormat:@"%lu",

(unsigned long)paramInteger];

return result;

};

NSString *result = [self convertIntToString:123

usingBlockObject: inlineConverter];

NSLog(@"result = %@", result);

}

Сравните примеры 7.1 и 7.3. Я удалил имевшийся в первом варианте код, в котором мы формировали сигнатуру блокового объекта. Данная сигнатура состояла из имени и аргумента — (^intToString) (NSUInteger). Остальную часть блокового объекта я не трогаю, и теперь он становится анонимным объектом. Но это не означает, что я никак не могу сослаться на блоковый объект. С помощью знака равенства (=) я присваиваю блоковый объект типу и имени: IntToStringConverter inlineConverter. Теперь я могу воспользоваться типом данных, чтобы стимулировать правильную работу методов, а при самой операции передачи блокового объекта использовать его имя.

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

— (void) doTheConversion{

NSString *result =

[self convertIntToString:123

usingBlockObject: ^NSString *(NSUInteger paramInteger) {

NSString *result = [NSString stringWithFormat:@"%lu",

(unsigned long)paramInteger];

return result;

}];

NSLog(@"result = %@", result);

}

Сравните этот пример с примером 7.2. Оба метода используют блоковый объект с применением синтаксиса usingBlockObject. Но, в то время как при применении первого варианта мы ссылались по имени на предварительно определенный блоковый объект (intToString), во втором варианте блоковый объект создается на лету. В этом коде мы создали встраиваемый блоковый объект, который передается методу convertIntToString: usingBlockObject: как второй параметр.

 

Постановка задачи

Необходимо понять разницу между доступом к переменным в методах Objective-C и доступом к этим переменным в блоковых объектах.

 

Решение

Вот краткое обобщение того, что необходимо знать о переменных в блоковых объектах.

Локальные переменные в блоковых объектах работают точно так же, как и в методах Objective-C.

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

• Нельзя ссылаться на self в независимых блоковых объектах, реализованных в классе Objective-C. Если необходим доступ к self, то вам нужно передать его объект блоковому объекту в качестве параметра. Чуть позже рассмотрим на примере и такую ситуацию.

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

• При работе со встраиваемыми блоковыми объектами локальные переменные, определяемые внутри реализации блокового объекта, доступны для считывания, но не для записи. Однако есть и исключение. Блоковый объект может записывать информацию в такие переменные, если они определены с типом хранения __block. Пример мы также рассмотрим.

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

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

 

Обсуждение

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

void (^independentBlockObject)(void) = ^(void){

NSInteger localInteger = 10;

NSLog(@"local integer = %ld", (long)localInteger);

localInteger = 20;

NSLog(@"local integer = %ld", (long)localInteger);

};

При активизации этого блокового объекта те значения, которые мы присваиваем, выводятся в окне консоли:

local integer = 10

local integer = 20

Пока все несложно. Теперь рассмотрим встраиваемые блоковые объекты и переменные, которые являются для них локальными:

— (void) simpleMethod{

NSUInteger outsideVariable = 10;

NSMutableArray *array = [[NSMutableArray alloc]

initWithObjects:@"obj1",

@"obj2", nil];

[array sortUsingComparator: ^NSComparisonResult(id obj1, id obj2) {

NSUInteger insideVariable = 20;

NSLog(@"Outside variable = %lu", (unsigned long)outsideVariable);

NSLog(@"Inside variable = %lu", (unsigned long)insideVariable);

/* Возвращаем значение для блокового объекта. */

return NSOrderedSame;

}];

}

Метод экземпляра sortUsingComparator:, относящийся к классу NSMutableArray, пытается сортировать изменяемый массив. Цель кода, приведенного в данном примере, — просто продемонстрировать использование локальных переменных. Можно и не задаваться тем, что именно делает этот метод.

Блоковый объект может считывать информацию и записывать данные в собственную локальную переменную insideVariable. При этом по умолчанию блоковый объект имеет доступ только для чтения к переменной outsideVariable. Чтобы блоковый объект мог записывать информацию в outsideVariable, нужно поставить перед outsideVariable префикс __block, указывающий соответствующий тип хранения:

— (void) simpleMethod{

__block NSUInteger outsideVariable = 10;

NSMutableArray *array = [[NSMutableArray alloc]

initWithObjects:@"obj1",

@"obj2", nil];

[array sortUsingComparator: ^NSComparisonResult(id obj1, id obj2) {

NSUInteger insideVariable = 20;

outsideVariable = 30;

NSLog(@"Outside variable = %lu", (unsigned long)outsideVariable);

NSLog(@"Inside variable = %lu", (unsigned long)insideVariable);

/* Возвращаем значение для блокового объекта. */

return NSOrderedSame;

}];

}

Доступ к self во встраиваемых блоковых объектах не вызывает никаких проблем, пока self определяется в лексической области видимости, внутри которой создается встраиваемый блоковый объект. Например, в данной ситуации блоковый объект сможет получить доступ к self, поскольку метод simpleMethod является методом экземпляра класса языка Objective-C:

— (void) simpleMethod{

NSMutableArray *array = [[NSMutableArray alloc]

initWithObjects:@"obj1",

@"obj2", nil];

[array sortUsingComparator: ^NSComparisonResult(id obj1, id obj2) {

NSLog(@"self = %@", self);

/* Возвращаем значение для блокового объекта. */

return NSOrderedSame;

}];

}

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

void (^incorrectBlockObject)(void) = ^{

NSLog(@"self = %@", self); /* self здесь не определен. */

};

Если вы хотите получить доступ к self в независимом блоковом объекте, просто передайте объект, представляемый self, вашему блоковому объекту в качестве параметра:

void (^correctBlockObject)(id) = ^(id self){

NSLog(@"self = %@", self);

};

— (void) callCorrectBlockObject{

correctBlockObject(self);

}

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

Рассмотрим объявленные свойства и посмотрим, как блоковые объекты могут получать к ним доступ. При работе со встраиваемыми блоковыми объектами можно применять точечную нотацию — она позволяет считывать информацию из объявленных свойств self или записывать в них данные. Допустим, например, что у нас в классе есть объявленное свойство типа NSString, которое называется stringProperty:

#import «AppDelegate.h»

@interface AppDelegate()

@property (nonatomic, copy) NSString *stringProperty;

@end

@implementation AppDelegate

Теперь не составляет труда получить доступ к этому свойству во встраиваемом блоковом объекте:

— (void) simpleMethod{

NSMutableArray *array = [[NSMutableArray alloc]

initWithObjects:@"obj1",

@"obj2", nil];

[array sortUsingComparator: ^NSComparisonResult(id obj1, id obj2) {

NSLog(@"self = %@", self);

self.stringProperty = @"Block Objects";

NSLog(@"String property = %@", self.stringProperty);

/* Возвращаем значение для блокового объекта. */

return NSOrderedSame;

}];

}

Но в независимом блоковом объекте нельзя использовать точечную нотацию для считывания объявленного свойства или записи информации в это свойство:

void (^correctBlockObject)(id) = ^(id self){

NSLog(@"self = %@", self);

/* Вместо этого используем метод-установщик */

self.stringProperty = @"Block Objects"; /* Ошибка времени компиляции */

/* Вместо этого используем метод-получатель. */

NSLog(@"self.stringProperty = %@",

self.stringProperty); /* Ошибка времени компиляции */

};

В данном сценарии будем пользоваться методом-установщиком и методом-получателем синтезированного свойства:

void (^correctBlockObject)(id) = ^(id self){

NSLog(@"self = %@", self);

/* Это будет работать нормально. */

[self setStringProperty:@"Block Objects"];

/* Это также будет работать нормально. */

NSLog(@"self.stringProperty = %@",

[self stringProperty]);

};

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

typedef void (^BlockWithNoParams)(void);

— (void) scopeTest{

NSUInteger integerValue = 10;

BlockWithNoParams myBlock = ^{

NSLog(@"Integer value inside the block = %lu",

(unsigned long)integerValue);

};

integerValue = 20;

/* Вызываем блок здесь после изменения

значения переменной integerValue. */

myBlock();

NSLog(@"Integer value outside the block = %lu",

(unsigned long)integerValue);

}

Мы определяем целочисленную локальную переменную и сначала присваиваем ей значение 10. Затем реализуем блоковый объект, но пока не вызываем его. После того как блоковый объект реализован, мы просто изменяем значение локальной переменной, которую затем (после того как мы его вызовем) попытается считать блоковый объект. Сразу после изменения значения локальной переменной на 20 вызываем блоковый объект. Логично предположить, что блоковый объект выведет для переменной на консоль значение 20, но этого не произойдет. Он выведет значение 10, как показано здесь:

Integer value inside the block = 10

Integer value outside the block = 20

Вот что здесь происходит. Блоковый объект сохраняет для себя копию переменной integerValue, доступную только для чтения, и делает это именно там, где реализуется блок. Напрашивается вопрос: почему же блоковый объект принимает доступное только для чтения значение переменной integerValue? Ответ прост, и мы уже дали его в этом разделе. Если у локальной переменной нет префикса __block, означающего соответствующий тип хранения, локальные переменные в лексической области видимости блокового объекта просто передаются блоковому объекту как переменные, доступные только для чтения. Следовательно, чтобы изменить это поведение, мы могли бы изменить реализацию метода scopeTest и сопроводить переменную integerValue префиксом __block, указывающим тип хранения. Это делается так:

— (void) scopeTest{

__block NSUInteger integerValue = 10;

BlockWithNoParams myBlock = ^{

NSLog(@"Integer value inside the block = %lu",

(unsigned long)integerValue);

};

integerValue = 20;

/* Вызываем блок здесь после изменения

значения переменной integerValue. */

myBlock();

NSLog(@"Integer value outside the block = %lu",

(unsigned long)integerValue);

}

Теперь, если вывести на консоль результаты после вызова метода scopeTest, мы увидим следующее:

Integer value inside the block = 20

Integer value outside the block = 20

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

 

Постановка задачи

Вы научились создавать блоковые объекты, а теперь требуется их исполнять и получать определенные результаты.

 

Решение

Исполняйте ваши блоковые объекты так же, как и функции на языке C. Подробнее об этом — в подразделе «Обсуждение».

 

Обсуждение

В разделах 7.1 и 7.2 вы видели примеры вызова блоковых объектов. В данном разделе приводятся более конкретные примеры.

Если у вас есть независимый блоковый объект, его можно вызвать так же, как мы вызывали бы функцию на языке C:

void (^simpleBlock)(NSString *) = ^(NSString *paramString){

/* Реализуем блоковый объект и используем параметр paramString. */

};

— (void) callSimpleBlock{

simpleBlock(@"O'Reilly");

}

Если вы хотите вызвать независимый блоковый объект внутри другого независимого блокового объекта, действуйте так же, как при активизации метода на языке C:

NSString *(^trimString)(NSString *) = ^(NSString *inputString){

NSString *result = [inputString stringByTrimmingCharactersInSet:

[NSCharacterSet whitespaceCharacterSet]];

return result;

};

NSString *(^trimWithOtherBlock)(NSString *) = ^(NSString *inputString){

return trimString(inputString);

};

— (void) callTrimBlock{

NSString *trimmedString = trimWithOtherBlock(@" O'Reilly ");

NSLog(@"Trimmed string = %@", trimmedString);

}

Продолжим данный пример и вызовем метод callTrimBlock на языке Objective-C:

[self callTrimBlock];

Метод callTrimBlock вызовет блоковый объект trimWithOtherBlock, а этот объект вызовет блоковый объект trimString, чтобы обрезать указанную строку. Отсечение строки — простая операция, для ее выполнения требуется всего одна строка кода. Но этот пример демонстрирует, как можно вызывать блоковые объекты внутри блоковых объектов.

 

См. также

Разделы 7.1 и 7.2.

 

Постановка задачи

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

 

Решение

Воспользуйтесь функцией dispatch_get_main_queue.

 

Обсуждение

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

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

 функция dispatch_async выполняет блоковый объект применительно к диспетчерской очереди;

 функция dispatch_async_f выполняет функцию C применительно к диспетчерской очереди.

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

Рассмотрим использование функции dispatch_async, которая принимает два параметра:

 описатель диспетчерской очереди — диспетчерская очередь, в которой должна выполняться задача;

 блоковый объект — блоковый объект, посылаемый в диспетчерскую очередь для асинхронного выполнения.

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

dispatch_queue_t mainQueue = dispatch_get_main_queue();

dispatch_async(mainQueue, ^(void) {

[[[UIAlertView alloc] initWithTitle:@"GCD"

message:@"GCD is amazing!"

delegate: nil

cancelButtonTitle:@"OK"

otherButtonTitles: nil, nil] show];

});

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

Если запустить данное приложение в эмуляторе iOS, пользователь увидит примерно такую картинку, как на рис. 7.1.

Рис. 7.1. Предупреждение, при выводе которого применялись асинхронные вызовы к GCD.

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

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

Как было указано ранее, функция dispatch_async_f позволяет передавать указатель на контекст, определяемый приложением. Этот контекст впоследствии может использоваться вызываемой нами функцией C. Итак, создадим структуру, в которой будут содержаться значения — в частности, заголовок предупреждающего вида, сообщение и надпись Cancel (Отмена) на соответствующей кнопке. Когда приложение запустится, мы поместим в эту структуру все значения и передадим ее функции C для отображения. Вот как определяется эта структура:

typedef struct{

char *title;

char *message;

char *cancelButtonTitle;

} AlertViewData;

Итак, продолжим и реализуем функцию C, которая в дальнейшем будет вызываться с GCD. Эта функция должна ожидать параметр типа void *, тип которого затем приводится к AlertViewData *. Иными словами, мы ожидаем от вызывающей стороны этой функции, что нам будет передана ссылка на данные, необходимые для работы предупреждающего вида, которые инкапсулированы в структуре AlertViewData:

void displayAlertView(void *paramContext){

AlertViewData *alertData = (AlertViewData *)paramContext;

NSString *title =

[NSString stringWithUTF8String: alertData->title];

NSString *message =

[NSString stringWithUTF8String: alertData->message];

NSString *cancelButtonTitle =

[NSString stringWithUTF8String: alertData->cancelButtonTitle];

[[[UIAlertView alloc] initWithTitle: title

message: message

delegate: nil

cancelButtonTitle: cancelButtonTitle

otherButtonTitles: nil, nil] show];

free(alertData);

}

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

А теперь вызовем функцию displayAlertView применительно к основной очереди и передадим ей контекст (структуру, содержащую данные для предупреждающего вида):

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

dispatch_queue_t mainQueue = dispatch_get_main_queue();

AlertViewData *context = (AlertViewData *)

malloc(sizeof(AlertViewData));

if (context!= NULL){

context->title = «GCD»;

context->message = «GCD is amazing.»;

context->cancelButtonTitle = «OK»;

dispatch_async_f(mainQueue,

(void *)context,

displayAlertView);

}

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

Если активизировать метод класса currentThread, относящийся к классу NSThread, то выяснится, что блоковые объекты или функции C, направляемые вами в главную очередь, действительно работают в главном потоке:

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

dispatch_queue_t mainQueue = dispatch_get_main_queue();

dispatch_async(mainQueue, ^(void) {

NSLog(@"Current thread = %@", [NSThread currentThread]);

NSLog(@"Main thread = %@", [NSThread mainThread]);

});

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

Вывод данного кода будет примерно таким:

Current thread = {name = (null), num = 1}

Main thread = {name = (null), num = 1}

Итак, мы изучили, как с помощью GCD решаются задачи, связанные с пользовательским интерфейсом. Перейдем к другим темам — в частности, поговорим о том, как выполнять задачи параллельно, используя параллельные очереди (см. разделы 7.5 и 7.6), и как при необходимости смешивать создаваемый код с кодом пользовательского интерфейса.

 

Постановка задачи

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

 

Решение

Воспользуйтесь функцией dispatch_sync.

 

Обсуждение

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

Любая задача, не связанная с пользовательским интерфейсом, позволяет применять глобальные параллельные очереди, которые предоставляет GCD. Они могут выполняться как синхронно, так и асинхронно. Но синхронное выполнение не означает, что программа дожидается, пока выполнится определенный фрагмент кода, а потом продолжает работу. Это лишь означает, что параллельная очередь дождется выполнения вашей задачи и только потом перейдет к выполнению следующего блока кода, стоящего в очереди. Когда вы ставите в параллельную очередь блоковый объект, ваша собственная программа всегда продолжает работу, не дожидаясь, пока выполнится код, стоящий в очереди. Дело в том, что параллельные очереди (как понятно из их названия) выполняют свой код в неглавных потоках. (Из этого правила есть исключение: когда задача передается в параллельную или последовательную очередь посредством функции dispatch_sync, система iOS при наличии такой возможности запускает задачу в текущем потоке. А это может быть и главный поток в зависимости от актуальной ветви кода. Это специальная оптимизация, запрограммированная в GCD, и вскоре мы обсудим ее подробнее.)

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

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

Рассмотрим пример. Данная функция выводит на консоль числа от 1 до 1000, всю последовательность подряд, и при этом не блокирует основной поток. Мы можем создать блоковый объект, выполняющий подсчет за нас, и синхронно (дважды) вызвать этот же блоковый объект:

void (^printFrom1To1000)(void) = ^{

NSUInteger counter = 0;

for (counter = 1;

counter <= 1000;

counter++){

NSLog(@"Counter = %lu — Thread = %@",

(unsigned long)counter,

[NSThread currentThread]);

}

};

Итак, попробуем активизировать этот блоковый объект с помощью GCD:

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

dispatch_queue_t concurrentQueue =

dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

dispatch_sync(concurrentQueue, printFrom1To1000);

dispatch_sync(concurrentQueue, printFrom1To1000);

// Точка переопределения для дополнительной настройки

// после запуска приложения

[self.window makeKeyAndVisible];

return YES;

}

Запустив этот код, вы заметите, что счетчик работает в главном потоке даже при том, что вы поставили эту задачу на выполнение в параллельную очередь. Оказывается, что это явление — специальная оптимизация GCD. Функция dispatch_sync будет использовать актуальный поток, то есть поток, который вы задействуете при направлении задачи в очередь, всякий раз, когда это возможно. В этом и заключается упомянутая оптимизация. Вот что об этом пишет Apple в справке по GCD: «В целях оптимизации работы данная функция активизирует блок кода в актуальном потоке всякий раз, когда это возможно».

Чтобы выполнить вместо блокового объекта функцию на языке C и сделать это синхронно, в диспетчерской очереди, используйте функцию dispatch_sync_f. Давайте просто преобразуем код, написанный для блокового объекта printFrom1To1000, в эквивалентную ему функцию на языке C:

void printFrom1To1000(void *paramContext){

NSUInteger counter = 0;

for (counter = 1;

counter <= 1000;

counter++){

NSLog(@"Counter = %lu — Thread = %@",

(unsigned long)counter,

[NSThread currentThread]);

}

}

А теперь можно воспользоваться функцией dispatch_sync_f для выполнения функции printFrom1To1000 в параллельной очереди:

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

dispatch_queue_t concurrentQueue =

dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

dispatch_sync_f(concurrentQueue,

NULL,

printFrom1To1000);

dispatch_sync_f(concurrentQueue,

NULL,

printFrom1To1000);

self.window = [[UIWindow alloc]

initWithFrame: [[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

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

• DISPATCH_QUEUE_PRIORITY_LOW — ваша задача будет получать меньше процессорного времени, чем выделяется на задачу в среднем;

• DISPATCH_QUEUE_PRIORITY_DEFAULT — ваша задача получит стандартный системный приоритет;

• DISPATCH_QUEUE_PRIORITY_HIGH — ваша задача будет получать больше процессорного времени, чем выделяется на задачу в среднем.

Второй параметр функции dispatch_get_global_queue зарезервирован, ему всегда следует передавать значение 0.

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

 

См. также

Разделы 7.6 и 7.10.

 

Постановка задачи

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

 

Решение

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

Чтобы выполнять в диспетчерской очереди асинхронные задачи, следует пользоваться одной из следующих функций:

• dispatch_async — отправляет блоковый объект в диспетчерскую очередь (и объект и очередь указываются в соответствующих параметрах) для асинхронного выполнения;

• dispatch_async_f — отправляет в диспетчерскую очередь функцию языка C вместе со ссылкой на контекст (все три элемента указываются в соответствующих параметрах) для асинхронного выполнения.

 

Обсуждение

Рассмотрим реальный пример. Напишем приложение для iOS, которое позволит нам скачивать изображение из Интернета по имеющейся гиперссылке (URL). После завершения загрузки наша программа должна отобразить изображение для пользователя. Далее приведен план работы и описано, как будут применены те или иные концепции, связанные с GCD, которые мы уже успели изучить.

1. Мы собираемся асинхронно запускать блоковый объект в параллельной очереди.

2. В ходе выполнения этого блока будем однократно (синхронно) запускать другой блоковый объект. Его мы будем использовать для скачивания изображения по URL, при этом будет применяться функция dispatch_sync. Мы поступаем именно так, поскольку хотим, чтобы обработка остального кода, стоящего в данной параллельной очереди, не начиналась, пока не загрузится изображение. В результате мы заставляем подождать только одну параллельную очередь, а не все остальные очереди. Если синхронно скачивать файл по URL из асинхронного блока кода, мы заблокируем лишь очередь, обрабатывающую синхронную функцию, но не главный поток. Вся операция так и остается асинхронной с точки зрения главного потока. Мы решаем основную задачу: при загрузке изображения главный поток не блокируется.

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

Каркас для планируемой программы совершенно прост:

— (void) viewDidAppear:(BOOL)animated{

[super viewDidAppear: animated];

dispatch_queue_t concurrentQueue =

dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

dispatch_async(concurrentQueue, ^{

__block UIImage *image = nil;

dispatch_sync(concurrentQueue, ^{

/* Здесь скачивается изображение. */

});

dispatch_sync(dispatch_get_main_queue(), ^{

/* Здесь мы демонстрируем изображение пользователю и делаем это

в главной очереди. */

});

});

}

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

Скачаем изображение и отобразим его для пользователя. Это мы сделаем в методе экземпляра viewDidAppear:, относящемся к контроллеру вида, который в данный момент отображается в приложении для iPhone:

— (void) viewDidAppear:(BOOL)paramAnimated{

[super viewDidAppear: paramAnimated];

dispatch_queue_t concurrentQueue =

dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

dispatch_async(concurrentQueue, ^{

__block UIImage *image = nil;

dispatch_sync(concurrentQueue, ^{

/* Здесь скачивается изображение. */

/* Изображение iPad с сайта Apple. Гиперссылка слишком длинная,

поэтому ее нужно правильно разбить на две строки. */

NSString *urlAsString = @" http://images.apple.com/mobileme/features "\

«/images/ipad_findyouripad_201 00518.jpg»;

NSURL *url = [NSURL URLWithString: urlAsString];

NSURLRequest *urlRequest = [NSURLRequest requestWithURL: url];

NSError *downloadError = nil;

NSData *imageData = [NSURLConnection

sendSynchronousRequest: urlRequest

returningResponse: nil

error:&downloadError];

if (downloadError == nil &&

imageData!= nil){

image = [UIImage imageWithData: imageData];

/* Изображение у нас есть. Теперь можно его использовать. */

}

else if (downloadError!= nil){

NSLog(@"Error happened = %@", downloadError);

} else {

NSLog(@"No data could get downloaded from the URL.");

}

});

dispatch_sync(dispatch_get_main_queue(), ^{

/* Здесь картинка отображается, и это происходит в главной очереди. */

if (image!= nil){

/* Здесь создается вид с изображением. */

UIImageView *imageView = [[UIImageView alloc]

initWithFrame: self.view.bounds];

/* Задаем характеристики изображения. */

[imageView setImage: image];

/* Убеждаемся, что изображение масштабировано правильно. */

[imageView setContentMode: UIViewContentModeScaleAspectFit];

/* Добавляем изображение к виду данного контроллера вида. */

[self.view addSubview: imageView];

} else {

NSLog(@"Image isn't downloaded. Nothing to display.");

}

});

});

}

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

Рис. 7.2. Загрузка изображения и демонстрация его пользователю, применяется GCD

Приведем другой пример. Допустим, у нас есть массив из 10 000 случайных чисел, которые сохранены в файле на диске. Мы хотим загрузить этот файл в память и отсортировать числа в порядке возрастания (то есть сделать так, чтобы список начинался с наименьшего числа). Потом мы хотим отобразить полученный список для пользователя. Инструмент управления, который будет применяться при этой операции, определяется тем, для какой системы вы пишете программу. В случае с iOS идеальным выходом было бы использовать экземпляр UITableView, а при работе с Mac OS X — экземпляр NSTableView. Поскольку массива у нас еще нет, начнем с его создания, потом загрузим этот массив, а потом отобразим.

Вот два метода, которые помогут нам найти место на диске устройства, где мы собираемся сохранить массив из 10 000 случайных чисел:

— (NSString *) fileLocation{

/* Получаем каталог (-и) документа. */

NSArray *folders =

NSSearchPathForDirectoriesInDomains(NSDocumentDirectory,

NSUserDomainMask,

YES);

/* Мы что-нибудь нашли? */

if ([folders count] == 0){

return nil;

}

/* Получаем первый каталог. */

NSString *documentsFolder = [folders objectAtIndex:0];

/* Прикрепляем имя файла к концу пути документа. */

return [documentsFolder

stringByAppendingPathComponent:@"list.txt"];

}

— (BOOL) hasFileAlreadyBeenCreated{

BOOL result = NO;

NSFileManager *fileManager = [[NSFileManager alloc] init];

if ([fileManager fileExistsAtPath: [self fileLocation]]){

result = YES;

}

return result;

}

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

— (void) viewDidAppear:(BOOL)paramAnimated{

[super viewDidAppear: paramAnimated];

dispatch_queue_t concurrentQueue =

dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

/* Если мы еще не отсортировали массив из 10 000 случайных чисел

на диске ранее, сгенерируем эти числа сейчас, а потом сохраним

их на диск в массиве. */

dispatch_async(concurrentQueue, ^{

NSUInteger numberOfValuesRequired = 10000;

if ([self hasFileAlreadyBeenCreated] == NO){

dispatch_sync(concurrentQueue, ^{

NSMutableArray *arrayOfRandomNumbers =

[[NSMutableArray alloc] initWithCapacity: numberOfValuesRequired];

NSUInteger counter = 0;

for (counter = 0;

counter < numberOfValuesRequired;

counter++){

unsigned int randomNumber =

arc4random() % ((unsigned int)RAND_MAX + 1);

[arrayOfRandomNumbers addObject:

[NSNumber numberWithUnsignedInt: randomNumber]];

}

/* Теперь записываем массив на диск. */

[arrayOfRandomNumbers writeToFile: [self fileLocation]

atomically: YES];

});

}

__block NSMutableArray *randomNumbers = nil;

/* Считываем числа с диска и сортируем их в порядке возрастания. */

dispatch_sync(concurrentQueue, ^{

/* Если файл на данный момент уже создан, занимаемся его считыванием. */

if ([self hasFileAlreadyBeenCreated]){

randomNumbers = [[NSMutableArray alloc]

initWithContentsOfFile: [self fileLocation]];

/* Теперь сортируем числа. */

[randomNumbers sortUsingComparator:

^NSComparisonResult(id obj1, id obj2) {

NSNumber *number1 = (NSNumber *)obj1;

NSNumber *number2 = (NSNumber *)obj2;

return [number1 compare: number2];

}];

}

});

dispatch_async(dispatch_get_main_queue(), ^{

if ([randomNumbers count] > 0){

/* Обновляем пользовательский интерфейс, задействуя числа

из массива randomNumbers. */

}

});

});

}

Функционал GCD далеко не ограничивается синхронным или асинхронным выполнением блоков кода или функций. В разделе 7.9 вы научитесь группировать блоковые объекты и готовить их к выполнению в диспетчерской очереди. Кроме того, рекомендую вам изучить разделы 7.7. и 7.8, где говорится о прочих функциях, которые предоставляются программисту в GCD.

 

См. также

Разделы 7.4, 7.7 и 7.8.

 

Постановка задачи

Требуется выполнить код, но после определенной задержки. Задержку планируется указывать с помощью GCD.

 

Решение

Воспользуйтесь функциями dispatch_after и dispatch_after_f.

 

Обсуждение

Работая с фреймворком Core Foundation, можно активизировать селектор в объекте по истечении заданного временного промежутка с помощью метода performSelector: withObject: afterDelay:, относящегося к классу NSObject. Например:

— (void) printString:(NSString *)paramString{

NSLog(@"%@", paramString);

}

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

[self performSelector:@selector(printString:)

withObject:@"Grand Central Dispatch"

afterDelay:3.0];

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

// Точка переопределения для настройки после запуска приложения

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

В данном примере мы приказываем среде времени исполнения вызвать метод printString: после трехсекундной задержки. Ту же операцию можно осуществить и в GCD с помощью функций dispatch_after и dispatch_after_f. Обе эти функции описаны далее.

• dispatch_after — направляет блоковый объект в диспетчерскую очередь по истечении заданного периода времени, указываемого в наносекундах. Эта функция требует следующих параметров:

• задержка в наносекундах — количество наносекунд, в течение которых длится ожидание в определенной диспетчерской очереди в GCD (указываемой во втором параметре), после чего выполняется блоковый объект (задаваемый в третьем параметре);

• диспетчерская очередь — диспетчерская очередь, в которой должен быть выполнен блоковый объект (указываемый в третьем параметре) после определенной задержки (задаваемой в первом параметре);

• блоковый объект — блоковый объект, который должен быть активизирован в заданной диспетчерской очереди по истечении заданного количества наносекунд. Блоковый объект не должен иметь возвращаемого значения и не должен принимать никаких параметров (см. раздел 7.1).

• dispatch_after_f — направляет функцию на языке C в GCD для выполнения по истечении указанного периода времени, задаваемого в наносекундах. Данная функция принимает четыре параметра:

• задержка в наносекундах — количество наносекунд, в течение которых длится ожидание в определенной диспетчерской очереди в GCD (указываемой во втором параметре), после чего выполняется заданная функция (задаваемая в четвертом параметре);

• диспетчерская очередь — диспетчерская очередь, в которой должна быть выполнена функция на языке C (указываемая во втором параметре) после определенной задержки (задаваемой в первом параметре);

• контекст — адрес в памяти, по которому находится определенное значение, относящееся к неупорядоченному массиву данных (куче). Это значение должно передаваться функции C. Подробнее об этом говорилось в разделе 7.4;

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

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

Сначала рассмотрим пример работ с функцией dispatch_after:

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

double delayInSeconds = 2.0;

dispatch_time_t delayInNanoSeconds =

dispatch_time(DISPATCH_TIME_NOW, delayInSeconds * NSEC_PER_SEC);

dispatch_queue_t concurrentQueue =

dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

dispatch_after(delayInNanoSeconds, concurrentQueue, ^(void){

/* Здесь выполняются требуемые операции. */

});

// Точка переопределения для настройки после запуска приложения

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

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

• Исходное время — если обозначить этот параметр через B, а приращение времени (Delta Parameter) — через D, то результирующее время от этой функции будет равно B+D. Для этого параметра можно задать значение DISPATCH_TIME_NOW, определив таким образом в качестве базового времени настоящий момент, а потом указать приращение, добавляемое к этому времени, используя дельта-параметр.

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

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

dispatch_time_t delay =

dispatch_time(DISPATCH_TIME_NOW, 3.0f * NSEC_PER_SEC);

А вот так задается период 0,5 с от настоящего момента:

dispatch_time_t delay =

dispatch_time(DISPATCH_TIME_NOW, (1.0 / 2.0f) * NSEC_PER_SEC);

Теперь рассмотрим, как можно использовать функцию dispatch_after_f:

void processSomething(void *paramContext){

/* Здесь происходит обработка. */

NSLog(@"Processing…");

}

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

double delayInSeconds = 2.0;

dispatch_time_t delayInNanoSeconds =

dispatch_time(DISPATCH_TIME_NOW, delayInSeconds * NSEC_PER_SEC);

dispatch_queue_t concurrentQueue =

dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

dispatch_after_f(delayInNanoSeconds,

concurrentQueue,

NULL,

processSomething);

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

// Точка переопределения для настройки после запуска приложения

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

 

См. также

Разделы 7.1 и 7.4.

 

Постановка задачи

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

 

Решение

Воспользуйтесь функцией dispatch_once.

 

Обсуждение

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

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

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

 Блоковый объект — блоковый объект, выполняемый не более одного раза. Блоковый объект не возвращает никаких значений и не принимает никаких параметров.

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

Например:

static dispatch_once_t onceToken;

void (^executedOnlyOnce)(void) = ^{

static NSUInteger numberOfEntries = 0;

numberOfEntries++;

NSLog(@"Executed %lu time(s)", (unsigned long)numberOfEntries);

};

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

dispatch_queue_t concurrentQueue =

dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

dispatch_once(&onceToken, ^{

dispatch_async(concurrentQueue,

executedOnlyOnce);

});

dispatch_once(&onceToken, ^{

dispatch_async(concurrentQueue,

executedOnlyOnce);

});

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

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

В руководстве Cocoa Fundamentals Guide (Руководство по основам Cocoa) () Apple объясняется, как создавать синглтон. Исходный код довольно старый и еще не обновлен с учетом использования GCD и автоматического подсчета ссылок. Мы можем изменить эту модель, чтобы можно было пользоваться GCD и функцией dispatch_once. В результате мы сможем создавать совместно используемый экземпляр объекта:

#import «MySingleton.h»

@implementation MySingleton

— (instancetype) sharedInstance{

static MySingleton *SharedInstance = nil;

static dispatch_once_t onceToken;

dispatch_once(&onceToken, ^{

SharedInstance = [MySingleton new];

});

return SharedInstance;

}

@end

 

Постановка задачи

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

 

Решение

Для создания групп в GCD пользуйтесь функцией dispatch_group_create.

 

Обсуждение

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

— (void) reloadTableView{

/* Здесь перезагружается табличный вид. */

NSLog(@"%s", __FUNCTION__);

}

— (void) reloadScrollView{

/* Здесь выполняется работа. */

NSLog(@"%s", __FUNCTION__);

}

— (void) reloadImageView{

/* Здесь перезагружается вид с изображением. */

NSLog(@"%s", __FUNCTION__);

}

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

• dispatch_group_create — создает описатель группы;

• dispatch_group_async — отправляет блок кода в группу для выполнения. Необходимо указать диспетчерскую очередь, в которой должен выполняться этот блок кода, а также группу, к которой этот блок кода относится;

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

Рассмотрим пример. Как объяснялось ранее, в этом примере мы собираемся активизировать методы reloadTableView, reloadScrollView и reloadImageView один за другим, а потом отобразить для пользователя сообщение о том, что задача выполнена. Для достижения этой цели применим мощные групповые функции, присущие GCD:

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

dispatch_group_t taskGroup = dispatch_group_create();

dispatch_queue_t mainQueue = dispatch_get_main_queue();

/* Перезагружаем табличный вид в главной очереди. */

dispatch_group_async(taskGroup, mainQueue, ^{

[self reloadTableView];

});

/* Перезагружаем прокручиваемый вид в главной очереди. */

dispatch_group_async(taskGroup, mainQueue, ^{

[self reloadScrollView];

});

/* Перезагружаем вид с изображением в главной очереди. */

dispatch_group_async(taskGroup, mainQueue, ^{

[self reloadImageView];

});

/* Когда все это будет сделано, диспетчеризуем следующий блок. */

dispatch_group_notify(taskGroup, mainQueue, ^{

/* Здесь происходит обработка. */

[[[UIAlertView alloc] initWithTitle:@"Finished"

message:@"All tasks are finished"

delegate: nil

cancelButtonTitle:@"OK"

otherButtonTitles: nil, nil] show];

});

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

Кроме работы с функцией dispatch_group_async, можно также направлять асинхронные функции на языке C, используя функцию dispatch_group_async_f.

GCDAppDelegate — это просто имя класса, из которого взят пример. Данное имя класса мы будем использовать для приведения типа контекстного объекта так, чтобы компилятор понимал наши команды.

Вот так:

void reloadAllComponents(void *context){

AppDelegate *self = (__bridge AppDelegate *)context;

[self reloadTableView];

[self reloadScrollView];

[self reloadImageView];

}

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

dispatch_group_t taskGroup = dispatch_group_create();

dispatch_queue_t mainQueue = dispatch_get_main_queue();

dispatch_group_async_f(taskGroup,

mainQueue,

(__bridge void *)self,

reloadAllComponents);

/* Когда все это будет сделано, диспетчеризуем следующий блок. */

dispatch_group_notify(taskGroup, mainQueue, ^{

/* Здесь происходит обработка. */

[[[UIAlertView alloc] initWithTitle:@"Finished"

message:@"All tasks are finished"

delegate: nil

cancelButtonTitle:@"OK"

otherButtonTitles: nil, nil] show];

});

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

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

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

Рис. 7.3. Управление группой задач в GCD

 

См. также

Раздел 7.4.

 

Постановка задачи

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

 

Решение

Воспользуйтесь функцией dispatch_queue_create.

 

Обсуждение

Работая с GCD, вы можете создавать собственные последовательные диспетчерские очереди (см. раздел 7.0, где подробно рассказано о последовательных очередях). Задачи в последовательных диспетчерских очередях выполняются по принципу «первым пришел — первым обслужен» (FIFO). Но асинхронные задачи, выполняемые в последовательных очередях, не осуществляются в главном потоке, благодаря чему последовательные очереди очень хорошо подходят для решения параллельных FIFO-задач.

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

Для создания последовательных очередей мы будем пользоваться функцией dispatch_queue_create. Первый параметр этой функции — строка на языке C (char *), которая уникально идентифицирует данную последовательную очередь в системе. Я делаю особый акцент на системе, потому что данный идентификатор действует в рамках всей системы. Это означает, что если ваше приложение создает новую последовательную очередь с идентификатором serialQueue1 и то же самое делает какое-то другое приложение, GCD не сможет зафиксировать акт создания такой одноименной последовательной очереди. Поэтому Apple настоятельно рекомендует, чтобы идентификаторы записывались в формате «обратное доменное имя» (Reverse DNS Format). Идентификаторы в формате обратных доменных имен обычно составляются по следующему принципу: com.COMPANY.PRODUCT.IDENTIFIER. Например, я могу создать две последовательные очереди и присвоить им следующие имена:

com.pixolity.GCD.serialQueue1

com.pixolity.GCD.serialQueue2

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

Пожалуй, самое время для примера. Вот он!

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

dispatch_queue_t firstSerialQueue =

dispatch_queue_create(«com.pixolity.GCD.serialQueue1», 0);

dispatch_async(firstSerialQueue, ^{

NSUInteger counter = 0;

for (counter = 0;

counter < 5;

counter++){

NSLog(@"First iteration, counter = %lu", (unsigned long)counter);

}

});

dispatch_async(firstSerialQueue, ^{

NSUInteger counter = 0;

for (counter = 0;

counter < 5;

counter++){

NSLog(@"Second iteration, counter = %lu", (unsigned long)counter);

}

});

dispatch_async(firstSerialQueue, ^{

NSUInteger counter = 0;

for (counter = 0;

counter < 5;

counter++){

NSLog(@"Third iteration, counter = %lu", (unsigned long)counter);

}

});

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

Запустив этот код, обратите внимание на то, какая информация выводится в окне консоли. Результаты будут примерно такими:

First iteration, counter = 0

First iteration, counter = 1

First iteration, counter = 2

First iteration, counter = 3

First iteration, counter = 4

Second iteration, counter = 0

Second iteration, counter = 1

Second iteration, counter = 2

Second iteration, counter = 3

Second iteration, counter = 4

Third iteration, counter = 0

Third iteration, counter = 1

Third iteration, counter = 2

Third iteration, counter = 3

Third iteration, counter = 4

Очевидно, что, хотя мы и направляли блоковые объекты в последовательную очередь асинхронно, очередь выполняла их код в порядке «первым пришел — первым обслужен». Мы можем изменить этот пример с кодом так, чтобы пользоваться функцией dispatch_async_f вместо dispatch_async:

void firstIteration(void *paramContext){

NSUInteger counter = 0;

for (counter = 0;

counter < 5;

counter++){

NSLog(@"First iteration, counter = %lu", (unsigned long)counter);

}

}

void secondIteration(void *paramContext){

NSUInteger counter = 0;

for (counter = 0;

counter < 5;

counter++){

NSLog(@"Second iteration, counter = %lu", (unsigned long)counter);

}

}

void thirdIteration(void *paramContext){

NSUInteger counter = 0;

for (counter = 0;

counter < 5;

counter++){

NSLog(@"Third iteration, counter = %lu", (unsigned long)counter);

}

}

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

dispatch_queue_t firstSerialQueue =

dispatch_queue_create(«com.pixolity.GCD.serialQueue1», 0);

dispatch_async_f(firstSerialQueue, NULL, firstIteration);

dispatch_async_f(firstSerialQueue, NULL, secondIteration);

dispatch_async_f(firstSerialQueue, NULL, thirdIteration);

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

 

Постановка задачи

Необходимо синхронно выполнить серию задач.

 

Решение

Создавайте операции и запускайте их вручную:

@interface AppDelegate ()

@property (nonatomic, strong) NSInvocationOperation *simpleOperation;

@end

Реализация делегата приложения такова:

— (void) simpleOperationEntry:(id)paramObject{

NSLog(@"Parameter Object = %@", paramObject);

NSLog(@"Main Thread = %@", [NSThread mainThread]);

NSLog(@"Current Thread = %@", [NSThread currentThread]);

}

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

NSNumber *simpleObject = [NSNumber numberWithInteger:123];

self.simpleOperation = [[NSInvocationOperation alloc]

initWithTarget: self

selector:@selector(simpleOperationEntry:)

object: simpleObject];

[self.simpleOperation start];

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

Вывод этой программы (в окне консоли) будет примерно таким:

Parameter Object = 123

Main Thread = {name = (null), num = 1}

Current Thread = {name = (null), num = 1}

Из имени данного класса (NSInvocationOperation) понятно, что основное применение объекта такого типа связано с активизацией метода в объекте. Это наиболее непосредственный способ активизации метода в объекте с помощью операций.

 

Обсуждение

Операция активизации, как объяснялось в разделе 7.0, позволяет активизировать метод в объекте. «Что же в этом особенного?» — спросите вы. Потенциал активизирующей операции можно продемонстрировать, когда такая операция добавляется в операционную очередь. Примененная вместе с операционной очередью, активизирующая операция может асинхронно запустить метод в заданном объекте параллельно тому потоку, который начал операцию. Внимательно рассмотрев вывод с консоли (приведенный в подразделе «Решение» данного раздела), вы заметите, что актуальный поток в методе, запущенный активизирующей операцией, равен главному потоку. Действительно, главный поток в методе application: didFinishLaunchingWithOptions: запускает операцию, пользуясь ее методом start. В разделе 7.12 мы научимся эффективно использовать операционные очереди для асинхронного выполнения задач.

Кроме активизирующих операций, вы можете применять блоковые или обычные операции для синхронного выполнения задач. Вот пример использования блоковой операции для подсчета чисел от 0 до 999 (это происходит в. h-файле делегата приложения):

@interface AppDelegate ()

@property (nonatomic, strong) NSBlockOperation *simpleOperation;

@end

@implementation AppDelegate

А вот реализация делегата приложения (.m-файл):

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

self.simpleOperation = [NSBlockOperation blockOperationWithBlock: ^{

NSLog(@"Main Thread = %@", [NSThread mainThread]);

NSLog(@"Current Thread = %@", [NSThread currentThread]);

NSUInteger counter = 0;

for (counter = 0;

counter < 1000;

counter++){

NSLog(@"Count = %lu", (unsigned long)counter);

}

}];

/* Запуск операции. */

[self.simpleOperation start];

/* Выводим что-нибудь на консоль, просто чтобы проверить,

должны мы дожидаться, пока выполнится блок кода, или нет.*/

NSLog(@"Main thread is here");

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

Если запустить приложение, мы увидим, что на экране выводятся значения от 0 до 999, а за ними следует сообщение Main thread is here (Это главный поток):

Main Thread = {name = (null), num = 1}

Current Thread = {name = (null), num = 1}

…

Count = 991

Count = 992

Count = 993

Count = 994

Count = 995

Count = 996

Count = 997

Count = 998

Count = 999

Main thread is here

Итак, убеждаемся, что, поскольку блоковая операция была запущена в методе application: didFinishLaunchingWithOptions:, который сам работает в главном потоке, код внутри блока также выполняется в главном потоке. Основные сведения, которые мы получаем из этих регистрационных записей (логов), сводятся к следующему: операция блокировала главный поток, и потребовалось вернуться к выполнению кода основного потока после того, как была завершена работа блоковой операции. Это образец очень непрофессионального программирования. На самом деле программисты, работающие с iOS, должны идти на любые уловки и пользоваться любыми известными им приемами, чтобы обеспечивать отклик основного потока в любой момент и чтобы этот поток мог заниматься своим основным делом — обработкой пользовательского ввода. Вот что об этом пишет Apple.

«Необходимо внимательно отслеживать, какие задачи вы решаете в главном потоке вашего приложения. Именно в главном потоке ваша программа отрабатывает события касания и другой пользовательский ввод. Чтобы гарантировать, что приложение в любой момент будет откликаться на действия пользователя, никогда не следует загружать главный поток выполнением долговременных задач либо выполнением задач с потенциально неопределенным концом. Таковы, в частности, задачи, связанные с доступом к сети. Напротив, подобные задачи следует решать в фоновых потоках. Оптимальный способ решения таких задач — заключение их в объект операции и добавление этого объекта к операционной очереди. Но вы можете и сами создавать потоки вручную».

Подробнее эта тема рассматривается в документе Performance Tuning («Повышение производительности») в справочной библиотеке iOS. Документ расположен по адресу 7072-CH8-SW1.

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

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

В реализации операции необходимо переопределить два важных метода экземпляра NSOperation — методы isExecuting и isFinished. Их может вызывать любой другой объект. В этих методах необходимо возвращать потоковобезопасное значение, которым можно будет управлять прямо из операции. Как только операция начинается, она должна посредством механизма «уведомления наблюдателей об изменениях в свойствах наблюдаемого объекта» (KVO) сообщать всем слушателям о том, что вы изменяете возвращаемые значения для двух этих методов. В примере с кодом мы рассмотрим, как это происходит на практике.

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

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

Вот объявление объекта операции (.h-файл):

#import 

@interface CountingOperation: NSOperation

/* Выделенный инициализатор */

— (id) initWithStartingCount:(NSUInteger)paramStartingCount

endingCount:(NSUInteger)paramEndingCount;

@end

Реализация операции (записываемая в. m-файле) несколько длинновата, но, надеюсь, вполне понятна:

#import «CountingOperation.h»

@implementation CountingOperation

@property (nonatomic, unsafe_unretained) NSUInteger startingCount;

@property (nonatomic, unsafe_unretained) NSUInteger endingCount;

@property (nonatomic, unsafe_unretained, getter=isFinished) BOOL finished;

@property (nonatomic, unsafe_unretained, getter=isExecuting) BOOL executing;

@end

@implementation CountingOperation

— (instancetype) init {

return([self initWithStartingCount:0

endingCount:1000]);

}

— (instancetype) initWithStartingCount:(NSUInteger)paramStartingCount

endingCount:(NSUInteger)paramEndingCount{

self = [super init];

if (self!= nil){

/* Сохраните эти значения для главного метода. */

startingCount = paramStartingCount;

endingCount = paramEndingCount;

}

return(self);

}

— (void) main {

@try {

/* Это автоматически высвобождаемый пул. */

@autoreleasepool {

/* Сохраняем здесь локальную переменную, которая

должна быть установлена в YES всякий раз, когда

мы завершаем выполнение задачи. */

BOOL taskIsFinished = NO;

/* Создаем здесь цикл while, существующий лишь в том случае,

когда переменная taskIsFinished устанавливается в YES

или операция отменяется. */

while (taskIsFinished == NO &&

[self isCancelled] == NO){

/* Здесь выполняется задача. */

NSLog(@"Main Thread = %@", [NSThread mainThread]);

NSLog(@"Current Thread = %@", [NSThread currentThread]);

NSUInteger counter = startingCount;

for (counter = startingCount;

counter < endingCount;

counter++){

NSLog(@"Count = %lu", (unsigned long)counter);

}

/* Очень важно. Здесь мы можем выйти из цикла, по-прежнему

соблюдая правила, по которым отменяются операции. */

taskIsFinished = YES;

}

/* Соответствие KVO. Генерируем требуемые уведомления KVO. */

[self willChangeValueForKey:@"isFinished"];

[self willChangeValueForKey:@"isExecuting"];

finished = YES;

executing = NO;

[self didChangeValueForKey:@"isFinished"];

[self didChangeValueForKey:@"isExecuting"];

}

}

@catch (NSException * e) {

NSLog(@"Exception %@", e);

}

}

@end

Операцию можно начать так:

@interface AppDelegate ()

@property (nonatomic, strong) CountingOperation *simpleOperation;

@end

@implementation AppDelegate

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

self.simpleOperation = [[CountingOperation alloc] initWithStartingCount:0

endingCount:1000];

[self.simpleOperation start];

NSLog(@"Main thread is here");

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

@end

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

Main Thread = {name = (null), num = 1}

Current Thread = {name = (null), num = 1}

…

Count = 993

Count = 994

Count = 995

Count = 996

Count = 997

Count = 998

Count = 999

Main thread is here

 

См. также

Раздел 7.12.

 

Постановка задачи

Требуется параллельно выполнять операции.

 

Решение

Воспользуйтесь операционными очередями. В качестве альтернативы можно создавать подклассы от NSOperation и откреплять новый поток в методе main.

 

Обсуждение

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

Идем дальше. Попробуем воспользоваться операционной очередью и добавим к ней две простые инициирующие операции (подробнее об инициирующих операциях рассказано в разделе 7.0). Дополнительные примеры кода, описывающие инициирующие операции, имеются в разделе 7.11. Вот объявление (.hm-файл) делегата приложения, в котором используются операционная очередь и две инициирующие операции:

@interface AppDelegate ()

@property (nonatomic, strong) NSOperationQueue *operationQueue;

@property (nonatomic, strong) NSInvocationOperation *firstOperation;

@property (nonatomic, strong) NSInvocationOperation *secondOperation;

@end

@implementation AppDelegate

А вот и внутренняя часть файла реализации делегата приложения:

— (void) firstOperationEntry:(id)paramObject{

NSLog(@"%s", __FUNCTION__);

NSLog(@"Parameter Object = %@", paramObject);

NSLog(@"Main Thread = %@", [NSThread mainThread]);

NSLog(@"Current Thread = %@", [NSThread currentThread]);

}

— (void) secondOperationEntry:(id)paramObject{

NSLog(@"%s", __FUNCTION__);

NSLog(@"Parameter Object = %@", paramObject);

NSLog(@"Main Thread = %@", [NSThread mainThread]);

NSLog(@"Current Thread = %@", [NSThread currentThread]);

}

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

NSNumber *firstNumber = @111;

NSNumber *secondNumber = @222;

self.firstOperation =[[NSInvocationOperation alloc]

initWithTarget: self

selector:@selector(firstOperationEntry:)

object: firstNumber];

self.secondOperation = [[NSInvocationOperation alloc]

initWithTarget: self

selector:@selector(secondOperationEntry:)

object: secondNumber];

self.operationQueue = [[NSOperationQueue alloc] init];

/* Добавляем операции в очередь. */

[self.operationQueue addOperation: self.firstOperation];

[self.operationQueue addOperation: self.secondOperation];

NSLog(@"Main thread is here");

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

Вот что происходит в реализации данного кода.

У нас есть два метода, firstOperationEntry: и secondOperationEntry:. Каждый из этих методов принимает в качестве параметра объект и выводит в окне консоли информацию об актуальном потоке, главном потоке и этом параметре. Это входные методы инициирующих операций, которые будут добавляться в операционную очередь.

Мы инициализируем два метода типа NSInvocationOperation и задаем целевой селектор в точке входа каждой операции (эти точки входа были описаны выше).

Затем инициализируем объект типа NSOperationQueue. (Он может создаваться и до того, как созданы методы входа.) Объект очереди будет обеспечивать параллелизм в работе операционных объектов. На данном этапе операционная очередь может немедленно начать (а может и не начать) запускать инициирующие операции, пользуясь их методами start. При этом очень важно помнить, что после добавления операции в операционную очередь от вас не требуется запускать операции вручную. Обеспечением запуска занимается операционная очередь.

Итак, еще раз запустим код примера и посмотрим, что же у нас на консоли:

[Running_Tasks_Asynchronously_with_OperationsAppDelegate firstOperationEntry: ]

Main thread is here

Parameter Object = 111

[Running_Tasks_Asynchronously_with_OperationsAppDelegate secondOperationEntry: ]

Main Thread = {name = (null), num = 1}

Parameter Object = 222

Current Thread = {name = (null), num = 3}

Main Thread = {name = (null), num = 1}

Current Thread = {name = (null), num = 4}

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

Main thread is here

[Running_Tasks_Asynchronously_with_OperationsAppDelegate firstOperationEntry: ]

[Running_Tasks_Asynchronously_with_OperationsAppDelegate secondOperationEntry: ]

Parameter Object = 111

Main Thread = {name = (null), num = 1}

Current Thread = {name = (null), num = 3}

Parameter Object = 222

Main Thread = {name = (null), num = 1}

Current Thread = {name = (null), num = 4}

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

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

Если обычные операции, являющиеся подклассами от NSOperation, добавлять в операционную очередь, то они будут работать асинхронно. Поэтому необходимо переопределить метод экземпляра isConcurrent, относящийся к классу NSOperation, и возвратить значение YES.

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

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

Переопределите методы isFinished и isExecuting операции и верните соответствующие логические (BOOL) значения, показывающие, завершена операция или продолжается в настоящий момент.

Вот объявление операции (.h-файл):

#import 

@interface SimpleOperation: NSOperation

/* Выделенный инициализатор */

— (id) initWithObject:(NSObject *)paramObject;

@end

Реализация операции такова:

#import «SimpleOperation.h»

@implementation SimpleOperation

— (instancetype) init {

return([self initWithObject:@123]);

}

— (instancetype) initWithObject:(NSObject *)paramObject{

self = [super init];

if (self!= nil){

/* Сохраните эти значения для главного метода. */

_givenObject = paramObject;

}

return(self);

}

— (void) main {

@try {

@autoreleasepool {

/* Сохраняем здесь локальную переменную, которая должна быть

установлена в YES всякий раз, когда мы завершаем

выполнение задачи. */

BOOL taskIsFinished = NO;

/* Создаем здесь цикл while, существующий лишь в том случае,

когда переменная taskIsFinished устанавливается в YES

или операция отменяется. */

while (taskIsFinished == NO &&

[self isCancelled] == NO){

/* Здесь выполняется задача. */

NSLog(@"%s", __FUNCTION__);

NSLog(@"Parameter Object = %@", givenObject);

NSLog(@"Main Thread = %@", [NSThread mainThread]);

NSLog(@"Current Thread = %@", [NSThread currentThread]);

/* Очень важно. Здесь мы можем выйти из цикла, по-прежнему

соблюдая правила, по которым отменяются операции. */

taskIsFinished = YES;

}

/* Соответствие KVO. Генерируем требуемые уведомления KVO. */

[self willChangeValueForKey:@"isFinished"];

[self willChangeValueForKey:@"isExecuting"];

finished = YES;

executing = NO;

[self didChangeValueForKey:@"isFinished"];

[self didChangeValueForKey:@"isExecuting"];

}

}

@catch (NSException * e) {

NSLog(@"Exception %@", e);

}

}

— (BOOL) isConcurrent{

return YES;

}

@end

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

@interface AppDelegate ()

@property (nonatomic, strong) NSOperationQueue *operationQueue;

@property (nonatomic, strong) SimpleOperation *firstOperation;

@property (nonatomic, strong) SimpleOperation *secondOperation;

@end

@implementation AppDelegate

Реализация делегата приложения такова:

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

NSNumber *firstNumber = @111;

NSNumber *secondNumber = @222;

self.firstOperation = [[SimpleOperation alloc]

initWithObject: firstNumber];

self.secondOperation = [[SimpleOperation alloc]

initWithObject: secondNumber];

self.operationQueue = [[NSOperationQueue alloc] init];

/* Добавляем операции в очередь. */

[self.operationQueue addOperation: self.firstOperation];

[self.operationQueue addOperation: self.secondOperation];

NSLog(@"Main thread is here");

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

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

Main thread is here

-[SimpleOperation main]

-[SimpleOperation main]

Parameter Object = 222

Parameter Object = 222

Main Thread = {name = (null), num = 1}

Main Thread = {name = (null), num = 1}

Current Thread = {name = (null), num = 3}

Current Thread = {name = (null), num = 4}

 

См. также

Разделы 7.11 и 7.15.

 

Постановка задачи

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

 

Решение

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

[self.firstOperation addDependency: self.secondOperation];

Свойства firstOperation и secondOperation относятся к типу NSInvocationOperation, подробнее об этом мы поговорим в подразделе «Обсуждение» данного раздела. В приведенном примере кода первая операция, находящаяся в операционной очереди, не будет выполняться до тех пор, пока не будет выполнена задача второй операции.

 

Обсуждение

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

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

#import «AppDelegate.h»

@interface AppDelegate ()

@property (nonatomic, strong) NSInvocationOperation *firstOperation;

@property (nonatomic, strong) NSInvocationOperation *secondOperation;

@property (nonatomic, strong) NSOperationQueue *operationQueue;

@end

@implementation AppDelegate

— (void) firstOperationEntry:(id)paramObject{

NSLog(@"First Operation — Parameter Object = %@",

paramObject);

NSLog(@"First Operation — Main Thread = %@",

[NSThread mainThread]);

NSLog(@"First Operation — Current Thread = %@",

[NSThread currentThread]);

}

— (void) secondOperationEntry:(id)paramObject{

NSLog(@"Second Operation — Parameter Object = %@",

paramObject);

NSLog(@"Second Operation — Main Thread = %@",

[NSThread mainThread]);

NSLog(@"Second Operation — Current Thread = %@",

[NSThread currentThread]);

}

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

NSNumber *firstNumber = @111;

NSNumber *secondNumber = @222;

self.firstOperation = [[NSInvocationOperation alloc]

initWithTarget: self

selector:@selector(firstOperationEntry:)

object: firstNumber];

self.secondOperation = [[NSInvocationOperation alloc]

initWithTarget: self

selector:@selector(secondOperationEntry:)

object: secondNumber];

[self.firstOperation addDependency: self.secondOperation];

self.operationQueue = [[NSOperationQueue alloc] init];

/* Добавляем операции в очередь. */

[self.operationQueue addOperation: self.firstOperation];

[self.operationQueue addOperation: self.secondOperation];

NSLog(@"Main thread is here");

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

Теперь после запуска программ вы увидите в окне консоли примерно следующее:

Second Operation — Parameter Object = 222

Main thread is here

Second Operation — Main Thread = {name = (null),

num = 1}

Second Operation — Current Thread = {name = (null),

num = 3}

First Operation — Parameter Object = 111

First Operation — Main Thread = {name = (null),

num = 1}

First Operation — Current Thread = {name = (null),

num = 3}

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

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

 

См. также

Раздел 7.12.

 

Постановка задачи

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

 

Решение

Воспользуйтесь таймером:

— (void) paint:(NSTimer *)paramTimer{

/* Делаем здесь что-либо. */

NSLog(@"Painting");

}

— (void) startPainting{

self.paintingTimer = [NSTimer

scheduledTimerWithTimeInterval:1.0

target: self

selector:@selector(paint:)

userInfo: nil

repeats: YES];

}

— (void) stopPainting{

if (self.paintingTimer!= nil){

[self.paintingTimer invalidate];

}

}

— (void)applicationWillResignActive:(UIApplication *)application{

[self stopPainting];

}

— (void)applicationDidBecomeActive:(UIApplication *)application{

[self startPainting];

}

Кроме того, метод invalidate будет высвобождать таймер сам и нам не придется делать это вручную. Как видите, мы определили свойство paintingTimer, которое следующим образом определяется в заголовочном файле (.h-файле):

#import «AppDelegate.h»

@interface AppDelegate ()

@property (nonatomic, strong) NSTimer *paintingTimer;

@end

@implementation AppDelegate

 

Обсуждение

Таймер — это объект, инициирующий определенное событие через заданные временные интервалы. Таймер должен быть запланирован в рабочем цикле. При определении объекта NSTimer создается незапланированный таймер, который ничего не делает, но остается в распоряжении программы на случай, если этот таймер понадобится запланировать. Как только будет сделан вызов вида scheduledTimerWithTimeInterval: target: selector: userInfo: repeats:, начинается работа запланированного таймера и будет инициировано затребованное вами событие. Запланированным называется такой таймер, который добавлен к рабочему циклу. Чтобы получить любой таймер и инициировать связанное с ним событие, таймер нужно запланировать в рабочем цикле. Это будет продемонстрировано в следующем примере, где мы создадим незапланированный таймер, а затем вручную запланируем его в главном рабочем цикле приложения.

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

Существуют различные способы создания, инициализации и планирования таймеров. Один из наиболее простых способов связан с использованием метода класса scheduledTimerWithTimeInterval: target: selector: userInfo: repeats:, относящегося к классу NSTimer. Далее перечислены параметры данного метода:

• scheduledTimerWithTimeInterval — количество секунд, в течение которого таймер должен ожидать, прежде чем запустит то или иное событие. Например, если вы хотите, чтобы таймер вызывал метод в своем целевом объекте дважды в секунду, то для этого параметра нужно установить значение 0.5 (1 секунда, деленная на 2). Если вы желаете, чтобы целевой метод вызывался четыре раза в секунду, то этот параметр должен иметь значение 0.25 (1 секунда, деленная на 4);

• target — объект, который будет получать событие;

• selector — сигнатура метода в том целевом объекте, который будет получать событие;

• userInfo — объект, который будет содержаться в таймере для дальнейшего пользования (в целевом методе целевого объекта);

• repeats — параметр указывает, как таймер должен вызывать целевой метод многократно (в таком случае данный параметр получает значение YES) или однократно (тогда этот параметр получит значение NO).

Как только таймер создан и добавлен к рабочему циклу, можно остановиться и высвободить этот таймер, воспользовавшись методом экземпляра invalidate, относящимся к классу NSTimer. Таким образом будет высвобожден не только таймер, но и объект (если имеется объект, который передан таймеру и который требуется сохранять на протяжении всего жизненного цикла таймера; например, объект может быть сообщен параметру userInfo метода класса scheduledTimerWithTimeInterval: target: selector: userInfo: repeats:, относящемуся к классу NSTimer). Если передать параметру repeats значение NO, то таймер самоуничтожится после первого прохода цикла и высвободит любой удерживаемый объект (при его наличии).

Есть и другие методы, с помощью которых можно создать запланированный таймер. Один из них — метод класса scheduledTimerWithTimeInterval: invocation: repeats:, относящийся к классу NSTimer:

— (void) paint:(NSTimer *)paramTimer{

/* Делаем здесь что-либо. */

NSLog(@"Painting");

}

— (void) startPainting{

/* Здесь находится селектор, который мы хотим вызвать. */

SEL selectorToCall = @selector(paint:);

/* Здесь на основе селектора составляется сигнатура метода.

Нам известно, что селектор относится к текущему классу,

поэтому составить сигнатуру метода совсем не сложно. */

NSMethodSignature *methodSignature =

[[self class] instanceMethodSignatureForSelector: selectorToCall];

/* Теперь основываем активизацию на сигнатуре метода. Данная активизация

требуется нам для того, чтобы запланировать таймер. */

NSInvocation *invocation =

[NSInvocation invocationWithMethodSignature: methodSignature];

[invocation setTarget: self];

[invocation setSelector: selectorToCall];

/* Теперь запускаем запланированный таймер. */

self.paintingTimer = [NSTimer scheduledTimerWithTimeInterval:1.0

invocation: invocation

repeats: YES];

}

— (void) stopPainting{

if (self.paintingTimer!= nil){

[self.paintingTimer invalidate];

}

}

— (void)applicationWillResignActive:(UIApplication *)application{

[self stopPainting];

}

— (void)applicationDidBecomeActive:(UIApplication *)application{

[self startPainting];

}

Планирование таймера можно сравнить с запуском автомобильного двигателя. Запланированный таймер — это работающий мотор. Незапланированный таймер — это мотор, который уже готов завестись, но пока не работает. Мы можем планировать и отменять (распланировать) таймер в любой момент работы приложения, точно так же как можем заводить и глушить двигатель, не выходя из машины. Если вы хотите вручную запланировать таймер на определенный момент жизненного цикла приложения, можно воспользоваться методом класса timerWithTimeInterval: target: selector: userInfo: repeats:, относящимся к классу NSTimer. Когда придет нужный момент, можно добавить таймер к интересующему вас рабочему циклу:

— (void) startPainting{

self.paintingTimer = [NSTimer timerWithTimeInterval:1.0

target: self

selector:@selector(paint:)

userInfo: nil

repeats: YES];

/* Здесь выполняется обработка, и когда наступает нужный момент,

задействуется метод экземпляра addTimer: forMode, относящийся к классу

NSRunLoop, чтобы запланировать данный таймер в этом рабочем цикле. */

[[NSRunLoop currentRunLoop] addTimer: self.paintingTimer

forMode: NSDefaultRunLoopMode];

}

Методы класса currentRunLoop и mainRunLoop, относящиеся к классу NSRunLoop, возвращают соответственно актуальный и главный рабочие циклы конкретного приложения, что понятно из их названий [7] .

Можно создавать запланированные таймеры с применением активизации, воспользовавшись вариантом с методом scheduledTimerWithTimeInterval: invocation: repeats:. С тем же успехом можно пользоваться методом класса timerWithTimeInterval: invocation: repeats:, относящимся к классу NSTimer, чтобы создать незапланированный таймер — также с применением активизации:

— (void) paint:(NSTimer *)paramTimer{

/* Делаем здесь что-нибудь. */

NSLog(@"Painting");

}

— (void) startPainting{

/* Здесь находится селектор, который мы хотим вызвать. */

SEL selectorToCall = @selector(paint:);

/* Здесь на основе селектора составляется сигнатура метода.

Нам известно, что селектор относится к текущему классу,

поэтому составить сигнатуру метода совсем не сложно. */

NSMethodSignature *methodSignature =

[[self class] instanceMethodSignatureForSelector: selectorToCall];

/* Теперь основываем активизацию на сигнатуре метода. Данная активизация

требуется нам для того, чтобы запланировать таймер. */

NSInvocation *invocation =

[NSInvocation invocationWithMethodSignature: methodSignature];

[invocation setTarget: self];

[invocation setSelector: selectorToCall];

self.paintingTimer = [NSTimer timerWithTimeInterval:1.0

invocation: invocation

repeats: YES];;

/* Здесь выполняется обработка, и когда наступает нужный момент,

задействуется метод экземпляра addTimer: forMode, относящийся к классу

NSRunLoop, чтобы запланировать данный таймер в данном рабочем цикле. */

[[NSRunLoop currentRunLoop] addTimer: self.paintingTimer

forMode: NSDefaultRunLoopMode];

}

— (void) stopPainting{

if (self.paintingTimer!= nil){

[self.paintingTimer invalidate];

}

}

— (void)applicationWillResignActive:(UIApplication *)application{

[self stopPainting];

}

— (void)applicationDidBecomeActive:(UIApplication *)application{

[self startPainting];

}

Целевой метод таймера получает экземпляр таймера, вызывающий его в качестве параметра. Например, метод paint:, показанный в начале данного раздела, демонстрирует, как таймер передается своему целевому методу — по умолчанию он (таймер) выступает в качестве единственного параметра целевого метода:

— (void) paint:(NSTimer *)paramTimer{

/* Что-то здесь делаем. */

NSLog(@"Painting");

}

Данный параметр дает нам ссылку на таймер, запускающий этот метод. Вы можете, например, при необходимости не допустить повторного запуска таймера — для этого используется метод invalidate. Кроме того, можно активизировать метод userInfo экземпляра класса NSTimer, чтобы получить объект, удерживаемый таймером (если такой объект имеется). Здесь мы имеем дело с обычным объектом, передаваемым методам инициализации NSTimer, затем этот объект передается непосредственно таймеру для дальнейшего пользования.

 

Постановка задачи

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

 

Решение

В приложении воспользуйтесь потоками. Это делается примерно так:

— (void) downloadNewFile:(id)paramObject{

@autoreleasepool {

NSString *fileURL = (NSString *)paramObject;

NSURL *url = [NSURL URLWithString: fileURL];

NSURLRequest *request = [NSURLRequest requestWithURL: url];

NSURLResponse *response = nil;

NSError *error = nil;

NSData *downloadedData =

[NSURLConnection sendSynchronousRequest: request

returningResponse:&response

error:&error];

if ([downloadedData length] > 0){

/* Загрузка завершена. */

} else {

/* Ничего загружено не было. Проверьте значение Error. */

}

}

}

— (void)viewDidLoad {

[super viewDidLoad];

NSString *fileToDownload = @"http://www.OReilly.com";

[NSThread detachNewThreadSelector:@selector(downloadNewFile:)

toTarget: self

withObject: fileToDownload];

}

 

Обсуждение

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

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

— (void) firstCounter{

NSUInteger counter = 0;

for (counter = 0;

counter < 1000;

counter++){

NSLog(@"First Counter = %lu", (unsigned long)counter);

}

}

— (void) secondCounter{

NSUInteger counter = 0;

for (counter = 0;

counter < 1000;

counter++){

NSLog(@"Second Counter = %lu", (unsigned long)counter);

}

}

— (void) thirdCounter{

NSUInteger counter = 0;

for (counter = 0;

counter < 1000;

counter++){

NSLog(@"Third Counter = %lu", (unsigned long)counter);

}

}

Очень просто, правда? Все циклы проходят от 0 до 1000, выводя на консоль номера счетчиков. Теперь предположим, что вы хотите, как обычно, запустить эти счетчики:

— (void) viewDidLoad{

[super viewDidLoad];

[self firstCounter];

[self secondCounter];

[self thirdCounter];

}

Этот код не обязательно должен находиться в методе viewDidLoad контроллера вида.

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

А что, если бы мы захотели запустить все счетчики одновременно? Разумеется, для каждого из них нам пришлось бы создать отдельный поток. Но подождите! Мы ведь уже знаем, что прямо при загрузке приложение само создает для нас потоки. Кроме того, весь код, который мы уже успели создать для приложения, когда бы он ни был написан, исполняется в полученном потоке. Итак, мы уже создали по потоку для первого и второго счетчиков, а третий счетчик будет работать в главном потоке:

— (void) firstCounter{

@autoreleasepool {

NSUInteger counter = 0;

for (counter = 0;

counter < 1000;

counter++){

NSLog(@"First Counter = %lu", (unsigned long)counter);

}

}

}

— (void) secondCounter{

@autoreleasepool {

NSUInteger counter = 0;

for (counter = 0;

counter < 1000;

counter++){

NSLog(@"Second Counter = %lu", (unsigned long)counter);

}

}

}

— (void) thirdCounter{

NSUInteger counter = 0;

for (counter = 0;

counter < 1000;

counter++){

NSLog(@"Third Counter = %lu", (unsigned long)counter);

}

}

— (void)viewDidLoad {

[super viewDidLoad];

[NSThread detachNewThreadSelector:@selector(firstCounter)

toTarget: self

withObject: nil];

[NSThread detachNewThreadSelector:@selector(secondCounter)

toTarget: self

withObject: nil];

/* Этот код запускаем в главном потоке. */

[self thirdCounter];

}

У метода thirdCounter нет автоматически высвобождаемого пула, поскольку он не работает в новом открепленном потоке. Этот метод будет выполняться в главном потоке приложения, а главный поток располагает автоматически высвобождаемым пулом. Данный пул создается автоматически при написании любого приложения Cocoa Touch.

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

Second Counter = 921

Third Counter = 301

Second Counter = 922

Second Counter = 923

Second Counter = 924

First Counter = 956

Second Counter = 925

First Counter = 957

Second Counter = 926

First Counter = 958

Third Counter = 302

Second Counter = 927

Third Counter = 303

Second Counter = 928

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

Каждый поток должен создавать автоматически высвобождаемый пул. Внутри такого пула содержатся ссылки на объекты, автоматически высвобождаемые до того, как будет высвобожден весь пул. Это очень важный механизм, действующий при управлении памятью с подсчетом ссылок в таких окружениях, как Cocoa Touch, то есть в средах, где объекты могут автоматически высвобождаться. Всякий раз при выделении экземпляра объекта количество ссылок на объект становится равным 1. Если пометить объекты как автоматически высвобождаемые, то количество ссылок на объект остается равным 1, но только до того момента, как высвободится тот пул, в котором создан объект. При высвобождении всего пула объект также получает сообщение release. Если на данный момент количество ссылок на объект так и осталось равным 1, объект высвобождается.

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

— (void) autoreleaseThread:(id)paramSender{

NSBundle *mainBundle = [NSBundle mainBundle];

NSString *filePath = [mainBundle pathForResource:@"AnImage"

ofType:@"png"];

UIImage *image = [UIImage imageWithContentsOfFile: filePath];

/* Делаем что-нибудь с изображением. */

NSLog(@"Image = %@", image);

}

— (void)viewDidLoad {

[super viewDidLoad];

[NSThread detachNewThreadSelector:@selector(autoreleaseThread:)

toTarget: self

withObject: self];

}

Если запустить этот код и одновременно следить за окном консоли, то можно увидеть примерно следующее сообщение:

*** __NSAutoreleaseNoPool(): Object 0x5b2c990 of

class NSCFString autoreleased with no pool in place — just leaking

*** __NSAutoreleaseNoPool(): Object 0x5b2ca30 of

class NSPathStore2 autoreleased with no pool in place — just leaking

*** __NSAutoreleaseNoPool(): Object 0x5b205c0 of

class NSPathStore2 autoreleased with no pool in place — just leaking

*** __NSAutoreleaseNoPool(): Object 0x5b2d650 of

class UIImage autoreleased with no pool in place — just leaking

Эти данные свидетельствуют о том, что созданный нами автоматически высвобождаемый экземпляр UIImage приводит к утечке памяти. Более того, утечку вызывают и экземпляр класса NSString под названием FilePath, а также другие объекты, которые в обычной ситуации спокойно высвободились бы. Дело в том, что при создании потока мы забыли первым делом выделить и инициализировать автоматически высвобождаемый пул — именно первым делом. Далее приведен правильный код. Можете сами его протестировать и убедиться, что никаких утечек не возникает:

— (void) autoreleaseThread:(id)paramSender{

@autoreleasepool {

NSBundle *mainBundle = [NSBundle mainBundle];

NSString *filePath = [mainBundle pathForResource:@"AnImage"

ofType:@"png"];

UIImage *image = [UIImage imageWithContentsOfFile: filePath];

/* Делаем что-то с изображением. */

NSLog(@"Image = %@", image);

}

}

— (void)viewDidLoad {

[super viewDidLoad];

[NSThread detachNewThreadSelector:@selector(autoreleaseThread:)

toTarget: self

withObject: self];

}

 

Постановка задачи

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

 

Решение

Воспользуйтесь методом экземпляра performSelectorInBackground: withObject:, относящимся к классу NSObject:

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

[self performSelectorInBackground:@selector(firstCounter)

withObject: nil];

[self performSelectorInBackground:@selector(secondCounter)

withObject: nil];

[self performSelectorInBackground:@selector(thirdCounter)

withObject: nil];

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

Методы счетчиков реализуются следующим образом:

— (void) firstCounter{

@autoreleasepool {

NSUInteger counter = 0;

for (counter = 0;

counter < 1000;

counter++){

NSLog(@"First Counter = %lu", (unsigned long)counter);

}

}

}

— (void) secondCounter{

@autoreleasepool {

NSUInteger counter = 0;

for (counter = 0;

counter < 1000;

counter++){

NSLog(@"Second Counter = %lu", (unsigned long)counter);

}

}

}

— (void) thirdCounter{

@autoreleasepool {

NSUInteger counter = 0;

for (counter = 0;

counter < 1000;

counter++){

NSLog(@"Third Counter = %lu", (unsigned long)counter);

}

}

}

 

Обсуждение

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

 

Постановка задачи

Требуется остановить поток или таймер либо не допустить его повторного запуска.

 

Решение

При работе с таймерами пользуйтесь методом экземпляра invalidate, относящимся к классу NSTimer. При работе с потоками используйте метод cancel. Старайтесь не применять метод exit при работе с потоками, так как он не позволяет потоку произвести после себя очистку, что в итоге приводит к утечке ресурсов из вашего приложения.

NSThread *thread = /* Здесь получаем ссылку на ваш поток. */;

[thread cancel];

NSTimer *timer = /* Здесь получаем ссылку на ваш таймер. */;

[timer invalidate];

 

Обсуждение

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

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

— (void) threadEntryPoint{

@autoreleasepool {

NSLog(@"Thread Entry Point");

while ([[NSThread currentThread] isCancelled] == NO){

[NSThread sleepForTimeInterval:4];

NSLog(@"Thread Loop");

}

NSLog(@"Thread Finished");

}

}

— (void) stopThread{

NSLog(@"Cancelling the Thread");

[self.myThread cancel];

NSLog(@"Releasing the thread");

self.myThread = nil;

}

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

self.myThread = [[NSThread alloc]

initWithTarget: self

selector:@selector(threadEntryPoint)

object: nil];

[self performSelector:@selector(stopThread)

withObject: nil

afterDelay:3.0f];

[self.myThread start];

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}

Данный код создает экземпляр класса NSThread и немедленно запускает поток. Поток в каждом цикле проводит 4 секунды в спящем режиме, а потом переходит к выполнению своей задачи. Тем не менее, прежде чем поток будет запущен, мы вызываем метод stopThread, относящийся к (написанному нами) контроллеру вида; это делается с трехсекундной задержкой. Данный метод вызывает метод cancel, относящийся к потоку, пытаясь заставить поток выйти из своего цикла. Теперь запустим приложение и посмотрим, что выводится в окне консоли:

…

Thread Entry Point

Cancelling the Thread

Releasing the thread

Thread Loop

Thread Finished

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

— (void) threadEntryPoint{

@autoreleasepool {

NSLog(@"Thread Entry Point");

while ([[NSThread currentThread] isCancelled] == NO){

[NSThread sleepForTimeInterval:4];

if ([[NSThread currentThread] isCancelled] == NO){

NSLog(@"Thread Loop");

}

}

NSLog(@"Thread Finished");

}

}

— (void) stopThread{

NSLog(@"Cancelling the Thread");

[self.myThread cancel];

NSLog(@"Releasing the thread");

self.myThread = nil;

}

— (BOOL) application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

self.myThread = [[NSThread alloc]

initWithTarget: self

selector:@selector(threadEntryPoint)

object: nil];

[self performSelector:@selector(stopThread)

withObject: nil

afterDelay:3.0f];

[self.myThread start];

self.window = [[UIWindow alloc] initWithFrame:

[[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible];

return YES;

}