大文件上传时Expo/React Native设备内存占用异常问题排查

核心问题分析 #

你的问题本质是分片处理过程中内存未及时释放导致的内存泄漏，结合依赖版本和操作流程，主要可能出在分片读取、base64转换、加密后的资源管理这几个环节。

排查与优化步骤 #

1. 检查分片处理的内存释放逻辑 #

• 每次分片处理完成后，主动解除对分片数据、加密结果的引用，帮助JS引擎回收内存：

  // 读取分片
  let chunkData = await FileSystem.readAsStringAsync(fileUri, {
    encoding: FileSystem.EncodingType.Base64,
    position: start,
    length: chunkSize
  });
  // 执行加密、上传逻辑...
  chunkData = null; // 处理完立即释放引用
  

• 避免在全局作用域或闭包中持久化持有分片数据，比如不要把所有分片的base64存入数组，处理一个上传一个，完成后直接丢弃该分片数据。

2. 优化分片大小与读取方式 #

• 缩小分片尺寸：如果当前分片过大（如100MB+），转换为base64后体积会膨胀33%，单次内存负载过高。建议将分片调整为10-20MB，降低单次内存占用。
• 优先用二进制读取：如果服务器支持二进制上传，改用readAsByteArrayAsync读取二进制数据，再加密后直接上传，比base64格式更节省内存。

3. 双文件库的共存与规范 #

两个库可以共存，但上传逻辑尽量统一用一个库处理，避免资源管理混乱：

• 上传流程统一基于expo-file-system实现，确保所有分片读取、处理都用同一套API，减少混用导致的资源泄漏风险。
• 用react-native-blob-util处理下载时，确保下载完成后调用对应API释放Blob资源（如close()方法），避免残留内存占用。

4. 垃圾回收（GC）相关说明 #

RN的Hermes引擎会自动触发GC，但如果内存中的对象被持续引用，GC无法回收：

• 不建议依赖手动GC，但可以在Debug模式下用global.gc()测试，验证是否是引用未释放导致的问题：

  await uploadChunk(chunkData);
  global.gc?.(); // Debug模式下触发GC，Release模式需额外配置
  

• Release模式下Hermes会自动优化GC时机，核心解决方向还是从代码层面解除无用引用。

5. 改用流处理（推荐） #

如果服务器支持分块流上传，优先用react-native-blob-util的流上传能力，无需把整个分片读入内存：

const uploadChunk = async (fileUri, start, chunkSize) => {
  const stream = await RNFetchBlob.fs.readStream(
    fileUri,
    'base64',
    chunkSize
  );
  // 执行流加密、上传逻辑...
  stream.close(); // 处理完关闭流，释放资源
};

流处理只会加载当前需要处理的部分数据，内存占用会稳定在分片大小范围内，不会持续增长。

6. 加密环节的内存优化 #

• 检查加密函数是否创建了持久化的大对象，比如加密后的Buffer是否被存入全局数组，或加密过程中是否存在内存泄漏。
• 改用异步加密库，避免同步操作阻塞JS线程，导致GC无法及时执行。

验证工具 #

用Flipper的Memory Inspector工具抓取内存快照，对比每次上传分片前后的内存变化，找出持续增长的对象类型（如String、Uint8Array），定位具体泄漏点。

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