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

Надо попробовать будет. Спасибо за опыт.

corristo 6 окт 2014 в 16:22

Да, вьюшка рендерится в невидимом симуляторе, который отдает в Interface Builder картинку.

visput 6 окт 2014 в 18:54

- (instancetype)initWithFrame:(CGRect)frame
{
    self = [self.class xxx_viewFromNib];
    self.frame = frame;
    return self;
}

А вот здесь у вас не будет двойного выделения памяти?
Ведь перед вызовом initWithFrame: разработчики вызывают alloc, а далее у Вас внутри вызывается метод класса [self.class xxx_viewFromNib], который возвращает новый объект. В результате изначальный alloc не имеет смысла.

corristo 6 окт 2014 в 19:06

Да, будет двойное выделение памяти, изначально выделенный участок памяти будет тут же освобожден. Учитывая, что UIView — достаточно легковесный объект (действительно «тяжелой» его частью является только backing store связанного CALayer, но его не может существовать до первой отрисовки, а тем более до вызова -init...), я бы не стал из-за этого беспокоиться, пока это действительно не станет бутылочным горлышком.

В общем-то все, что реализовано по паттерну class cluster в Cocoa как-то так и работает. Буду рад ошибаться.

corristo 6 окт 2014 в 19:18

Хотя нет, с class cluster можно организовать более эффективную схему, переопределив +allocWithZone: у корневого класса, чтоб он возвращал всегда один и тот же объект-плейсхолдер, тут так не получится.

visput 6 окт 2014 в 20:10

Все равно это мягко говоря «костыльно». По сути здесь наблюдается таже проблема, что и раньше: нельзя ложить в xib вью, которая реализована в другой xib.
Решалось это двумя способами:
1. Не использовать xib для вашей вью;
2. Добавлять вашу вью в коде, а не в xib.

IB_DESIGNABLE компоненты должны быть реализованы в коде, без использования xib.

corristo 6 окт 2014 в 20:12

3. использовать storyboard embed segue и UIVIewController вместо UIView ;)

Если уж так не нравится «костыль», можно обернуть его в #ifdef/#endif, чтоб -initWithFrame: присутствовал только в режиме live rendering.

IB_DESIGNABLE компоненты должны быть реализованы в коде, без использования xib.

Это где-то прямым текстом в докуентации Apple написано?

visput 6 окт 2014 в 20:33

Не знаю, написано ли там это. Я сделал такой вывод исходя из того, что Вы написали в статье.
Возможно я выразился слишком обобщенно. Нужно было сказать так:
«Исходя из информации в статье IB_DESIGNABLE компоненты нужно реализовать в коде, без использования xib, иначе будет выполняться двойное выделение памяти, что само по себе неправильно. Неважно 1 байт это или 1 мегабайт.»

По поводу #ifdef/#endif, не понял как это поможет решить проблему в runtime.

kostyl 7 окт 2014 в 23:11

А нельзя как то IB_DESIGNABLE обернуть в #ifdef? А то получается какая то ерунда, бандл меняется, вообще лучше бы не было этих аттрибутов… Или это только в симуляторе? Вообще я так и не понял, зачем что то передавать из симулятора в ХCode, ведь этот аттрибут нужен только для отображения в IB…

corristo 7 окт 2014 в 23:15

IB_DESIGNABLE влияет только на live rendering, и вся эта чехарда с бандлами тоже актальна только при live rendering. Просто так у вас в коде ничего не сломается.

Поясню про «передавать из симулятора в Xcode»:

Вы открываете в IB xib/storyboard, который содержит view, поддерживающий live rendering
Xcode собирает ваш проект в отдельную папочку
Xcode запускает в фоне симулятор iOS и просит его отрендерить view такого-то класса (который можно найти в бинарнике, полученном в п. 2) с такими-то параметрами
Симулятор рендерит вьюшку и отправляет обратно в Xcode изображение

corristo 7 окт 2014 в 23:23

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

kostyl 8 окт 2014 в 10:11

Спасибо за пояснения, теперь понятно. Ну в таком случае вроде как ничего страшного нету.

egormerkushev 30 ноя 2014 в 16:18

Вот хорошая статья про то же самое на Swift
justabeech.com/2014/07/27/xcode-6-live-rendering-from-nib/

Там обходят проблему Swift

Должен заметить, что в Swift такой трюк не пройдёт (так как там initializers похожи на конструкторы в Java или C++, то есть не могут подменить инициализируемый объект другим).

путем двойного вкладывания

CustomView
    CustomView
        UIImageView
        UILabel

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Пробуем Xcode Live Rendering

Комментарии 18

Публикации

Истории