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

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

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

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

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

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

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

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


mvp gwt gwt-mvp
person nogridbag    schedule 13.09.2011    source источник

Ответы (2)


arrow_upward
3
arrow_downward

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

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

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

person Hilbrand Bouwkamp    schedule 14.09.2011

arrow_upward
0
arrow_downward

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

На мой взгляд выгодного решения нет - если вам не нужны "выдвижные" панели, я бы не стал использовать DeckLayoutPanel (т.к. все дополнительные компоненты усложняют).

person omnomnom    schedule 13.09.2011
comment
Я искал ответ, более ориентированный на производительность. Насколько велико ваше приложение GWT? Я думаю, что только на крупных веб-сайтах эти вещи становятся проблемами. - person nogridbag; 14.09.2011
comment
Это небольшой веб-сайт - всего около 30-40 отдельных просмотров - все работает как синглтоны. Насчет производительности - как я уже писал, проблем с производительностью не замечал - проверял как на десктопе, так и на мобильном телефоне. Единственная досадная проблема связана с переключением между одним и тем же экземпляром представления, но это не связано с производительностью. - person omnomnom; 14.09.2011