react-native-ble-plx iOS模拟器正常 真机启动崩溃如何调试

这类启动即崩的问题基本都是原生层抛出的错误，JS侧的错误边界、console日志根本捕获不到，按下面的顺序排查就行：

• 第一步先拿原生层崩溃栈，别瞎猜JS逻辑
  用数据线把iPhone连到Mac上，打开Xcode选中真机作为运行目标，直接通过Xcode启动安装在真机上的App，崩溃发生时Xcode会直接打印原生层的完整调用栈，能直接定位到崩溃点是在权限校验、模块加载还是内存访问环节。如果不想全量构建，也可以打开Xcode的Devices and Simulators面板，选中对应真机后点View Device Logs，筛选你自己的App包名，找时间最新的崩溃报告看触发线程的调用栈。
• 优先排查蓝牙权限配置缺失，这是90%同类问题的诱因
  iOS模拟器不会校验蓝牙相关的权限配置，哪怕Info.plist里一个蓝牙相关的键都没加也能正常跑，但真机上只要原生模块加载时检测到缺失权限描述，会直接触发进程级崩溃，连权限申请弹窗都不会弹。
  打开项目路径下的ios/[你的项目名]/Info.plist，确认两个必填权限键都存在且值不为空：
  • NSBluetoothAlwaysUsageDescription：iOS13及以上版本必填，填写你使用蓝牙的具体用途说明
  • NSBluetoothPeripheralUsageDescription：兼容iOS12及以下版本必填，缺了低系统版本真机必崩

  注意：只要你在代码里import了react-native-ble-plx相关的模块，哪怕还没渲染蓝牙页面、没主动调用BleManager初始化，原生端加载模块时就会触发权限校验，所以你移除蓝牙页面就不崩的现象，和这个问题的表现完全吻合。

• 检查模块初始化时机
  不要在App入口文件、根组件的同步执行逻辑里初始化BleManager。真机启动时如果系统蓝牙服务还没就绪、权限还没完成授权就提前触发原生端蓝牙中心对象创建，很容易触发EXC_BAD_ACCESS类型的内存崩溃。调整初始化逻辑：进入蓝牙功能页面前再创建BleManager实例，初始化前先判断当前蓝牙权限状态、蓝牙开关状态，不要把BLE相关逻辑放到App启动的同步执行链路里。
• 校验原生依赖配置一致性
  进入项目的ios目录，执行pod deintegrate && pod install重新安装CocoaPods依赖，确保JS端安装的react-native-ble-plx版本和ios目录下安装的原生pod版本完全一致——版本不匹配时x86架构的模拟器可能兼容运行，arm64架构的真机会因为原生方法签名不匹配，加载模块时直接崩溃。
  同时打开Xcode的Signing & Capabilities面板检查配置：如果确实需要使用蓝牙后台能力，就勾选Uses Bluetooth LE accessories选项；如果不需要后台蓝牙能力，不要在Info.plist里乱加蓝牙后台模式的配置键，错加后台权限也会导致App启动时被系统直接杀掉。
• 排除依赖冲突
  如果上面的配置都没问题，做个最小复现验证：新建一个干净的RN项目，安装同版本的react-native-ble-plx，加好权限配置后跑真机。如果最小Demo能正常启动，说明你现有项目里存在其他依赖和BLE模块冲突——常见的是其他同样调用iOS蓝牙底层接口的库（比如蓝牙打印、特定外设连接、定位相关的库），多个库同时初始化CBCentralManager实例时会触发系统层面的冲突导致崩溃。

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