地下车库、偏远校园是自动售货机的常见部署点，网络极不稳定。本文对比了HTTP轮询与MQTT长连接在IoT场景下的优劣，并分享了如何通过自定义二进制协议、精简报文Payload，将单台设备的月度流量费降低60%的实战经验。
正文：
1. 痛点：高昂的流量费与不可靠的连接
画册显示智购的设备分布极广，其中很多在地下室。早期我们的设备用的是HTTP短连接轮询，每隔30秒向云端请求一次"是否有指令"。这导致了两个致命问题：
第一，流量费极高。每次HTTP请求都要携带大量的Header头信息，即使没有指令，也要白白消耗流量。
第二，实时性极差。用户付款后，指令可能要在云端等30秒才能被设备拉取到，体验极差。
2. 为什么选择MQTT？
我们全面切换到了MQTT协议。MQTT采用发布/订阅模型，设备与云端保持长连接，有指令瞬间下发，真正做到毫秒级响应。同时，MQTT的报文头部极短，只有2个字节，极其省流量。
3. 深度优化：自定义Payload格式
虽然MQTT协议省流量，但JSON格式的Payload却非常臃肿。例如上报一个设备心跳：{"deviceId": "ZG-ZL-N60-xxx", "status": "online", "temp": 4, "rssi": -75}，这一条JSON有近80个字节。
我们做了一步硬核优化：采用Protocol Buffers（Protobuf）替代JSON。通过定义字段标签，同样的心跳数据，经过Protobuf序列化后，仅仅占用不到20个字节。省下来的都是真金白银的4G流量费。
4. 心跳保活策略的调优
如果所有设备都固定发心跳，对云端网关压力很大。我们将心跳分为"活跃"和"休眠"两种状态。白天高频交易时段，心跳间隔设为30秒；凌晨低峰期，心跳间隔自动拉长到5分钟。通过这种动态心跳策略，极大地缓解了云端的并发压力。
5. 总结
在IoT领域，通信协议的选型和报文优化，直接关系到运营商的成本和用户体验。采用MQTT+Protobuf组合，配合动态心跳，是弱网环境下最优解之一。