ListView ANR during dynamic-height recycling on Android 10+

Measuring UI-thread stalls before optimizing ListView recycling

Profiling a Titanium 10.x Android app reveals Application Not Responding (ANR) reports when a ListView with 500+ rows uses custom templates set to height: Ti.UI.SIZE. The goal is to quantify whether the ANR originates from repeated measure/layout passes that defeat RecyclerView view-holder recycling, or from JavaScript execution spikes after the V8 9.4 upgrade changed JIT heuristics.

Constraints include the inability of ti profile --cpu alone to correlate JS function timings with native main-thread stalls, and the cross-platform divergence where iOS UITableView recycling behaves differently than Android RecyclerView. Memory growth observed via ti profile --heap snapshots may not capture native view-holder allocation pressure.

Which profiling combination reliably isolates the recycling failure: Chrome DevTools timeline, Android Studio CPU profiler main-thread trace, or Ti.API.info timestamps in the template's postlayout event? Does enforcing fixed row heights eliminate the ANR without redesigning the data model? How can developers verify view-holder reuse counts on Android without modifying the Titanium SDK source?