Не думаю, что где-то записано правило, но, надеюсь, это поможет:
Сначала давайте уточним некоторые определения. Я думаю, что внеэкранный или экранный рендеринг в большинстве случаев не является главной проблемой, потому что рендеринг за кадром может быть таким же быстрым, как и на экране. Основная проблема заключается в том, выполняется ли рендеринг аппаратно или программно.
Существует также очень небольшая практическая разница между использованием слоев и представлений. Представления являются лишь тонкой оболочкой для CALayer, и большую часть времени они не приводят к значительному снижению производительности. Вы можете переопределить тип слоя, используемого представлением, используя метод + layerClass, если вы хотите, чтобы представление поддерживалось CAShapeLayer или CATileLayer и т. Д.
Как правило, в iOS пиксельные эффекты и графика Quartz / Core Graphics не ускоряются аппаратно, как и большинство других.
Следующие вещи не ускоряются аппаратно, а это значит, что их нужно делать программно (за кадром):
Все, что сделано в drawRect. Если у вашего вида есть drawRect, даже пустой, рисование не выполняется аппаратно, и снижается производительность.
Любой слой со свойством shouldRasterize, установленным в YES.
Любой слой с маской или тенью.
Текст (любой вид, включая UILabels, CATextLayers, Core Text и т. Д.).
Любой рисунок, который вы делаете самостоятельно (на экране или вне экрана) с использованием CGContext.
Большинство других вещей с аппаратным ускорением, поэтому они намного быстрее. Однако это может не означать, что вы думаете.
Любой из вышеперечисленных типов рисования является медленным по сравнению с аппаратным ускорением рисования, однако они не обязательно замедляют ваше приложение, потому что они не должны происходить каждый кадр. Например, рисование тени на виде в первый раз происходит медленно, но после его рисования оно кэшируется и перерисовывается, только если вид меняет размер или форму.
То же самое относится и к растеризованным представлениям или представлениям с пользовательским drawRect: представление обычно не перерисовывается каждый кадр, оно рисуется один раз, а затем кэшируется, поэтому производительность после того, как представление впервые настроено, не хуже, если только границы меняются или вы вызываете setNeedsDisplay для него.
Для хорошей производительности хитрость заключается в том, чтобы не использовать программный чертеж для видов, которые меняют каждый кадр. Например, если вам нужна анимированная векторная фигура, вы получите лучшую производительность, используя CAShapeLayer или OpenGL, чем drawRect и Core Graphics. Но если вы нарисуете фигуру один раз, а затем ее менять не нужно, это не будет иметь большого значения.
Точно так же, не помещайте тень на анимированный вид, потому что это замедлит вашу частоту кадров. Но тень на виде, которая не меняется от кадра к кадру, не окажет большого негативного влияния.
Еще одна вещь, на которую следует обратить внимание, это замедление установки времени просмотра. Например, предположим, что у вас есть страница текста с тенями по всему тексту; Первоначально на рисование уйдет очень много времени, поскольку и текст, и тени должны быть отрисованы программно, но после отрисовки это будет быстро. Поэтому вы захотите настроить это представление заранее, когда ваше приложение загружается, и сохранить его копию в памяти, чтобы пользователю не приходилось долго ждать отображения представления, когда оно впервые появляется на экране.
Это, вероятно, причина очевидного противоречия в видео WWDC. Для больших сложных представлений, которые не изменяют каждый кадр, их отрисовка один раз в программном обеспечении (после чего они кэшируются и не нуждаются в перерисовке) даст лучшую производительность, чем аппаратная перекомпоновка каждого кадра, даже если рисовать будет медленнее в первый раз.
Но для представлений, которые должны постоянно перерисовываться, например для ячеек таблицы (ячейки перерабатываются, поэтому они должны перерисовываться каждый раз, когда одна ячейка прокручивается за пределами экрана и используется повторно, когда она переходит обратно на другую сторону в виде другой строки),рисование программного обеспечения может сильно замедлить процесс.