2088
大家好，我是雜燴君。
越來(lái)越多的硬件產(chǎn)品，硬件構(gòu)成不僅僅是集成在一塊板子上，而是多塊控制板協(xié)同工作。
此時(shí)，就會(huì)涉及到多塊板之間的通信（有線(xiàn)/無(wú)線(xiàn)通信），就會(huì)涉及到到通信協(xié)議。很多時(shí)候，我們都會(huì)自定義一些協(xié)議。
我們之前在也分享一種常用的自定義協(xié)議格式：分享一種靈活性很高的協(xié)議格式（附代碼例子）
在多板系統(tǒng)中，會(huì)有以下這些應(yīng)用場(chǎng)景：
我們?cè)谲浖^(guò)程中，可能會(huì)涉及到板間交互的數(shù)據(jù)的升級(jí)，比如新增數(shù)據(jù)。
新增的某個(gè)數(shù)據(jù)屬性上屬于某個(gè)數(shù)據(jù)集合，比如與某個(gè)結(jié)構(gòu)體是同類(lèi)數(shù)據(jù)，理論上為了程序設(shè)計(jì)得更合理些，應(yīng)該把這個(gè)數(shù)據(jù)加在已有的結(jié)構(gòu)體里面。
但是，這可能會(huì)涉及到兼容性問(wèn)題。
如果直接往結(jié)構(gòu)體里新增數(shù)據(jù)，升級(jí)時(shí)，有些板子升級(jí)成功了，有些板子沒(méi)升級(jí)成功。可能就會(huì)出現(xiàn)數(shù)據(jù)異常導(dǎo)致功能異常。
公共板升級(jí)新增協(xié)議之后，可能就不能完全兼容與其通信的板子。
比如，有一條數(shù)據(jù)叫做設(shè)備信息的數(shù)據(jù)需要在板間通信，設(shè)備信息里包含了：設(shè)備IP、設(shè)備Mac。
#define??MSG_ID_DEV_INFO???0x0001
typedef?struct?_dev_info
{
?char?dev_ip[IP_MAX_LEN];
?char?dev_mac[MAC_MAX_LEN];
}dev_info_t;
此時(shí)，有新需求需要再加一個(gè)設(shè)備的sn，這個(gè)數(shù)據(jù)我們應(yīng)該如何加？
如果是項(xiàng)目前中期，這時(shí)候還是在開(kāi)發(fā)階段，我們可以隨意修改。因?yàn)樵O(shè)備sn也是設(shè)備信息的一部分，可以直接在設(shè)備信息這個(gè)數(shù)據(jù)里添加會(huì)比較合理：
#define??MSG_ID_DEV_INFO???0x0001
typedef?struct?_dev_info
{
?char?dev_ip[IP_MAX_LEN];
?char?dev_mac[MAC_MAX_LEN];
?char?dev_sn[SN_MAX_LEN];
}dev_info_t;
如果是項(xiàng)目后期，或已經(jīng)上市流通，則就需要考慮兼容性問(wèn)題了。
針對(duì)這種兼容性問(wèn)題，有如下解決方案：
方案一：新增的數(shù)據(jù)單獨(dú)走一條數(shù)據(jù)協(xié)議
比如針對(duì)以上例子，可以這么來(lái)擴(kuò)展：
#define??MSG_ID_DEV_INFO???0x0001
#define??MSG_ID_DEV_SN?????0x0002
typedef?struct?_dev_info
{
?char?dev_ip[IP_MAX_LEN];
?char?dev_mac[MAC_MAX_LEN];
}dev_info_t;
typedef?struct?_dev_sn
{
????char?dev_sn[SN_MAX_LEN];
}dev_sn_t;
這種方案雖然能解決問(wèn)題，但越到后面，程序會(huì)越來(lái)越亂，各種數(shù)據(jù)很散亂，很不好維護(hù)。
而且，一開(kāi)始也不可能把所有數(shù)據(jù)都規(guī)劃得很完美。有沒(méi)有什么方法，可以比較合理地?cái)U(kuò)充數(shù)據(jù)，并且也能應(yīng)對(duì)這種兼容性問(wèn)題。
看一下方案二。
方案二：項(xiàng)目設(shè)計(jì)初期，引入一些數(shù)據(jù)序列化庫(kù)。
比如protobuf。
Protocol Buffers，是Google公司開(kāi)發(fā)的一種數(shù)據(jù)描述語(yǔ)言，類(lèi)似于XML能夠?qū)⒔Y(jié)構(gòu)化數(shù)據(jù)序列化，可用于數(shù)據(jù)存儲(chǔ)、通信協(xié)議等方面。它不依賴(lài)于語(yǔ)言和平臺(tái)并且可擴(kuò)展性極強(qiáng)。
同XML相比，Protocol buffers在序列化結(jié)構(gòu)化數(shù)據(jù)方面有許多優(yōu)點(diǎn)：
消息格式升級(jí)和兼容性好
- 支持跨平臺(tái)多語(yǔ)言序列化反序列化速度很快序列化后體積相比Json和XML很小，適合網(wǎng)絡(luò)傳輸
相關(guān)文章：
Protobuf：一種更小、更快、更高效的協(xié)議
干貨 | 項(xiàng)目乏力？nanopb助你一臂之力
干貨 | protobuf-c之嵌入式平臺(tái)使用
如何利用Google的protobuf，來(lái)實(shí)現(xiàn)自己的RPC框架
針對(duì)上面的例子，使用protobuf。
原來(lái)的數(shù)據(jù)：
syntax?=?"proto2";
?
message?dev_info
{
????required?string?dev_ip????=?1;
????required?string?dev_mac???=?2;
}
新增數(shù)據(jù)dev_sn直接新增即可：
syntax?=?"proto2";
?
message?dev_info
{
????required?string?dev_ip????=?1;
????required?string?dev_mac???=?2;
????required?string?dev_sn????=?3;
}
以上就是本次的分享，歡迎收藏、轉(zhuǎn)發(fā)！
