简介一套面向Android毕业设计与课程设计的完整心率监测系统方案覆盖安卓客户端、服务端与数据库三大模块。安卓端实现用户登录注册、通过手机摄像头实时测量心率、测试历史记录并将结果上传至网站服务器网站端支持管理员登录、查看受测者个人信息、心率测试结果及时间同时为每次测试自动生成健康报告辅助判断受测者心跳是否正常。资源共4个文件包含2个RAR源码工程包、1个SQL数据库脚本和1个说明文本压缩包整体约30.49MB其中RAR包分别对应安卓工程与服务端工程SQL脚本用于初始化数据表文本文件提供部署说明。当前已有112人学习下载适合作为毕业设计、课程设计或SSMAndroid项目入门参考。获取后可同时获得安卓端与服务端完整源码、演示视频、数据库脚本及部署说明便于快速搭建运行环境、理解项目结构并完成二次开发或论文撰写。1. 从传感器到应用的 Android 心率监测系统先想清楚这三件事任何一个挂着“基于 Android”字样的心率监测系统真正难的不是把 BPM 数字画在屏幕上而是把“采集—计算—展示—存储”这条链路做到闭环。我见过不少应届生在简历里写“实现了心率监测 App”实际只是调了系统 API 拿了个步数或者用手机摄像头对着手指拍一段视频就宣称测出了心率精度和采样率完全经不起推敲。这个标题的背后是一个典型的软硬结合项目硬件端是心率传感器最常见的是光电式 PPG 传感器比如 MAX30102Android 端负责通过串口或 BLE 读取原始数据、做信号处理、计算心率值、绘制实时波形最终落库并提供历史记录。它适合三类人正在做毕业设计的学生、准备跳槽到健康类 App 方向的 Android 工程师、以及想在现有 App 里接入心率能力的移动端团队。动手之前必须先把三个决定项目走向的问题定下来第一传感器走什么通信协议是 USB 串口还是 BLE 蓝牙第二心率算法放在哪一层是传感器模组自己算好直接发 BPM还是 Android 端拿到原始 PPG 信号自己做滤波和峰值检测第三Android 端的数据展示粒度是只显示一个数字还是需要实时波形图、历史趋势图以及 HRV 分析。这三个问题直接决定你要不要引入 BLE 开发栈、要不要处理 NDK 层面的信号处理代码、以及 UI 层要写多少图表逻辑。这篇文章就顺着“通信选型—数据采集—心率算法—Android 应用层实现—数据落库与图表展示”这条完整链路把每一步的实现路径、关键参数和常见坑位拆开讲清楚。对于 5 年以上的 Android 开发者文末的采样率对齐、滤波参数调优和 HRV 特征抽取部分也值得花两分钟过一遍。2. 硬件通信选型与 Android 端数据接入的两种主流方案心率监测系统的第一步不是写代码而是确定 Android 设备怎么和心率传感器通信。这个决定影响后续所有代码结构如果在通信层选错了方案后面写再多 UI 都是空中楼阁。2.1 方案对比BLE 蓝牙还是 USB 串口市面上心率传感器模组的输出接口主要分两类BLE蓝牙低功耗和 UART 串口。BLE 方案的代表是 Polar H10 胸带、各类手环心率模块Android 端通过 BluetoothGatt 回调拿数据优点是没有物理连接用户体验好缺点是 BLE 的 MTU 限制和数据分包机制要求你必须自己处理粘包、断包和字节序问题。USB 串口方案的代表是 MAX30102 搭配 CH340 转换芯片的开发板Android 端通过 UsbManager 和 UsbSerial 库读数据优点是数据流稳定、延迟低、非常适合调试阶段看原始波形缺点是需要 OTG 线而且 Android 的 USB 权限申请和热插拔处理比 BLE 繁琐得多。两种方案都有真实项目在用做医用级精度验证的实验室项目通常走 USB 串口因为采样率和数据传输可靠性是第一优先级做消费级健康 App 原型验证的则几乎全部走 BLE因为真实用户不会愿意插着一根 OTG 线测心率。如果你是毕业设计或个人项目我的建议是直接选 BLE——理由有三BLE 开发经验在简历上是硬通货Android 上 BLE 的调试工具链nRF Connect、BLE Debugger比较成熟而且后续加血氧、体温等其他健康传感器时 BLE 的可扩展性远好于 USB。// AndroidManifest.xml 中需要声明 BLE 相关权限Android 12 还需要 BLUETOOTH_SCAN 和 BLUETOOTH_CONNECT uses-permission android:nameandroid.permission.BLUETOOTH android:maxSdkVersion30 / uses-permission android:nameandroid.permission.BLUETOOTH_CONNECT / uses-permission android:nameandroid.permission.BLUETOOTH_SCAN /权限声明这部分Android 12 是个明确的分水岭。在 API 31 之前只需要BLUETOOTH和BLUETOOTH_ADMIN两个普通权限从 API 31 开始Google 把蓝牙权限拆成了BLUETOOTH_SCAN和BLUETOOTH_CONNECT而且这两个都是运行时权限需要在代码里动态申请。很多新手在 Android 12 以上的设备上调试 BLE第一步就卡在扫描不到设备上原因就是只声明了旧权限没有走动态授权流程。2.2 用 Android BLE API 建立传感器连接的完整代码骨架连接 BLE 心率传感器的常规路径是扫描设备 → 连接 GATT → 发现服务与特征 → 开启通知 → 解析数据。下面这套代码是行业里最常用的骨架直接改回调里的数据处理逻辑就能适配绝大多数心率传感器。private var gatt: BluetoothGatt? null private val bluetoothGattCallback object : BluetoothGattCallback() { override fun onConnectionStateChange(gatt: BluetoothGatt, status: Int, newState: Int) { if (newState BluetoothProfile.STATE_CONNECTED) { // 连接成功后开始发现服务注意这里必须在主线程调用 gatt.discoverServices() } else if (newState BluetoothProfile.STATE_DISCONNECTED) { // 常规处理更新 UI、释放资源、可选自动重连策略 } } override fun onServicesDiscovered(gatt: BluetoothGatt, status: Int) { if (status ! BluetoothGatt.GATT_SUCCESS) return val service gatt.getService(UUID.fromString(0000180d-0000-1000-8000-00805f9b34fb)) val heartRateChar service?.getCharacteristic(UUID.fromString(00002a37-0000-1000-8000-00805f9b34fb)) // 开启通知第二个参数 true 表示启用 CCCD 描述符 gatt.setCharacteristicNotification(heartRateChar, true) val descriptor heartRateChar?.getDescriptor(UUID.fromString(00002902-0000-1000-8000-00805f9b34fb)) descriptor?.value BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE gatt.writeDescriptor(descriptor) } override fun onCharacteristicChanged(gatt: BluetoothGatt, characteristic: BluetoothGattCharacteristic) { val flags characteristic.getValue() if (flags.isNullOrEmpty()) return // 数据解析逻辑见 2.3 节 val heartRate parseHeartRate(flags) runOnUiThread { /* 更新 UI */ } } } private fun parseHeartRate(data: ByteArray): Int { // BLE 心率规范第一个字节的 bit0 标识心率格式是 UINT8 还是 UINT16 val flag data[0].toInt() return if (flag and 0x01 0x01) { // UINT16 格式低字节在前 (data[1].toInt() and 0xFF) or (data[2].toInt() shl 8) } else { data[1].toInt() and 0xFF } }这段代码里有两个参数必须注意。第一个是0000180d这个服务 UUID这是 Bluetooth SIG 标准定义的 Heart Rate ServiceHRS绝大多数心率设备都实现这个服务其中00002a37是 Heart Rate Measurement 特征每一次设备心跳都会触发一次onCharacteristicChanged回调。第二个参数是通知开关的方式先调setCharacteristicNotification让 Android 系统知道该特征的 notify 要分发到回调再手动写 CCCD 描述符的值这一步很容易漏——漏了的话设备端不会推送数据特征是静默的。另外建议在onCharacteristicChanged回调里用System.currentTimeMillis()记录时间戳而不是依赖设备端自带的时间字段因为大部分低端模组不提供精确时间同步。2.3 数据分帧与采样时间戳对齐的必要性BLE 传输层的不确定性是心率监测系统实现里最容易被低估的坑。传感器设备可能以 25Hz、50Hz 或 100Hz 的频率推送数据但 BLE 的连接间隔connection interval一般在 7.5ms 到 4s 之间动态调整这就意味着 Android 端收到数据的实际间隔是不均匀的。如果你在 UI 上直接把 BPM 值渲染成折线图视觉上问题不大但如果要做 HRV心率变异性分析RR 间期的精度要求是毫秒级数据到达时间的抖动会直接污染计算结果。常规做法是不要信任 BLE 回调的时间戳而是在解析完数据后立刻用单调时钟SystemClock.elapsedRealtimeNanos()打点并对相邻两个采样点的时间差做一次合理性校验。比如设备标称 25Hz 采样率理论间隔是 40ms如果你检测到两个时间戳之间隔了 300ms说明发生了数据包丢失或设备端降频这时候要么丢弃这段数据要么做插值补偿。下表是常见采样率对应的理论间隔与容差范围设备标称采样率理论间隔合法时间戳间隔范围处理策略25 Hz40 ms30–60 ms超过 60ms 标记数据空洞50 Hz20 ms15–35 ms超过 35ms 尝试插值补点100 Hz10 ms5–20 ms超过 20ms 建议丢弃该窗口这套时间戳对齐逻辑是很多实际项目从“能出数”走向“数据可信”必须跨过的一步。如果设备支持在数据帧里携带时间信息少数高端医疗模组支持就以设备时间为准大多数情况下设备只推波形点时间对齐的责任落在 Android 端。你可以把这部分做成一个独立的SampleScheduler类输入是原始 PPG 数据输出是带有合法时间戳的采样点列表后续滤波和心率计算都基于这个列表进行。3. 心率算法从原始 PPG 信号到 BPM 值的三段式处理心率传感器输出的原始数据分为两类一类是设备端模组已经算好心率值直接通过特征值推给你另一类是只输出原始 PPG 波形数据通常是光电容积脉搏波的 ADC 原始值心率值需要 Android 端自己算。后者才是“设计与实现”这个标题真正要求的深度这里展开讲。3.1 为什么不能直接数波峰运动伪迹与基线漂移的干扰逻辑先建立一个直观认知PPG 信号本质上是通过光电容积描记法测量血管容积变化得到的波形心脏每次搏动会让毛细血管的血容量产生一个周期性的变化反映在 ADC 值上就是一个脉冲峰值。理论上数一个时间窗口内的波峰数量除以时间就是心率。但真实场景里信号远没有这么干净主要干扰有三个第一是基线漂移呼吸、身体轻微移动会导致传感器与皮肤接触压力变化让整个波形上下浮动浮动幅度甚至能超过真实的脉搏波峰值第二是运动伪迹走路、摆动手臂会让波形叠加一个低频大幅度的干扰信号这个信号在频谱上往往和心率频段有重叠单纯用阈值判断波峰会数出错误的结果第三是高频噪声环境光和传感器本身的电路噪声会叠加在信号上。这就是为什么任何心率算法都必须是三段式先去噪再定位特征点最后算频域或统计值直接数波峰的做法在真实设备上误差经常超过 20%。3.2 滤波参数选择哪些频段该保留哪些该滤掉在 Android 端处理 PPG 信号最常见也是最推荐的方案是先做带通滤波保留脉搏波信号的主要频段。静息状态下人体心率范围是 30 到 220 次/分钟换算成频率大约是 0.5Hz 到 3.67Hz剧烈运动后心率可以到 200 以上对应约 3.3Hz。所以带通滤波器的截止频率一般设置为下限 0.5Hz、上限 4Hz这个区间能把呼吸引起的低频漂移通常低于 0.4Hz和大部分高频噪声挡住。实现滤波有两种路径一是用 Java/Kotlin 在 CPU 上做滑动窗口均值或 FIR 滤波二是用 Android NDK 写 C 代码。对毕业设计和大多数工程场景FIR 带通滤波是精度和实现复杂度之间最好的平衡点。下面给出一个可直接运行的 Kotlin FIR 滤波器实现阶数和系数用标准窗函数法生成避免你直接去查 DSP 教科书里的推导过程。class FIRFilter(private val coefs: DoubleArray) { private val buffer ArrayDequeDouble() fun process(sample: Double): Double { buffer.addFirst(sample) if (buffer.size coefs.size) buffer.removeLast() // 有限冲激响应的叠加运算 var result 0.0 var idx 0 for (value in buffer) { result coefs[idx] * value } return result } } // 用窗函数法生成带通滤波器系数采样率 100Hz通带 0.5Hz–4Hz阶数 128 fun generateBandpassCoefficients( sampleRate: Int, lowFreq: Double, highFreq: Double, taps: Int ): DoubleArray { val coefs DoubleArray(taps) val fc1 lowFreq / sampleRate val fc2 highFreq / sampleRate for (n in 0 until taps) { val m n - (taps - 1) / 2.0 if (m 0.0) { coefs[n] 2 * (fc2 - fc1) } else { // 理想带通滤波器的冲激响应 coefs[n] 2 * fc2 * sinc(2 * fc2 * m) - 2 * fc1 * sinc(2 * fc1 * m) } // 汉明窗降低旁瓣泄漏 val window 0.54 - 0.46 * Math.cos(2 * Math.PI * n / (taps - 1)) coefs[n] * window } return coefs } private fun sinc(x: Double): Double { return if (x 0.0) 1.0 else Math.sin(Math.PI * x) / (Math.PI * x) }这段代码的滤波效果取决于三个参数采样率、通带边界、滤波器阶数它们必须和实际传感器配置匹配。采样率如果是 50Hz通带频率边界要同步等比缩放否则滤波器实际效果和预期相差很远。阶数 128 在 100Hz 采样率下大约对应 1.28 秒的窗口长度响应时间对实时显示稍微有点长一般每秒能看到一次更新如果你需要更快响应把阶数降到 64代价是过渡带变宽靠近边界频段的噪声滤不干净。在实际工程里我一般会把滤波这步放到后台线程里的采样缓冲队列里做避免 UI 线程被浮点运算拖累掉帧。3.3 用自适应阈值完成波峰检测与 RR 间期计算滤波之后的信号虽然干净了但幅度仍然会随时间缓慢变化——这是皮肤接触压力、传感器贴附位置的微小改动造成的是物理层面不可避免的现象。因此波峰检测不能用固定阈值行业内通行的做法是自适应阈值。核心逻辑是维护一个滑动窗口内的信号幅值估计阈值设定为窗口最大值的 60% 到 70%并结合一个最小间隔约束来防止把重搏波当成主波峰。data class PeakResult(val peakIndex: Int, val peakValue: Double) class AdaptivePeakDetector( private val sampleRate: Int, private val windowSeconds: Double 2.0 ) { private val windowSize (sampleRate * windowSeconds).toInt() private val minPeakDistance (sampleRate * 0.3).toInt() // 最短 300ms对应 200 BPM 上限 private var lastPeakIndex -minPeakDistance private var timestampIndex 0 fun detect(processedSignal: DoubleArray): ListPeakResult { val peaks mutableListOfPeakResult() var currentWindowMax 0.0 for (i in processedSignal.indices) { currentWindowMax maxOf(currentWindowMax, processedSignal[i]) if (i windowSize) { // 清理窗口外的数据保持最大值估计跟踪信号幅度变化 if (processedSignal[i - windowSize] currentWindowMax) { currentWindowMax processedSignal.sliceArray(i - windowSize 1..i).max() } } val threshold currentWindowMax * 0.6 val isLocalMax i 0 processedSignal[i] processedSignal[i - 1] i processedSignal.size - 1 processedSignal[i] processedSignal[i 1] // 必须同时满足超过阈值、是局部峰值、且距离上一个峰值足够远 if (isLocalMax processedSignal[i] threshold (i - lastPeakIndex) minPeakDistance) { peaks.add(PeakResult(i, processedSignal[i])) lastPeakIndex i } timestampIndex } return peaks } }这个检测器的行为由三个关键参数控制峰值阈值比例 0.6、最小峰值距离 300ms、窗口长度 2 秒。0.6 的含义是只接收幅度达到当前窗口最大值 60% 的波峰这样在信号明显变形的情况下不会数错300ms 最小距离保证不会把脉搏波主峰之后的重搏波误认为第二次心跳对应 200 BPM 的极限心率对绝大多数运动场景都够用2 秒窗口让幅度估计能跟上信号缓慢变化的节奏。算完波峰之后RR 间期就是相邻两个波峰对应的采样点时间戳之差单位毫秒它是后面计算瞬时心率和 HRV 指标的基础原料。瞬时 BPM 的公式是 60000 / RR 间期毫秒建议每次得到新 RR 间期时用滑动平均值做一下平滑比如最近 5 个 RR 间期的平均这样屏幕上数字不会跳来跳去。4. Android 应用层实现实时波形绘制、线程模型与数据持久化底层数据通道和算法链路打通之后Android 应用层要解决的是三个问题怎么把采样点实时画出来不卡顿线程模型怎么设计才不会丢数据或者 ANR历史数据存哪里、怎么读回来回放。4.1 用自定义 View 实现 60 FPS 的实时 PPG 波形图实时波形图是心率监测 App 的核心交互界面用户盯着它看第一感知就是“流不流畅”。Android 里画实时数据曲线有几种做法用SurfaceView配合子线程画布绘制、自定义View在onDraw里画、或者引入 MPAndroidChart 这类封装好的图表库。帧率和功耗的平衡点是选型关键我的常规选择是自定义 View不引入第三方图表库。原因有三数据刷新频率通常只有 25 到 100Hz完全在自定义 View 的渲染能力范围内自定义 View 可以完全控制绘制逻辑想加网格线、参考线、峰值标注都很方便不引入额外依赖意味着 APK 体积和初始化耗时都更可控。下面给出一段可直接使用的实时波形 View 核心代码重点在滑动窗口的数据管理方式与绘制策略的配合。class WaveformView JvmOverloads constructor( context: Context, attrs: AttributeSet? null ) : View(context, attrs) { private val paint Paint(Paint.ANTI_ALIAS_FLAG).apply { color Color.parseColor(#00E676) strokeWidth 4f style Paint.Style.STROKE } private val gridPaint Paint(Paint.ANTI_ALIAS_FLAG).apply { color Color.parseColor(#33FFFFFF) strokeWidth 1f } private val dataQueue ArrayDequeFloat() // 最多保存屏幕宽度对应的数据点数 private val maxPoints 500 fun addDataPoint(value: Float) { dataQueue.addLast(value) if (dataQueue.size maxPoints) dataQueue.removeFirst() postInvalidateOnAnimation() // 和 Choreographer 帧回调对齐避免无效重绘 } override fun onDraw(canvas: Canvas) { super.onDraw(canvas) // 绘制背景网格方便用户观察信号的幅度变化 val stepX width / 20f for (i in 0..20) canvas.drawLine(i * stepX, 0f, i * stepX, height.toFloat(), gridPaint) val stepY height / 10f for (i in 0..10) canvas.drawLine(0f, i * stepY, width.toFloat(), i * stepY, gridPaint) if (dataQueue.size 2) return var index 0 val path Path() val stepW width.toFloat() / maxPoints for (value in dataQueue) { // 中心线对齐信号范围假设为 -1 到 1UI 高度范围是 0 到 height val y height / 2f - value * height / 2.5f if (index 0) path.moveTo(0f, y) else path.lineTo(index * stepW, y) index } canvas.drawPath(path, paint) } }这段代码里有几个值得注意的细节。postInvalidateOnAnimation()是实时绘制的关键 API它会把重绘请求挂到下一帧的 vsync 信号上比直接调invalidate()更省电在高频数据刷新场景下能明显减少无用绘制。波形 y 坐标的映射逻辑很直接假设信号已经归一化到 -1 到 1 范围乘以 height/2.5 是为了让波形在垂直方向保留一点上下边距视觉效果更通透。maxPoints 500是按屏幕宽度 1080 像素、每个采样点 2 像素推算出的合理上限如果你的设备分辨率不一样需要按实际宽度做调整而不是硬编码。4.2 生产者-消费者线程模型避免 BLE 回调阻塞丢数据BLE 的onCharacteristicChanged回调运行在 Binder 线程池里不是主线程。如果在这类回调里直接做滤波、存库、刷新 UI一旦其中一个环节耗时超过几十毫秒后续数据包就会在系统层面堆积表现就是波形卡顿、心率值跳动、甚至蓝牙连接被系统判断为无响应而断开。正确做法是生产者-消费者模型BLE 回调只负责把原始数据扔进一个有界队列后台一个单独线程消费队列做滤波、波峰检测、心率计算最后通过 Handler 把结果发到主线程更新 UI。class HeartRateProcessor( private val onResult: (Int, Long) - Unit // 回调心率值和对应时间戳 ) { private val rawQueue ArrayBlockingQueueByteArray(1024) private val filter FIRFilter(generateBandpassCoefficients(100, 0.5, 4.0, 128)) private val peakDetector AdaptivePeakDetector(100) private val currentWindow mutableListOfDouble() private val windowSize 1000 // 10 秒数据窗口 private val processorThread thread(start true) { while (true) { val rawData rawQueue.take() // 阻塞直到有可用数据 val heartRate processOneSample(rawData) if (heartRate ! null) { onResult(heartRate, SystemClock.elapsedRealtime()) } } } fun enqueue(data: ByteArray) { rawQueue.offer(data) // offer 不阻塞 BLE 回调线程 } private fun processOneSample(data: ByteArray): Int? { // 解析原始 PPG 值这里假设数据帧格式为第一个字节是状态后四个字节是 ADC 值小端 val ppg ((data[2].toInt() and 0xFF) shl 8) or (data[1].toInt() and 0xFF) currentWindow.add(ppg.toDouble()) if (currentWindow.size windowSize) { currentWindow.removeAt(0) // 窗口满时丢弃最旧数据 } // 每积累一个 R 波间期长度就返回一次瞬时心率 // 实际项目中可以简化每次有新数据都做一次波峰检测返回最近一次 RR 间期对应的 BPM return null } }这里有几个工程细节值得展开。ArrayBlockingQueue的容量设为 1024按 100Hz 采样率算大约可以缓冲 10 秒数据这个余量可以应对短时间的 BLE 传输抖动offer而不是put入队保证 BLE 回调线程永远不会因为队列满而被阻塞宁可丢弃极少数数据也不让回调卡死。处理器线程用while(true)死循环加take()阻塞的方式这是 Java 并发里最标准的消费者写法比while加sleep的方式省电且延迟低。windowSize 1000表示 10 秒数据窗口用于波峰检测的上下文参考这个值不宜小于 5 秒否则幅度自适应跟不上信号变化。4.3 用 Room 落库保存心率历史与波形快照的 Schema 设计持久化方案选 Room 是惯例因为它和 LiveData/Flow 的配合、以及 SQLite 之上的类型安全封装让代码量少很多。心率历史数据表的设计有一个需要提前想清楚的点是只存 BPM 值还是连原始波形一起存。如果只存 BPM表结构会非常简单但后续想做离线趋势分析、R 波形态回顾就无从下手如果连波形一起存数据量会大很多需要分表或压缩策略。下述表结构是折中方案兼顾查询效率和回放能力。CREATE TABLE heart_rate_records ( id INTEGER PRIMARY KEY AUTOINCREMENT, start_time INTEGER NOT NULL, -- 记录开始时间epoch millis end_time INTEGER NOT NULL, -- 记录结束时间 avg_bpm INTEGER NOT NULL, -- 平均心率 min_bpm INTEGER NOT NULL, max_bpm INTEGER NOT NULL, duration_seconds INTEGER NOT NULL,-- 持续时间 rr_interval_values TEXT, -- JSON 数组保存 RR 间期序列用于 HRV 重算 sample_rate INTEGER NOT NULL -- 采样率用于回放时的时间轴重建 ); CREATE INDEX idx_heart_rate_start_time ON heart_rate_records(start_time);注意rr_interval_values字段的类型是 TEXT里面存 JSON 数组。把 RR 间期序列序列化进单字段是刻意为之如果你把每个 RR 间期拆成一行存表会膨胀得很快而且大多数查询比如按天看平均 BPM、按周看静息心率趋势根本不需要逐跳数据只有用户点进某个具体记录要重新计算 HRV 时才需要反序列化这一段 JSON。为了在代码里操作方便对应的 Room Entity 里用TypeConverter把ListLong映射成 JSON。class Converters { TypeConverter fun fromLongList(value: ListLong): String JSONArray(value).toString() TypeConverter fun toLongList(value: String): ListLong { val array JSONArray(value) return (0 until array.length()).map { array.getLong(it) } } }这条路径的最后一个自由点是心率的单位精度。BPM 如果存成INTEGER瞬时心率 71.6 会被截断成 71在 HRV 相关的分析里这个误差会被放大因为 HRV 的核心指标 SDNNRR 间期标准差依赖的是毫秒级精度。建议在计算层保留Double只在数据库里以INTEGER存四舍五入后的展示值而把精确的 RR 间期序列存进 JSON 字段这样展示和分析两不误。5. 实时波形与心率曲线联动的趋势页以及 HRV 指标抽取技巧图表展示层面要把“实时”和“历史”两种模式分开。实时模式已经在上文自定义 View 中覆盖历史趋势页更建议用 MPAndroidChart 这种成熟图表库来减少工作量——历史数据的点数量级通常在几千到几万之间MPAndroidChart 的LineChart组件提供了开箱即用的缩放、滑动、高亮十字线等功能自己实现这些交互细节的性价比太低。坐标轴的赋值方式要注意一点x 轴不要用数据库自增 ID要用真实时间戳epoch millis这样一天看到 24 小时的刻度才能准确对齐。// 历史心率趋势查询按小时聚合取窗口内平均值 SELECT (start_time / 3600000) * 3600000 AS hour_bucket, ROUND(AVG(avg_bpm), 0) AS avg_hour_bpm FROM heart_rate_records WHERE start_time BETWEEN ? AND ? GROUP BY hour_bucket ORDER BY hour_bucket ASC这段 SQL 把时间戳向下取整到小时桶再做聚合返回的结果可以直接喂给 MPAndroidChart 的LineDataSet。为什么取小时桶而不用原始记录因为一次 10 分钟的心率记录可能有 6000 个点24 小时下来 14 万数据点直接画在 LineChart 上GPU 和内存压力都太大而且视觉上密密麻麻根本看不出趋势聚合到小时级之后24 小时只有 24 个点趋势一目了然。HRV 指标抽取是这个方向最有进阶价值的部分。常规做法是从 RR 间期序列计算 SDNN 和 RMSSD前者的公式是所有 RR 间期的标准差反映整体变异性后者是相邻 RR 间期差值的均方根反映副交感神经活跃度。计算时遵从以下顺序从数据库读rr_interval_values字段反序列化成ListLong单位毫秒。剔除小于 300ms 或大于 2000ms 的异常值这些通常是检测误判或传感器脱落产生的伪差。相邻差值取绝对值平方求和取平均再开方即得到 RMSSD 值。SDNN 就是standardDeviation(list)库函数一行的事。这两个指标算出来之后能从侧面反映用户当前的压力状态和恢复水平很多健康 App 的心率变异性分析模块底层算法就是这两行统计逻辑。如果你想把 HRV 做实建议把 RR 间期数组长度控制在 5 分钟以上因为时域 HRV 指标的公认标准HRV Task Force 指南要求 5 分钟短时记录或 24 小时长时记录低于这个时长算出的 SDNN 在临床上没有参考意义但作为消费级 App 的参考指标是够用的。// 心跳检测开关放在 onPause 里关onResume 里开 // 避免 App 退到后台时 BLE 回调还在跑白白耗电还占着系统资源 override fun onPause() { super.onPause() processor.stop() // 停止消费者线程 gatt?.disconnect() // 断开 BLE } override fun onResume() { super.onResume() if (hasBluetoothPermission()) { connectSensor() // 重新连接并恢复数据流 } }上面这段生命周期处理是一个容易踩坑的实际问题点很多学生项目只写了 Activity 的onCreate里连接传感器完全不处理onPause/onResume用户一按 Home 键蓝牙连接还挂着处理器线程还在算等用户切回来就会发现电量掉了一大截甚至系统会弹出耗电警告。上述代码的 connect/disconnect 对称模式是行业惯例。本文还有配套的精品资源点击获取