芯耀
207
造成“丢包”（即接收不到部分广播包）的原因是多方面的，主要可以从以下几个层面来解释：
一、 核心原因：蓝牙扫描的“被动监听”机制
手机上的标准蓝牙扫描（特别是在App层面）是被动、非连续的。它不是像收音机一样一直“开着耳朵”听，而是周期性地打开接收窗口进行监听。这个周期由操作系统和应用设置决定。
· 手机扫描间隔：即使信标每500ms发一次，手机的蓝牙扫描器可能每1秒、2秒甚至更长时间才被唤醒一次来“听一下”。如果两次扫描窗口之间信标广播了，这个包就会被错过。
· 扫描窗口持续时间：即使扫描被唤醒，它也只“听”一个很短的时间（例如几十毫秒）。如果在这个“听”的瞬间，没有信标广播，这个扫描窗口就“空”了。
简单比喻：
信标就像一个每分钟响一次（500ms）的闹钟。
您的手机就像一个每隔几分钟才醒过来几秒钟的人，醒来后听一下有没有闹钟声。
如果闹钟在您睡着的时候响了，或者您醒来的那几秒钟恰好没响，您就“漏听”了这次响声。
二、 物理层与环境因素
1. 无线电干扰与碰撞：
· Wi-Fi 与蓝牙同频段干扰：蓝牙和2.4GHz Wi-Fi 都在2.4GHz频段工作。当Wi-Fi路由器、微波炉等设备工作时，会产生强烈的无线电“噪音”，可能直接“淹没”微弱的蓝牙信号。
· 多个信标干扰：如果环境中有多个蓝牙信标（或其他蓝牙设备），它们的广播可能在空气中“撞车”，导致手机无法正确解析任何一个。
2. 信号衰减与多径效应：
· 距离与障碍物：信号强度随距离平方衰减。穿墙、经过人体（人体含大量水分，对2.4GHz信号吸收很强）、金属物遮挡都会大幅削弱信号。
· 信号反射：无线电波会经过墙壁、家具等反射，产生多个路径到达手机。这些相位不同的信号叠加，有时反而会相互抵消，导致特定位置瞬间信号极差，称为“多径衰落”。
三、 手机硬件与操作系统调度
1. 省电策略与CPU休眠：
· 现代手机为省电，会深度管理后台进程。扫描蓝牙的App可能在后台被“挂起”，CPU不再为其工作，导致扫描中断。
· 手机在锁屏状态下，系统会大幅降低扫描频率以节省电量。
2. 天线性能与芯片差异：
· 不同手机型号的蓝牙天线设计、接收灵敏度差异巨大。一些低端机型的接受能力本身就较弱。
· 手机握持姿势（尤其是手握金属边框天线部位）会显著影响信号接收。
3. 操作系统限制：
· iOS/Android 的扫描限制：为了统一管理功耗和隐私，操作系统对后台蓝牙扫描有严格限制。例如，iOS的 CBCentralManager 在后台模式下的扫描行为与前台不同。
· 扫描去重：系统层或SDK层可能会对短时间内收到的相同UUID、相同Major/Minor的信标广播包进行去重，以避免应用层收到过多重复数据，这也会让您感觉“包变少了”。
四、 协议与应用层因素
1. 广播信道跳频：
· 蓝牙BLE广播在3个固定的信道上进行（37, 38, 39）。信标会在这3个信道间轮换发送广播包。
· 如果手机的扫描窗口恰好只“听”了其中一个或两个信道，就会错过在其他信道上的广播。
2. 应用层处理延迟：
· 即使手机底层收到了广播包，还需要经过操作系统调度、传递给前台/后台的App。如果App正在处理其他任务（如UI刷新、网络请求），可能会造成短暂的“处理拥塞”，导致一些包虽然收到但未被App及时记录上报，感觉像是丢了。
如何验证与改善？
1. 使用专业工具验证：使用像 nRF Connect 这样的低层调试工具进行扫描，它能显示最底层的广播包，排除应用层逻辑的影响。
2. 调整信标参数（如可行）：缩短广播间隔（例如从500ms改为200ms），能显著提高被扫描窗口“捕捉”到的概率，但会大幅增加信标功耗。
3. 优化手机设置：确保App有后台运行、位置、蓝牙等所有必要权限；在系统设置中关闭该App的电池优化。
4. 控制环境：在无Wi-Fi干扰、空旷、近距离（1-3米内）环境下测试，作为基准。
5. 应用层容错设计：这是最关键的一点。您的应用程序绝对不能依赖“收到每一个包”。正确的设计应该是：
· 基于信号强度（RSSI）和“最近收到包的时间”来判断距离和存在。
· 使用移动平均、卡尔曼滤波等算法来平滑RSSI值，避免因单次丢包或RSSI跳动导致判断失误。
· 设置合理的超时时间（例如，3-5秒没收到包才认为信标已远离）。
结论
您观察到的“丢包”是预期内的正常现象，而非故障。这是由于无线通信的不确定性、手机系统的功耗管理策略以及蓝牙协议本身的工作机制共同导致的。在实际应用中，20%甚至更高的丢包率都是常见的。关键在于您的应用程序逻辑要能够适应这种不可靠的、间歇性的数据流，通过算法和策略来保证最终用户体验的稳定性和可靠性。
