React Native应用内存泄漏排查：推荐使用JS层面调试工具还是原生性能分析工具？

刚好之前在使用Hermes的React Native项目里蹲过内存泄漏的坑，其实这两类工具真不是“二选一”的关系，而是要配合着用——核心是先搞清楚你的内存泄漏到底出在JS层还是原生层，再针对性选工具效率才高。

先从JS层工具说起（React Native DevTools、Chrome DevTools） #

大部分React Native应用的内存泄漏，其实根源都是JS层的问题，比如：

• 组件卸载后没清理定时器、事件监听器（比如setInterval没清、自定义事件的订阅没移除）
• Context、Redux这类状态管理库中，意外持有了已卸载组件的引用
• 自定义Hook里的异步请求、订阅逻辑没做销毁处理

这种情况优先用React Native DevTools的Memory tab，它和Hermes的兼容性拉满，操作起来也直接：

1. 打开RN DevTools，切换到Memory面板
2. 先拍一个初始堆快照（比如应用刚启动、目标组件未加载时）
3. 复现你怀疑有泄漏的操作（比如反复打开/关闭某个页面）
4. 再拍一次快照，对比两次快照里的对象差异——如果某个组件实例在卸载后还大量存在，顺着引用链就能找到是谁在“抓着”它不放（比如某个全局定时器、未清理的订阅）

如果你更习惯Chrome的调试流程，也可以用Chrome DevTools，不过要记得开启Hermes的远程调试模式。只是注意，Hermes和Chrome的快照数据可能有一点点偏差，所以优先推荐RN DevTools。

再说说原生层工具（Xcode Instruments、Android Studio Profiler、LeakCanary） #

如果JS层排查了一圈，内存还是持续增长，那就要考虑原生层的问题了，比如：

• 第三方原生模块里的OC/Swift/Java代码出现循环引用
• 原生模块错误地持有了JS对象的引用没释放（跨层泄漏）
• 原生侧的图片、大资源加载后没及时释放

这时候对应的工具就派上用场了：

• Android端：用LeakCanary会很省心，它能自动检测原生Java/Kotlin对象的泄漏，直接给你弹出泄漏提示和完整引用链；Android Studio Profiler的Memory面板可以实时监控内存变化，还能导出堆转储做深度分析。
• iOS端：Xcode的Instruments里的Leaks工具，能精准追踪OC/Swift对象的泄漏情况，还能看到对象的分配栈和引用关系，帮你快速定位到泄漏的代码位置。

总结一下排查流程 #

我一般会按这个顺序来，效率最高：

1. 先用JS层工具快速扫一遍，排除90%以上的常见JS侧泄漏
2. 如果JS层没问题，再切换到原生工具查原生侧的问题
3. 要是遇到跨层的泄漏（比如原生模块持有了JS回调函数的引用），就得两边工具配合着交叉验证了

内容来源于stack exchange