华为手环心率实时传输到UWP应用：手机中转+局域网推送方案-开发者社区

前阵子接手一个项目，要在UWP应用里实时显示华为手环的心率数据。网上搜了一圈，中文资料要么停在“用手机App看就行”的层面，要么就是问了一句“能不能连PC”然后就没了下文。真正动手做才发现，华为手环不像专业心率带那样公开标准蓝牙协议，直接连PC这条路基本走不通。折腾了几天，最后我用了一套“手机采集+局域网推送+UWP接收”的架构把整条链路打通了。这篇文章就把整个方案从架构设计、代码实现到遇到的坑都梳理一遍，给你一套能照着复现的参考实现。

如果你最近也在做类似的项目，或者正打算把手环的实时心率数据接到Windows桌面端，那这篇文章很适合你。我会先说清楚数据到底该怎么拿，再讲Android端怎么采集和推送，最后说UWP端怎么接收和展示，中间穿插我实测中遇到的问题和解决办法。

1. 先聊清楚：华为手环的“实时心率”到底怎么拿

1.1 手环数据的三条获取路径

要拿到华为手环的心率数据，从技术上看主要有三条路。

第一条是走华为官方的Health Kit接口。华为运动健康App把用户授权过的心率、睡眠、运动等数据传到华为云端，第三方应用通过Health Kit获取。这条路最稳，官方维护，不需要逆向任何协议，但需要申请开发者权限，而且数据要经过手机App中转。

第二条是直接用蓝牙BLE连接手环，读取GATT服务里的心率特征。这条路上很多做智能硬件的人第一反应就是它，但对华为手环来说坑很深。华为手环对外基本不暴露标准心率服务，数据走的是私有协议，官方也没有公开文档。即使通过抓包或者社区逆向拿到了一部分协议，手环固件一升级可能就废了。

第三条是走系统级共享通道。部分华为手机和手环之间有私有数据通道，华为运动健康App会将一些数据写入系统传感器，其他应用通过系统API读取。这个方案限制很大，只适用于部分华为设备，对PC端UWP项目来说完全不现实。

1.2 为什么直接拿BLE连PC最容易被卡住

我一开始也抱着侥幸心理，想着“蓝牙心率服务都是标准化的，0x180D这个服务ID总该有吧”。实测结果很打脸：华为手环在PC上能被扫描到，但广播包里根本没有标准Heart Rate Service。强行用BluetoothLEDevice.FromIdAsync去连接，也拿不到0x180D的服务句柄。

就算有些型号能连接上，手环也不会默认向外持续发送心率数据。手环的心率上报机制是“按需触发”的，只有在华为运动健康App建立连接并且开启运动模式之后，才会以较高频率持续上报。PC上的UWP应用没有华为的私有配对认证流程，很难触发这个状态。

另外，Windows的BLE API本身就面向标准GATT协议设计，对私有服务和加密特征的支持很有限。所以直接BLE连PC这个方案，从稳定性和工作量角度来看都不划算。

1.3 我的推荐架构：手机做中转，UWP做接收端

既然直接连PC走不通，那就换一条务实路线。最终我采用的是这样一条数据链路：

华为手环 → 华为运动健康App（蓝牙连接）→ 手机端Health Kit SDK读取 → 局域网Socket推送 → PC端UWP接收解析并展示

这个架构的好处有几个。数据源头是华为官方通道，心率数值的可信度有保障。不需要逆向蓝牙协议，只要把Health Kit的权限申请下来就能用。手机端负责采集和转发，PC端只做接收和业务展示，职责分离清晰，后续换设备或者加功能都比较方便。

唯一的代价就是手机必须常驻后台，而且手机和PC需要处在同一个局域网内。对于个人项目或者实验室Demo来说，这个代价完全能接受。

2. 数据源头：手机端用华为Health Kit采集心率

2.1 申请Health Kit权限与工程配置

华为Health Kit不是开通就能用的，需要在华为开发者联盟逐步申请。第一步注册开发者账号并且创建应用，包名、签名证书的SHA256指纹必须和你最后打包用的证书一致。这一点很多人会忽略，先用debug签名申请，后面换成release证书又会遇到鉴权失败，还得重新走审核流程。

创建完应用之后，在AppGallery Connect后台开通Health Kit服务。注意心率属于敏感健康数据，申请权限时最好把使用场景写清楚，比如“用于PC端实时心率监控demo”，审核周期一般是1到3个工作日。我那次等了两天半，所以项目排期一定要把这个时间算进去。

工程配置方面，把后台下载的agconnect-services.json放到Android工程的app目录下，然后在根目录的build.gradle里配置华为Maven仓库，在app/build.gradle里添加Health Kit依赖。不同版本SDK的依赖坐标略有差异，大致是这样的写法：

dependencies { implementation 'com.huawei.hms:health:6.11.0.301' }

2.2 授权登录与心率读取流程

Health Kit的使用有个前置条件：用户必须先用华为账号登录，并且明确授权你的应用读取心率数据。这个授权流程在代码里分三步。

第一步，集成华为账号登录，也就是Account Kit。用户点击登录按钮之后，会跳转到华为账号授权页，同意后返回Authorization Code。第二步，用这个Code去换取Health Kit的访问权限，也就是申请scope，心率对应的scope类似https://www.huawei.com/health/kit/heartrate。第三步，检查用户是否已经在华为运动健康App里绑定了手环并且开启了数据同步。这一步经常被漏掉，如果运动健康App里没有设备，Health Kit拿到的永远是空数据。

授权通过之后，就可以创建HealthDataCollector来读取心率了。我当时的伪代码大致是这个样子：

class HeartRateService : Service() { override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int { val healthDataCollector = HealthDataCollector(this) healthDataCollector.setDataCollectorListener( object : DataCollectorListener { override fun onReceiveData( dataType: HiHealthDataType, samplePoints: List<SamplePoint> ) { val heartRate = samplePoints .firstOrNull() ?.getFieldValue(HiHealthFields.FIELD_HEART_RATE) heartRate?.let { sendToUwp(it) } } }, HiHealthDataType.CONTINUOUS_HEART_RATE ) return START_STICKY } }

这里要提醒一句，华为SDK的类名在不同版本里有过调整，DataCollectorListener可能在新的SDK里改成了别的回调接口。写代码的时候以官方文档为准，但整体思路不变：注册一个针对连续心率数据类型的监听，拿到SamplePoint之后提取心率字段。

2.3 把心率数据推到PC端UWP

手机端拿到心率之后，接下来的任务就是把数据送到PC。我在这个环节选择了TCP长连接，而不是HTTP轮询。原因是心率数据是持续产生的，TCP长连接一次握手之后就能一直传数据，延迟低很多，UWP端的StreamSocketListener实现起来也不复杂。

为了保证UWP端能正确切割数据帧，我约定了以换行符\n作为每条JSON数据的结束标志。Android端发送心率的代码简化之后是这样的：

fun sendHeartRate(heartRate: Int, timestamp: Long) { Thread { try { val socket = Socket("192.168.1.100", 9000) val json = "{\"heartRate\":$heartRate,\"timestamp\":$timestamp}\n" socket.getOutputStream().write(json.toByteArray(Charsets.UTF_8)) socket.close() } catch (e: Exception) { Log.e("HeartRateSender", "send failed", e) } }.start() }

在实际工程里需要处理几个细节。一是连接断开后的自动重连，我建议在手机端维护一个全局的Socket连接，断线后每秒重试一次。二是发送频率不要过高，心率数据每秒一次到两次就够用了，否则手机耗电和PC端UI刷新压力都会变大。三是建议用前台服务来跑这个发送逻辑，否则Android系统会在App退到后台几分钟后杀掉进程。

2.4 提高实时性的几个小技巧

Health Kit虽然能拿到数据，但实时性取决于手环的上报策略。我实测发现，手环在普通待机状态下心率上报频率很低，可能在几十秒到几分钟才更新一次。要让数据更实时，需要做几件事。

第一，让手环进入运动模式。华为手环在跑步、走路这类运动模式下，心率的采样频率会明显提高，基本能做到每秒甚至更密的上报。第二，把华为运动健康App在手机后台锁定，同时关闭系统省电策略对它的限制，否则App一被杀，数据链路就断了。第三，如果SDK支持配置读取周期，把周期设为尽可能短，比如1秒读取一次。

实测下来这样调整之后，UWP端收到的数据延迟基本在1到3秒以内。对于“实时心率展示”这个需求来说，这个延迟是完全可以接受的。

3. UWP端工程搭建：从收数据到图表展示

3.1 UWP项目的基础配置

UWP端我用的是标准空白应用模板，目标版本设置成Windows 10 1809以上就可以。创建完项目之后，有两件事必须第一时间做掉。

第一件事是修改Package.appxmanifest，声明网络和蓝牙能力。如果只走局域网Socket方案，声明privateNetworkClientServer就够了；如果后面还想尝试BLE直连，还需要加上bluetooth设备能力。声明之后看起来像这样：

<Capabilities> <Capability Name="privateNetworkClientServer" /> <DeviceCapability Name="bluetooth" /> </Capabilities>

第二件事是添加JSON解析库。微软官方的System.Text.Json在UWP上可以直接用，但我个人更喜欢用Newtonsoft.Json，API熟悉，UWP兼容性也稳定。

这里有个容易踩的坑：UWP默认的网络访问权限很严格，如果忘了声明privateNetworkClientServer，程序运行时会默默抛异常，不会弹明显的错误提示。所以遇到收不到数据的问题时，优先检查这个声明有没有写上。

3.2 用StreamSocketListener实现TCP接收端

UWP里搭建TCP接收端比较简单，核心就两个类：StreamSocketListener负责监听连接，DataReader负责读数据。启动监听的代码大致是这样：

private StreamSocketListener _listener; private async void StartServer() { _listener = new StreamSocketListener(); _listener.ConnectionReceived += OnConnectionReceived; await _listener.BindServiceNameAsync("9000"); }

连接建立之后，每次收到数据时触发OnConnectionReceived回调。这里需要注意，TCP是流式协议，Android端发送的多个JSON包可能粘在一起，也可能发生半包。所以我写了一个简单的按行读取方法，以\n作为分隔符切分完整帧：

private async Task<string> ReadLineAsync(StreamSocket socket) { var reader = new DataReader(socket.InputStream); reader.InputStreamOptions = InputStreamOptions.Partial; var builder = new StringBuilder(); while (true) { var size = await reader.LoadAsync(512); if (size == 0) break; for (uint i = 0; i < size; i++) { var ch = (char)reader.ReadByte(); if (ch == '\n') return builder.ToString(); builder.Append(ch); } } return null; }

这个方法的核心思路是用Partial模式每次先读一批字节，然后逐个字符找换行符，找到就返回一帧数据，没找到就把当前内容缓存到StringBuilder里继续读。实测下来对心率这种小数据量的场景完全够用。

3.3 JSON解析与界面实时刷新

收到完整的一帧JSON字符串后，就可以解析成对象了。我定义的数据结构很简单：

public class HeartRateData { public int HeartRate { get; set; } public long Timestamp { get; set; } }

解析代码用Newtonsoft.Json一行就能搞定：

var data = JsonConvert.DeserializeObject<HeartRateData>(line);

拿到数据之后剩下的事情就是更新界面。UWP中UI更新必须回到UI线程，我用的是DispatcherQueue来实现。核心逻辑是这样：

private async void OnHeartRateReceived(HeartRateData data) { await DispatcherQueue.EnqueueAsync(() => { CurrentHeartRateText.Text = data.HeartRate.ToString(); LastUpdateTimeText.Text = DateTimeOffset.FromUnixTimeMilliseconds(data.Timestamp).ToString("HH:mm:ss"); }); }

如果需要画实时曲线，推荐用LiveCharts.Uwp，把最近N秒的数据点放到ObservableCollection里，曲线会自动刷新。我自己项目里还接了一个历史记录列表，每来一条数据就往ListView里塞一条，方便事后回看。

3.4 顺带跑通的BLE直连备用方案

虽然华为手环直接BLE连PC不现实，但这套UWP代码我后来也没白写，因为我把它用在了专业心率带上。如果你以后遇到支持标准心率服务的设备，可以参考下面这段扫描和读取的流程。

先用DeviceInformation.FindAllAsync扫描附近的BLE设备，找到之后用BluetoothLEDevice.FromIdAsync连接，再通过GetGattServiceAsync拿到心率服务，订阅心率特征的通知事件：

var device = await BluetoothLEDevice.FromIdAsync(deviceId); var service = await device.GetGattServiceAsync(GattServiceUuids.HeartRate); var characteristic = service.GetCharacteristics(GattCharacteristicUuids.HeartRateMeasurement)[0]; characteristic.ValueChanged += OnHeartRateChanged; await characteristic.WriteClientCharacteristicDescriptorAsync( GattClientCharacteristicConfigurationDescriptorValue.Notify);

OnHeartRateChanged事件里会收到字节数组，心率值就在其中。这个流程对标准BLE心率设备非常可靠，延迟几乎是毫秒级。所以如果你的项目对实时性要求极高，与其死磕华为手环，不如直接用专业心率带，UWP端代码几乎不用改，只是数据源换了一下。

4. 常见问题与排查技巧实录

4.1 Health Kit授权与数据为空

这个问题我遇到过好几次，而且表现很诡异：应用能正常启动，也没有报错，但onReceiveData就是不回调，或者回调里samplePoints始终是空的。

排查时我建议按这个顺序来。先确认华为运动健康App里已经绑定了手环，并且首页能看到当前心率。再做一遍Health Kit授权，确认授权页面里心率权限是勾选状态。最后核对AGC后台配置，包名、证书指纹、Health Kit服务状态是否全部一致。我那次就是证书指纹对不上，重新配置之后数据就正常了。

还有一个比较隐蔽的点：如果手环和手机连接的是不同华为账号，Health Kit里也读不到数据。手环绑定的账号必须和App登录的账号一致。

4.2 手机端网络推送失败

手机端Socket推不出去，优先检查三件事。第一，手机和PC是否在同一个局域网，有些办公网络会做AP隔离，设备之间互相ping不通。第二，PC防火墙是否放行了UWP应用的入站连接，Windows Defender防火墙默认会拦截UWP应用的入站请求，需要手动添加规则。第三，Android端Socket连接PC时，PC的IP地址要写对，而且建议先在PC上用其他工具验证一下9000端口确实在监听。

另外提醒一点，Android 9之后默认禁止明文HTTP和Socket连接，如果出现Cleartext communication not permitted的报错，需要给应用显式允许明文流量，或者使用加密方案。

4.3 UWP端收不到数据或粘包解析错误

UWP端收不到数据，我就干过一件蠢事：代码逻辑完全正确，但忘记在Package.appxmanifest里声明privateNetworkClientServer能力，折腾了一下午。所以这个问题必须排在第一位排查。

粘包问题在心率场景下不太明显，但如果发送频率调高，比如每秒多次，还是会出现两个JSON挤在一个TCP包里的情况。解决办法就是我3.2节里提到的按行读取和\n分隔符，这个方法实测能稳定解决粘包。

还有一个编码坑：Android端发送时如果用了getBytes()默认编码，中文注释还好，但JSON里的字段值如果包含特殊字符，PC端解析就可能乱码。最好两端统一用UTF-8。

4.4 实时性不达预期的处理思路

如果你按上面的方案跑通之后发现数据更新频率还是太低，大概率是手环没有处于运动模式。华为手环在普通待机状态下，心率上报频率会被大幅降低，Health Kit自然拿不到连续数据。解决办法是让用户在华为运动健康App里开启一个运动项目，比如健走或者跑步，心率上报频率马上就会上来。

如果这样还是不能满足实时性要求，那就说明华为手环本身的能力上限就到这了。消费级手环的心率传感器和算法，本来就是为健康管理设计的，不是为科研或者医疗场景准备的。真要做秒级甚至毫秒级的实时心率应用，建议换支持标准BLE心率服务的专业心率带，代码复用我3.4节的部分就行。

5. 最后分享几点经验

项目收尾之后我自己复盘了一下，有几个经验值得单独说。

第一个经验是先用假数据联调UWP端，再做Android端到PC端的真实链路。我一开始就直接上了真设备，结果Android端连不上PC、UWP端解析报错、PC防火墙拦截三个问题同时冒出来，排错排到怀疑人生。后来改成先用一个简单的Android模拟器或者命令行工具往9000端口发假数据，UWP端调通之后再去解决手机端的问题，效率高了很多。

第二个经验是华为Health Kit的权限审核周期比想象中长，而且审核通过之后SDK配置还有各种细节。建议项目一启动就先把开发者账号、应用创建、权限申请这些前置流程走起来，不要等到代码写完了再申请，不然只能在等待审核中干瞪眼。

第三个经验是架构的价值大于单个设备。这套手机采集加局域网转发的方案，数据源只要换成苹果的HealthKit、小米手环的开放平台或者专业BLE心率带，UWP端几乎不用动。所以如果你后续有接入其他穿戴设备的需求，这套架构完全可以复用，只需要新增一个适配器。

最后再提一句，华为手环的实时心率本质上是“消费级指标”，它更适合做趋势展示、运动记录这类场景。如果甲方的需求里写着“实时”而且精度要求很高，建议第一时间把预期拉回到合理范围，或者直接建议换硬件。技术方案能解决的问题很多，但硬件能力的天花板，还是要尽早说清楚。