Несмотря на то, что iPhone 5 и iPad 4 поставляются с мощным процессором A6 (X) и намного большим объемом оперативной памяти, чем у оригинального iPhone, это не означает, что приложения для iOS по определению являются быстрыми и производительными. В этом кратком совете я дам вам пять советов по повышению производительности приложений.
1. Кеширование
Если приложение iOS извлекает удаленный ресурс, важно, чтобы оно не извлекало те же самые ресурсы каждый раз, когда ему необходимо получить к нему доступ. Например, если вы планируете разработать клиент Twitter для iOS, клиенту не следует загружать один и тот же аватар каждый раз, когда ему нужно его отобразить. Кэширование аватара значительно улучшит производительность приложения.
Что такое кеширование? Основная идея кеширования проста. Когда приложение выбирает удаленный ресурс в первый раз, оно сохраняет копию этого ресурса на диске для последующего использования. Если этот же ресурс понадобится позже, приложение может загрузить его с диска, а не извлекать его удаленно. Дополнительным преимуществом является то, что ресурс также доступен, когда устройство не подключено к Интернету. Сложный аспект кэширования заключается в том, как хранить ресурс, когда его хранить и, что наиболее важно, когда его обновлять.
Оливье Poitrey разработал небольшую библиотеку под названием SDWebImage, которая предназначена для кэширования изображений. Он предоставляет категорию на UIImageView же, как и AFNetworking . Основное отличие состоит в том, что SDWebImage кэширует загружаемые изображения. Изображения загружаются в фоновом режиме, а каждое изображение распаковывается, что ускоряет загрузку. Библиотека использует Grand Central Dispatch для поддержки отзывчивости основного потока. Если ваше приложение работает с удаленными изображениями, вам стоит взглянуть на этот драгоценный камень.
2. Не блокируйте основной поток
Один из самых важных уроков при разработке для платформы iOS — никогда не блокировать основной поток. Если вы заблокируете основной поток с помощью длительной операции, такой как загрузка изображений или других ресурсов, ваше приложение перестанет отвечать на запросы, пока операция не будет завершена. Сделайте привычкой перемещать долго выполняющиеся задачи в фоновый поток. Даже если вам нужно всего лишь несколько байтов, если подключение устройства к сети медленное, операция все равно заблокирует основной поток.
Написание безопасного многопоточного кода стало намного проще с введением Grand Central Dispatch. Взгляните на следующие фрагменты кода. Первый фрагмент загружает данные в основной поток, а второй фрагмент использует Grand Central Dispatch для выполнения той же задачи в фоновой очереди.
|
1
2
3
|
NSData *data = [NSData dataWithContentsOfURL:URL];
UIImage *image = [UIImage imageWithData:data];
[imageView setImage:image];
|
|
01
02
03
04
05
06
07
08
09
10
|
dispatch_queue_t queue = dispatch_queue_create(«downloadAsset»,NULL);
dispatch_async(queue, ^{
NSData *data = [NSData dataWithContentsOfURL:URL];
dispatch_async(dispatch_get_main_queue(), ^{
UIImage *image = [UIImage imageWithData:data];
[imageView setImage:image];
});
});
|
3. Ленивая загрузка
Быть ленивым не всегда плохо, особенно если вы программист. Ленивая загрузка — это хорошо известная концепция в разработке программного обеспечения. Это просто означает, что вы откладываете создание объекта до тех пор, пока он вам не понадобится. Это выгодно по нескольким причинам. В зависимости от объекта и стоимости создания экземпляра это может значительно повысить производительность приложения и использование памяти. Ленивая загрузка объектов не является сложной концепцией. Простейшая реализация этого шаблона — переопределение метода получения свойства, как показано ниже.
|
1
2
3
4
5
6
7
|
— (MyClass *)myObject {
if (!_myObject) {
_myObject = [[MyClass alloc] init];
}
return _myObject;
}
|
Шаблон отложенной загрузки может применяться во многих областях разработки программного обеспечения. Например, если часть пользовательского интерфейса вашего приложения не отображается по умолчанию, может быть полезно отложить его создание до тех пор, пока эта часть не будет показана.
Представления таблиц и коллекций используют сочетание кэширования и отложенной загрузки для оптимизации производительности. Если следующая ячейка или элемент будет отображаться на экране, таблица или представление коллекции ищет ячейку или элемент, которые можно использовать повторно (кэширование). Только если нет доступных для повторного использования ячеек или элементов, таблица или представление коллекции (или их источник данных) будут создавать новую ячейку или элемент (отложенная загрузка).
4. Измерение производительности
Если вы замечаете, что ваше приложение иногда работает медленно, и вы хотите выяснить, что его вызывает, то вам может потребоваться профилировать ваше приложение с помощью такого инструмента, как Инструменты. Колин Руффенах написал хороший урок о профилировании времени с помощью инструментов на Mobiletuts +.
Если Instruments не дает четкого ответа, вас может заинтересовать MGBenchmark , библиотека для эталонного тестирования, разработанная и поддерживаемая Mattes Groeger . Эта компактная библиотека позволяет вам измерять скорость выполнения вашего кода и помогает выявлять узкие места в вашей кодовой базе. На самом деле он очень хорошо дополняет инструменты, поэтому не стоит использовать тот или другой. Библиотека Mattes Groeger поставляется с обширным набором функций и является удивительно мощным. Я настоятельно рекомендую его как альтернативу или дополнение к инструментам.
5. Стресс-тестирование
Если вы разрабатываете приложение, которое работает с большим количеством данных, важно протестировать его с … ну … большим количеством данных! Во время разработки приложения не всегда легко и невозможно представить, как ваши пользователи будут использовать ваше приложение, но хорошо бы проверить его скорость перед выпуском. Ваше приложение может работать превосходно во время разработки и работать ужасно в ситуациях, когда оно переполнено данными. Вы, вероятно, не сможете предсказать, не говоря уже о тестировании, все обстоятельства, в которых будет использоваться ваше приложение, но вы можете попытаться имитировать типичные ситуации, создавая наборы данных для тестирования.
Я часто создаю небольшой скрипт или класс, который заполняет приложение тестовыми данными, чтобы измерить, насколько хорошо оно работает с большим количеством данных. В идеале вы хотите заполнить приложение большим количеством тестовых данных, чем будет у обычного пользователя — в той степени, в которой вы можете предсказать это во время разработки. Когда я разрабатывал Pixelsync, приложение для iPad, которое взаимодействует с Aperture и iPhoto, я создал библиотеку Aperture с почти 500 000 изображений. Если бы Pixelsync работал хорошо с библиотекой фотографий такого размера, я мог бы быть вполне уверен, что обычный пользователь не столкнется с проблемами производительности.
Если вы действительно ленивый разработчик или вам просто не хватает времени, то вы также можете проявить творческий подход, создав робота, который сделает всю работу за вас .
Вывод
Производительность приложений остается важным аспектом разработки программного обеспечения, несмотря на то, что устройства нового поколения гораздо более мощные и функциональные. Например, блокировка основного потока всегда приведет к ухудшению работы пользователя, независимо от того, насколько оно способно.