Blazor Server传感器值实时UI更新：两种方案的适用场景与性能对比

业务场景 #

Blazor Server应用需读取传感器值并在UI上展示，当传感器值变化时，UI需同步更新。

现有方案适用场景 #

方案a：借助SignalR Hub更新UI #

适用于以下场景：

• 传感器数据来自独立后端服务或外部系统（如传感器采集服务与Blazor Server不在同一进程/机器）
• 需要支持多客户端同步更新（比如多个浏览器页面同时监控传感器数据）
• 传感器数据需跨进程、跨网络传递的场景

代码示例：

protected override async Task OnInitializedAsync()
{
    sensorServiceHub= new HubConnectionBuilder()
        .WithUrl(NavigationManager.ToAbsoluteUri("/sensorServiceHub"))
        .Build();
    sensorServiceHub.On("changed", () =>
    {
        StateHasChanged();
    });
    await sensorServiceHub.StartAsync();
}

方案b：Action委托触发UI更新 #

适用于以下场景：

• 传感器数据在Blazor Server进程内处理（比如传感器读取逻辑是项目内的本地服务）
• 仅需当前客户端实例更新UI，无需多客户端同步
• 追求低延迟的轻量级场景，无跨进程/网络开销

代码示例：

protected override async Task OnInitializedAsync()
{
    SensorService.OnValueChanged += () =>
    {
        InvokeAsync(this.StateHasChanged);
    };
}

其他解决方案 #

• INotifyPropertyChanged 绑定：让传感器服务的数值属性实现INotifyPropertyChanged接口，组件订阅PropertyChanged事件触发StateHasChanged，或直接使用Blazor的双向绑定（@bind）自动同步UI。这种方式更符合Blazor的组件绑定设计模式。
• 后台服务定时轮询：如果传感器数据更新频率不高（如几秒一次），可创建BackgroundService定时读取传感器值，通过注入的服务通知组件更新。实现简单，适合非毫秒级实时的场景。
• IAsyncEnumerable 流式传递：在传感器服务中返回IAsyncEnumerable<SensorValue>，组件内通过await foreach接收数据流，自动触发UI更新。这是Blazor原生支持的流式数据处理方式，适合连续产生的传感器数据。

性能差异 #

• 方案b性能更优：属于进程内直接调用，无网络序列化、传输开销，延迟极低，适合高频率更新（如每秒几十次）的场景。需注意用InvokeAsync确保在UI线程执行更新，避免线程安全问题。
• 方案a存在额外开销：SignalR需要处理WebSocket连接维护、消息序列化、网络传输，延迟高于进程内调用。仅当跨进程/跨机器的场景下才值得使用，单客户端进程内场景用SignalR会造成不必要的性能损耗。
• 两种方案都需注意：避免过于频繁调用StateHasChanged，可合并多次更新操作，减少UI渲染次数，提升整体性能。

内容的提问来源于stack exchange，提问作者Pfeffer