React Native真机崩溃问题：如何排查崩溃原因？

我来分享几个针对这种「模拟器正常但真机直接崩溃」场景的排查步骤，都是日常处理这类问题时验证有效的方法：

1. 优先获取崩溃日志，定位核心问题 #

没有日志的排查都是瞎猜，第一步一定要拿到真机的崩溃信息：

• 用ADB抓取实时日志：连接真机到电脑，执行命令过滤错误日志：

  # 查看所有级别为Error的日志
  adb logcat *:E
  # 过滤React Native相关的日志，更精准
  adb logcat ReactNative:V ReactNativeJS:V *:E
  

  启动应用后，日志里会显示崩溃的堆栈信息，比如是Java层的原生崩溃，还是JS层的错误。
• 用Android Studio查看崩溃详情：把真机连接到Android Studio，打开Logcat面板，选择对应的设备和应用进程，启动应用后就能看到完整的崩溃轨迹，甚至可以直接定位到原生代码的报错行。

2. 检查权限差异：模拟器默认权限≠真机权限 #

Android 6.0（API 23）开始引入动态权限，模拟器通常会自动授予所有权限，但真机需要手动申请：

• 确认AndroidManifest.xml里是否声明了必要的权限（比如存储、相机、位置等）；
• 检查代码中是否针对危险权限做了动态申请逻辑，比如使用PermissionsAndroid模块；
• 测试时手动去系统设置给应用开启所有权限，看是否还会崩溃——如果开启后正常，就是权限申请逻辑的问题。

3. 排查原生代码/第三方库的兼容性问题 #

模拟器和真机的硬件、系统环境差异可能导致原生模块行为不一致：

• 硬件相关模块排查：如果应用用到了相机、传感器、蓝牙等硬件模块，检查这些模块在真机上的初始化逻辑，比如是否判断了硬件是否存在，是否处理了权限拒绝的情况；
• API版本适配：Android 23到26之间有不少API变更，比如FileProvider替代Uri.fromFile、权限申请API的变化，检查原生代码中是否有直接调用高版本API但没做兼容判断的情况；
• 第三方库排查：逐个禁用第三方RN库（注释掉相关代码和依赖），用二分法测试哪个库导致崩溃——有些库在特定Android版本的真机上存在未修复的bug，尝试升级到最新版本或者替换替代库。

4. 验证构建与签名配置差异 #

Debug版本（模拟器常用）和Release版本（真机可能用的是这个）的配置差异也会导致崩溃：

• 签名配置：如果真机安装的是Release包，检查签名文件是否配置正确，是否和调试签名一致（有些库对签名有要求）；
• 混淆配置：Release包如果开启了ProGuard/R8混淆，检查是否添加了React Native的混淆规则，避免RN核心代码被混淆导致崩溃；
• 构建类型差异：确认Debug和Release的gradle配置是否一致，比如是否有某些依赖只在Debug模式下存在。

5. 排查系统定制化与资源问题 #

国内厂商的定制系统（小米、华为、OPPO等）可能有额外的限制：

• 电池优化/后台限制：有些系统会默认限制应用的后台运行权限，导致应用启动时被杀死，尝试把应用加入电池优化白名单；
• 资源兼容性：检查应用中的图片、音频等资源是否存在真机不支持的格式，比如某些高分辨率图片在低配置真机上加载失败导致OOM；
• 系统版本特性：比如Android 26的后台执行限制，检查应用是否在启动时执行了后台任务而没有适配。

6. JS层崩溃的特殊排查 #

如果日志显示是JS层崩溃，而模拟器正常，可以尝试：

• 禁用Hermes引擎：如果开启了Hermes，暂时关闭它测试，看是否是Hermes在特定版本真机上的兼容性问题；
• 清除缓存：执行npx react-native start --reset-cache清除缓存，重新打包安装；
• Remote Debugging（如果能启动）：如果应用能短暂启动再崩溃，开启Remote Debugging查看JS控制台的错误信息。

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