Цикл рисования представления

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

Когда представление сначала показано или когда часть представления должна быть перерисована, iOS просит, чтобы представление нарисовало свое содержание путем вызова представления drawRect: метод.

Существует несколько действий, которые могут инициировать обновление представления:

• Перемещение или удаление другого представления, частично затенявшего представление

• Создание ранее скрытого представления, видимого снова путем установки скрытый свойство к NO

• Прокрутка представления прочь экрана и затем назад на экран

• Явно вызов setNeedsDisplay или setNeedsDisplayInRect: метод Вашего представления

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

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

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

Системы координат и Рисующий в iOS

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

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

Кроме того, как показано на рисунке 1-1, каждый графический контекст имеет систему координат. Более точно каждый графический контекст имеет три системы координат:

• Получение (пользователь) система координат. Эта система координат используется при выпуске команд рисования.

• Система координат представления (базируют пространство). Эта система координат является фиксированной системой координат относительно представления.

• (Физическая) система координат устройства. Эта система координат представляет пиксели на физическом экране.

Платформы получения iOS создают графические контексты для рисования определенным местам назначения — экран, битовые массивы, содержание PDF, и т.д. — и эти графические контексты устанавливают начальную систему координат получения для того места назначения. Эта начальная система координат получения известна как система координат по умолчанию и 1:1 отображающийся на базовую систему координат представления.

Каждое представление также имеет текущую матрицу преобразования (CTM), математическая матрица, отображающая точки в текущей системе координат получения к (фиксированной) системе координат представления. Приложение может изменить эту матрицу (как описано позже) для изменения поведения будущих операций рисования.

Каждая из платформ получения iOS устанавливает систему координат по умолчанию на основе текущего графического контекста. В iOS существует два основных типа систем координат:

• Система координат верхнего левого источника (ULO), в котором источник операций рисования в верхнем левом углу области получения с положительными значениями, расширяющимися вниз и вправо. Система координат по умолчанию, используемая UIKit и Базовыми платформами Анимации, основана на ULO.

• Система координат нижнего левого источника (ЛЛО), в котором источник операций рисования в нижнем левом углу области получения с положительными значениями, расширяющимися вверх и вправо. Система координат по умолчанию, используемая Базовой Графической платформой, НАХОДИТСЯ В ЛЛО.

Эти системы координат показаны на рисунке 1-2.

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

Точки по сравнению с пикселями

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

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

• Одна точка не обязательно соответствует одному физическому пикселю.

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

В iOS, UIScreen, UIView, UIImage, и CALayer классы обеспечивают свойства, чтобы получить (и, в некоторых случаях, установить) масштабный коэффициент, описывающий отношение между точками и пикселями для того определенного объекта. Например, каждое представление UIKit имеет a contentScaleFactor свойство. На экране стандартного разрешения масштабный коэффициент обычно 1.0. На экране с высокой разрешающей способностью масштабный коэффициент обычно 2.0. В будущем другие масштабные коэффициенты могут также быть возможными. (В iOS до версии 4 необходимо принять масштабный коэффициент 1,0.)

Собственные технологии получения, такие как Базовая Графика, принимают текущий масштабный коэффициент во внимание для Вас. Например, если одно из Ваших представлений реализует a drawRect: метод, UIKit автоматически устанавливает масштабный коэффициент для того представления к масштабному коэффициенту экрана. Кроме того, UIKit автоматически изменяет текущую матрицу преобразования любых графических контекстов, используемых во время рисования для принятия во внимание масштабного коэффициента представления. Таким образом любое содержание Вы подходите к концу Ваш drawRect: метод масштабируется соответственно для экрана базового устройства.

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

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

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

То, где масштабный коэффициент играет роль, при определении, сколько пикселей покрыто одной точкой широкая строка.

На дисплее с низкой разрешающей способностью (с масштабным коэффициентом 1,0), одна точка широкая строка один пиксель шириной. Чтобы избежать сглаживаться при рисовании одной точки широкая горизонтальная или вертикальная строка если строка является нечетным числом пикселей по ширине, необходимо сместить позицию 0,5 точками любой стороне позиции с целым номером. Если строка является четным числом точек по ширине, для предотвращения нечеткой строки, Вы не должны делать так.

На дисплее с высокой разрешающей способностью (с масштабным коэффициентом 2,0), строка, которая является одной широкой точкой, не сглаживается вообще, потому что это занимает два полных пикселя (от-0.5 до +0.5). Чтобы чертить линию, который покрывает только единственный физический пиксель, необходимо было бы сделать его 0,5 точками в толщине и сместить ее позицию 0,25 точками. Сравнение между двумя типами экранов показано на рисунке 1-4.

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

Получение графических контекстов

Большую часть времени графические контексты сконфигурированы для Вас. Каждый объект представления автоматически создает графический контекст так, чтобы Ваш код мог начать рисовать сразу как только Ваше пользовательское drawRect: метод вызывают. Как часть этой конфигурации, базового UIView класс создает графический контекст (a CGContextRef непрозрачный тип) для текущей среды получения.

Если Вы хотите нарисовать где-нибудь кроме Вашего представления (например, получить ряд операций рисования в PDF или растровом файле), или если необходимо вызвать Базовые Графические функции, требующие объекта контекста, необходимо предпринять дополнительные шаги для получения графического объекта контекста. Разделы ниже объясняют как.

Для получения дополнительной информации о графических контекстах, изменяя информацию о состоянии графики, и с помощью графических контекстов для создания пользовательского содержания посмотрите Кварц 2D Руководство по программированию. Для списка функций, используемых в сочетании с графическими контекстами, см. Ссылку CGContext, Ссылку CGBitmapContext и Ссылку CGPDFContext.

Цветовые и цветовые пространства

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

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

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

Конфигурирование графического контекста

Прежде, чем вызвать Ваш drawRect: метод, объект представления создает графический контекст и устанавливает его как текущий контекст. Этот контекст существует только для времени жизни drawRect: вызвать. Можно получить указатель на этот графический контекст путем вызова UIGraphicsGetCurrentContext функция. Эта функция возвращает ссылку на a CGContextRef введите, который Вы передаете Базовым Графическим функциям для изменения текущего состояния графики. Таблица 1-1 перечисляет основные функции, которые Вы используете для установки различных аспектов состояния графики. Для полного списка функций см. Ссылку CGContext. Эта таблица также приводит альтернативы UIKit, где они существуют.

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

Для получения общей информации о графических контекстах и использовании их для конфигурирования среды получения посмотрите Графические Контексты в Кварце 2D Руководство по программированию.

Создание и рисование путей

Путь является основанными на векторе формами, создаваемыми из последовательности кривых Bézier и строк. UIKit включает UIRectFrame и UIRectFill функции (среди других) для рисования простых контуров, таких как прямоугольники в Ваших представлениях. Базовая Графика также включает функции удобства для создания простых контуров, таких как прямоугольники и замещающие знаки.

Для более сложных контуров необходимо создать путь сами с помощью UIBezierPath класс UIKit или использование функций, воздействующих на CGPathRef непрозрачный тип в Базовой Графической платформе. Несмотря на то, что можно создать путь без графического контекста с помощью любого API, точки по пути все еще должны относиться к текущей системе координат (который или имеет ULO или ориентацию ЛЛО), и Вам все еще нужен графический контекст для фактического рендеринга пути.

При рисовании пути необходимо было установить текущий контекст. Этот контекст может быть контекстом пользовательского представления (в drawRect:), растровый контекст или контекст PDF. Система координат определяет, как представляется путь. UIBezierPath принимает систему координат ULO. Таким образом, если Ваше представление зеркально отражается (для использования координат ЛЛО), получающаяся форма может представить по-другому, чем предназначенный. Для лучших результатов необходимо всегда указывать точки относительно источника текущей системы координат графического контекста, используемого для рендеринга.

Для создания путей в iOS рекомендуется использовать UIBezierPath вместо CGPath функции, если Вам не нужны некоторые возможности, что только Базовая Графика обеспечивает, такие как добавляющие замещающие знаки к путям. Для больше при создании и рендеринге путей в UIKit, посмотрите, что Формы Получения Используют Пути Bézier.

Для получения информации об использовании UIBezierPath для рисования путей посмотрите, что Формы Получения Используют Пути Bézier. Для получения информации о том, как нарисовать пути с помощью Базовой Графики, включая информацию о том, как Вы указываете точки для элементов сложного контура, посмотрите Пути в Кварце 2D Руководство по программированию. Для получения информации о функциях Вы используете, чтобы создать пути, видеть Ссылку CGContext и Ссылку CGPath.

Создавая образцы, градиенты и штриховки

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

Подробные данные для создания и использования образцов, градиентов и штриховок все покрыты Кварцем 2D Руководство по программированию.

Настройка координатного пространства

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

Когда Ваше представление drawRect: метод сначала вызывают, CTM сконфигурирован так, чтобы источник системы координат соответствовал источник Вашего представления, его положительная ось X расширяется вправо, и его положительная ось Y расширяется вниз. Однако можно изменить CTM путем добавления масштабирования, вращения и факторов перевода к нему и таким образом изменить размер, ориентацию и позицию системы координат по умолчанию относительно базового представления или окна.

CGContextSaveGState(graphicsContext);

CGContextTranslateCTM(graphicsContext, 0.0, imageHeight);

CGContextScaleCTM(graphicsContext, 1.0, -1.0);

CGContextDrawImage(graphicsContext, image, CGRectMake(0, 0, imageWidth, imageHeight));

CGContextRestoreGState(graphicsContext);

Побочные эффекты рисования с различными системами координат

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

Дуги и вращения

Если Вы рисуете путь с функциями такой как CGContextAddArc и CGPathAddArc и примите систему координат ЛЛО, тогда необходимо зеркально отразить CTM для рендеринга дуги правильно в представлении UIKit. Однако при использовании той же функции, чтобы создать дугу с точками, расположенными в системе координат ULO и затем представить путь в представлении UIKit, Вы заметите, что дуга является измененной версией своего оригинала. Завершающаяся конечная точка дуги теперь указывает в противоположном направлении того, что сделала бы та конечная точка, было создаваемое использование дуги UIBezierPath класс. Например, указывающая вниз стрелка теперь указывает вверх (как показано на рисунке 1-5), и направление, в котором «изгибается» дуга, также отличается. Необходимо изменить направление Базовых Нарисованных из графики дуг для учета основанной на ULO системы координат; этим направлением управляют startAngle и endAngle параметры тех функций.

Можно наблюдать тот же вид зеркального отражения эффекта при вращении объекта (например, путем вызова CGContextRotateCTM). Если Вы поворачиваете объект с помощью Базовых Графических вызовов, ссылающихся на систему координат ULO, направление объекта, когда представлено в UIKit изменено. Необходимо составить различные направления вращения в коде; с CGContextRotateCTM, Вы делаете это путем инвертирования знака angle параметр (так, например, отрицательная величина становится положительным значением).

Тени

Направление тень падает от своего объекта, указано значением смещения, и значение того смещения является соглашением платформы получения. В UIKit положительные смещения x и y заставляют тень потерять работоспособность и направо от объекта. В Базовой Графике положительные смещения x и y заставляют тень восстановить работоспособность и направо от объекта. Зеркальное отражение CTM для выравнивания объекта с системой координат по умолчанию UIKit не влияет на тень объекта, и таким образом, тень правильно не отслеживает свой объект. Чтобы заставить его отслеживать правильно, необходимо изменить значения смещения соответственно для текущей системы координат.

Об уровнях

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

• Можно присвоить a CGImageRef к contents свойство расположенного на слое объекта.

• Можно присвоить делегата в уровне и позволить делегату обработать получение.

• Можно разделить на подклассы CALayer и переопределите один из методов дисплея.

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

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

Об анимациях

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

Базовая Анимация также позволяет Вам собрать в группу многократные анимации в единый блок, названный транзакцией. CATransaction объект управляет группой анимаций как модуль. Можно также использовать методы этого класса для установки продолжительности анимации.

Для примеров того, как создать пользовательские анимации, посмотрите Типы Анимации и Синхронизирующий Руководство по программированию.

Учет масштабных коэффициентов в базовых слоях анимации

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

• Создает дополнительные Базовые Слои анимации с различными масштабными коэффициентами и составляет их в его собственное содержание

• Наборы contents свойство Базового Слоя анимации непосредственно

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

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

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