首页 文章

Gluon上的ListView性能不佳

提问于
浏览
2

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

enter image description here

左侧代表日期,由3个标签组成,放在一个 VBox 和"CounterContent"由计数器组成,每个数字包含一个 TextField ,包含在 HBox 中,两个包含 Hboxes 的标签包含kWh,kWh /天和等等 . 这似乎太过分了,无法正常运行 .

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

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

列表单元是复杂的还是其他可能导致性能不佳的问题?

UPDATE:

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

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

这些步骤都没有带来相当大的改进 .

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

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

1 回答

  • 4

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

    的ListCell

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

    在没有查看代码的情况下我无法分辨,但是您应该通过只有一个实例来避免一直在单元格中创建每个节点的新实例,并且在 updateItem 方法中只更改节点的内容 .

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

    节点数

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

    高速缓存

    如果您使用从Internet下载的图像,请使用Gluon Charm Down Cache 以避免反复下载相同的图像 .

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

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

    CSS

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

    动画也是如此:如果可能的话,避免动画,过渡甚至CSS效果 .

    自定义控制

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

    CharmListView

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

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

    JavaFXPorts版本

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

    性能工具

    使用Monitor等性能工具并使用其profiling选项,这样您就可以追踪任何可能的瓶颈 .

    中央处理器

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

    尝试在Cortex A5上渲染复杂的场景,假设“它是最小,成本最低,功耗最低的ARMv7应用程序_2398459”,或者使用非常旧的Android 4.1.1,它的运行效果不如在具有更高规格的全新设备 .

    正如您所提到的,在Cortex A7上运行会执行"way better" . 看看这个comparison,找到合适的工作架构 .

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

相关问题