nRF52在iOS端更新GATT服务后无法触发服务发现的程序化解决方案问询

核心触发原因 #

iOS CoreBluetooth内置本地GATT服务缓存机制：对已建立过连接的外设，系统会直接读取本地存储的旧服务结构，不会主动发起新的服务发现流程。你遇到的“更新含新增服务的版本后异常、需飞行模式重置蓝牙才能恢复”的场景，本质就是外设的GATT结构变更后，没有给系统传递明确的“服务已修改”信号，导致iOS持续命中旧缓存，跳过自动服务发现。

设备侧（nRF52端）可直接落地的处理 #

• 严格按照BLE规范配置并主动推送服务变更指示（0x2A07）：在GATT数据库中添加对应特征，在连接建立事件触发后1s内，主动向已连接的iOS端发送全服务范围（句柄范围0x0001~0xFFFF）的变更指示，触发iOS端自动刷新本地GATT缓存。注意需要给该特征的CCC描述符配置正确的访问权限，允许iOS端开启指示接收，无权限配置的指示无法被系统识别。nRF52 SDK中可直接调用ble_gatts_service_changed_ind_send 完成指示发送。
• 服务结构变更时同步更新外设可识别标识：小幅修改设备信息服务中的*设备名称（0x2A00）或系统ID（0x2A23）*特征值，给iOS端提供明确的身份变更信号，绕开原有缓存的匹配逻辑。注意不要修改外设的蓝牙MAC地址，仅修改特征值即可，改动量极小。
• 广播包内容和实际GATT数据库保持严格一致：把新增的服务UUID完整加入广播的服务列表字段，避免iOS扫描到广播信息后和实际服务结构不匹配，直接跳过自动服务发现流程。

App侧（iOS端）兜底处理逻辑 #

• 不依赖系统自动触发的服务发现流程，在收到连接成功的代理回调后，主动显式调用peripheral.discoverServices(nil) 发起全量服务发现，强制系统发起ATT层的服务读取请求。
• 增加异常检测逻辑：当服务发现返回的UUID列表和预期结构不匹配时，主动断开当前连接，间隔2s后重新发起连接，连续重试2次即可绕过缓存读取问题，无需用户手动切换飞行模式重置蓝牙。
• 调试阶段可临时在App内增加“清除当前外设缓存”的调试入口，触发系统重新读取全量GATT结构，替代手动重置蓝牙的操作。

调试排查建议 #

• 使用蓝牙抓包工具过滤ATT层交互，观察连接建立后iOS是否主动发起Read By Group Type Request请求：如果未发起，即可确认是本地缓存命中问题，优先排查服务变更指示的发送逻辑；如果发起但返回的服务结构异常，需检查nRF52端的GATT句柄是否存在重叠、权限配置是否错误、服务是否未完全初始化就开启广播。
• 检查SoftDevice配置：Nordic官方SDK中默认的服务变更发送逻辑，需确保未被注释，且连接参数协商完成后再触发指示发送，避免连接未稳定时发送的指示被系统丢弃。
• 避免在GATT服务未完成注册时就开启广播，防止iOS将不完整的服务结构固化到本地缓存中，后续即使服务补全也无法正常识别。

注意：该类异常仅在iOS端出现的核心原因，是Android端无系统级的GATT本地缓存机制，每次连接都会主动发起全量服务发现，因此不会受旧服务结构的影响。

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