Sticky headers in SectionList cause unnecessary item re-rendering and visual glitches

Description

I am experiencing a rendering issue when using sticky headers on a section list with virtualization. The recording below shows the behavior - the section items seem to disappear while the section headers re-render. Eventually the section headers "catch up" to the currently visible section. Logging each time renderItem is called per element shows that items earlier in the list are rendered many times despite never scrolling up.

Weirdly enough this issue only appears when stickySectionHeadersEnabled is set to true and when the list has virtualization enabled (e.g. disableVirtualization is set to false).

See the reproducible Snack here

https://github.com/facebook/react-native/assets/44410687/98ce234e-b6ef-4c86-aa56-6c76b142b9ea

Steps to reproduce

1. Install the Snack on a physical device (*)
2. Scroll down the list
3. Depending on scroll speed the sticky header will start to render old headers around sections 70-100
4. Click the Log Item Map button to log how many times each item has been rendered to the console
5. Observe that items near the beginning of the list are rendered multiple times, despite never scrolling up

• The web view also shows the issue but the interaction presents itself a little differently

React Native Version

0.73.6

Affected Platforms

Runtime - Android, Runtime - iOS

Output of npx react-native info

System:
  OS: macOS 13.6
  CPU: (10) arm64 Apple M1 Max
  Memory: 483.84 MB / 32.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 20.10.0
    path: ~/.nvm/versions/node/v20.10.0/bin/node
  Yarn:
    version: 3.6.1
    path: ~/.nvm/versions/node/v20.10.0/bin/yarn
  npm:
    version: 10.2.3
    path: ~/.nvm/versions/node/v20.10.0/bin/npm
  Watchman:
    version: 2023.09.04.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.12.0
    path: /Users/****/.rbenv/shims/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 22.2
      - iOS 16.2
      - macOS 13.1
      - tvOS 16.1
      - watchOS 9.1
  Android SDK:
    API Levels:
      - "29"
      - "31"
      - "32"
      - "33"
      - "34"
    Build Tools:
      - 29.0.2
      - 30.0.2
      - 30.0.3
      - 31.0.0
      - 33.0.0
      - 33.0.1
      - 34.0.0
    System Images:
      - android-24 | ARM 64 v8a
      - android-28 | Google APIs ARM 64 v8a
      - android-28 | Google ARM64-V8a Play ARM 64 v8a
      - android-29 | Android TV Intel x86 Atom
      - android-29 | ARM 64 v8a
      - android-29 | Intel x86 Atom
      - android-29 | Google APIs ARM 64 v8a
      - android-29 | Google APIs Intel x86 Atom
      - android-29 | Google APIs Intel x86 Atom_64
      - android-29 | Google Play ARM 64 v8a
      - android-29 | Google Play Intel x86 Atom
      - android-29 | Google Play Intel x86 Atom_64
      - android-31 | Google APIs ARM 64 v8a
      - android-33 | Google APIs ARM 64 v8a
      - android-33 | Google Play ARM 64 v8a
      - android-34 | Google APIs ARM 64 v8a
    Android NDK: 25.0.8775105
IDEs:
  Android Studio: 2023.2 AI-232.10227.8.2321.11479570
  Xcode:
    version: 14.2/14C18
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.9
    path: /usr/bin/javac
  Ruby:
    version: 3.1.2
    path: /Users/****/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.73.6
    wanted: 0.73.6
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: true
  newArchEnabled: false

Stacktrace or Logs

This log shows how many times each item has rendered. I use a `Map<string, number>` to track this and log an array with the number of times `renderItem` is called for each element. These logs were taken after scrolling down in the list to around section 60.


Number of items loaded: 257
Total items rendered 924
►[1,1,1,1,1,1,1,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,4,4,4,4,4,4,4,4,4,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,2,2,2,2,2,2,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1]

Reproducer

https://snack.expo.dev/@zacdev/section-list-investigation

Screenshots and Videos

See description above.

从链接的 Snack 复现示例开始，并比较启用虚拟化且将 stickySectionHeadersEnabled 设置为 true 时的 SectionList。跟踪滚动时 SectionList/VirtualizedList 的渲染行为；当视觉故障消失，并且屏幕外项目在 Android 和 iOS 上不再被重复渲染时，即表示完成。