React Native Android正式版WebSocket高频竞价页面随机冻结问题

问题背景 #

开发的实时竞价应用基于WebSocket实现，出价最高者获得商品。页面包含以下独立模块组件，状态统一由父组件更新以实现跨组件共享：

• 商品卡片：展示商品图片、价格，商品售出后更新
• 竞价窗口：显示当前最高出价、出价者及剩余倒计时
• 用户列表：展示已购商品用户及待竞拍商品队列
• 自动竞价开关
• 手动竞价按钮

问题现象 #

仅在.\gradlew assembleRelease构建的正式版APK中出现，开发版无此问题：
当用户高频竞价（每秒2-3次）时，经过15-18件商品后页面完全冻结，无状态更新、无UI变化，仅开关、左侧侧滑菜单及滚动功能可用，需重启应用。问题出现时机随机：部分设备4-5件商品后即冻结，部分需17-18件。

问题规律 #

• 用户竞价越频繁，页面冻结越快
• 参与竞价的用户越多，越容易触发冻结
• 测试设备RAM差异影响明显：2GB设备冻结较慢甚至不冻结，6GB/8GB设备冻结更快

业务逻辑 #

用户进入拍卖流程：

1. 发起WebSocket连接请求
2. 连接建立后获取拍卖快照（当前出价、出价者等）
3. 通过无依赖useEffect更新UI状态
   用户出价时：
4. 向服务器发送出价事件
5. 服务器广播事件给所有连接用户
6. 所有客户端同步更新状态

已尝试的无效解决方案 #

• 内存泄漏排查：Android Studio分析开发版内存，峰值未超300MB，30件商品拍卖无异常
• 启用Hermes Engine：无任何改善
• 开启newArchEnabled：修改CMakeList后，正式版无法启动，开发版持续崩溃
• 优化状态更新与事件监听：减少不必要的setState，用useRef存储变量，在清理函数中移除事件监听器
• CPU线程分析：主线程与UI线程仅在必要状态更新时活动，无冗余操作

环境依赖（package.json） #

{"name": "--","version": "0.0.1","private": true,"scripts": {"android": "react-native run-android","ios": "react-native run-ios","lint": "eslint .","start": "react-native start","test": "jest"},"dependencies": {"@notifee/react-native": "^7.8.2","@react-native-async-storage/async-storage": "^1.21.0","@react-native-community/clipboard": "^1.5.1","@react-native-firebase/app": "^18.7.3","@react-native-firebase/auth": "^18.7.3","@react-native-firebase/messaging": "^18.7.3","@react-navigation/bottom-tabs": "^6.5.11","@react-navigation/drawer": "^6.6.6","@react-navigation/material-top-tabs": "^6.6.5","@react-navigation/native": "^6.1.9","@react-navigation/native-stack": "^6.9.16","@reduxjs/toolkit": "^1.9.7","base-64": "^1.0.0","date-fns": "^2.30.0","jwt-decode": "^4.0.0","lodash": "^4.17.21","lottie-react-native": "^6.4.0","react": "18.2.0","react-hook-form": "^7.47.0","react-native": "0.72.6","react-native-animatable": "^1.4.0","react-native-bootsplash": "^5.1.3","react-native-confirmation-code-field": "^7.3.2","react-native-countdown-circle-timer": "^3.2.1","react-native-date-picker": "^4.3.5","react-native-dotenv": "^3.4.9","react-native-gesture-handler": "^2.13.4","react-native-image-picker": "^7.1.0","react-native-linear-gradient": "^2.8.3","react-native-modal": "^13.0.1","react-native-pager-view": "^6.2.3","react-native-progress": "^5.0.1","react-native-reanimated": "^3.5.4","react-native-safe-area-context": "^4.7.4","react-native-screens": "^3.27.0","react-native-sound": "^0.11.2","react-native-sse": "^1.2.0","react-native-svg": "^13.14.0","react-native-svg-transformer": "^1.1.0","react-native-swipe-gestures": "^1.0.5","react-native-switch-selector": "^2.3.0","react-native-tab-view": "^3.5.2","react-native-toast-message": "^2.2.0","react-native-uuid": "^2.0.1","react-redux": "^8.1.3","react-timer-hook": "^3.0.7","redux-logger": "^3.0.6"},"devDependencies": {"@babel/core": "^7.20.0","@babel/preset-env": "^7.20.0","@babel/runtime": "^7.20.0","@react-native/eslint-config": "^0.72.2","@react-native/metro-config": "^0.72.11","@tsconfig/react-native": "^3.0.0","@types/react": "^18.0.24","@types/react-test-renderer": "^18.0.0","babel-jest": "^29.2.1","babel-plugin-transform-remove-console": "^6.9.4","eslint": "^8.19.0","jest": "^29.2.1","metro-react-native-babel-preset": "0.76.8","prettier": "^2.4.1","react-test-renderer": "18.2.0","rn-nodeify": "github:tradle/rn-nodeify","typescript": "4.8.4"},"engines": {"node": ">=16"}}

针对性排查建议 #

1. 正式版专属代码差异排查

   • 检查babel-plugin-transform-remove-console插件是否导致依赖console的隐藏逻辑失效，部分调试用的状态判断可能在正式版中异常
   • 对比metro打包的正式版与开发版配置，确认是否开启的压缩、混淆选项破坏了WebSocket事件处理逻辑
   • 验证正式版WebSocket连接的重连、事件监听是否存在内存泄漏，开发版DevTools可能自动清理这类资源，正式版无此机制

2. 状态更新批量处理优化

   • 高频竞价时服务器广播事件会触发大量setState，正式版React批量更新机制与开发版存在差异，尝试用unstable_batchedUpdates包裹状态更新逻辑，减少重绘次数
   • 检查父组件状态更新是否触发所有子组件不必要重渲染，即使使用memo，也要确保props中的引用类型（对象、数组）使用稳定引用（比如用useMemo缓存）

3. 大内存设备GC延迟问题

   • 大内存设备GC触发频率低，未及时回收的WebSocket事件回调、订阅可能堆积，阻塞JS线程。可在正式版测试时手动触发GC，验证是否能缓解冻结
   • 检查组件卸载时是否完全清理WebSocket事件订阅，避免回调函数累积

4. WebSocket库兼容性验证

   • 当前使用react-native-sse，尝试替换为其他成熟WebSocket库（如react-native-websocket）测试，排查库本身在正式版打包后的兼容性问题

5. 正式版调试手段

   • 为正式版开启远程调试：执行adb reverse tcp:8081 tcp:8081后打开应用调试菜单，通过Chrome DevTools监控JS线程调用栈、内存变化，定位冻结时的阻塞点
   • 用Android Studio Profiler对正式版APK做CPU、内存分析，对比开发版数据，找出正式版特有的资源占用异常

内容的提问来源于stack exchange，提问作者Ali Ahmed Khan