React Native应用Google Play控制台出现JavascriptException崩溃报错

已上架Google Play的React Native应用，在控制台崩溃统计板块捕获到如下异常栈，常规检索未定位根因的问题，可按以下思路排查解决。

异常原始栈 #

com.facebook.react.common.JavascriptException: 
  at java.lang.reflect.Method.invoke (Native Method)
  at com.facebook.react.bridge.JavaMethodWrapper.invoke (JavaMethodWrapper.java:372)
  at com.facebook.react.bridge.JavaModuleWrapper.invoke (JavaModuleWrapper.java:151)
  at com.facebook.react.bridge.queue.NativeRunnable.run (Native Method)
  at android.os.Handler.handleCallback (Handler.java:888)
  at android.os.Handler.dispatchMessage (Handler.java:100)
  at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage (MessageQueueThreadHandler.java:27)
  at android.os.Looper.loop (Looper.java:213)
  at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run (MessageQueueThreadImpl.java:226)
  at java.lang.Thread.run (Thread.java:929)

这个栈是RN桥接层的通用Native栈，没有携带具体JS侧错误信息，也是大部分同类问题找不到根因的核心原因——Google Play默认采集的是Native层调用栈，JS侧的错误详情被截断了。

排查步骤 #

• 补全JS侧错误上下文采集
  先不要盲目猜问题，现有栈看不到具体触发点，必须先把JS侧的错误信息抓全。在RN应用入口处全局注册错误监听，把JS错误栈、当前路由、设备信息、APP版本等上下文一起上报到自有埋点平台，不要只依赖Google Play的默认崩溃采集：

  // 捕获全局JS致命/非致命异常
  ErrorUtils.setGlobalHandler((error, isFatal) => {
    // 收集error.stack、当前页面路由、设备型号、系统版本、RN版本等信息
    // 信息收集完成后再走原有崩溃流程，不要吞掉错误
  });
  
  // 捕获未处理的Promise异常，这类异常占RN崩溃的30%以上
  require('promise/setimmediate/rejection-tracking').enable({
    allRejections: true,
    onUnhandled: (id, error) => {
      // 同样上报错误栈和上下文
    }
  });
  

• 重点排查Native模块调用场景
  栈中明确显示异常触发点在JavaMethodWrapper.invoke，也就是JS侧调用Java层Native模块时抛出的错误，优先排查几类高频场景：
  • 调用Native模块方法时传参类型不匹配，比如Native层要求传入整型参数，JS侧传了字符串、undefined或者null
  • 页面销毁、组件卸载后，Native模块的异步回调还在执行，持有已经释放的Activity/View引用
  • 升级RN版本、第三方带原生代码的RN库版本后，桥接方法的签名、参数格式发生变化，JS侧未同步修改调用逻辑
  • 高版本Android系统权限适配缺失，比如调用存储、定位、蓝牙相关Native方法前，没有先判断权限是否已经授予
• 检查Release包混淆规则
  如果打正式包开启了ProGuard/R8混淆，确认是否误混淆了RN桥接相关类、自定义Native模块、第三方RN原生模块，导致JS侧找不到对应方法、参数解析失败。在混淆配置文件中补全对应规则：

  # 保留RN核心类不被混淆
  -keep class com.facebook.react.** {*;}
  # 保留自定义Native模块、第三方RN原生模块的类和方法不被混淆，替换成自己项目的实际包路径
  -keep class com.yourpackagename.nativemodules.** {*;}
  

• 定向复现验证
  拿到具体JS错误栈后，优先在对应系统版本的低内存机型上复现问题：
  • 打开开发者选项中的「不保留活动」开关，反复进出疑似崩溃的页面，验证是否为组件卸载后异步回调执行导致的异常
  • 必须打Release包本地测试，不要只在Debug环境验证——Debug环境有红屏拦截，很多类型错误、混淆问题、线上环境的特殊逻辑在Debug下不会触发
  • 排查近期上线版本新增的带原生代码的第三方依赖，可以尝试逐个回退版本，定位是哪个依赖引入的兼容性问题

高频根因对应解决方案 #

• 如果补全的错误信息显示null is not an object：本质是JS侧调用Native方法时，对应的Native模块未成功初始化，常见于部分机型阉割系统服务、权限未授予导致模块初始化失败的场景，在调用Native方法前加非空判断即可
• 如果错误和组件渲染相关：检查Android平台下是否使用了不兼容的组件属性，比如给Image组件传了不支持的resizeMode、滚动组件嵌套层级过深导致的渲染溢出，这类问题在低性能Android机型上触发概率更高
• 如果崩溃仅在特定厂商Android 10+机型上出现：检查是否适配了分区存储、包可见性规则，是否调用了厂商定制的非公开系统API，targetSdkVersion升级到30+后这类适配缺失很容易触发Native调用崩溃

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