NSCell vs NSView: когда требуется много элементов управления

Question

Я знаю, что Apple отказывается от использования NSCell в пользу NSView (см. Примечания к выпуску AppKit 10.10). Ранее было рекомендовано, чтобы NSCell использовался по соображениям производительности, когда требовалось много элементов управления.

Я потратил немало времени на внедрение настраиваемого элемента управления, для которого требовалось много подвидных объектов, а производительность с использованием подматрицы типа NSView не была хорошей. См. related stackoverflow discussionКаковы практические ограничения по количеству экземпляров типа NSView, которые вы можете иметь в окне? Я боролся с 1000-2000 объектами в памяти (что не кажется много). Какова фактическая причина этого ограничения?

Одна вещь, которая меня смущает по приведенному выше, представляет собой представление о каскаде NSTableViews на основе представления. Вы можете создавать таблицы с более чем 1000-2000 ячеек, и у них нет плохой загрузки и прокрутки производительности? Если каждая из ячеек является NSView, то как это достигается?

Если есть практические ограничения, то что думают Apple, когда говорят, что они не рекомендуют использовать NSCell's? Я уверен, что они знают, что некоторым элементам управления требуется большое количество подвид.

Далее, (возможно, устаревшее) Apple Руководство разработчика дать следующее объяснение разницы между NSView & NSCell, который мне нужно пояснено:

«Поскольку клетки легче вес, чем в контроле, в терминах унаследованных данных и поведение, более эффективно использовать многоэлементный контроль, а не несколько элементов управления ».

Унаследованные данные: это, несомненно, вызовет только «раздувание», если данные были использованы =>, и он будет использоваться только в том случае, если вам это нужно?

Унаследованное поведение: методы, которые вы не используете в классе/объекте, не могут вызвать накладные расходы?

В чем разница между легким NSCell и супертяжелом NSView, чем это, по-видимому, принято считать общепринятым? (я действительно хотел бы знать.)

Answer 1

Краткий и неполный ответ:

NSCells около рисования состояния, а не многое другое. NSViews должны рисовать, но также должны поддерживать и обновлять все виды другой информации, например, их компоновку, отвечать на события ввода пользователя и т. Д.

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

NSCells, напротив, не существуют в макете таким образом. Их единственная работа - рисовать информацию в заданном прямоугольнике всякий раз, когда просят сделать это.

Answer 2

Одна вещь, которая меня смущает на приведенном выше представлении о какао NSTableViews на основе представления. Вы можете создавать таблицы с более чем 1000-2000 ячеек, и у них нет плохой загрузки и прокрутки производительности? Если каждая из ячеек является NSView, то как это достигается?

NSTableViews повторное использование видов. Только созданные на самом деле виды - это те, которые видны, плюс, может быть, ряд представлений выше и строка под видимой областью. При прокрутке таблицы значение объекта, связанное с данной строкой представлений, изменяется на то, что представления в строке будут отображать различное содержимое.