Find N3入網：最高支持16+1TB
OPPO將于近期登場的Find N3折疊屏目前已經正式入網，型號為PHN110。本次Find N3在外觀方面相比前兩代有很大的變化，不再是小號的橫向折疊屏，而是跟別的廠商一樣采用了較為常見的
最近咱們公司內部搞了個技術交流，討論起了序列化協議怎么選。我覺得這話題挺有意思的，就順手整理了一下現在主流的序列化協議的優缺點。這樣一來，以后查起來也方便。
先說說 JSON，這貨讀起來挺舒服，用起來也簡單。擴展性和兼容性都不錯，能在不同語言之間傳來傳去結構化數據。
但 JSON 也有缺點，比如體積大，影響性能，尤其是高并發的時候。還有就是缺乏命名空間，有時候信息會亂成一團。
總結起來，JSON 是個簡單通用的應用協議，用得挺廣，開發效率挺高，但性能一般，維護成本也偏高。
接下來是 Protobuf，這貨是個高性能、易擴展的序列化框架。
優點很明顯，跨語言，向后兼容，新增字段不影響已有的協議。代碼自動生成，用起來簡單。二進制消息，效率高，性能好。而且安全性也不錯，只寫字段號，編碼成二進制，破解難度大。
缺點嘛，二進制消息可讀性差，字段冗余，類文件會越來越大，維護成本高。而且 Protobuf 只管序列化和反序列化，RPC 功能得另請高明。
RPC 是啥？就是遠程過程調用，一個機器（客戶端）調用另一個機器（服務器）上的函數或方法，然后拿到結果。RPC 會隱藏底層通信細節，不用你直接處理 Socket 或 Http 通信，用起來就像調用本地函數一樣。
總結 Protobuf，上手簡單，高效，兼容性強，但維護成本也高。
Thrift 是 Facebook 2007年開發的跨語言 RPC 框架，支持多語言編譯，提供多種服務器工作模式。
優點是序列化和 RPC 一站式解決，比 Protobuf 方便。跨語言，IDL 接口定義語言，自動生成多語言文件。省流量，體積小。包含完整的客戶端/服務端堆棧，RPC 實現起來快。服務端有多種工作模式，比如線程池、非阻塞模型。
缺點是不支持雙通道，RPC 方法非線程安全，服務器容易被掛死，需要串行化。默認不具備動態特性，開發環境和編譯有點麻煩。
總結 Thrift，跨語言，實現簡單，但初次使用有點麻煩，得注意使用問題和場景限制。
MessagePack 是一種高效的二進制序列化格式。
優點是跨語言，多語言支持。序列化反序列化效率高，文件體積小，比 JSON 小一倍，還兼容 JSON 數據格式。
缺點是缺乏復雜模型支持，對復雜數據類型（List、Map）支持不夠。序列化沒問題，但反序列化回來就麻煩了，尤其是對 Java 開發人員來說。維護成本也高，因為 MessagePack 通過值的順序來定位屬性，不同語言中都得維護一樣的模型和屬性順序。還不支持模型嵌套。
總結 MessagePack，性能高，但擴展性差，維護成本高。
哦，對了，在整理的時候我還有點疑問。有人說 MessagePack 的序列化和反序列化效率是 Protobuf 的 4 倍，我個人表示懷疑。后續的文章可能會對這兩個協議做個細致的對比。
好了，今天的分享就到這兒，希望對你有幫助。有啥問題咱們再討論！
本文鏈接：http://www.www897cc.com/showinfo-26-84586-0.htmlJSON, Protobuf, Thrift和MessagePack的優缺點對比
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 我LocalStorage犯了兩個小錯誤，差點導致項目大崩潰！
下一篇： 五款開源、美觀、強大的WPF UI組件庫
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號