GWT 活动 - 使用 SimplePanel 与 DeckPanel(卡片面板)的性能影响

发布于 2024-12-04 13:17:23 字数 636 浏览 1 评论 0原文

在我见过的大多数“活动”和“地点”示例中,人们使用 SimplePanel 作为 ActivityManager 的显示。

我想知道使用 DeckPanel/DeckLayoutPanel 而不是 SimplePanel 是否有好处。在实现 AcceptsOnWidget 的 Deck 面板周围创建一个包装器是相当简单的。

我还没有在任何地方看到过这个话题的讨论。在GWT中普遍使用MVP+Activities之前,人们通常使用Tab面板(内部使用deck类型面板)和Deck面板来控制给定视图内面板之间的切换。

两者之间的区别是 SimplePanel.setWidget(..) 将从 DOM 中删除以前的子级并附加新的窗口小部件,而甲板类型面板将使用 CSS 来控制当前面板的可见性(即“display: none”来隐藏非活动面板)。

  1. 如果使用甲板面板,通常意味着 DOM 中将有更多的元素。我想这会使用更多内存并使应用程序“缓慢”,即使这些节点不可见(“显示:无”)。这是真的吗?

  2. 如果这是真的,为什么 Google 对 TabPanel/TabLayoutPanel 使用了甲板面板样式 impl,而不是在内部使用 SimplePanel?

  3. 一种方法是否比另一种更有利?

In most of the Activities and Places examples I've seen, people use a SimplePanel as the display for an ActivityManager.

I was wondering if there's a benefit to using a DeckPanel/DeckLayoutPanel instead of SimplePanel. It's fairly trivial to create a wrapper around a Deck panel that implements AcceptsOnWidget.

I haven't seen this topic discussed anywhere. Prior to MVP+Activities being commonly used in GWT, people generally used Tab panels (which internally uses deck type panels) and Deck panels to control switching between panels within a given view.

The difference between the two is SimplePanel.setWidget(..) will remove the previous child from the DOM and append the new widget whereas a deck type panel will use CSS to control visibility of the current panel (i.e. "display: none" to hide inactive panels).

  1. If using a deck panel, it generally means you will have much more Elements in the DOM. I would imagine this uses more memory and makes the application "sluggish", even if those nodes are not visible ("display: none"). Is this true?

  2. If this is true, why did Google use a deck panel style impl for TabPanel/TabLayoutPanel instead of internally using a SimplePanel?

  3. Is one approach more favorable over the other?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

渔村楼浪 2024-12-11 13:17:23

性能方面没有区别。这完全取决于你如何使用它。在 DeckLayoutPanel 中,所有子项都保存在内存中。但是,如果您使用 SimplePanel 实现相同的功能,则需要自己保留指向这些相同子项的指针,因此内存占用量将大致相同。除非使用 SimplePanel,您每次显示子项时都创建并渲染它,并在隐藏时将其丢弃,这可能会提高内存效率(如果垃圾收集器正常工作),但由于渲染成本高昂,因此会影响可用性。

其次,如果您使用 DeckLayoutPanel,它的所有子级都会立即创建,而只显示一个。对于性能来说,这可能不是最佳的。因此,出于这个原因,您可以在子级和 DeckLayoutPanel 之间添加一个 LazyPanel,这样它仅在显示时创建。但这可能需要一些额外的编码才能使其工作(因为它很懒,您需要延迟初始化它,这可能会导致一些困难)但是,对于 DeckLayoutPanel 和 SimplePanel 之间的比较,这只是您何时为SimplePanel(所有前面的==与 DeckLayoutPanel 相同的问题),而不是特定于 DeckLayoutPanel 和 SimplePanel 之间差异的内容。

一般来说,如果您有一组已定义的有序子项,请使用 DeckLayoutPanel(如 TabPanel),如果您有一组未定义的子项,则 SimplePanel 是更好的选择(如在 MVP 中显示当前视图)。

Performance wise there is no difference. It all depends how you use it. In the DeckLayoutPanel all children are kept in memory. But if you would implement the same thing with a SimplePanel you need to keep a pointer to those same children yourself, so the memory footprint would be about the same. Unless with a SimplePanel you create and render a child each time it's shown and throw it away when hidden, which would possible be memory efficient (if the garbage collector does it's work), but it would be a hit on usability since rendering is expensive.

Second if you use a DeckLayoutPanel all it's children are created at once, while only one is shown. For performance this might not be optimal. So for this reason you could add a LazyPanel between the child and the DeckLayoutPanel, so it's only created when shown. But that might take some extra coding to make it work (because it's lazy you need to lazy initialze it which can cause some difficulties) However, still for the comparison between DeckLayoutPanel and SimplePanel it's only a matter of when you would create the children for the SimplePanel (all up front == same issue as with DeckLayoutPanel) and not something specific to the difference between DeckLayoutPanel and SimplePanel.

In general if you have a defined ordered set of children use a DeckLayoutPanel (like with a TabPanel) and if you have a undefined set SimplePanel is the better choice (like in MVP to show the current view).

灼疼热情 2024-12-11 13:17:23

DeckLayoutPanel 内部保存所有视图(实际上是您已注册或显示的视图)的集合,以便能够确定滑动动画方向(取决于您是后退还是前进)。除此之外,我没有注意到从 SimplePanel 切换到 DeckLayoutPanel 时应用程序变得缓慢。当您的所有视图都是单例时,它尤其安全。但请注意,在这种情况下,当在同一视图实例之间切换时(例如主类别列表 -> 子类别列表),DeckLayoutPanel 渲染滑动动画可能会出现一些问题。

在我看来,没有有利的解决方案 - 如果您不需要“滑动”面板,我不会使用 DeckLayoutPanel (因为所有附加组件都会增加复杂性)。

DeckLayoutPanel internally holds collection of all your views (actually views that you've registered or displayed) in order to be able to determine sliding animation direction (depending if you go back or forward). Apart from this, I didn't notice that application become sluggish when switched from SimplePanel do DeckLayoutPanel. It's especially safe, when all your views are singletons. But please aware that in such case, when switching between the same view instance (for example main categories list -> subcategories list), DeckLayoutPanel may have some problems rendering sliding animation.

In my opinion there is no favorable solution - if you don't need "sliding" panels, I would not use DeckLayoutPanel (since all additional components increases complexity).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文