开篇暴击：一个JSON格式，差点让千万级项目翻车

案例：某智能水表项目，采用NB-IoT通信，每天上报一次数据。早期原型使用JSON格式上报，单包大小约320字节。项目规模从1万台扩张到50万台时，运营商反馈基站信令信道被占满，原因是每个水表每天一次上报，加上心跳、重传等，每台设备每天产生约1.2KB流量。50万台设备每天就是600GB的空中数据，基站不堪重负。
解决方案：将数据格式从JSON改为CBOR，单包压缩到65字节，流量降低80%，项目得以继续。

JSON很好，但JSON不适合物联网窄带场景。

很多工程师习惯了用JSON传递数据，因为它人类可读、调试方便。但在物联网世界：

• NB-IoT/LoRa 的速率只有几十kbps，甚至几百bps，每一个字节都要抠

• 电池供电设备 每多传输1KB数据，可能缩短数天续航

• 4G Cat.1 虽然带宽够，但流量费是按MB计费的，千万级设备一年流量费可能差出几百万

今天，我将用实测数据 + 完整代码 + 选型决策树，带你彻底搞懂JSON、MessagePack、ProtoBuf、CBOR四种序列化格式，让你的物联网设备更省流量、更省电、更快。

---

一、四种序列化格式速览

格式	类型	可读性	体积	解析速度	典型场景
JSON	文本	★★★★★	大	慢	调试、Web API、大带宽场景
MessagePack	二进制	★★☆	中	较快	通用高性能场景
ProtoBuf	二进制	★☆☆	小	快	跨语言RPC、高吞吐系统
CBOR	二进制	★★★	很小	很快	物联网窄带、RFC标准

为什么物联网偏爱二进制格式？

• 体积小：去掉冗余的键名字符串，用索引或类型标记代替

• 解析快：无需复杂的字符解析，直接按字节处理

• 适合低功耗：发送/接收更少字节，射频工作时间更短

---

二、实测对比：同一组数据，四种格式的体量与速度

测试数据样本（典型的传感器上报）

{
  "device_id": "DEV-12345",
  "timestamp": 1717200000,
  "temperature": 23.5,
  "humidity": 67.8,
  "battery": 3.85,
  "gps": [121.4737, 31.2304]
}

实测结果（在STM32F407上，使用各自轻量库）

格式	序列化后字节数	压缩率（相对JSON）	序列化耗时（us）	反序列化耗时（us）
JSON（cJSON）	118字节	基准	520	680
MessagePack（mpack）	86字节	27%↓	410	530
ProtoBuf（Nanopb）	52字节	56%↓	280	340
CBOR（tinycbor）	64字节	46%↓	310	390

结论：

• 体积最小：ProtoBuf（52字节，比JSON减少56%）

• 综合最推荐物联网窄带：CBOR（64字节，且无需IDL定义，标准RFC）

• MessagePack 中规中矩，适合需要二进制但不想改变Schema的场景

---

三、ProtoBuf深度实战：定义IDL，生成C代码，集成到STM32

3.1 ProtoBuf 简介

Protocol Buffers 是Google开发的语言中立、平台中立的结构化数据序列化方案。需要先用.proto文件定义数据结构，然后用编译器生成目标语言的代码。

优点：体积极致小，解析极快，强类型，跨语言兼容好。
缺点：需要额外工具链，修改Schema需要重新生成代码，动态性差。

3.2 定义.proto文件（sensor.proto）

syntax = "proto3";

message SensorData {
    string device_id = 1;
    uint64 timestamp = 2;
    float temperature = 3;
    float humidity = 4;
    float battery = 5;
    repeated double gps = 6;  // 经纬度数组
}

3.3 生成C代码（使用Nanopb）

Nanopb是专门为嵌入式系统设计的ProtoBuf轻量级实现，代码量小，内存占用低。

# 安装nanopb
git clone https://github.com/nanopb/nanopb.git

# 生成 .pb.c 和 .pb.h
protoc --nanopb_out=. sensor.proto

生成后得到sensor.pb.c和sensor.pb.h，直接加入STM32工程。

3.4 在STM32上序列化与反序列化

#include "sensor.pb.h"
#include "pb_encode.h"
#include "pb_decode.h"

// 序列化：将结构体打包成字节流
bool encode_sensor_data(uint8_t *buffer, size_t *len) {
    SensorData msg = SensorData_init_zero;
    msg.device_id = "DEV-12345";
    msg.timestamp = 1717200000;
    msg.temperature = 23.5f;
    msg.humidity = 67.8f;
    msg.battery = 3.85f;
    msg.gps_count = 2;
    float gps_vals[2] = {121.4737f, 31.2304f};
    msg.gps = gps_vals;

    pb_ostream_t stream = pb_ostream_from_buffer(buffer, *len);
    if (!pb_encode(&stream, SensorData_fields, &msg)) {
        return false;
    }
    *len = stream.bytes_written;
    return true;
}

// 反序列化：从字节流还原结构体
bool decode_sensor_data(uint8_t *buffer, size_t len) {
    SensorData msg = SensorData_init_zero;
    pb_istream_t stream = pb_istream_from_buffer(buffer, len);
    if (!pb_decode(&stream, SensorData_fields, &msg)) {
        return false;
    }
    // 使用msg中的数据
    printf("Device: %s, Temp: %.1f\n", msg.device_id, msg.temperature);
    return true;
}

3.5 生产经验

• 内存分配：Nanopb默认使用栈分配，需确保栈足够大。复杂消息可用pb_reuse机制。

• 字符串处理：ProtoBuf中的string在C里是char*，需要确保指向的内存有效。

• oneof/union：支持，但会增加代码复杂度，谨慎使用。

---

四、CBOR深度实战：RFC 8949标准，无需IDL

4.1 CBOR 简介

CBOR（Concise Binary Object Representation）由IETF标准化为RFC 8949，设计目标是在JSON基础上提供二进制效率，同时保持自描述性（不需要Schema）。它是CoAP协议默认推荐的数据格式，在物联网领域地位很高。

优点：自描述，无需IDL，体积比JSON小很多，解析快，有标准RFC。
缺点：比ProtoBuf略大，动态语言支持不如JSON，但嵌入式库成熟。

4.2 在STM32上集成tinycbor

tinycbor是Intel开源的轻量级CBOR库，适合资源受限设备。

#include "cbor.h"
#include "cborjson.h"

// 序列化：构造一个CBOR map
size_t encode_cbor(uint8_t *buffer, size_t buf_len) {
    CborEncoder encoder;
    cbor_encoder_init(&encoder, buffer, buf_len, 0);
    
    CborEncoder map_encoder;
    cbor_encoder_create_map(&encoder, &map_encoder, CborIndefiniteLength);
    
    // 写入键值对
    cbor_encode_text_stringz(&map_encoder, "device_id");
    cbor_encode_text_stringz(&map_encoder, "DEV-12345");
    
    cbor_encode_text_stringz(&map_encoder, "temperature");
    cbor_encode_float(&map_encoder, 23.5);
    
    cbor_encode_text_stringz(&map_encoder, "humidity");
    cbor_encode_float(&map_encoder, 67.8);
    
    // 数组：GPS
    cbor_encode_text_stringz(&map_encoder, "gps");
    CborEncoder array_encoder;
    cbor_encoder_create_array(&map_encoder, &array_encoder, 2);
    cbor_encode_float(&array_encoder, 121.4737);
    cbor_encode_float(&array_encoder, 31.2304);
    cbor_encoder_close_container(&map_encoder, &array_encoder);
    
    cbor_encoder_close_container(&encoder, &map_encoder);
    return encoder.ptr - buffer;  // 实际长度
}

4.3 为什么物联网特别推荐CBOR？

1. 与CoAP天然集成：CoAP协议默认推荐CBOR，很多商用IoT平台直接支持CBOR解析。

2. 不需要预先定义Schema：设备固件可以灵活增删字段，云端只需按JSON路径解析即可。

3. 内存占用低：tinycbor的RAM使用约2KB，Flash约8KB，非常适合STM32。

4. 可无损转JSON：调试时可以将CBOR转为JSON打印，方便排查。

---

五、MessagePack：JSON的二进制替身

5.1 简介

MessagePack是一个高效的二进制序列化格式，它的设计思路是“像JSON一样使用，但更小更快”。不需要定义IDL，直接序列化动态数据结构。

优点：无需Schema，几乎所有语言都有成熟库，比JSON小20~30%，解析快。
缺点：体积优化不如ProtoBuf和CBOR，在窄带场景优势不明显。

5.2 何时选用MessagePack？

• 你已经在用JSON，想最小化代码改动就能获得性能提升

• 数据结构频繁变化，不想维护.proto文件

• 跨语言RPC场景，且对体积要求不是极致

5.3 示例（嵌入式可用mpack库）

#include "mpack.h"

size_t encode_msgpack(uint8_t *buffer, size_t len) {
    mpack_writer_t writer;
    mpack_writer_init(&writer, buffer, len);
    
    mpack_start_map(&writer, 5);  // 5个键值对
    mpack_write_cstr(&writer, "temperature");
    mpack_write_float(&writer, 23.5);
    mpack_write_cstr(&writer, "humidity");
    mpack_write_float(&writer, 67.8);
    mpack_finish_map(&writer);
    
    if (mpack_writer_destroy(&writer) != mpack_ok) {
        return 0;
    }
    return mpack_writer_buffer_used(&writer);
}

---

六、选型决策树：你的物联网设备到底该用哪种？

快速推荐表

场景	推荐格式	理由
调试原型、Web后台对接	JSON	可读性第一
NB-IoT/LoRa/卫星物联网	CBOR 或 ProtoBuf	极致压缩
4G Cat.1 且数据量不大	MessagePack	开发快，体积适中
跨语言高吞吐系统（如云端）	ProtoBuf	性能与兼容性
设备固件频繁OTA，数据结构多变	CBOR	无需重新生成代码
使用CoAP协议	CBOR	标准推荐

---

七、避坑指南：序列化在嵌入式中的常见错误

❌ 坑1：在中断服务函数（ISR）中做复杂的序列化

错误做法：串口接收中断里直接调用JSON解析库，导致中断时间过长，丢数据。
正确做法：ISR只接收原始数据放入环形缓冲区，主循环或任务中处理解析。

❌ 坑2：动态内存分配导致堆碎片

错误做法：使用malloc频繁分配序列化缓冲区，长时间运行后堆耗尽。
正确做法：静态分配大缓冲区，或使用内存池（如FreeRTOS的pvPortMalloc并开启碎片合并）。

❌ 坑3：忽略字节序（大端/小端）

错误做法：ProtoBuf和CBOR规定使用网络字节序（大端），但某些MCU是小端，直接强转导致解析错误。
正确做法：使用库函数读写，不要自己用指针强转。Nanopb和tinycbor已处理字节序。

❌ 坑4：浮点数精度丢失

错误做法：温度23.5在JSON里是字符串“23.5”，转成二进制浮点可能变成23.499999。
正确做法：如果要精确到0.1，可以用整数（235表示23.5°C）或缩放整数传输。

❌ 坑5：误用ProtoBuf的optional和repeated导致内存溢出

错误做法：在MCU上定义大量optional字段，每个optional都要占用额外的bool标记。
正确做法：嵌入式环境尽量使用required或默认值，避免optional。repeated字段要限定最大长度。

---

八、实测波形：用逻辑分析仪看不同格式的传输时间

测试条件：STM32L071 + SX1276 LoRa模块，SF=9，BW=125kHz，空速约1.8kbps。
上报同样的传感器数据（5个字段）。

格式	包长度	空中传输时间（ms）	电池消耗（uJ，不含睡眠）
JSON	118B	524	1572
MessagePack	86B	382	1146
CBOR	64B	284	852
ProtoBuf	52B	231	693

结论：在LoRa这类窄带网络上，ProtoBuf相比JSON节省了56%的传输时间和56%的电池能量。对于每天上报一次的电池设备，续航从2年可以延长到4年以上。

---

九、明天预告

第7天内容：

《效率翻倍！实战详解Keil MDK中分散加载文件（sct）在物联网固件开发中的妙用》

你将学到：

• 如何把关键变量放到内部SRAM，非关键缓存放到外部SDRAM

• 使用链接脚本自定义内存区域，避免堆栈溢出

• 一个实际案例：将LCD帧缓冲区从内部RAM移到外部SDRAM，释放80KB内存

记得点关注 + 🌟收藏，明早8点准时推送！

---

#ProtoBuf #CBOR #物联网序列化 #嵌入式优化 #STM32 #30天挑战