首先直接回应你的核心疑问：iOS的CBCentralManager没有直接设置扫描速率的配置项，但Android的BluetoothLeScanner可以通过扫描模式间接控制扫描频率；而导致两者接收数量差异的原因，主要来自系统策略、厂商定制、硬件性能等多个维度，下面逐条拆解：

一、扫描速率的配置可能性 #

iOS端 #

你的代码里已经设置了CBCentralManagerScanOptionAllowDuplicatesKey: true，这是让iOS返回所有收到的广播包（默认会过滤短时间内的重复包），但iOS并没有提供像Android那样的“扫描速率”或“扫描间隔”的直接配置参数——扫描的底层频率由系统管控，前台扫描时系统会保持较高的扫描频率，后台则会降低（从你的测试数据看应该是前台场景）。

Android端 #

Android的BluetoothLeScanner可以通过ScanSettings.Builder间接控制扫描频率，核心是扫描模式的选择：

• 使用setScanMode(ScanSettings.SCAN_MODE_LOW_LATENCY)：这是前台扫描的最高优先级模式，扫描间隔最短，能尽可能多地捕获广播包；
• 若使用SCAN_MODE_BALANCED或SCAN_MODE_LOW_POWER，系统会为了省电主动降低扫描频率，接收包数量会锐减；
• 同时要设置setReportDelay(0)，确保系统收到广播包后立即回调，不会合并延迟上报。

二、导致接收数量差异的核心原因 #

1. 系统扫描策略差异
   iOS在前台开启允许重复扫描后，系统会尽可能返回每一个收到的iBeacon广播包，底层扫描机制的优先级较高；而Android系统本身就有更严格的功耗管控，即便是前台扫描，默认也可能会合并短时间内的相同广播包，减少回调次数。

2. Android厂商的定制优化
   这是不同Android机型接收数量差异巨大的关键：国内小米、华为、OPPO等厂商的ROM会对BLE扫描做额外的省电优化——哪怕你设置了最高扫描模式，系统也可能主动降低扫描频率、过滤弱信号包，甚至在前台也触发“智能省电”限制，不同厂商的管控力度不同，所以出现230-480的数量区间完全符合预期。

3. 硬件接收性能差异
   不同Android手机的蓝牙模块、天线灵敏度存在差异，信号较弱时，性能差的设备会丢失更多广播包；而iOS设备的蓝牙硬件和系统优化更统一，接收稳定性更好。

4. 扫描参数的配置差异
   如果你Android端没有明确设置SCAN_MODE_LOW_LATENCY和setReportDelay(0)，系统会使用默认的平衡模式，自然会比iOS收到的包少很多。

三、优化建议 #

• Android端调整扫描参数：确保代码里使用最高优先级的扫描模式，示例代码如下：

  val scanSettings = ScanSettings.Builder()
      .setScanMode(ScanSettings.SCAN_MODE_LOW_LATENCY)
      .setReportDelay(0)
      .build()
  bluetoothLeScanner.startScan(null, scanSettings, scanCallback)
  

• 关闭厂商省电限制：把测试App加入系统的“电池优化白名单”，关闭“智能省电”“超级省电”等模式，避免系统限制扫描；
• 统一测试环境：固定iBeacon的广播间隔（比如设置为100ms），计算理论5分钟内的广播包数量（3000个），再对比实际接收数量，更清晰定位丢包原因；
• 日志排查：在Android端打印每个广播包的RSSI和时间戳，判断是信号弱导致丢包，还是系统主动过滤。

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