[Redth]

Follow-up to #74. That fixed the window-insets churn; this one stops the Android list from tearing down and rebuilding row views it should reuse.

Problem

Profiling PoolMath's Timeline (NativeAOT, simpleperf) after #74, binding rows was ~12% of UI-thread time while scrolling, and about half of that was building new rows: CreateView → ToPlatform → handlers, plus the GCs those allocations trigger. Two causes:

1. Recycled-view pool too small, and sized from the wrong count.
   • Per-type cap: RvRecycledViewPool keeps at most 5 holders per view type, and its total capacity comes from the live RecyclerView.ChildCount.
   • Fast flings: a list that's mostly one row type (6–7 visible) hands back more than 5 rows of that type during a fast fling. The extras are Release()d (MAUI views torn down) and rebuilt moments later.
   • Full rebinds: during NotifyDataSetChanged, for example after pull-to-refresh, RecyclerView detaches every row first. ChildCount is ~0 exactly when they're all handed to the pool, so the capacity falls to its minimum and the pool evicts nearly all of them. Every refresh rebuilt every visible row.
2. Double binding pass on reuse. OnViewRecycled → Unbind() set BindingContext = null, pushing defaults through every binding and its property-changed handlers, then Bind set the next item.

Changes

• RvRecycledViewPool: per-type cap max(5, visible + 2), with visible and the total capacity taken from a high-water mark of the visible row count instead of the live ChildCount.
• RetainedView.Unbind(clearContext): RvAdapter.OnViewRecycled passes false, so a pooled row keeps its previous BindingContext until it's rebound. Every other caller (the stale-position path, iOS, Windows) behaves as before.
• RetainedView.Bind: only resets BindingContext to null first when the same item is bound again, which is still needed to re-apply its bindings. A different item replaces the context directly, so it's one binding pass. Release still clears the context.

Trade-off: a pooled row holds a reference to its last item, and its bindings stay subscribed to it, until the row is rebound or released. The pool is bounded at about a screenful per type.

Results

PoolMath Timeline, Pixel 8 Pro, CoreCLR Release, scripted workloads. Baseline is main with #74 and the app-side insets fix; "after" also includes small app-side binding changes (an in-place weather label, factory DataTemplates).

	before	after
rows rebuilt, 18 scroll flings	8	0
rows rebuilt, 3 pull-to-refreshes	15	0
worst frames during refresh	248 / 234 / 227 ms	50 / 49 / 44 ms
avg bind, main row type	12 ms	3.9 ms
janky frames (scroll)	3.45%	2.78%
p99 frame (scroll)	42 ms	29 ms

The refresh "before" (248/234/227 ms, 15 rebuilds) is from an intermediate build that already had the larger per-type cap but still sized the pool from the live ChildCount. That's how the high-water mark was found to matter.

Testing

• Builds: net10.0-android and net10.0, both Release.
• In the app: via a locally patched package. Scrolling, pull-to-refresh, item taps, and mixed row types (test / chemical / maintenance / note rows) still bind correct data after reuse.
• Not run: iOS and Windows. Their only change is the shared Bind reset condition: they still clear the context in Unbind(), so Bind behaves as before there.

🤖 Generated with Claude Code