<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>android on</title><link>https://www.reactnativepro.com/categories/android/</link><description>Recent content in android on</description><generator>Hugo -- gohugo.io</generator><lastBuildDate>Mon, 06 Apr 2026 12:00:00 +1000</lastBuildDate><atom:link href="https://www.reactnativepro.com/categories/android/index.xml" rel="self" type="application/rss+xml"/><item><title>FlashList Performance in React Native: architecture recommendations for high-performance apps</title><link>https://www.reactnativepro.com/tutorials/flashlist-performance-in-react-native-a-case-study/</link><pubDate>Mon, 06 Apr 2026 12:00:00 +1000</pubDate><guid>https://www.reactnativepro.com/tutorials/flashlist-performance-in-react-native-a-case-study/</guid><description>Why this case study matters # FlashList is fast, but it is not a free pass. If each row does expensive work, mounts large hidden subtrees, or owns too much state, the list can still feel slow on real devices. That is exactly what happened to us on a tutorial curriculum screen in a production React Native app.
The screen looked straightforward:
a list of modules per-module progress indicators locked and unlocked states expandable lesson rows auto-expansion of the next recommended module On paper, this is a perfect FlashList use case.</description></item></channel></rss>