iBeacon广播唤醒与GATT长连接工程实践

简介本资源面向iOS开发者聚焦iBeacon唤醒App与蓝牙长连接这一实际工程问题通过一个轻量的单例管理类示范如何在后台监听iBeacon信号并唤醒应用。压缩包内共2个文件为1个.h头文件与1个.m实现文件整体仅3KB属于可直接嵌入工程阅读与复用的最小示例代码。内容围绕RY_iBeaconManager展开涵盖iBeacon信号监听与数据解析、基于UUID及Major、Minor的地理围栏判定、始终定位权限的申请与使用要点以及蓝牙连接事件的维护与异常处理并对后台常驻带来的电量消耗给出优化思路便于读者理解单例初始化、避免重复注册等关键细节。已有581人学习适合希望补齐室内定位与近场推送能力的中级开发者参考。1. 手机被划掉还能弹提醒靠的就是它手机揣在兜里App 早被划掉了人刚走到门口锁屏上就弹出一条到店提醒——这套动作背后跑的就是 iBeacon。这份 iBeacon.zip 打包的是围绕「信标广播 → 唤醒 App → 蓝牙长连接」整条链路的一套可运行工程iOS 与 Android 两端都有对应实现另外带了广播参数配置和 GATT 连接管理的示例。它适合两类人一类是想给线下门店、展厅、设备巡检加一套近场触达能力的开发者另一类是被后台唤醒、蓝牙保活这些玄学问题折腾过、想找份能对照的代码看的人。定位很明确它不解决室内定位精度问题也不做云端信标管理就是把信标这一层的收发、唤醒、连接跑通业务逻辑自己往上搭。2. 工程结构拆解一份 iBeacon 项目里到底有什么拿到压缩包别急着点运行先把目录过一遍。信标类项目和普通 App 的差别在于它有两套生命周期完全不同的链路一套是系统级的广播监听App 没跑也要能被叫起来另一套是进程内的 GATT 连接必须 App 活着才能干活。目录的组织方式基本就是按这两条链路切的看懂了目录后面调代码就不会迷路。2.1 目录结构与各模块职责典型的工程会分成 iOS、Android、tools 三块。下面的结构是把压缩包解开后最常见的一种组织方式模块名可能略有出入职责划分基本一致iBeacon/ ├── ios/ │ ├── BeaconDemo.xcodeproj │ └── BeaconDemo/ │ ├── AppDelegate.swift # 冷启动入口唤醒后在这里接管事件 │ ├── Beacon/ │ │ ├── BeaconScanner.swift # 区域监控 测距回调的封装 │ │ ├── BeaconRegionStore.swift # UUID/major/minor 配置的本地读写 │ │ └── BeaconFrame.swift # 广播帧数据模型 │ ├── BLE/ │ │ ├── GattCentral.swift # CoreBluetooth 中心设备管连接/MTU/通知 │ │ └── ReconnectPolicy.swift # 退避重连策略 │ └── Info.plist # 后台模式、权限描述文案 ├── android/ │ ├── app/src/main/ │ │ ├── AndroidManifest.xml # 蓝牙/定位权限与前台服务声明 │ │ └── java/.../beacon/ │ │ ├── BeaconBootstrap.kt # 把扫描能力挂到进程生命周期上 │ │ ├── BeaconScanService.kt # 前台服务负责长期扫描 │ │ ├── BeaconFrameParser.kt # 厂商数据解析成 UUID/major/minor │ │ └── gatt/GattClient.kt # 连接、分包、通知订阅 └── tools/ └── beacon-simulator.md # 用一台手机模拟信标的操作步骤Beacon/和beacon/这两个目录承担的是「广播侧」的活收到广播包、解析三要素、判断进出区域。它们不建立任何连接功耗极低是唤醒能力的来源。BLE/和gatt/目录承担的是「连接侧」的活连上设备、读特征值、订阅通知。这两块千万别混在一起写我见过不少新手把连接逻辑塞进扫描回调里结果扫描频率一高就疯狂重连电量掉得肉眼可见。tools/beacon-simulator.md这份文档价值不小。手里没有真实信标硬件的时候用两台手机就能完成大部分联调一台装个能发广播的工具当假信标另一台跑工程收包。省掉等硬件快递的几天时间也方便复现特定 UUID 的场景。2.2 两端技术栈对照iOS 和 Android 在信标这块的能力差异很大同一个需求在两边的工作量可能差三倍。做选型评估时这张表比看代码更有用能力iOS 侧实现Android 侧实现广播监听CoreLocation 区域监控BluetoothLeScanner 第三方扫描库进程未运行时唤醒系统级 Region Monitoring 回调前台服务 / 广播接收器 / 定时任务测距startRangingBeacons 约每秒回调扫描回调里按 RSSI 自行估算长连接CoreBluetooth CentralBluetoothGatt后台限制后台模式 location、bluetooth-central8.0 起后台服务受限需前台服务权限申请定位「始终允许」 蓝牙12 起需 BLUETOOTH_SCAN / CONNECTiOS 的优势在于唤醒是系统兜底的代码写对了App 被划掉也能被叫起来代价是回调频率被系统牢牢攥着你想让它每秒报一次进入事件它不会听。Android 反过来扫描节奏你能自己定但保活得自己操心厂商定制系统的后台清理策略是每个做信标的人都得面对的坎。2.3 广播帧格式UUID、major、minor 到底长什么样iBeacon 的广播包塞在 BLE 的厂商自定义数据段里AD Type 为0xFF去掉长度和类型字节后固定 25 字节结构是死的偏移长度含义0–12厂商标识低字节在前2–32固定0x02 0x15标识 iBeacon 帧类型与后续长度4–1916UUID大端顺序20–212major无符号 16 位22–232minor无符号 16 位2411 米处标定功率有符号字节单位 dBm解析代码不长但索引位置极容易写错因为不同扫描库交到你手上的字节数组裁到了不同层级。有的是完整 AD 结构带长度和类型有的只给了厂商数据还有的把厂商 ID 也剥掉了。下面这段按「已剥离长度与类型字节、保留厂商 ID」的约定来解析// 把扫描回调里的厂商自定义数据解析成 iBeacon 三要素 data class BeaconFrame(val uuid: String, val major: Int, val minor: Int, val txPower: Int) fun parseIBeacon(raw: ByteArray?): BeaconFrame? { // 至少要容纳 2 字节厂商 ID 2 字节帧头 21 字节负载 if (raw null || raw.size 25) return null // 厂商 ID 是低字节在前拼的时候别弄反 val companyId (raw[0].toInt() and 0xFF) or ((raw[1].toInt() and 0xFF) shl 8) if (companyId ! 0x004C) return null // 0x02 0x15类型 2、长度 21对不上就不是标准 iBeacon 帧 if ((raw[2].toInt() and 0xFF) ! 0x02 || (raw[3].toInt() and 0xFF) ! 0x15) return null // UUID 16 字节按大端拼再切成 8-4-4-4-12 的标准写法 val hex buildString { for (i in 0 until 16) append(%02X.format(raw[4 i])) } val uuid ${hex.substring(0, 8)}-${hex.substring(8, 12)}- ${hex.substring(12, 16)}-${hex.substring(16, 20)}-${hex.substring(20)} // major / minor 同样是大端 16 位用 and 0xFF 防止符号位扩展 val major ((raw[20].toInt() and 0xFF) shl 8) or (raw[21].toInt() and 0xFF) val minor ((raw[22].toInt() and 0xFF) shl 8) or (raw[23].toInt() and 0xFF) // 第 25 字节是 1 米处 RSSI 标定值有符号直接取 toInt 即可 val txPower raw[24].toInt() return BeaconFrame(uuid, major, minor, txPower) }几个参数值得单独说。companyId的0x004C是 iBeacon 规范约定的厂商标识换成别的值说明这不是标准 iBeacon 帧可能是别的厂商私有格式直接丢弃最省事。txPower是有符号字节常见取值在 -59 到 -65 之间它不代表当前信号强度而是「设备放在离你 1 米远时应该收到多少 dBm」用来做距离标定。拿txPower和实时 RSSI 估距离业内通用公式是d 10^((txPower - rssi) / (10 * n))n是环境衰减因子空旷环境取 2.0有货架或墙体干扰取 2.5 到 3.0。这个值只能当粗略参考RSSI 本身抖动能到 ±8 dBm换算成距离误差可能翻倍。所以别拿它做「用户站在第几块地砖上」的判定做「在门内还是门外」这种粗粒度判断就够了。3. 唤醒链路从广播包到 App 被拉起的完整过程广播包收到了接下来要解决的问题是App 没在运行谁来收这个包这块两端的设计思路完全不同iOS 把这件事收进了系统Android 交给了开发者。代码写得对不对直接决定唤醒成功率是 95% 还是 5%。3.1 iOS 侧Region Monitoring 为什么能在进程被杀后拉起核心在于startMonitoring(for:)。它注册的不是一个扫描任务而是一个「地理围栏」——只不过这个围栏的边界不是经纬度而是信标的 UUID/major/minor 组合。系统在蓝牙控制器层面持续做匹配匹配成功后拉起你的进程调 delegate整个过程中你的代码可能一行都没跑。// 用 UUID major minor 定义区域三者可以只填 UUID 做范围更宽的匹配 let uuid UUID(uuidString: E2C56DB5-DFFB-48D2-B060-D0F5A71096E0)! let constraint CLBeaconIdentityConstraint(uuid: uuid, major: 100, minor: 1) let region CLBeaconRegion(beaconIdentityConstraint: constraint, identifier: store-entry) // 进出事件都要否则只会回调进入 region.notifyOnEntry true region.notifyOnExit true // 屏幕点亮时补一次状态判定解决「人一直在区域内但首次回调丢了」的情况 region.notifyEntryStateOnDisplay true locationManager.delegate self locationManager.requestAlwaysAuthorization() locationManager.startMonitoring(for: region) // 测距是另一套频率只有进程活着时才生效用于判断远近 locationManager.startRangingBeacons(satisfying: constraint)startMonitoring和startRangingBeacons的区别必须搞清楚这是新手最容易混淆的一对 API。前者是低频的区域进出通知进程被杀也能触发但不给你具体列表后者是每秒一次的高频回调能拿到每个信标的 RSSI 和估算距离但只在 App 处于前台或后台运行状态时有效。notifyEntryStateOnDisplay这个开关建议打开。实际场景里经常出现「用户已经在区域内待了十分钟锁屏再点亮才收到回调」的情况原因是系统为了省电会合并事件。打开之后屏幕点亮会强制做一次状态判定把漏掉的进入事件补回来。代价是回调次数变多业务侧要自己做幂等同一个区域短时间内重复触发只处理第一次。权限这一关绕不过去。requestAlwaysAuthorization()弹的是「始终允许」用户选了「使用 App 期间」的话后台唤醒直接失效。实践中的做法是首次进入 App 用WhenInUse完成基本功能等用户真正触发一次信标相关操作后再引导升级到Always转化率比一上来就要权限高得多。Info.plist 里对应的描述文案别写「需要定位权限」要写清楚具体用途否则审核和被用户拒绝的概率都不低。3.2 Android 侧后台扫描的三条路和各自的代价Android 没有系统级围栏这回事必须自己维持一个扫描循环。8.0 之后后台服务被收紧能走通的路基本只剩三条选哪条取决于你对唤醒延迟的容忍度。第一条是前台服务。启动一个带常驻通知的 Service在里面跑BluetoothLeScanner的持续扫描。稳定性最好延迟在秒级代价是通知栏一直挂着一个图标用户可能觉得烦部分定制系统还会在你手动划掉通知后把服务一并清掉。适合巡检、工业设备这类 B 端场景。第二条是广播接收器加定时任务。用AlarmManager或WorkManager每隔几分钟唤醒一次扫 10 秒再睡。功耗可控但唤醒延迟取决于间隔做「到店提醒」这种场景体验会很差。适合对实时性要求不高的数据采集。第三条是交给第三方扫描库托管生命周期。多数库提供了 Bootstrap 类的封装原理是把扫描能力注册到进程生命周期的监听上进程被系统重启后自动恢复扫描。用起来最省心// Bootstrap 把扫描能力挂到进程生命周期App 被系统回收重启后也能恢复监听 class BeaconBootstrap(private val ctx: Context) : RegionBootstrap.Listener { override fun onEnteredRegion(region: Region, beacons: MutableListBeacon) { // 回调线程不能做重活先落一条本地事件再交给前台服务去处理 val nearest beacons.minByOrNull { it.distance } BeaconEventBus.post(EnterEvent(region.uniqueId, nearest?.rssi ?: -127)) BeaconsSyncService.enqueue(ctx) } override fun onExitedRegion(region: Region) { BeaconEventBus.post(ExitEvent(region.uniqueId)) } }onEnteredRegion里绝对不要做网络请求或者数据库大批量写入。这个回调可能发生在进程刚被拉起的瞬间Application 都还没初始化完重活容易触发 ANR。正确姿势是往事件总线或本地队列里塞一条记录然后交给前台服务或者 WorkManager 异步消化。权限这块 Android 12 起是个大坑。BLUETOOTH_SCAN和BLUETOOTH_CONNECT是运行时权限不申请就扫描静默失败——不是崩溃是没有任何回调日志一片干净排查起来相当费劲。BLUETOOTH_SCAN上还有个android:usesPermissionFlagsneverForLocation属性加上之后不需要定位权限但系统可能会过滤掉一部分扫描结果。如果拿不到 beacon先把这个属性去掉试试。3.3 冷启动接力把唤醒事件安全带进业务层唤醒成功只是第一步进程被拉起之后还有一段脆弱期。iOS 侧系统给你的后台执行时间通常只有几十秒Android 侧进程刚起来时各种组件还没就绪。这段时间里你要做的是「记下来」而不是「马上处理」。我一般会在两端的入口处各放一个极简的事件落盘逻辑iOS 在didEnterRegion里把region.identifier和时间戳写进 UserDefaults 或轻量数据库Android 在onEnteredRegion里写进 Room 或 SharedPreferences。等主界面真正启动时再读出来做业务判断——该弹提醒弹提醒该拉接口拉接口。这样做的另一个好处是幂等好做。系统回调不保证只来一次同一个人在同一区域待着可能因为信号抖动触发好几次进入事件。有了落盘的时间戳业务层判断「距上次处理不超过 5 分钟就跳过」重复推送的问题直接消失。没有这层用户手机一响就是三条一模一样的到店提醒这种翻车现场我见过不止一次。4. 蓝牙长连接连上 Beacon 之后怎么稳定传数据很多人第一次接触 iBeacon 会以为它是个可以连的设备其实标准 iBeacon 只广播、不连接。但实际项目里信标常常要兼做数据通道——带温湿度传感器的信标要读数据、带 LED 的展位牌要下发颜色、带电池的设备要读电量。这时候就得走 GATT 连接和广播是两套完全独立的机制别混着用。4.1 GATT 连接流程与连接参数连接本身不复杂connectGatt一行就能发起麻烦的是参数和时序。Android 侧的requestConnectionPriority有三档HIGH对应 11.25ms 间隔吞吐高但耗电BALANCED是 30–50ms日常够用LOW_POWER能到 100ms 以上适合只偶尔读一次电量的场景。连接间隔不是你想设多少就多少最终取值由外设和手机双方协商外设的固件里写死了范围的话你请求HIGH也可能只拿到 40ms。真要优化功耗得连上之后在onConnectionUpdated回调里把实际生效的间隔打出来看光看自己请求的值没意义。另外两个参数值得留意从机延迟slave latency允许外设在若干个连接事件里不响应省电但会增加响应延迟超时时间supervision timeout决定多久没收到包就判定断线低于连接间隔的 6 倍容易误判断线。这几个值通常在外设固件里配置App 侧改不了但排查连接莫名其妙断开的问题时必须知道去哪看。4.2 MTU 协商与分包为什么你的数据总是被截断BLE 默认 MTU 是 23 字节扣掉 3 字节的 ATT 头一次最多传 20 字节。超过这个长度的写入会被截断或者直接失败而且失败得悄无声息日志里只有一行GATT_INVALID_ATTRIBUTE_LENGTH。Android 可以主动协商更大的 MTU上限 517实际生效值由外设决定// 连接成功后第一步先谈 MTU谈完再发现服务顺序反了容易读到旧缓存 override fun onConnectionStateChange(gatt: BluetoothGatt, status: Int, newState: Int) { if (newState BluetoothProfile.STATE_CONNECTED) { gatt.requestMtu(247) // 请求 247留 3 字节头单包可传 244 } } override fun onMtuChanged(gatt: BluetoothGatt, mtu: Int, status: Int) { if (status ! BluetoothGatt.GATT_SUCCESS) { // 协商失败就退回默认 23后续按 20 字节切片 negotiatedMtu 23 } else { negotiatedMtu mtu } gatt.discoverServices() }参数说明一下247是常见的目标值能被多数芯片接受negotiatedMtu一定要存下来给写数据的模块用别到处硬编码 20。真正的写数据逻辑长这样// 大包按 (MTU - 3) 切片顺序写用串行队列保证包序否则外设收到的顺序会乱 fun writeLarge(ch: BluetoothGattCharacteristic, payload: ByteArray) { val chunkSize negotiatedMtu - 3 payload.toList().chunked(chunkSize).forEach { chunk - ch.value chunk.toByteArray() ch.writeType BluetoothGattCharacteristic.WRITE_TYPE_DEFAULT if (!gatt.writeCharacteristic(ch)) { // 上一包还没回调写失败交给队列下次重试 pendingQueue.offer(chunk.toByteArray()) return } awaitWriteCallback() // 阻塞到 onCharacteristicWrite 再发下一包 } }这里有两个必须注意的点。一是包序BLE 的写操作是异步的不等回调就连发三包外设收到的顺序可能是乱的拼出来的数据直接报废。二是写类型WRITE_TYPE_NO_RESPONSE吞吐高但丢了不会重传做固件升级这类场景必须用WRITE_TYPE_DEFAULT等确认。4.3 通知订阅与断线重连读取传感器数据走通知比轮询省电得多但订阅通知有两个步骤少一步就永远收不到数据override fun onServicesDiscovered(gatt: BluetoothGatt, status: Int) { val ch gatt.getService(DATA_SERVICE_UUID) ?.getCharacteristic(NOTIFY_CHAR_UUID) ?: return // 第一步本地打开通知开关让系统把收到的包派发给本进程 gatt.setCharacteristicNotification(ch, true) // 第二步往 CCCD0x2902写使能位告诉外设「可以开始发了」 ch.getDescriptor(CCCD_UUID)?.let { desc - desc.value BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE gatt.writeDescriptor(desc) } }setCharacteristicNotification只影响本机的派发不写 CCCD 外设压根不知道你要收数据。这两步都做了还没数据就去查 CCCD 的 UUID 是不是写成了0x2901那是用户描述符不是配置描述符这个笔误在开源代码里都出现过。断线重连千万别在onConnectionStateChange里立刻重新connectGatt。刚断开时外设那边的连接资源还没释放立刻连大概率返回 133。正确做法是关掉旧连接、延迟一段时间、用指数退避重试// 133 错误的经典处理先 close 释放句柄再按 1s/2s/4s 退避重连 private fun scheduleReconnect(attempt: Int) { val delayMs minOf(1000L shl attempt, 30_000L) // 上限 30 秒 handler.postDelayed({ gatt?.close() // 不 close 直接连必失败 gatt device.connectGatt(ctx, false, callback, BluetoothDevice.TRANSPORT_LE) }, delayMs) }退避上限建议压在 30 秒以内。信标设备通常就挂在墙上人走过去要连的时候等半分钟才有反应体验太差。另外 Android 上有个细节connectGatt的autoConnect参数设成true会让系统托管重连省电但首次连接极慢做即时数据交互的必须传false。5. 避坑与排查信标项目里最常见的五个坑5.1 区域死活匹配不上日志里一个回调都没有现象信标硬件确认在发广播扫描工具的列表里也能看到但 App 的 Region 回调一次都不触发。原因大概率是 UUID 字符串对不上。UUID 比对是严格按字符串做的大小写不同就认为是两个不同的区域而很多广播配置工具会把 UUID 自动转成大写显示代码里却写的小写。另一种情况是分隔符有的工具给的是带连字符的标准格式有的直接给 32 位裸串开发者原样粘进代码就废了。解决所有 UUID 进代码前统一uppercased()/toUpperCase()并用一个正则校验格式是否满足 8-4-4-4-12。我习惯在配置层加一个normalizeUuid()函数所有入口都过一遍这类问题就再没出现过。5.2 Android 12 以上扫描静默失效现象代码在旧机型上跑得好好的换到新系统上扫描回调一个都没有也没有任何异常抛出。原因BLUETOOTH_SCAN属于新引入的运行时权限清单里声明了不代表拿到了。更隐蔽的是部分系统会在未授予定位权限时直接返回空结果而不是报错。解决启动扫描前显式检查checkSelfPermission没授权就发起请求。同时在清单里确认usesPermissionFlagsneverForLocation是否真的需要——开了它免定位权限但可能过滤扫描结果关掉它则必须一并申请定位权限。两种配法都测一遍取能拿到数据的那种。5.3 iOS 后台唤醒频率低误以为代码没生效现象前台测试时进入区域立刻就弹提醒锁屏或者切到后台之后要等好几分钟甚至完全不触发怀疑是自己代码写错了。原因系统对区域监控做了严格的频率限制同一个区域短时间内重复进入只会回调一次不同区域之间也有冷却。另外 App 被用户手动强杀后唤醒能力会受影响这是平台行为不是 bug。解决先确认requestAlwaysAuthorization拿到的是「始终允许」再看 Info.plist 的UIBackgroundModes里有没有location。调试阶段建议打开系统的蓝牙日志或者用 Console 过滤能看到系统的调度痕迹。别指望后台唤醒做到秒级产品设计上就要把延迟预期写进去。5.4 通知订阅成功但收不到第一包数据现象setCharacteristicNotification返回 trueCCCD 也写成功了外设说在发数据但onCharacteristicChanged一次都没进。原因写 CCCD 和打开本地开关之间有个时序窗口外设在 CCCD 写成功的那一刻就开始发如果本地开关还没生效第一包会直接丢。有些外设发完这一包就进入低功耗不再主动发于是看起来像完全没通。解决把本地开关放在写 CCCD 之前顺序见 4.3 的代码写完之后主动读一次特征值把当前状态拉回来别等外设推。如果外设有「开始上报」的控制命令再加一步显式触发。5.5 连接后立刻发现服务服务列表是空的现象connectGatt回调显示已连接紧接着discoverServices()onServicesDiscovered回来时gatt.services长度是 0或者缺了自定义服务。原因Android 的 GATT 服务缓存机制。系统会按设备地址缓存服务列表如果上一次连接时外设固件更新过服务结构缓存没失效读到的就是旧的。另一个原因是 MTU 协商和服务发现并发执行底层状态机打架。解决连接成功后串行推进——先requestMtu等onMtuChanged回调再discoverServices。真遇到缓存问题调用隐藏方法BluetoothGatt.refresh()反射调用清缓存或者让用户关开一次系统蓝牙。这个坑没有后悔药只能靠流程约束规避。6. 二次开发把 Demo 改成能上线的信标业务系统Demo 能跑通之后第一件事是把硬编码的 UUID 干掉。实际项目里信标的编号是有层级含义的我一般按「UUID 定业务域、major 定门店、minor 定店内点位」来规划字段位数规划方式示例含义UUID128 位一个业务场景一个全局唯一到店场景 / 巡检场景分开major16 位按场地编号上限 65535第 12 号门店minor16 位按点位编号场地内唯一该门店的入口展台这样规划的好处是区域匹配可以分层收窄。做「用户到店」判断时只注册 UUID 级别的 Region覆盖所有门店代码里一个区域搞定需要精确到具体点位时再用 major/minor 加一层startRangingBeacons在回调里按 major 过滤。如果反过来把 major/minor 全写死在 Region 里一百家店就要注册一百个区域系统的区域数量是有上限的早晚撞墙。第二件事是把扫描参数抽成配置。广播间隔、发射功率、RSSI 过滤阈值这三个值在不同现场差别很大开阔展厅里 -70 dBm 就算远货架密集的仓库可能 -85 dBm 才靠谱。我一般会在 App 里留一个隐藏的调试页能实时看到附近所有信标的 RSSI 并按强度排序现场调试的时候拿着手机走一圈阈值当场就能定下来比远程猜快十倍。第三件事是验证。没有真机硬件时用一台手机装个能自定义 UUID/major/minor 和发射功率的广播工具另一台跑你的 App把「进入 → 唤醒 → 拉数据 → 断开」整条链路走一遍。重点测三个场景App 在前台、App 在后台、App 被划掉。三个都能过再上真机复测。我踩过最疼的一次是把txPower的标定值当成了固定常量 -59 写死在代码里结果换了一批发射功率不同的信标算出来的距离全部偏大用户明明站在展台前App 说他在 8 米外。从那以后我每次接入新硬件都强制先拿扫描工具在 1 米处实测一遍txPower把真实值写进设备配置表再让测距模块去读。这个动作多花五分钟能省掉后面好几轮「是不是代码有 bug」的排查。希望这些能帮到你少走点弯路。本文还有配套的精品资源点击获取