React Native Expo类TikTok垂直视频流FlatList在Android端内存异常排查求助

一、FlatList配置参数修正（触发VirtualizedList警告的直接原因） #

• 当前配置存在RN 0.63（Expo SDK40内置RN版本）的已知兼容问题：
  • windowSize={2}的单位为屏幕数，而非列表项数。过窄的渲染窗口会在滚动时触发频繁重渲染，哪怕仅传入7条数据也会弹出“大列表更新慢”的警告，建议调整为windowSize={5}，覆盖当前屏+上下各2屏的渲染范围，兼顾渲染效率和内存占用
  • initialNumToRender={0}在Android端存在已知的空渲染循环bug，会反复触发视图挂载/卸载流程抬升内存峰值，建议调整为initialNumToRender={1}
  • maxToRenderPerBatch调整为2，匹配“同一时刻最多渲染2个列表行”的需求，降低单批次渲染的内存峰值
  • 关闭removeClippedSubviews参数：该参数在SDK40的Android端存在组件卸载时不释放硬件纹理内存的已知bug，卸载逻辑完全交由onViewableItemsChanged手动控制即可

二、Expo-AV在Android端的内存泄漏修复 #

• SDK40版本的Expo-AV在Android端没有自动释放视频解码器资源的机制，仅靠组件生命周期卸载无法回收内存：
  • 在onViewableItemsChanged回调中，对可见占比低于75%的视频项，显式调用其内部Video实例的unloadAsync方法，完成解码器和纹理资源的主动释放
  • 强制设置Video组件参数：useNativeControls={false}、resizeMode={Video.ResizeMode.CONTAIN}，减少硬件解码时的冗余纹理占用
  • 降低视频状态回调频率：将progressUpdateIntervalMillis设置为500以上，避免高频JS桥接通信累积JS侧内存
• 避开已知渲染坑：不要在VideoItem层嵌套包含动图、大图的自定义交互元素，Android硬件加速机制会为每个叠加层单独创建纹理内存块，3个以上叠加的视频层就会触发系统内存告警

三、业务逻辑层的内存冗余优化 #

• Redux Store中不要存储视频的临时本地URI、下载链接，仅存储视频的基础元数据；需要渲染对应列表项时再从Firebase Storage拉取临时资源链接，避免全局引用导致的系统内存无法回收
• 对Firebase返回的视频下载链接做列表项级别的本地缓存，避免滚动过程中重复生成临时URL、累积OkHttp连接缓存
• 手势逻辑不要将Video实例的ref存在全局作用域，所有交互回调通过组件内部闭包实现，避免GC无法回收已经卸载的Video实例

四、兜底的内存管控逻辑 #

• 严格控制VideoItem的更新逻辑：仅当组件的聚焦状态（是否为当前75%以上可见的播放项）发生变化时才触发重渲染，减少无意义的组件更新
• 增加内存阈值检测逻辑：当应用内存占用超过系统分配阈值的70%时，主动卸载相邻位置的非播放视频实例，仅保留当前正在播放的视频，避免系统触发lowMemory回调导致的数分钟渲染卡死

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