react-native-memory-profile(JSC 与 V8)
- 选择要进行内存分析的分支
- npm i
- 在单独的终端中使用 `npm run start-server` 命令运行服务器。
- react-native run-android(用于开发)
- cd android && ./gradlew assembleRelease 用于发布 apk
无需安装即可测试 APK
从 ${PROJECT_ROOT}/releaseAPK 下的相应分支下载 APK 文件
我们@WalmartLabs的 Android 应用遇到了内存问题,因为 Android 原生的 JSC 垃圾回收机制非常有限。我们尝试了多种方法来减少应用的内存占用,但都无济于事。
当使用 React Native 的扁平列表应用并添加大量项目(我们这里大约有 1000 个)时,问题变得更加严重。每次页面切换都会持续增加内存占用,即使清除数据也无法减少。
几周前,@kudochien 在推特上提到了react-native-v8包,它可以让我们把 V8 与 React Native 打包到 Android 系统中,而不是使用 JSC。
与此同时,jsc-android也发布了新版本 245459.0.0,而 Hermes 则在 @ChainReactConf 上正式发布。
因此,我们决定比较Stock JSC (v241213.1.0)、new JSC (v245459.0.0)、Hermes和react-native-v8的内存占用情况,并创建了一个示例存储库来模拟真实世界的用例。
新版 JSC v241213.1.0 的内存管理性能优于之前的版本 v241213.1.0,Hermes 紧随其后,但 react-native-v8 在应用启动内存、扁平列表内存管理、大数据内存占用以及最重要的垃圾回收方面都遥遥领先。
它是三者中性能最差的。内存占用非常高,垃圾回收率却很低。
应用启动内存(MB) - 59(总计),20(JS)
加载扁平列表后(MB)(870 项) -> 239(总计),128(JS)
添加记录后(添加 16 条记录后应用崩溃)(MB) -> 1153(总计),1098(JS)
垃圾回收- 极少
它在内存管理和垃圾回收方面比 Stock JSC 做得更好。
应用启动内存(MB) - 53(总计),15(JS)
加载扁平列表后(MB)(870 项) -> 191(总计),107(JS)
添加记录后(MB) -> 714(总计),596(JS)
垃圾回收-> 已完成,内存降至 234 MB(总计),121 MB(JS)
应用启动内存(MB) - 40(总计),9(JS)[下降 55%(JS)]
加载扁平列表后(MB)(870 项) -> 105(总计),36(JS)[下降 70%(JS)]
添加记录后(100 条) -> 82(总计),25(JS)[期间执行了垃圾回收]
垃圾回收-> 已执行,最大内存达到 103 MB(总计),36 MB(JS),垃圾回收后约为 78 MB(总计),14 MB(JS)
Hermes 于 7 月 11 日在 ChainReactConf 大会上发布。它是一个开源的 JavaScript 引擎,针对在 Android 上运行 React Native 应用进行了优化。
应用启动内存(MB) - 33(总计),7(JS)[下降65%(JS)]
加载扁平列表后(MB)(870项) -> 397(总计),110(JS)
垃圾回收后(MB) ** -> 358(总计),48(JS)
** 添加记录后(添加50条记录后应用崩溃) -> 556(总计),149(JS)
垃圾回收-> 已执行,最大内存达到556 MB(总计),149 MB(JS),垃圾回收后约为143 MB(总计),48 MB(JS)
根据内存分析图,react-native-v8 胜出,Hermes 紧随其后。
但是,在 React Native 中选择 JS 引擎并没有万能的解决方案,一切都取决于具体的使用场景。因此,测试不同 JS 引擎下的应用性能,并选择最适合你的引擎至关重要。
很高兴现在 react-native 为用户提供了根据使用场景选择 JS 引擎的选项。
文章来源:https://dev.to/anotherjsguy/react-native-memory-profiling-jsc-vs-v8-vs-hermes-1c76