DefaultItemAnimator为何强制重新创建变更的ViewHolder？何时重建ViewHolder比局部更新更合适？

Great question—this is a common point of confusion when working with RecyclerView's update behavior, and your analysis of DefaultItemAnimator is spot-on. Let's unpack this fully.

First, Recapping the Mechanism You Identified #

As you noted, the DefaultItemAnimator's canReuseUpdatedViewHolder method dictates whether RecyclerView reuses an existing ViewHolder or creates a new one for an update:

@Override
public boolean canReuseUpdatedViewHolder(@NonNull RecyclerView.ViewHolder viewHolder, @NonNull List<Object> payloads) {
    return !payloads.isEmpty() || super.canReuseUpdatedViewHolder(viewHolder, payloads);
}

The key takeaway here:

• If you pass non-empty payloads when calling onItemRangeChanged(), the method returns true, so RecyclerView reuses the existing ViewHolder and triggers a partial bind via onBindViewHolder(holder, position, payloads).
• If payloads are empty, it falls back to the superclass logic (which usually returns false for full updates), leading to a new ViewHolder being created, paired with a fade-in/fade-out animation for the full Item.

Your fix—using a non-empty payload—is exactly the right approach for your scenario, where you only needed to toggle a single widget's visibility.

When Is Recreating a ViewHolder Better Than Partial Binding? #

While partial updates are almost always more performant for small changes, there are specific scenarios where recreating the ViewHolder makes sense:

1. Major Layout or Structural Changes to the Item #

If an update completely changes the Item's layout structure, size, or core visual hierarchy (e.g., switching from a single-column to a two-column layout within the same Item type), rebuilding the ViewHolder ensures the new layout is inflated correctly. Trying to adjust existing Views to fit this new structure could lead to layout bugs, broken constraints, or excessive code to reset all existing View states.

2. Resetting Complex ViewHolder States #

If your ViewHolder contains complex stateful components (e.g., custom animated Views, nested RecyclerViews, or Views with persistent user input like text fields or sliders), resetting all those states manually to match the updated data might be more costly than inflating a fresh ViewHolder. A new ViewHolder starts with a clean, default state, avoiding the need to track and revert every possible state change.

3. Intentional Full-Item Visual Transitions #

In some UI designs, a full Item replacement (with fade-in/fade-out) is a deliberate choice for clarity. For example, if an Item's entire purpose changes (e.g., from a "pending" state to a "completed" state with a completely different visual treatment), the full animation can signal to the user that the Item has fundamentally changed, rather than just a minor tweak.

Why Your Scenario Favors Partial Binding #

In your case—only toggling a single widget's visibility—recreating the ViewHolder is indeed inefficient. Inflating a new ViewHolder involves:

• Inflating the layout from XML (a relatively expensive I/O and parsing operation)
• Finding all View references via findViewById
• Setting up initial states for all Views, even the ones that didn't change

Partial binding skips all that overhead, directly updating only the specific View that needs to change. That's why using payloads is the optimal solution here.

内容的提问来源于stack exchange，提问作者Max Gierlachowski