iBeacon广播帧与后台唤醒：31字节到GATT长连接实战

简介这份压缩包面向需要实现 iBeacon 后台唤醒与蓝牙长连接的 iOS 开发者围绕以单例方式封装 iBeacon 管理这一常见需求给出可直接参考的实现代码。包内共 2 个文件分别为 1 个 h 头文件与 1 个 m 实现文件压缩包约 3KB体量轻巧核心逻辑集中在一个管理器类中结构紧凑便于整体阅读也方便移植到现有工程。目前已有 581 人学习下载。代码涉及 iBeacon 信号的监听与数据解析、按预设规则唤醒 App、申请并使用“始终使用位置”权限以支持后台触发以及蓝牙连接事件的异常处理与电量消耗控制等要点。读者可据此理清单例初始化时机、后台监控的权限前置条件与长连接维护思路避免重复初始化与资源浪费适合作为室内定位、到店推送类应用开发的起步参考。1. 一个硬币大小的信标凭什么能把冷启动的 App 触发起来我把iBeacon.zip解压后做的第一件事不是跑 Demo而是把手机调到广播模式用另一台设备抓包看空口里到底飞了什么。原因很直接iBeacon 唤醒 App 这件事成败九成在广播帧那 31 个字节里就定了剩下的才是权限和连接。这个包里给的是广播端、扫描端、唤醒回调三段配套的东西还带了蓝牙长连接那部分——因为 iBeacon 本身只负责“叫醒”叫醒之后要传数据还得自己起一条 GATT 通道。它适合三类人做室内到店提醒、做资产标签定位、以及被“后台唤不醒”折腾过的 Android/iOS 开发者。下面按“帧怎么拼 → 怎么唤醒 → 怎么连 → 哪里翻车 → 怎么验证”的顺序拆每一步都能直接对着改参数。2. 31 字节广播帧拆解UUID、Major、Minor 到底摆在哪2.1 从空口报文到 Region三层寻址的粒度设计BLE 的一次广播事件空口上是一个完整的包1 字节前导码、4 字节接入地址、2 字节 PDU 头、6 字节广播地址、最多 31 字节的 AdvData最后 3 字节 CRC。iBeacon 的规范只规定了 AdvData 里怎么写其余全是链路层的事所以你会看到很多抓包工具把前面那段灰掉只解析后面 31 字节。这 31 字节里iBeacon 占 28 字节结构是固定的字节序列含义取值02 01 06FlagsLE 通用可发现 不支持 BR/EDR固定1A后续 AD 结构长度 26固定FFAD 类型厂商自定义数据固定4C 00厂商 ID小端存放iBeacon 规范固定02信标类型固定15剩余长度 21固定16 字节Proximity UUID自定义2 字节Major自定义大端2 字节Minor自定义大端1 字节TxPower有符号实测校准02 01 061A FF ...一共 28 字节31 - 28 3 字节余量。这 3 字节就是你以后想塞电池电量、塞传感器状态的全部空间塞不下就只能走长连接或者厂商自定义广播。很多人第一次做产品规划时把 UUID 当“设备唯一 ID”用给每个信标生成一个随机 UUID结果发现 iOS 端一个 Region 只能盯一个 UUID、系统最多挂 20 个 Region设备一多直接崩盘。正确的粒度是三层UUID 标识“这一批信标属于哪个业务场景”Major 标识“哪一层楼 / 哪家门店”Minor 标识“哪个具体点位”。这样 Region 可以按三种粒度注册只给 UUID整个场景、UUID Major某一层、UUID Major Minor某个点位。粒度越细系统过滤越省电但可注册的 Region 总数是硬上限规划编号时就得把预算算清楚。这里还有一个容易被忽略的坑UUID 在报文里是按 RFC 4122 的大端顺序逐字节写入的Major 和 Minor 同样是高位在前。有些第三方生成工具输出的是小端序拼出来的包抓开一看 Major 变成0xE9 0x03而不是0x03 0xE9接收端算出来的编号永远对不上。我一般写完广播代码后第一件事就是拿通用 BLE 调试工具抓一包肉眼核对这 20 个字节。2.2 TxPower 与 RSSI那个 -59 是怎么来的TxPower 是 iBeacon 里被误解最深的一个字段。它不控制发射功率发射功率是芯片的射频参数跟这个字节没关系。TxPower 的含义是在 1 米远处接收端应该测到多少 dBm。它是一个“校准参考值”接收端拿到它才能把 RSSI 换算成距离。典型取值是 -59因为大多数信标在 0 dBm 发射功率、全向天线、1 米无遮挡的条件下RSSI 落在这个附近。但它是个有符号字节意味着范围是 -128 到 127实际工程里一般落在 -100 到 -40 之间。如果你的信标外壳是金属的、或者天线朝向贴墙1 米实测可能只有 -70那 TxPower 就得老老实实写 -70否则算出来的距离会偏大一倍以上。距离换算用的是对数衰减模型d 10 ^ ((TxPower - RSSI) / (10 * n))n是路径损耗指数。自由空间取 2.0办公室有隔断取 2.5 到 3.0货架密集的仓库能到 3.5。这个模型在 1 到 5 米内还算能用超过 10 米误差会大到没有参考价值——不是因为公式不对是因为多径反射让 RSSI 的方差本身就很大。所以别指望用 RSSI 做厘米级定位用它做“远了 / 近了”的粗判定才是合理预期。2.3 用手机把自己变成信标广播端逐字节拼包包里广播端用的是手机外设模式把上面那 28 字节手工拼出来扔进厂商自定义数据。Android 侧的实现是这样// BeaconAdvertiser.kt —— 把手机自己变成一枚 iBeacon private val advCallback object : AdvertiseCallback() { override fun onStartSuccess(settingsInEffect: AdvertiseSettings) { Log.i(TAG, 广播已启动间隔${settingsInEffect.mode}) } // 失败码 1数据太长 2太频繁 3未开蓝牙先把这三个查一遍 override fun onStartFailure(errorCode: Int) { Log.e(TAG, 广播启动失败 code$errorCode) } } fun startBeacon(uuid: UUID, major: Int, minor: Int, calibratedRssi: Byte -59) { val advertiser bluetoothAdapter.bluetoothLeAdvertiser ?: return Log.e(TAG, 该设备不支持外设模式) val settings AdvertiseSettings.Builder() .setAdvertiseMode(AdvertiseSettings.ADVERTISE_MODE_LOW_LATENCY) // 约 100ms 一包 .setTxPowerLevel(AdvertiseSettings.ADVERTISE_TX_POWER_HIGH) .setConnectable(false) // iBeacon 只广播不接收连接置 true 会多出可连接标志位 .setTimeout(0) // 0 不超时一直发 .build() val payload ByteArrayOutputStream().apply { write(byteArrayOf(0x02, 0x15)) // 信标类型 后续 21 字节 write(uuidToBigEndian(uuid)) // 16 字节务必大端别用 toString 再转 write(byteArrayOf((major shr 8).toByte(), major.toByte())) // Major 高字节在前 write(byteArrayOf((minor shr 8).toByte(), minor.toByte())) // Minor 高字节在前 write(calibratedRssi.toInt()) // 1 米处实测值写错距离全错 }.toByteArray() val data AdvertiseData.Builder() // 厂商 ID 由系统补在数据前面这里只传 02 15 之后的部分别自己再写 4C 00 .addManufacturerData(0x004C, payload) .setIncludeDeviceName(false) // 关掉名字否则 31 字节放不下 .setIncludeTxPowerLevel(false) // 同样为了省字节 .build() advertiser.startAdvertising(settings, data, advCallback) }这段代码有三个参数需要专门说明。setAdvertiseMode选LOW_LATENCY时广播间隔约 100ms扫描端发现延迟通常在 1 秒内代价是功耗BALANCED约 250msLOW_POWER约 1000ms 但发现延迟能到 5 秒以上做“到店提醒”这种场景别用低功耗档。setIncludeDeviceName(false)不是可选项而是必须项设备名动辄十几字节加上去立刻超过 31 字节上限有的芯片会直接截断广播数据表现就是“广播回调成功、对方扫不到”非常难查。addManufacturerData的第一个参数是厂商 ID系统会自动把它以小端形式写进 AD 结构如果你在 payload 里又手写一遍4C 00接收端解析出来的类型字段就整体错位UUID 全是乱码。iOS 侧没有开放广播厂商自定义数据的接口所以包里 iOS 部分做的是接收端。要去验证广播帧是否正确我一般用一台 Android 发、一台设备收两边对照 Major/Minor 是否一致比盯着日志猜快得多。3. iBeacon 唤醒 App后台监听的触发条件与权限链3.1 Monitoring 与 Ranging 的分工谁负责叫醒谁负责测距iOS 把信标监听拆成了两套完全不同的机制混用是新手最常见的错误来源。startMonitoring(for:)是区域监听它的语义是“告诉我进没进这个区域、出没出去”系统在底层用极低占空比去嗅探即使 App 已经被系统回收只要不是用户手动上划杀掉蓝牙事件到来时系统会把 App 在后台拉起来投递回调。这是 iBeacon 唤醒能力的核心。它的代价是延迟系统为了省电会拉长扫描窗口实测进入区域的回调通常在 1 到 15 秒之间极端情况能到几十秒而且这个延迟不受你控制。startRangingBeacons是测距它每隔约 1 秒给你一批信标带 RSSI 和推算距离。但它只在 App 处于前台或刚退到后台的那十几秒内有效进入后台运行一会儿就会被系统停掉。所以正确的用法是Region 回调负责叫醒叫醒后如果用户可能在看屏幕再开 Ranging 做精细判断。从 iOS 13 起 Ranging 的 API 换成了基于约束对象的形式兼容写法是这样// BeaconMonitor.swift —— 先挂 Region 负责唤醒再按需开 Ranging let uuid UUID(uuidString: E2C56DB5-DFFB-48D2-B060-D0F5A71096E0)! // 粒度可以只给 uuid也可以叠加 major / minor粒度越细越省电 let region CLBeaconRegion(uuid: uuid, major: 1001, minor: 1, identifier: demo-region) // 屏幕点亮时补一次状态判定能明显缩短“用户已经站在信标前但没回调”的窗口 region.notifyEntryStateOnDisplay true locationManager.delegate self locationManager.requestAlwaysAuthorization() // 必须 AlwaysWhenInUse 后台不投递 locationManager.startMonitoring(for: region) // 测距只在需要精确距离时开且不要指望它在后台长期存活 if #available(iOS 13.0, *) { let constraint CLBeaconIdentityConstraint(uuid: uuid, major: 1001, minor: 1) locationManager.startRangingBeacons(sensing: constraint) } else { locationManager.startRangingBeacons(in: region) }notifyEntryStateOnDisplay这个开关值得单独说打开后用户点亮屏幕的瞬间系统会补做一次区域判定。很多“到店提醒”类需求抱怨唤醒太慢实际上用户走到店门口、掏出手机点亮屏幕的那一刻才是最佳触发点靠这个开关比靠调广播间隔有效得多。回调里要做的事也有讲究func locationManager(_ manager: CLLocationManager, didDetermineState state: CLRegionState, for region: CLRegion) { guard state .inside, region.identifier demo-region else { return } // 这里已经能被后台唤起了但千万别直接开长连接 // 后台连接保活时间有限先做一次短扫描确认对方在不在再决定连不连 scheduleQuickScan(windowSeconds: 5) }3.2 两端权限清单Android 12 的 neverForLocation 与 iOS 的 Always唤醒失败八成是权限链断了而不是代码写错。两端要的东西完全不一样。iOS 侧要三样定位权限必须是AlwaysWhenInUse在前台正常退到后台就不再投递区域回调Info.plist里要有定位用途说明Xcode 的 Capabilities 里要勾上蓝牙后台模式bluetooth-central否则 App 在后台收不到蓝牙事件。另外系统对单个 App 的区域监听数量有上限20 个左右超出的部分静默失效不报错——这是最难查的一种。Android 侧要复杂得多且随版本层层加码系统版本必需权限容易漏的点6.0 - 9蓝牙 定位ACCESS_FINE_LOCATION定位服务总开关必须打开否则扫不到任何结果10 - 11增加ACCESS_BACKGROUND_LOCATION后台扫描必须有它且要引导用户选“始终允许”12 及以上BLUETOOTH_SCAN、BLUETOOTH_CONNECT运行时申请见下方 neverForLocation 陷阱Android 12 引入了android:usesPermissionFlagsneverForLocation这个属性本意是让不需要定位的 App 声明“我扫蓝牙不是为了推算位置”从而免掉定位权限。问题在于一旦声明了这个标志系统会把扫描结果里所有可用于推断位置的广播过滤掉而 iBeacon 恰恰属于这一类。表现就是权限全给了、蓝牙也开着、广播端明明在发onScanResult一个回调都没有。解决方法是把这一行去掉老老实实申请定位权限。3.3 把唤醒链路写完整注册扫描 → 回调 → 拉起前台Android 没有系统级的区域监听常规做法是常驻前台服务一直扫代价是通知栏永远挂一条。包里用的是更省事的另一条路把扫描交给系统代劳用PendingIntent形式注册App 进程被杀掉后系统仍会替你扫扫到就发一个广播把进程拉起来。// BeaconWakeup.kt —— 用 PendingIntent 注册扫描进程死了也能被拉起来 val settings ScanSettings.Builder() .setScanMode(ScanSettings.SCAN_MODE_LOW_POWER) // 交给系统时本来也会被降频 .setCallbackType(ScanSettings.CALLBACK_TYPE_ALL_MATCHES) // 该模式下必须是这个值 .setReportDelay(0) // 同样必须为 0否则注册失败 .build() // 只匹配厂商自定义数据的前两个字节02 15UUID 在回调里自己再判 val filter ScanFilter.Builder() .setManufacturerData(0x004C, byteArrayOf(0x02, 0x15), byteArrayOf(0xFF.toByte(), 0xFF.toByte())) .build() val pending PendingIntent.getBroadcast( context, 1001, Intent(context, BeaconReceiver::class.java).setAction(ACTION_BEACON_FOUND), PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_MUTABLE ) scanner.startScan(listOf(filter), settings, pending)逻辑上有两点要说明。setManufacturerData的第三个参数是掩码长度必须与第二个参数一致掩码位为0xFF表示该字节必须精确匹配这里只给了前两字节的掩码长度不够时会直接抛异常所以实际项目里我会把数组补齐到与数据等长、后面全填0x00表示“任意”。另外这个接口的扫描频率由系统调度发现延迟通常比前台主动扫描慢一个档次做门禁、迎宾这种对时延敏感的场景还是得用前台服务。广播接收器里只做一件事把信标标识取出来扔给前台服务去处理连接别在onReceive里做耗时操作10 秒超时会 ANR。class BeaconReceiver : BroadcastReceiver() { override fun onReceive(ctx: Context, intent: Intent) { val result intent.getParcelableExtraScanResult(BluetoothLeScanner.EXTRA_DEVICE) ?: return val rssi intent.getIntExtra(BluetoothLeScanner.EXTRA_RSSI, -127) // 解析 02 15 之后的 21 字节16 字节 uuid 2 字节 major 2 字节 minor 1 字节 txPower val parsed parseIBeacon(result.scanRecord?.bytes) ?: return if (rssi -85) return // 太弱的信号不值得唤醒省电也省误报 BeaconService.start(ctx, result.device, parsed) } }那个rssi -85 return的阈值不是拍脑袋弱信号下连接成功率极低唤起了也连不上反而多一次失败重连的耗电。4. 蓝牙长连接唤醒之后把数据搬完的那几秒4.1 为什么 iBeacon 只能叫醒、不能传数据广播是单向的发送方喊完就完事没有任何确认机制也建立不了会话。31 字节的载荷里 28 字节被固定结构占掉剩下的空间连一个时间戳加一个电量都塞得勉强。所以只要你的需求里出现“下发配置”“上传日志”“OTA”就必须在广播之后另起一条 GATT 连接。常规流程是广播唤醒 → 扫描确认设备在 →connectGatt建连 → 发现服务 → 读特征值或订阅通知 → 数据搬完 → 主动断开。最后一步很多人省掉觉得保持连接下次更快结果电池和稳定性双双翻车。连接本身有几个状态要盯STATE_CONNECTING、STATE_CONNECTED、STATE_DISCONNECTED。真正能开始读写的是服务发现完成之后也就是onServicesDiscovered回调里status GATT_SUCCESS才代表链路可用。在建连成功就立刻读特征值的写法十次里有三次拿到空值。4.2 连接参数三件套interval / latency / timeout 的取值权衡蓝牙长连接“稳不稳”大半取决于三个参数怎么配参数取值范围影响常见配法连接间隔 interval7.5ms - 4s步进 1.25ms越小越快越费电数据流 15-30ms心跳 200-500ms从机延迟 latency0 - 499 个间隔从机可跳过的包数省电但增加时延电池设备取 4-20实时设备取 0监督超时 timeout100ms - 32s多久收不到包判定断连取 interval 的 4-6 倍留余量有一条硬约束必须满足timeout (1 latency) × interval × 2。不满足时对端会直接拒绝参数更新请求而你只会看到一次静默失败日志里什么都不打。这是我在现场排查过最久的一个问题最后是拿计算器把三组数字代进去才发现的。还有一点平台差异iOS 作为中心设备时最小连接间隔是 15ms而且中心设备不能强行指定参数只能发一个“期望值”请求最终由外设决定。Android 相对宽松requestConnectionPriority有三档可选底层发的就是一个参数更新请求。4.3 Android 端的连接、参数更新与重连// BeaconGattClient.kt —— 建连 提优先级 退避重连 fun connect(device: BluetoothDevice) { // autoConnectfalse 走直连速度快true 会一直挂着等适合“迟早要连上”的场景 gatt device.connectGatt(context, false, callback, BluetoothDevice.TRANSPORT_LE) } private val callback object : BluetoothGattCallback() { override fun onConnectionStateChange(g: BluetoothGatt, status: Int, newState: Int) { if (newState BluetoothProfile.STATE_CONNECTED) { // 必须在发现服务之前提优先级顺序反了不生效 g.requestConnectionPriority(BluetoothGatt.CONNECTION_PRIORITY_HIGH) g.discoverServices() } else if (newState BluetoothProfile.STATE_DISCONNECTED) { g.close() retryCount // 指数退避避免信号弱时疯狂重连把电耗光 val delayMs minOf(30_000L, 500L * (1L shl minOf(retryCount, 6))) handler.postDelayed({ connect(g.device) }, delayMs) } } override fun onServicesDiscovered(g: BluetoothGatt, status: Int) { if (status ! BluetoothGatt.GATT_SUCCESS) return val ch g.getService(SERVICE_UUID)?.getCharacteristic(CHAR_UUID) ?: return // 开通知接收外设推送 g.setCharacteristicNotification(ch, true) val cccd ch.getDescriptor(CCCD_UUID) cccd.value BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE g.writeDescriptor(cccd) } }requestConnectionPriority(CONNECTION_PRIORITY_HIGH)对应的就是大约 11.25ms 间隔、0 延迟那一档传输吞吐最高但电流也最高。传完数据记得降回CONNECTION_PRIORITY_BALANCED否则一个挂在后台的连接能把手机续航啃掉一截。重连用指数退避而不是固定间隔是血泪经验现场信号差的时候固定 500ms 重连一小时能试七千次手机烫得握不住。4.4 iOS 端后台连接的状态保存与恢复iOS 的麻烦在于进程随时可能被系统回收。解法是CBCentralManager初始化时带上恢复标识符并在Info.plist里声明蓝牙中心后台模式// 带恢复标识建管理器系统回收进程后会带着连接状态把 App 拉回来 central CBCentralManager(delegate: self, queue: nil, options: [CBCentralManagerOptionRestoreIdentifierKey: beacon-restore]) func centralManager(_ central: CBCentralManager, willRestoreState dict: [String: Any]) { // 进程重启后这里是唯一能拿回旧外设引用的机会务必接住 if let restored dict[CBCentralManagerRestoredStatePeripheralsKey] as? [CBPeripheral] { self.peripherals restored restored.forEach { $0.delegate self } } }willRestoreState里拿回的外设对象已经断开了但引用是有效的直接调用connect就能续上比你从头扫一遍快得多。这条链路只有在“App 被系统回收”时成立用户手动上划杀掉的不算。5. 避坑与排查五个让 iBeacon 项目卡住的现场5.1 广播回调成功但对方扫不到厂商 ID 写了两遍现象onStartSuccess正常打印另一台设备扫不到任何厂商数据或者抓包看到的厂商数据里 UUID 整体错位两字节。原因Android 的addManufacturerData第一个参数就是厂商 ID系统会自动以小端写进 AD 结构。有人在 payload 里又手写了一遍0x4C 0x00结果报文里出现两遍厂商 ID解析端按规范读出来的类型字段变成0x02之外的垃圾值。解决payload 只放02 15之后的内容也就是 24 字节。改完后拿通用 BLE 调试工具抓一包逐字节核对能看到1A FF 4C 00 02 15这六个字节连在一起才算对。5.2 Android 12 扫不到任何信标neverForLocation 把结果过滤没了现象权限全部授予、定位开关打开、蓝牙正常startScan后onScanResult一次都没触发换成别的 App 却能扫到。原因清单文件里声明了android:usesPermissionFlagsneverForLocation。这个标志会让系统把可用于推断位置的广播从结果里滤掉iBeacon 正在名单里。解决删掉这一行同时补上ACCESS_FINE_LOCATION的运行时申请。如果产品确实不想申请定位权限那就只能改协议换成自定义厂商数据加自己约定的格式代价是失去通用性。5.3 iOS 后台收不到 didEnterRegion三种不同病因现象前台一切正常退到后台就再也不回调锁屏更没反应。原因通常有三个。一是定位授权被用户选成了“使用 App 期间”后台直接不投递二是用户从后台切换器上划杀掉了 App这种状态下系统不会再为区域事件重启进程直到用户主动再打开一次三是注册的 Region 超过系统上限后面的静默失效。解决启动时调locationManager.authorizationStatus判断是否authorizedAlways不是就弹引导页说明为什么需要“始终允许”被强杀这个无解只能通过引导用户不要上划来缓解或者改用其他能自恢复的推送通道兜底Region 数量用monitoredRegions打印出来数一数把不用的stopMonitoring掉。5.4 距离从 2 米跳到 30 米TxPower 没校准 用单包 RSSI现象accuracy值剧烈跳变同一位置相邻两秒能给出 1.8 米和 27 米两个结果Android 侧自己算的距离更是没法看。原因一是 TxPower 填的是规范默认值 -59而实际外壳和天线装出来 1 米处是 -71模型整体偏了 12dB换算距离直接差出好几倍二是用了单次 RSSI 做判断而 RSSI 本身方差就有 6 到 10dB单点采样毫无统计意义。解决按下一章的三点采样法重新校准 TxPower然后对 RSSI 做滑动平均至少取 20 个包的中位数再代入公式。做“近 / 中 / 远”三档判定比做连续距离可靠得多。5.5 长连接撑不过五分钟超时参数和系统休眠现象连接建立后能正常收发放那儿不动三五分钟就断开重连又正常反复。原因一是监督超时设得太小比如间隔 30ms、延迟 0、超时 200ms稍有干扰就判定链路丢失二是手机进入休眠后射频被节流尤其 Android 的 Doze 模式下后台连接会被压制。解决把 timeout 抬到(1latency) × interval × 2的两倍以上留足余量判断数据传完就主动断开、下次唤醒再连别硬扛保活确实需要长期在线的设备改成外设主动定时广播、中心设备被动扫描的模型功耗和稳定性都好得多。6. 校准与验证把“信标能用”变成三个可复现的数字信标这类东西最怕“体感验收”站着走两圈觉得差不多就上线回头现场全是投诉。我后来固定用一套三点采样流程每个新硬件、每种新外壳都要过一遍。准备一条卷尺在开阔无遮挡的地方标出 1 米、3 米、10 米三个位置手机固定在离地 1.2 米高度每个点静置采集 60 个广播包。采样时把数据直接打印成一行行的distance,rssi回来丢给脚本算import math, statistics def calibrate(samples, default_n2.0): samples: {距离(米): [rssi, ...]}返回每点的中位数与反推的 n rows, ns [], [] for d, rssis in sorted(samples.items()): # 先剔除异常值-127 表示无效-100 以下基本是丢包噪声 clean [r for r in rssis if -100 r 0] if not clean: continue med statistics.median(clean) # 中位数比均值抗多径 n (TX_POWER_SEED - med) / (10 * math.log10(d)) if d ! 1 else default_n if d ! 1: ns.append(n) rows.append((d, round(med, 1), len(clean), round(n, 2))) return rows, (statistics.mean(ns) if ns else default_n) def rssi_to_meter(rssi, tx_power, n): 拿校准后的 tx_power 和 n 反算距离 return round(10 ** ((tx_power - rssi) / (10 * n)), 2) TX_POWER_SEED -59校验时看两个数1 米点的中位数就是新的 TxPower直接写回广播端3 米和 10 米反推出的n应该在 2.0 到 3.5 之间偏离这个区间说明采样环境有问题旁边有金属货架、或者人站在了中间重采。判定标准我会记成一张表硬件验收时逐项打勾检查项通过标准不通过时先查1 米中位 RSSI与写入的 TxPower 偏差 ≤ 3dB天线朝向、外壳材质反推路径损耗指数 n2.0 - 3.5采样环境是否有遮挡或反射面10 米处有效包率≥ 60%60 包收到 36 包以上发射功率档位、广播间隔进入区域回调延迟中位数 ≤ 5 秒广播间隔、iOS 的 notifyEntryStateOnDisplay连接后连续收发 10 分钟零断连连接参数是否满足超时不等式有一回在一个金属货架密集的仓库10 米处有效包率只有 30%我把广播间隔从 100ms 调到 250ms 反而更好——因为低延迟模式下三路广播信道挤得太满互相干扰。这件事之后我每次换现场都强制把这五条走一遍不再相信任何“理论覆盖半径”。希望这套流程能帮你少走两趟现场。本文还有配套的精品资源点击获取