在为市级教育局或医联体交付心理健康平台时，业务方常要求在触控大屏（通常搭载定制化 Android 盒子）上部署数据丰富的政务端 App。这类应用往往需要展示全市多所学校的心理高危预警地图，并实时渲染大量的滚动报警流及复杂的柱状图表。
考虑到跨平台开发的维护效率，前端团队通常倾向于使用 React Native (RN) 来构建此类应用。但在实际部署中，当包含大量 View 节点的大屏 App 运行在硬件配置普通的安卓大屏机顶盒上时，常会面临严重的性能问题：地图拖动卡顿、报警流滚动掉帧，甚至在切换复杂报表时引发内存溢出（OOM）崩溃。
本文将探讨 React Native 在处理海量复杂图表时的渲染瓶颈，并分享一些务实的优化策略。
JS Bridge 通信风暴与 UI 线程阻塞
React Native 在非 Fabric 架构下的运行机制分为 JS 线程（业务逻辑）和 Native 线程（UI 渲染）。两者之间的通信依赖 JS Bridge。
当大屏界面需要通过 FlatList 或定时器高频更新报警数据，或者需要根据滑动手势实时更新动画时，JS 线程必须将大量的更新命令序列化为 JSON 并通过 JS Bridge 发送给 Native 线程。在低端安卓设备上，这种密集的跨线程序列化和反序列化操作会迅速耗尽 CPU 资源，导致 UI 线程无法及时响应绘制请求，进而引发明显的卡顿。
动画计算下沉至 UI 线程
为了减轻跨线程通信的压力，团队在实践中发现，将伴随手势和滚动触发的高频动画交由 JS Bridge 处理并非明智之举。
我们在橙星云大前端团队的优化实践中，逐渐抛弃了原生自带的 Animated API，转而引入 react-native-reanimated。Reanimated 的设计思路是将动画算力转移到 Native 端。它基于 JSI (JavaScript Interface) 机制，绕过 JS Bridge，直接在 UI 线程中开辟一个独立的 JS 执行环境 (Worklet)。在配置拖拽地图或复杂图表交互动画后，坐标计算与视图更新都在底层 UI 线程内同步完成，即使主 JS 线程因处理其他复杂业务逻辑而繁忙，动画表现依然能保持流畅。
长列表渲染的虚拟化改造
政务大屏上不断滚动的“实时报警流”，如果使用常规的 ScrollView 甚至未经优化的 FlatList，内存占用会随着数据条目的增加而持续上升，最终导致应用崩溃。
应对这种场景，引入更高效的长列表替代方案是必要的。目前业界反馈较好的是 Shopify 开源的 FlashList。它的核心机制在于复用已有组件而非不断创建新的 View 节点。即使存在数万条报警信息，框架在内存中也仅维护屏幕可见区域及附近的一小部分组件实例 (Cell)。当用户滑动时，移出屏幕的 Cell 会被放入回收池，随后被重新填充新的数据并放置在屏幕另一端。这种“组件回收”设计有效控制了 DOM 树的规模，从根本上缓解了低配安卓设备上的 OOM 问题。
在资源受限的大屏设备上，平衡 React Native 的跨端便利性与物理性能始终是一项挑战。通过将动画逻辑下沉至 UI 线程，以及采用高效的组件回收机制，技术团队能够在有限的硬件条件下实现复杂的交互与海量数据展示，确保心理数据大屏稳定运行。