Gluon上的ListView性能不佳

时间:2016-04-24 05:10:42

标签: gluon gluon-mobile

我有一个自定义ListCell实现,如下图所示。

enter image description here

左侧代表日期,由3个标签组成,放在VBox中,“CounterContent”由计数器组成,每个数字包含TextField,包含在{ {1}}和两个HBox包含kWh,kWh / day等标签。这似乎太过分了,无法正常运行。

我尝试在后台任务中加载数据,显示进度指示器,同时任务正在运行,但与桌面上不同,在Android上性能非常差。每当我切换到listview时,垃圾收集就会启动,并阻塞ui线程,以便进度指示器永远不会出现。

我在华为Y-300,Android 4.1.1,javafxports 8.60.6(因为javafxports 8.60.7导致错误,导致Hboxes无法使用)和三星S5迷你上尝试过,Android 5+。在三星手机上,性能总体来说更好,就像预期的那样,因为我猜的是Ahead-of-Time编译,但仍然存在垃圾收集问题。此外,在使用单元格填充列表视图后,滚动不是很顺利。

列表单元是否复杂或者其他可能是性能不佳的问题?

更新

经过大量测试后,似乎不平滑的滚动不是由性能问题引起的。至少在S5(javafxports 8.60.7)上。

我删除了所有css样式,并用单个标签替换了文本字段(计数器节点已经是一个自定义控件(忘记了),它在2 TextField中放置了文本字段(不是{{1}并且Regions的节点在构造函数中实例化。此外,我将HBoxes切换为ListCell并设置android.monocle.input.touchRadius = 1.

这些步骤都没有带来可观的改善。

只是为了澄清:与华为手机相比,S5和Android 5+上的滚动功能可以使用,但它不是很流畅,这会让用户体验不尽如人意。

在华为(javafxports 8.60.6)上,更改标签的计数器文本字段给出了显着的改进,但没有达到滚动变得可用的程度。直到我设置这个神奇的实验开关:gluon.experimental.performance = true,这使得listview快速滚动闪电(经过一点点预热延迟),但仍然不是很平滑。

1 个答案:

答案 0 :(得分:4)

复杂场景的性能降低有很多原因,因此这只是一个可能有助于改进它的任何想法的列表。

的ListCell

对于初学者来说,单元格中的节点数量非常多。请注意,您创建的每个滚动都意味着保存可见单元格的虚拟流的完整呈现。对于每个单元格,这意味着重新创建其内容。

在不查看代码的情况下我无法告诉您,但是您应该始终只使用一个实例来避免在单元格中创建每个节点的新实例,并且只需更改updateItem方法节点的内容。

看看这个sampleNoteCell类是自定义单元格,其中使用了ListTile

节点数

您是否尝试仅使用Label替换8个文本字段和3个框?

缓存

如果您使用从互联网下载的图像,请使用Gluon Charm Down Cache以避免同时下载相同的图像。

看看这个sample。没有缓存,即使在桌面上,性能也会受到影响。

还可以为任何节点使用JavaFX内置缓存,尝试不同的缓存策略。

CSS

复杂的CSS需要很长的CPU时间。尽量简化它。即使你可以删除整个CSS进行快速测试。然后决定你可以使用或不使用的内容。

动画也是如此:如果可能,请避免使用动画,过渡甚至CSS效果。

自定义控件

计数器复杂节点可能会被优化渲染的自定义控件所取代。

CharmListView

您是否尝试过使用Gluon Charm CharmListView控件而不是ListView

有一个新的实验标记,您可以使用它来测试可能的优化,这可能会在滚动列表时提高性能。在gluon.experimental.performance=true文件上设置java.custom.properties,然后尝试一下。

JavaFXPorts版本

由于TextField错误,您提到您使用的是8.60.6。在这种情况下,您的TextField节点是否可编辑?如果没有,我建议用其他节点替换它们并运行8.60.7,因为它包含很多性能改进。

效果工具

使用Monitor等性能工具并使用其profiling选项,以便追踪任何可能的瓶颈。

CPU

最后但同样重要的是:您的移动设备规格始终至关重要。

尝试在Cortex A5上渲染复杂场景,因为它是#34;它是最小,成本最低,功耗最低的ARMv7应用程序processor"或使用非常古老的Android 4.1。 1,不能在具有更高规格的全新设备上运行它。

正如您所提到的,在Cortex A7上运行会更好地执行#34;。看看这个comparison,找到合适的工作架构。

无论如何,总有改进的余地,并且付出了很多努力。我们随时欢迎您的反馈。