智能家居消息提醒系统设计与优化实践

1. 家庭数字中心的消息提醒系统设计

作为一名智能家居开发者，我花了三个月时间迭代了家庭数字中心的消息提醒模块。这个看似简单的功能，在实际落地时却遇到了各种意想不到的挑战。今天就来分享这套支持多协议、多终端、智能分发的消息提醒系统是如何设计的。

现代家庭中的消息来源越来越复杂：从门铃摄像头的移动侦测，到空调滤网更换提醒，再到快递柜取件通知，不同重要程度的消息需要差异化的处理策略。我们的系统需要解决三个核心问题：如何统一接入各类协议的消息？如何根据消息类型智能路由？以及如何在不同终端上实现最佳展示效果？

2. 消息接入层设计

2.1 协议转换网关

我们开发了一个支持插件化扩展的协议转换层，目前已经接入了以下协议类型：

• HTTP Webhook（支持钉钉、企业微信等平台回调）
• MQTT（用于IoT设备消息）
• SMTP（邮件协议转换）
• WebSocket（实时消息推送）

每个协议插件都实现了统一的MessageAdapter接口：

java复制public interface MessageAdapter {
    Message normalize(RawMessage raw); // 标准化原始消息
    boolean support(ProtocolType type); // 支持的协议类型
}

关键点：协议转换时要特别注意时区处理。我们发现很多IoT设备上报的时间戳不带时区信息，需要在转换层统一转换为UTC+8时区。

2.2 消息元数据规范

所有接入的消息都会被标准化为以下结构：

json复制{
  "msgId": "uuidv4",
  "source": "device|service|human",
  "priority": 0-5, 
  "timestamp": "ISO8601",
  "content": {
    "text": "空调滤网需要更换",
    "media": ["https://.../filter.jpg"] 
  },
  "actions": [
    {"text": "立即购买", "type": "url", "target": "taobao://..."}
  ]
}

优先级定义采用了动态调整算法：

• 安防类消息自动+2级
• 工作时间外的消息自动-1级
• 同一设备重复消息逐次降级

3. 消息路由引擎

3.1 路由规则配置

通过可视化界面可以配置如下的路由规则：

yaml复制- match: 
    source: "doorbell"
    contains: "移动侦测"
  actions:
    - notify: ["mobile", "tv"]
    - tts: "门口有人停留"
    - record: true
    
- match:
    priority: ">=4"
  actions:
    - notify: ["all"]
    - flash: true

我们特别设计了"假期模式"，当系统检测到家庭Wi-Fi连接设备少于2台时，会自动：

1. 将非紧急消息静默处理
2. 关键通知转为短信备用通道
3. 关闭夜间声音提醒

3.2 终端能力协商

不同终端通过心跳包上报其能力：

protobuf复制message DeviceCapability {
  bool support_rich_text = 1;
  bool support_voice = 2; 
  int32 max_display_len = 3;
  repeated string supported_actions = 4;
}

这让我们可以实现：

• 电视端显示大图+语音播报
• 手机端展示完整操作按钮
• 智能手表只显示摘要文字

4. 消息展示优化

4.1 移动端渐进式加载

针对移动网络优化的加载策略：

1. 先传输纯文本（<1KB）
2. 按需加载缩略图（20KB）
3. 用户点击后再加载原图

我们使用WebP格式将图片体积减少了65%，并通过CDN边缘节点缓存高频消息模板。

4.2 多终端状态同步

采用Operational Transformation算法解决典型场景：

• 手机端已读的消息自动在平板电脑上标记已读
• 电视上播放的提醒在手机端显示"正在播报"状态
• 跨设备操作历史实时同步

5. 实战中的经验教训

1. 消息去重陷阱：
   最初使用content文本MD5作为去重依据，结果发现：

• 同一内容的告警因时间戳不同被视为新消息
• 不同语言的相似消息反而被去重
  改进方案：采用"设备ID+事件类型"作为去重键

2. 离线队列处理：
   当家庭网络中断时，采用分级存储策略：

• 优先级>=3的消息写入SQLite
• 普通消息暂存内存队列
• 超过100条时启动LRU淘汰

3. 语音合成优化：
   直接调用TTS服务会导致：

• 不同设备语音播报不同步
• 网络延迟造成卡顿
  解决方案：预生成语音包并P2P分发

6. 性能数据对比

优化前后的关键指标对比：

这套系统目前稳定运行了8个月，日均处理消息23万条，峰值时期达到1500QPS。最让我自豪的是成功将安防消息的端到端延迟控制在300ms内，这得益于我们在协议转换层做的零拷贝优化。