Всегда мера

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

Используйте масштабируемую архитектуру

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

Не боритесь с платформой

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

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

Знайте о неопределенных операциях времени

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

Рассмотрите данные, кэширующиеся тщательно

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

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

Задержите операции каждый раз, когда возможно

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

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

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

Задержите дисплей динамично обновленных данных

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

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

  Отмена перечисления 1 и перезапуск reloadData работы

// Cancel the old request

[NSObject cancelPreviousPerformRequestsWithTarget:myTableView selector:@selector(reloadData) object:nil];

// Initiate a new request after a brief delay.

[myTableView performSelector:@selector(reloadData) withObject:nil afterDelay:0.3];

Используйте двоичную сериализацию каждый раз, когда возможно

При использовании информации о списке свойств класса чтения и записи NSPropertyListSerialization необходимо отформатировать файлы списка свойств как двоичный XML, когда это возможно. Двоичные данные значительно более компактны, чем его основанный на тексте дубликат. В результате чтение и запись основанных на двоичном файле данных значительно быстрее (часто в 5 - 20 раз быстрее), чем чтение и запись соответствующих основанных на тексте данных.

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

Для получения дополнительной информации о списках свойств и форматах двоичного файла, см. Руководство по программированию Списка свойств.