我有一些复杂的 Observable 结构，这可能是坏主意，也可能不是坏主意，但这不是这个问题的重点。

这些结构的问题在于它们会生成大量由 UI 显示的 Observable 对象的无效。据我所知，当 JavaFX UI 正在显示某些内容时，它会在其上注册一个 ChangeListener，因此任何使用惰性求值的尝试都会消失。也就是说，使 observable 无效似乎是在告诉 UI 它可能发生了变化，这会导致 UI 立即请求它的值，迫使它立即求值。

因此，我有了通过 Platform.runLater() 推迟失效的想法。

我创建了一个名为 DeferredBinding 的类，它将所有内容委托(delegate)给包装的 Binding，invalidate() 方法除外，它推迟到稍后处理的 JavaFX UI 线程。它似乎有效……我可以使无效一百次，但它似乎只实际处理了一次无效。

但是，我以前没有见过这种模式，我担心它可能属于“不错的尝试，但不是个好主意”的类别。

那么，问题是:这是个坏主意吗？我特别担心引入依赖于 DeferredBinding 的其他 Observable 对象的错误。一旦 Platform.runLater() 发生，它们会好吗？

package com.myapp.SAM.model.datastructures;

import java.util.concurrent.atomic.AtomicBoolean;
import java.util.logging.Logger;

import javafx.application.Platform;
import javafx.beans.InvalidationListener;
import javafx.beans.binding.Binding;
import javafx.beans.value.ChangeListener;
import javafx.collections.ObservableList;

/**
 * Specialized binding that defers its invalidations to the JavaFX UI thread in a throttled manner. The idea being that, if invalidate() is called many times,
 * it only basically happens once (when the UI thread gets to it).
 */
public class DeferredBinding<T> implements Binding<T> {

    private static final Logger logger = Logger.getLogger(DeferredBinding.class.getName());

    private final Binding<T> binding;

    private final AtomicBoolean pendingInvalidation = new AtomicBoolean(false);

    public DeferredBinding(Binding<T> binding) {
        this.binding = binding;
    }

    @Override
    public void addListener(ChangeListener<? super T> listener) {
        binding.addListener(listener);
    }

    @Override
    public void removeListener(ChangeListener<? super T> listener) {
        binding.removeListener(listener);
    }

    @Override
    public T getValue() {
        return binding.getValue();
    }

    @Override
    public void addListener(InvalidationListener listener) {
        binding.addListener(listener);
    }

    @Override
    public void removeListener(InvalidationListener listener) {
        binding.removeListener(listener);
    }

    @Override
    public boolean isValid() {
        return binding.isValid();
    }

    /**
     * Override logic for invalidate() method to defer invalidation to runLater. Throttle the invalidations so as not to floor the JavaFX UI thread with
     * multiple calls
     */
    @Override
    public void invalidate() {
        if (pendingInvalidation.getAndSet(true) == false) {
            Platform.runLater(() -> {
                // Signal that the UI is processing the pending invalidation, so any additional invalidations must schedule another update.
                pendingInvalidation.set(false);
                binding.invalidate();
            });
        }
    }

    @Override
    public ObservableList<?> getDependencies() {
        return binding.getDependencies();
    }

    @Override
    public void dispose() {
        binding.dispose();
    }

}

最佳答案

我不会尝试提前解决性能问题。衡量您的应用程序以确定您是否有问题，然后继续..

假设您有一个问题，有很多方法可以解决您的抽象问题。我想到了三种解决方案:

1

合并更新 (Platform.runLater()) 以防止 FX 事件队列饱和，就像您在示例中所做的那样。

而且由于您只是使绑定(bind)无效，因此您不必担心在途中丢失值。所以看起来(不知道完整的应用程序)这种方式应该有效。

2

使用 Node 的内置行为将区域标记为脏以进行(重新)布局。在某些时候，您将调用 javafx.scene.Parent.requestLayout()(这是“失效”)，这将在将来的某个时候调用 javafx.scene.Parent.layoutChildren( ) 将脏属性应用到该区域。

3

以不同的方式使用解决方案 2:通过使用虚拟化布局容器。 TableView、TreeTableView 和 ListView 都使用虚拟化方法来仅更新可见单元格。 请参阅 com.sun.javafx.scene.control.skin.VirtualFlow 和 com.sun.javafx.scene.control.skin.VirtualContainerBase 一些 JDK 示例，另一个示例将成为 Flowless API .

由于您没有说明任何细节，我无法进一步指导您。但应该清楚，您的方法可能非常有效，还有其他方法。

关于java - 这是最小化绑定(bind)失效的有效方法吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/45891414/