前言
為了提高通信效率，可以采用 protobuf 替代 XML 和 Json 資料互動格式，protobuf 相對來說資料量小，在行程間通信或者設備之間通信能夠提高通信速率，下面介紹 protobuf 在 ARM 平臺上的使用，
簡介
官方檔案給出的定義和描述：
protocol buffers 是一種語言無關、平臺無關、可擴展的序列化結構資料的方法，它可用于（資料）通信協議、資料存盤等，
Protocol Buffers 是一種靈活，高效，自動化機制的結構資料序列化方法－可類比 XML，但是比 XML 更小（3 ~ 10倍）、更快（20 ~ 100倍）、更為簡單，
你可以定義資料的結構，然后使用特殊生成的源代碼輕松的在各種資料流中使用各種語言進行撰寫和讀取結構資料，你甚至可以更新資料結構，而不破壞由舊資料結構編譯的已部署程式，
簡單來說：
-
和平臺無關，和開發語言無關（支持多種語言和多個平臺）
-
高效：資料量小，因此更快
-
擴展性和兼容性較好
使用方式
編譯安裝
1、以下僅介紹在嵌入式設備軟體中使用，即交叉編譯開發環境，以 protobuf-3.19.3為例
$ tar -xzvf protobuf-cpp-3.19.3.tar.gz
$ cd protobuf-3.19.3/
$ ./autogen.sh2、配置交叉編譯環境和編譯安裝后的路徑，并編譯
$ ./configure --host=arm-linux CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ --prefix=/home/protobuf/linux
$ make -j;make install
3、此時會在 /home/protobuf/linux 生成三個檔案夾
bin：可執行檔案 protoc，可以將對應的 proto 檔案生成代碼的工具（在 ARM 下使用，所以這個不用）
lib：對應的庫，包含靜態庫和動態庫等，還有對應裁剪版功能的lite庫
include：集成時需要包含的頭檔案
4、重新配置編譯環境和安裝后的路徑，并編譯（Ubuntu系統）
$ ./configure --prefix=/home/protobuf/ubuntu
$ make -j;make install
5、此時會在 /home/protobuf/ubuntu 生成三個檔案夾，和上述一樣（Ubuntu 的編譯環境），但是這個我們只需要bin檔案即可（我們使用的開發環境是 Ubuntu，所以通常都是在 Ubuntu 上執行protoc，用來生成對應的代碼）
使用步驟
1、創建 .proto 檔案，定義資料結構，如：
// 指定版本 （默認）使用protobuf2
syntax = "proto2";
// 指定命名空間
package ExampleNC;
// 例1: 在 xxx.proto 檔案中定義 CExample message
message CExample
{
optional string stringDesc = 1;
optional bytes bytesVal = 2;
}2、通過可執行檔案 protoc 將 .proto 檔案生成對應的代碼檔案
$ protoc -I=$SRC_DIR --cpp_out=$DST_DIR $SRC_DIR/xxx.proto$SRC_DIR是.proto檔案所在的路徑，$DST_DIR是生成代碼的路徑，--cpp_out 是表示生成 C++代碼；
生成對應的 xxx.pb.h 和 xxx.pb.cc 兩個檔案，可將這兩個檔案放入需要集成的代碼中（包括交叉編譯生成的頭檔案include）
3、通過生成的類 CExample 定義變數，設定對應的值，如：
CExample *pInfo = new CExample();
pInfo->set_stringdesc("test"); // 賦值
printf("info: %s\n", pInfo->DebugString().c_str());// 列印設定的值（文本格式，lite版本不支持）
int length = pInfo->ByteSize();
char *pBuf = (char *)malloc(length);
pInfo->SerializeToArray(pBuf, length);// 序列化為hex
printf_hexdump("HEX:", pBuf, length);// 列印序列化后的hex資料
CExample *pOutInfo = new CExample();
pOutInfo->ParseFromArray(pBuf, length);//反序列化
printf("OUTinfo: %s\n", pOutInfo->DebugString().c_str());// 列印設定的值（文本格式，lite版本不支持）
free(pBuf);其中，定義新的類后，若沒有進行賦值操作的變數，序列化中則沒有該資料內容
常見問題
在代碼運行時，出現以下錯誤
[libprotobuf ERROR google/protobuf/descriptor_database.cc:641] File already exists in database: ais_msg.proto
[libprotobuf FATAL google/protobuf/descriptor.cc:2021] CHECK failed: GeneratedDatabase()->Add(encoded_file_descriptor, size):
terminate called after throwing an instance of 'google::protobuf::FatalException'
what(): CHECK failed: GeneratedDatabase()->Add(encoded_file_descriptor, size): 網上提供的解決辦法
【轉自 https://m.newsmth.net/article/Programming/single/5862/3】
Protobuf是Google的一個開源專案，它的大部分代碼是用C++寫的，當別的程式想要使用protobuf時，既可以采用動態鏈接，也可以采用靜態鏈接，Google內部主要是采用靜態鏈接為主，而在Linux的世界里，大部分發行版都把Protobuf編譯成了動態庫，
最佳實踐
如果你的Project本身是一個動態庫，那么你應該避免在它的公開介面中用到任何protobuf的符號，并且采用靜態鏈接到protobuf的方式，同時你應該在dllmain中呼叫google::protobuf::ShutdownProtobufLibrary()來清理protobuf使用過記憶體，
如果你的Project本身是一個靜態庫，那么決定權不在你手里，而且最終把你的靜態庫編譯成PE/ELF檔案的那個人手里，但是你需要在你的build system中留出介面讓他可以告知你這個資訊，
如果你的Project本身是一個動態庫，并且你公開介面中用到了protobuf的符號，那么你必須動態鏈接到protobuf， 否則當你跨DLL傳送protobuf的物件時，如果這個物件在A.DLL中創建，但是在B.DLL中被銷毀，那么就會導致程式崩潰，因為當你采用靜態鏈接到Protobuf時，每個DLL內部都有一個protobuf的副本，并且protobuf內部有自己的記憶體池，跨DLL傳輸物件就會導致該物件可能在不屬于自己的記憶體池中被釋放，
動態鏈接的注意事項
首先，不推薦在Windows上這么做， 因為protobuf本身是基于C++的，而Windows上DLL的匯出符號應該都是C風格的，不應含有任何STL、std::string這樣的東西， 如果你一定要這么做，那么你就會收到C4251警告，這是一個level 1的警告，屬于最高嚴重等級，
如果你決定動態鏈接到protobuf，并且目標平臺是Windows作業系統，那么你應該在編譯你的project的源代碼的時候"#define PROTOBUF_USE_DLLS"， 這樣聯結器才知道應該使用dllimport的方式去尋找protobuf的符號， Linux不需要這么做，但是Linux需要注意把code編譯成PIC的， 同時，在Windows上需要注意所有代碼必須采用動態鏈接到CRT，而不能采用靜態鏈接， 這條適用于libprotobuf.dll自身以及它的所有使用者，
無論是Windows還是Linux，動態鏈接帶來的另一個問題是：從.proto生成的那些C/C++代碼可能也需要被編譯成動態庫共享，因為protobuf本身有一個global的registry，每個message type都需要去那里注冊一下，而且不能重復注冊，所以，假如你在A.DLL中定義了某些message type，那么B.DLL就只能從A.DLL的exported的DLL interface中使用這些message type, 而不能從proto檔案中重新生成C/C++代碼并包含到B.DLL里去，并且B.DLL也不能私自的去修改、擴展這個message type，據說換成protobuf-lite就能避免這個問題，但是Google官方并沒有對此表態，
另外，protobuf動態庫自身不能被unload然后reload， 這個限制讓我很意外，但是Google自己說他們在設計的時候從來沒考慮過這樣的使用場景，不過，在Linux上這其實是很常見的事情，GLIB自身都不支持unload，
糟糕的用例：Tensorflow
首先，tensorflow作為一個python的plugin,它必須是動態庫，不能是靜態庫，
Tensorflow選擇了靜態鏈接到protobuf，
Tensorflow想要支持動態加載plugin，每個plugin是一個動態庫，
plugin本身需要訪問Tensorflow的介面，而這些介面常常又含有protobuf的符號，Tensorflow會暴露(provide) libprotobuf 的部分符號，如果這個plugin需要的符號恰好在tensorflow中都能找到，那么很好， 但事情并非總是如此， 因為Tensorflow它只有一個partial的libprotobuf，它只包含它自己所必須的那部分protobuf的code，當這個plugin想要的超出了tensorflow所能提供的范疇，寫plugin的人就會嘗試把protobuf加到link command中，這樣就會變得非常非常危險，程式隨時會崩潰，因為它會在兩個不同的protobuf副本之間傳送protobuf的物件， 所以，不要看到“unresolved external symbol”就不動腦子的把缺的庫加上，有時候這個錯誤代表的是更深層次的問題，
糟糕的用例： cmake
cmake 3.16做了一個火上澆油的事情：當你使用find_package(Protobuf)的時候，你需要提前知道你找到的究竟是動態庫還是靜態庫，如果是靜態庫那么你需要設定Protobuf_USE_STATIC_LIBS成OFF，否則在Windows上鏈接會失敗，請注意： 不是cmake告訴你它找到的是什么，而是你要主動告訴它，它找到的會是什么，首先說明錯誤的具體原因：因為需要通信多個行程模塊都集成了相同的 *.pb.cc 和 *.pb.h 檔案進行編譯（動態庫或者執行檔案），且在編譯時通過動態庫 libprotobuf.so 的方式進行鏈接，
因為這個，導致在運行時報錯，通過網上查找得到：protobuf 本身有一個 global 的 registry，每個 message type 都需要去那里注冊一下，而且不能重復注冊，上述的
Add錯誤就是因為注冊失敗，原因就是因為這幾個中重復注冊了（多份*.pb.cc實作），
解決方案
根據網上的解決方案，我自己也實驗了，歸納如下：
1、靜態庫編譯，使用 libprotobuf.a，即多個編譯目標通過靜態庫的方式鏈接，但是這種方式勢必會導致程式編譯后的目標大小增大，不太適合 ARM 容量小的設備，如果編譯目標是動態庫，則需要在交叉編譯 protobuf 加上-fPIC，
$ ./configure --host=arm-linux --disable-shared CFLAGS="-fPIC -fvisibility=hidden" CXXFLAGS="-fPIC -fvisibility=hidden" CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ --prefix=/home/protobuf/linux
$ make -j;make install或者改 configure 檔案再執行 configure
// 改成下面的樣子（不同版本位置不對，所以可以搜索 ac_cv_env_CFLAGS_set）
if test "x${ac_cv_env_CFLAGS_set}" = "x"; then
CFLAGS="-fPIC"
fi
if test "x${ac_cv_env_CXXFLAGS_set}" = "x"; then
CXXFLAGS="-fPIC"
fi$ ./configure --host=arm-linux --disable-shared CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ --prefix=/home/protobuf/linux
$ make -j;make install2、使用 protobuf-lite 版本，可以通過動態庫 libprotobuf-lite.so 鏈接，但這個版本裁剪了很多功能，只保留了基本功能，這個需要修改 *.proto 檔案，增加 option optimize_for 選項，重新生成 *.pb.cc 和 *.pb.h 檔案，然后各模塊集成編譯即可，
// 指定版本 （默認）使用protobuf2
syntax = "proto2";
// 使用 lite 版本
option optimize_for = LITE_RUNTIME;
// 指定命名空間
package ExampleNC;
// 例1: 在 xxx.proto 檔案中定義 CExample message
message CExample
{
optional string stringDesc = 1;
optional bytes bytesVal = 2;
}3、將生成的 *.pb.cc 和 *.pb.h 和 libprotobuf.a 編譯成一個新的動態庫 libprotobuf-new.so，其他模塊包含 *.pb.h 檔案并通過動態庫的方式鏈接這個新的動態庫即可，
這種方式解決了上述問題，也保留了全部功能，但是對于后續的維護存在一定問題，如果更新 *.proto 檔案，重新生成并編譯了 libprotobuf-new.so，那么其他使用的模塊也必須都更新*.pb.h 檔案重新編譯，否則在使用中會遇到:
- 程式包只替換了 libprotobuf-new.so ，程式運行時可能存在踩踏資料的情況，引發系統例外
- 程式包只替換了其他模塊的庫，并沒有替換 libprotobuf-new.so ，就會導致行程崩了
所以，在多人合作開發的程式實作資料通信時，這種方式并不好，兼容性太差，因為需要替換所有涉及的模塊動態庫或者執行檔案
以上三種解決方案各有利弊，可以根據實際情況選擇
本文來自博客園，作者：大橙子瘋，轉載請注明原文鏈接：https://www.cnblogs.com/const-zpc/p/16364417.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/498638.html
標籤：其他