Android BLE 信号强度获取与 底层原理深度解析

引言

在上一篇文章中，我们讨论了蓝牙信号强度 RSSI 的负数含义，理解了它代表接收功率小于 1 毫瓦时的对数表达。然而，对于一个 Android 开发者来说，仅仅知道 RSSI 的意义远远不够------我们需要知道如何在代码中获取它，以及它背后的扫描和连接机制是如何工作的。

本文将站在 Android 蓝牙 BLE 专家的视角，以热门的开源框架 FastBle为引子，深入剖析 Android BLE 开发中信号强度获取的实现方式，并揭示从应用层到硬件层的完整技术栈原理。无论你是刚接触 BLE 的新手，还是希望深入了解底层机制的资深开发者，这篇文章都将为你提供有价值的参考。

一、FastBle 框架简介：让 BLE 开发"快"起来

FastBle 是由 Jasonchenlijian 开源的 Android BLE 快速开发框架，在 GitHub 上收获了 5.4k+ Star 和 1.2k+ Fork，至今已有近十年的社区积累。它使用简洁的方式封装了 BLE 开发中的核心操作：过滤（Filtering）、扫描（Scanning）、连接（Linking）、读写（Reading/Writing）、通知订阅（Notification）和取消、信号强度获取（readRssi）、最大传输单元设置（setMTU）以及多设备连接与重连。

在开始信号强度获取的底层剖析之前，我们需要先理解 BLE 的基础架构。

二、BLE 基础知识：从协议栈到角色模型

2.1 BLE 协议栈结构

BLE 协议栈按功能可以划分为三个层次：

1. 控制器（Controller） ：物理设备层，负责发射和接收无线电信号，并将信号翻译成数据包。控制器包含物理层（PHY）和链路层（LL）。

2. 主机（Host） ：软件栈，管理设备间的通信逻辑。包含 L2CAP（逻辑链路控制与适配协议）、ATT（属性协议） 、GATT（通用属性配置文件） 、SMP（安全管理协议）和 GAP（通用访问配置文件） 。

3. 应用层（Application） ：使用协议栈实现具体的用户功能，定义服务（Service）、特征（Characteristic）和描述符（Descriptor）。

2.2 角色与职责

在 BLE 的世界里，设备的角色分为两个维度：

• 连接维度的主从角色：中心设备（Central/Master）负责扫描并发起连接；外围设备（Peripheral/Slave）负责广播并等待连接。

• 数据维度的 GATT 角色：GATT 客户端（Client）从 GATT 服务器（Server）读写数据。通常中心设备充当 GATT 客户端。

2.3 核心协议：GAP 与 GATT

• GAP（通用访问配置文件） ：负责设备发现、连接建立和安全控制，控制链路层的五种状态------Advertising（广播）、Scanning（扫描）、Initiatng（启动连接）、Connected（已连接）等。

• GATT（通用属性配置文件） ：构建在 ATT 之上，定义了如何通过服务和特征在 BLE 链路上发送和接收短数据片段（称为"属性"）。所有当前的 BLE 应用配置文件都基于 GATT。在 FastBle 中，当连接成功时回调 onConnectSuccess，即表示 GATT 连接已建立，系统已发现设备上可用的服务和特征。

理解协议栈结构后，我们再来看信号强度究竟从何而来。

三、BLE 信号强度 RSSI 的获取方式

3.1 什么是 RSSI？

RSSI（Received Signal Strength Indicator）是接收信号强度指示，单位为 dBm。如前文所述，由于接收功率通常小于 1 mW，RSSI 值表现为负数。数值越大（越接近 0）表示信号越强。

3.2 方式一：扫描阶段获取 RSSI（无需连接）

这是获取 RSSI 最常用、成本最低的方式。当中心设备扫描周围 BLE 外围设备时，外围设备会在广播信道（Advertising Channels） 上发送广播数据包。中心设备的蓝牙控制器接收数据包时会一并测量信号功率，计算后以 RSSI 值的形式上报。

在 Android 原生 API 中，通过 BluetoothLeScanner 的 startScan() 启动扫描，并实现 ScanCallback。onScanResult() 回调中的 ScanResult 对象直接包含 RSSI 值。具体代码范式如下：

BluetoothLeScanner scanner = BluetoothAdapter.getDefaultAdapter().getBluetoothLeScanner();

scanner.startScan(new ScanCallback() {

    @Override

    public void onScanResult(int callbackType, ScanResult result) {

        int rssi = result.getRssi();

        BluetoothDevice device = result.getDevice();

    }

});

在 FastBle 框架中，扫描结果以 BleDevice 对象的形式返回，开发者可以直接调用 getRssi() 方法获取扫描到时刻的信号强度。FastBle 在底层封装了 BluetoothLeScanner 和 ScanCallback，对开发者屏蔽了原生 API 的复杂性，同时提供了工作线程回调 onLeScan() 和主线程回调 onScanning() 两种模式。

💡 补充提示：同一个 BLE 设备会在不同时间点被多次扫描到，每次的 RSSI 值可能不同，因为设备在移动、环境在变化，或者广播发送本身就有时序上的随机性。你需要根据业务需求决定取平均值、最近值还是最小值来做处理。

3.3 方式二：连接后主动读取 RSSI

在设备已建立 GATT 连接的情况下，可以通过 BluetoothGatt 的 readRemoteRssi() 方法主动请求读取当前连接的 RSSI 值。这是一个异步操作，结果通过 BluetoothGattCallback 的 onReadRemoteRssi() 方法返回。

bluetoothGatt.readRemoteRssi();

  


@Override

public void onReadRemoteRssi(BluetoothGatt gatt, int rssi, int status) {

    if (status == BluetoothGatt.GATT_SUCCESS) {

        // 成功获取 RSSI

    }

}

FastBle 同样封装了此功能，以 readRssi(BleDevice, BleReadRssiCallback) 的形式暴露给上层。

两种方式的区别在于：扫描阶段获取的 RSSI 反映的是广播信号的强度 ，对应的是设备广播时的状态；连接后读取的 RSSI 反映的是已建立连接的链路上的信号强度，更能反映当前持续通信的质量。在实时性要求高的场景下，连接后周期性读取能提供更准确的信号监测，但需要考虑额外的功耗开销。

3.4 RSSI 的局限性

虽然 RSSI 值看起来很简单，但有几点需要特别注意：

• RSSI 受环境影响极大：人体遮挡、金属物体、Wi-Fi 干扰等都会导致 RSSI 剧烈波动。

• 不同型号的蓝牙芯片在相同距离下输出的 RSSI 可能不同，没有绝对的校准。

• 用于距离估算时，只能做趋势判断（远/近），很难做到精确测距。

如果项目确实需要做相对精确的距离估算，通常需要结合多个蓝牙接收端的 RSSI 做三角定位，或者配合 CSI（Channel State Information）等更高级的物理层信息来提升精度。

四、BLE 扫描机制的底层原理

4.1 从应用层到硬件层的完整链路

当应用调用 BluetoothLeScanner.startScan() 时，数据是如何一步步流转到蓝牙芯片的？以下是完整的链路：

1. 应用层（Framework API） ：App 调用 BluetoothLeScanner.startScan()，传入 ScanCallback。

2. Framework 服务 ：调用链进入 BluetoothManagerService，通过 Binder 跨进程通信调用系统服务 IBluetoothManager。

3. Bluetooth 进程（bluetooth.apk） ：系统蓝牙服务进程处理扫描请求，构建扫描参数（频率、窗口、模式等），封装成 HCI 命令。

4. HCI 层（Host-Controller Interface） ：通过 HCI 协议将扫描命令发送到蓝牙控制器芯片。

5. 控制器（固件层） ：蓝牙固件按照指定的扫描间隔和扫描窗口，在 37、38、39 三个广播信道上监听广播数据包。

6. 数据上报 ：控制器接收到广播包后，测量 RSSI，通过 HCI 事件原路返回给蓝牙进程，再由 ScanCallback 回传到应用层。

4.2 扫描参数的含义与平衡

ScanSettings 类允许开发者配置扫描行为，核心参数包括：

4.3 广播与扫描的时序关系

BLE 外围设备以一定广播间隔 （Advertising Interval，通常在 20ms ~ 10.24s 之间）在广播信道上发送广播包。中心设备以扫描间隔+扫描窗口 的方式进行周期性扫描。RSSI 值只在中心设备的扫描窗口与外围设备的广播时隙重叠时才能被捕获并上报。

因此，扫描阶段获取的 RSSI 并不是连续的值，而是一个个"采样点"。这也是为什么即使在蓝牙设备静止不动的情况下，观察到的 RSSI 仍然会呈现一定的波动。

五、BLE 连接机制的底层原理

5.1 连接的建立过程

当中心设备通过扫描发现外围设备后，要建立 GATT 连接，需要经过以下步骤：

1. 发起连接请求：中心设备基于扫描获得的广播数据包中的设备地址，发送 CONNECT_REQ 数据包。此后，中心设备从 Scanner 状态切换为 Initiator 状态。

2. 跳频建立 ：双方协议约定一套跳频序列和数据传输时机。BLE 使用自适应跳频技术（Adaptive Frequency Hopping）来躲避干扰。

3. 连接参数协商：交换连接参数，包括连接间隔（Connection Interval）、从机延迟（Slave Latency）和监控超时（Supervision Timeout）。

4. GATT 服务发现：GATT 连接建立后，GATT Client 主动向 GATT Server 发送服务发现请求。系统会依次发现设备上的所有 Service、Characteristic 和 Descriptor。这一步对于后续的数据读写至关重要。

5. 应用层交互：客户端根据发现的特征，进行读写或订阅通知操作。

5.2 连接与扫描的本质区别

5.3 FastBle 的连接管理

FastBle 在原生连接 API 之上做了很多增强，包括多设备连接、自动重连机制（可配置重连次数和间隔，如 setReConnectCount(1, 5000)）和连接状态监控。其 BleGattCallback 涵盖了连接的完整生命周期：onStartConnect()、onConnectSuccess()、onConnectFail() 和 onDisConnected()。一个常见问题是，主动断开后立即重连可能导致长时间连接不上，实践中通常建议在断开和重连之间留一定的时间缓冲。

六、FastBle 源码解析：层层封装背后的设计哲学

6.1 全局单例设计

FastBle 的核心入口 BleManager 采用全局单例模式。应用在启动时调用 BleManager.getInstance().init(Application) 完成框架初始化，所有 BLE 操作都通过这个单例进行。这种设计确保了在整个应用生命周期中蓝牙资源的统一管理。

6.2 线程调度优化

Android 原生 BLE API 的回调线程不可控（某些回调在 Binder 线程池中执行），开发者往往需要手动切换线程来更新 UI。FastBle 内部将耗时的扫描和连接操作放在工作线程中执行，并通过 Handler 将结果回调自动切换到主线程。onScanning() 回调回到主线程，适合直接更新 UI，而 onLeScan() 保持在子线程中，适合做密集的数据处理。

6.3 连接状态的精细化追踪

FastBle 将每个蓝牙设备封装为 BleDevice 对象，该对象持有设备名称、MAC 地址、广播数据（getScanRecord()）和 RSSI 等核心信息。无论后续的连接、断开、读写操作，都通过这个设备对象进行，极大简化了状态管理。

6.4 异常处理与容错

原生 Android BLE API 的异常处理比较薄弱，很多错误仅返回一个 status code，没有统一的异常对象。FastBle 将各类错误封装为 BleException 及其子类，使得错误定位和处理更加清晰。

6.5 权限封装

Android 6.0 及以上版本，BLE 扫描不仅需要蓝牙权限，还需要位置权限（ACCESS_COARSE_LOCATION 或 ACCESS_FINE_LOCATION），因为 BLE 信标广播数据可用于位置推断。FastBle 在其使用指南中明确指出了这一要求，帮助开发者避免权限遗漏导致的扫描无结果问题。此外，框架在内部封装了蓝牙状态检查和开关，使用前通过 isSupportBle() 和 isBlueEnable() 就能快速判断设备支持情况。

七、开发实践与常见问题

7.1 扫描不到设备怎么办？

• 检查是否已动态申请 ACCESS_FINE_LOCATION 或 ACCESS_COARSE_LOCATION 权限（Android 6.0+）

• 部分手机（华为、小米等）还需要在系统设置中手动开启"定位服务"，否则即使授予了权限，扫描也可能无法正常工作

• 确认 BLE 设备正在广播（通常设备需要有指示灯或日志表示广播状态）

• 注意区分经典蓝牙设备和 BLE 设备------虽然主流的 Android 4.3+ 设备都支持 BLE，但部分老设备可能不支持 BLE，需要做兼容判断

7.2 优化扫描策略

• 扫描到目标设备后立即停止扫描，避免持续消耗电量

• 为扫描设置合理的超时时间（通常 5-10 秒）

• 使用 ScanFilter 过滤不关心的设备，减少回调次数

• 尽量不要在循环中反复启动停止扫描，合理的做法是采用周期性扫描策略

7.3 连接稳定性建议

• 连接失败时使用 FastBle 的重连机制，但断开和重连之间保留至少几秒的间隔

• 合理设置连接参数，过短的连接间隔会增加功耗，过长的间隔会影响数据实时性

• 监听 onDisConnected 回调，自动处理意外断开情况

• 在 Android 12（API 31）及以上版本中，还需额外声明 BLUETOOTH_SCAN 和 BLUETOOTH_CONNECT 等运行时权限

八、总结

本文从信号强度的意义出发，深入剖析了 Android BLE 开发中的两大核心------扫描与连接，并以 FastBle 框架为例展示了如何优雅地封装这些复杂的底层机制。

回顾关键要点：

• 信号强度 RSSI 为负数的根本原因是接收功率小于 1 mW，用 dBm 对数单位表达时的自然结果

• RSSI 可通过扫描阶段的 ScanResult 获取（无需连接），也可通过连接后的 readRemoteRssi() 主动读取

• BLE 扫描是通过 HCI 协议驱动蓝牙控制器在 3 个广播信道上监听广播包实现的

• BLE 连接建立在 GATT 协议之上，中心设备充当 GATT Client，外围设备充当 GATT Server

• FastBle 通过全局单例、线程自动调度、状态精细追踪和异常封装大幅降低了 BLE 开发的门槛

无论你最终选择原生 API 还是 FastBle 这类封装框架，理解底层机制都能让你在遇到问题时更从容地定位和解决。BLE 的世界远不止本文介绍的这些，GATT 服务发现、特征读写、通知订阅、MTU 协商等内容同样是 BLE 开发中的重要课题，值得在实际项目中深入探索。