Действия GWT - последствия использования SimplePanel против DeckPanel (панель карт) для производительности

Question

В большинстве примеров «Активности» и «Места», которые я видел, люди используют SimplePanel в качестве дисплея для ActivityManager.

Мне было интересно, есть ли польза от использования DeckPanel / DeckLayoutPanel вместо SimplePanel. Довольно просто создать оболочку вокруг панели Deck, которая реализует AcceptsOnWidget.

Я нигде не обсуждал эту тему. До того, как MVP + Activity обычно использовался в GWT, люди обычно использовали панели Tab (которые внутренне используют панели типа палубы) и панели Deck для управления переключением между панелями в данном представлении.

Разница между ними заключается в том, что SimplePanel.setWidget (..) удалит предыдущего дочернего элемента из DOM и добавит новый виджет, тогда как панель типа колоды будет использовать CSS для управления видимостью текущей панели (т. Е. «Display: none»). «скрыть неактивные панели).

1. Если вы используете панель деки, это обычно означает, что у вас будет гораздо больше элементов в DOM. Я бы предположил, что это использует больше памяти и делает приложение «вялым», даже если эти узлы не видны («display: none»). Это правда?

2. Если это правда, почему Google использовал стиль панели панелей для Impl для TabPanel / TabLayoutPanel вместо внутреннего использования SimplePanel?

3. Один подход более благоприятен по сравнению с другим?

Answer 1

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

Во-вторых, если вы используете DeckLayoutPanel, все его дочерние элементы создаются одновременно, а отображается только один. Для производительности это не может быть оптимальным. Поэтому по этой причине вы можете добавить LazyPanel между дочерним элементом и DeckLayoutPanel, поэтому он создается только при показе. Но это может потребовать некоторого дополнительного кодирования, чтобы заставить его работать (потому что это ленивый, вам нужно лениво инициализировать его, что может вызвать некоторые трудности) Однако, все же для сравнения между DeckLayoutPanel и SimplePanel, это только вопрос, когда вы создадите дочерние элементы для SimplePanel (все сразу == та же проблема, что и у DeckLayoutPanel), а не что-то конкретное для различия между DeckLayoutPanel и SimplePanel.

В общем, если у вас есть определенный упорядоченный набор дочерних элементов, используйте DeckLayoutPanel (как с TabPanel), и если у вас есть неопределенный набор, SimplePanel - лучший выбор (как в MVP для отображения текущего представления).

Answer 2

DeckLayoutPanel внутренне содержит коллекцию всех ваших представлений (фактически просмотров, которые вы зарегистрировали или отобразили), чтобы иметь возможность определять направление анимации скольжения (в зависимости от того, идете вы назад или вперед). Кроме того, я не заметил, что приложение стало вялым при переключении с SimplePanel на DeckLayoutPanel. Это особенно безопасно, когда все ваши взгляды синглтоны. Но имейте в виду, что в таком случае при переключении между одним и тем же экземпляром представления (например, списком основных категорий -> списком подкатегорий) у DeckLayoutPanel могут возникнуть некоторые проблемы с рендерингом скользящей анимации.

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