Проблема с производительностью автомакета iOS в портретном режиме. [Оптимизация NSISEngine]

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

Я также открыл билет поддержки по этой проблеме.

Обновлять:

Я нашел причину в моей ситуации. Это был следующий набор ограничений:

NSArray *constraints = [NSLayoutConstraint
                        constraintsWithVisualFormat : @"|[sunLabel][monLabel(==sunLabel)][tueLabel(==sunLabel)][wedLabel(==sunLabel)][thuLabel(==sunLabel)][friLabel(==sunLabel)][satLabel(==sunLabel)]|"
                        options : 0
                        metrics : nil
                        views : labelViewsDictionary];

Он указывает, что 7 меток в родительском представлении имеют одинаковый размер и расширяют ширину родительского представления. Я считаю, что чрезмерная реляционная природа макета приводила к автоматическому подбору макета, особенно потому, что ширина родительского представления не делилась без остатка на 7.

Чтобы решить эту проблему, я создал массив ограничений, определяющих ширину каждой метки, и применил эти ограничения. Когда устройство поворачивается, ширина родителя изменяется, поэтому я возвращаюсь и настраиваю константу в ограничениях на 1/7 ширины родительского представления. Теперь это работает хорошо, процесс загрузки всплывающего окна теперь занимает менее 300 мс, а не 2000 мс.

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

Вчера у меня была такая же проблема на устройстве Ipad iOS6.1. Инструментирование приложения показало, что метод fixupIntegralizationViolations занимал около 300 мс при каждом вызове (около 20 раз, что очень много), что делало приложение абсолютно бесполезным.

Моя проблема была очень похожа на ту, что комментирует Джек Кокс, но я решил ее по-другому. Мое ограничение было:

@"H:|[allButton][inStoreButton(==allButton)][onlineButton(==allButton)][sortButton(50)]|"

Проблема в том, что parentView здесь представляет собой полную ширину iPad в альбомной ориентации, поэтому математика этого ограничения давала каждой кнопке эту ширину: (1024-50)/3 = 324,6666667.

Обычно это не проблема в автомакете, поскольку он заботится о больших числах с плавающей запятой и правильно их округляет, но кажется, что в iPad iOS6 Ландшафтное округление этих чисел вызывает ошибку, которая блокирует пользовательский интерфейс. Чтобы обойти это, все, что мне нужно было сделать, это изменить sortButton на 52, поэтому ширина каждой кнопки теперь составляет: (1024-52)/3 = 324. Вот и все. Теперь метод fixupIntegralizationViolations занимает около 1 мс при каждом вызове.

Интересно то, что использование 52 дает не десятичную ширину в альбомной ориентации, но дает десятичное число в портретной ориентации: (768-52)/3 = 238,666667. Тем не менее, у портрета, похоже, нет ошибок, и авторазметка правильно округляет числа.