Настройка для производительности и скорости отклика
Поскольку Вы разрабатываете свое приложение, и Ваш код проекта стабилизировался, можно начать настройку производительности. Конечно, Вы хотите, чтобы Ваше приложение запустило и реагировало на команды пользователя как можно быстрее. Быстро реагирующее приложение соответствует легко потоку операций пользователя и чувствует себя хорошо обработанным.
Ускорьте время запуска своего приложения
Можно улучшить производительность приложения во время запуска путем минимизации или задержки работы, пока не завершилась последовательность запуска. Запуск приложения предоставляет пользователям первое впечатление от Вашего приложения, и это - что-то, что они видят регулярно.
Ваша переопределяющая цель во время запуска должна состоять в том, чтобы вывести на экран строку меню приложения и главное окно и затем начать отвечать на пользовательские команды как можно быстрее. Создание Вашего приложения, быстро реагирующего к командам быстро, предоставляет лучший опыт пользователю. Следующие разделы обеспечивают некоторые общие советы о том, как заставить Ваше приложение запуститься быстрее.
Код инициализации задержки
Много приложений тратят много кода инициализации времени, не использующегося до намного позже. Задержка инициализации подсистем, которые не сразу необходимы, может ускорить Ваше время запуска значительно. Помните, что цель состоит в том, чтобы вывести на экран Ваш интерфейс приложения быстро, так попытайтесь инициализировать только подсистемы, связанные с той целью первоначально.
Как только Вы отправили свой интерфейс, Ваше приложение может продолжать инициализировать дополнительные подсистемы по мере необходимости. Однако помните, что просто, потому что Ваше приложение в состоянии обработать команды, не означает, что Вам нужен весь тот код сразу же. Предпочтительный способ инициализировать подсистемы по мере необходимости. Ожидайте, пока пользователь не выполняет команду, требующую определенной подсистемы, и затем инициализируйте его. Тот путь, если пользователь никогда не выполняет команду, Вы не будете тратить впустую времени, выполняя код для подготовки к ней.
Избегите вставлять много посторонней инициализации, кодируют Ваш awakeFromNib методы. Системные вызовы awakeFromNib метод Вашего основного файла пера перед Вашим приложением вводит свой основной цикл событий. Используйте тот метод, чтобы инициализировать объекты в том пере и подготовить Ваш интерфейс приложения. Для всей другой инициализации используйте applicationDidFinishLaunching: метод Вашего NSApplicationDelegate объект вместо этого. Для получения дополнительной информации о файлах пера и как они загружаются, см. Руководство по программированию Ресурса.
Упростите свой основной файл пера
Загрузка файла пера является дорогим процессом, который может замедлить Ваше время запуска приложения, если Вы не осторожны. Когда файл пера загружается, все объекты в том файле инстанцируют и готовят для использования. Чем больше объектов, которые Вы включаете в основное перо своего приложения, тем больше времени оно берет, чтобы загрузить тот файл и запустить Ваше приложение.
Процесс инстанцирования для объектов в файле пера требует, чтобы любые платформы, используемые теми объектами, самостоятельно находились в памяти. Таким образом загрузка пера для приложения Какао, вероятно, потребовала бы загрузки и платформ AppKit и Основы, если бы они не были уже резидентными в памяти. Точно так же, если Вы объявляете пользовательский класс в своем основном файле пера, и тот класс полагается на другие платформы, система должна загрузить те платформы также.
При разработке основного файла пера приложения необходимо включать только те объекты, должен был вывести на экран интерфейс исходного пользователя приложения. Обычно, это включило бы просто строку меню Вашего приложения и начальное окно. Для любых пользовательских классов Вы включаете в перо, удостоверьтесь, что их код инициализации максимально минимален. Задержите любые длительные операции или выделения памяти, пока не инстанцируют класс.
Минимизируйте глобальные переменные
И для приложений и для платформ, бояться объявлять глобальные переменные, требующие существенного количества инициализации. Система инициализирует глобальные переменные прежде, чем вызвать Ваше приложение main подпрограмма. При использовании глобальной переменной для объявления объекта, система должна вызвать конструктора или метод инициализации для того объекта в течение времени запуска. В целом, когда можно использовать указатель вместо этого, лучше избегать объявлять объекты как глобальные переменные в целом.
При реализации платформы или какого-либо типа модуля повторно используемого кода необходимо также минимизировать число глобальных переменных, которые Вы объявляете. Каждое приложение, соединяющееся с платформой, получает копию глобальных переменных той платформы. Эти переменные могли бы потребовать нескольких страниц виртуальной памяти, тогда увеличивающей объем потребляемой памяти приложения. Увеличенный объем потребляемой памяти может привести к разбивке на страницы в приложении, оказывающем огромное влияние на производительность.
Один способ минимизировать глобальные переменные в платформе состоит в том, чтобы сохранить переменные в a malloc- выделенный блок памяти вместо этого. В этом методе Вы получаете доступ к переменным через указатель на память, которую Вы храните как глобальная переменная. Другое преимущество этого метода состоит в том, что он позволяет Вам задерживать создание любых глобальных переменных до первого раза, когда они фактически используются. Посмотрите Подсказки для Выделения Памяти в Инструкциях по Производительности Использования памяти для получения дополнительной информации.
Минимизируйте доступ к файлу во время запуска
Доступ к файлу является одной из самых медленных операций, выполняемых на компьютере, таким образом, важно, чтобы Вы сделали это как можно меньше, особенно во время запуска. Всегда существует некоторый доступ к файлу, который должен произойти во время запуска, такое как загрузка Вашего исполняемого кода и чтение в Вашем основном файле пера, но сокращение Вашей начальной зависимости от файлов запуска может обеспечить значительные улучшения скорости.
Если можно задержать чтение файла до окончания времени запуска, сделайте так. Следующий список включает некоторые файлы, в содержании которых Вы, возможно, не нуждаетесь до окончания запуска:
Платформы, не используемые непосредственно Вашим приложением — Избегают кода вызова, использующего несущественные платформы до окончания запуска.
Файлы пера, содержание которых сразу не выведено на экран — Удостоверяются Ваши файлы пера и
awakeFromNib:код не делает слишком много во время запуска. Посмотрите Упрощают Ваш Основной Файл Пера для получения дополнительной информации.Файлы пользовательской настройки — Пользовательские настройки могут не быть локальными так читает их позже, если Вы можете.
Файлы шрифтов — Рассматривают задерживающуюся инициализацию шрифта, пока не запустилось приложение.
Сетевые файлы — Избегают читать файлы, расположенные в сети если вообще возможный.
Если необходимо считать файл во время запуска, сделайте так только один раз. Если Вы нуждаетесь в многократных частях данных от того же файла, такой как от предпочтительного файла, рассматриваете чтение всех данных один раз вместо того, чтобы получить доступ к файлу многократно.
Не блокируйте основной поток
Основной поток - то, где Ваше приложение обрабатывает пользовательские события и другой ввод, таким образом, необходимо сохранить свободным как можно больше быть быстро реагирующими пользователю. В частности никогда не используйте основной поток для выполнения продолжительных или потенциально неограниченных задач, таких как задачи, требующие доступа к сети. Вместо этого всегда переходите те задачи на фоновые потоки. Предпочтительный способ сделать так состоит в том, чтобы использовать Grand Central Dispatch (GCD) или объекты операции для выполнения задач асинхронно.
Для получения дополнительной информации о выполнении работы на фоновых потоках, см. Руководство по программированию Параллелизма.
Уменьшите размер кода своего приложения
В контексте производительности, чем больше памяти Ваше приложение занимает, тем более неэффективный это. Больше памяти означает больше выделений памяти, больше кода и больший потенциал для разбивки на страницы.
Сокращение Вашего места кода не является просто вопросом включения оптимизации кода в Вашем компиляторе, несмотря на то, что это действительно помогает. Можно также сократить место кода путем организации кода так, чтобы только минимальный набор требуемых функций был в памяти в любой момент времени. Вы реализуете эту оптимизацию путем профилирования кода.
См. “Инструменты Памяти” в Инструментальном Руководстве пользователя для получения информации о профилировании выделений памяти Вашего приложения.
Оптимизация уровня компилятора
Компилятор XCode поддерживает опции оптимизации, позволяющие Вам выбрать, предпочитаете ли Вы меньший двоичный размер, быстрее кодируете, или более быстрое время изготовления. Для новых проектов XCode автоматически отключает оптимизацию для конфигурации отладочной сборки и выбирает Fastest, опцию Smallest для конфигурации сборки конечных версий. Оптимизация кода любого доброго результата в более медленное время изготовления из-за дополнительной работы, вовлеченной в процесс оптимизации. Если Ваш код изменяется, как он делает во время цикла разработки, Вы не хотите включенную оптимизацию. Как Вы около конца Вашего цикла разработки, тем не менее, конфигурация сборки конечных версий может дать Вам индикацию относительно размера Вашего готового продукта, таким образом, Самая быстрая, опция Smallest является надлежащей.
Таблица 6-1 перечисляет уровни оптимизации, доступные в XCode. При выборе одной из этих опций XCode передает надлежащие флаги компилятору для данной группы или файлов. Эти опции доступны на целевом уровне или как часть конфигурации сборки. Посмотрите Руководство по Системе сборки XCode для получения информации о работе с настройками сборки для Вашего проекта.
Как с любым улучшением производительности, не делайте предположения, о которых опция даст Вам лучшие результаты. Необходимо всегда измерять результаты каждой оптимизации, которую Вы пробуете. Например, опция Fastest могла бы генерировать чрезвычайно быстрый код для определенного модуля, но это обычно делает так за счет исполнимого размера. Любая скорость способствует Вам, усиление от генерации кода легко потеряно, если код должен быть разбит на страницы в от диска во время выполнения.
Используйте базовые данные для больших наборов данных
Если Ваше приложение управляет большими суммами структурированных данных, сохраните его в Базовых Данных персистентное хранилище или в базе данных SQLite вместо в плоском файле. И Базовые Данные и SQLite обеспечивают эффективные способы управлять большими наборами данных, не требуя, чтобы весь набор был в памяти одновременно. Используйте SQLite, если Вы имеете дело с низкоуровневыми структурами данных или существующей базой данных SQLite. Базовые Данные обеспечивают высокоуровневую абстракцию для эффективного управления графа объектов с интерфейсом Objective-C; это - однако, усовершенствованная платформа, и Вы не должны использовать его, пока Вы не получили соответствующий опыт.
Для получения дополнительной информации о Базовых Данных, см. Базовое Руководство по программированию Данных и Оптимизирующий Базовые Данные с Инструментами.
Устраните утечки памяти
Ваше приложение не должно иметь никаких утечек памяти. Можно использовать Инструментальное приложение для разыскивания утечек в коде, и в средстве моделирования и на существующих устройствах. См. “Инструменты Памяти” в Инструментальном Руководстве пользователя для получения информации о нахождении утечек памяти.
Мертвая полоса Ваш код
Для статически соединенных исполнимых программ разделение невыполняемого кода является процессом удаления не имеющего ссылки кода от исполняемого файла. Если код является не имеющим ссылки, он не должен использоваться и поэтому не необходим в исполняемом файле. Удаление невыполняемого кода сокращает размер Вашей исполнимой программы и может помочь сократить разбивку на страницы.
Для включения разделения невыполняемого кода в XCode, в Соединении группы Настроек Сборки, устанавливают опцию Dead Code Stripping в Да.
Информация о символе полосы
Отладочная информация и информация о динамическом связывании могут привести много в рабочее состояние пространства и включить большой процент размера Вашей исполнимой программы. Прежде, чем поставить Ваш код, необходимо разделить все ненужные символы.
Для разделения отладочной информации от исполнимой программы измените опцию Generate Debug Symbols компиляторной генерации кода XCode на номер, можно также генерировать отладочную информацию на основе цели целью, если Вы предпочитаете. Посмотрите Справку XCode для получения дополнительной информации о конфигурациях сборки и предназначайтесь для настроек.