我第一次知道FlatBuffers是因為Facebook寫的這篇Android的技術博客文章。它主要介紹了FlatBuffers對比JSON的優(yōu)勢，以及Facebook Android App應用了FlatBuffers后，衍生的數(shù)據(jù)和界面更新的工作流轉(zhuǎn)模式。建議去讀一讀，作者還是一個中國人哦。

下面開始介紹了一下FlatBuffers，首先看看它和JSON的對比。

? ?

先引用GitHub?frogermcs/FlatBuffs上的兩張Gif效果圖.

那個Loading菊花是干什么的呢？點擊上下兩個按鈕開始數(shù)據(jù)解析，而數(shù)據(jù)解析是故意放在主線程上執(zhí)行，而Loading菊花能直觀的辨別解析過程有沒有導致UI卡頓。

左圖，點擊"PARSE JSON"按鈕是用的Gson解析了一個468KB的Json文件，耗時200-300ms。

右圖，點擊"USE FLATBUFFERS"，是“解析”同樣的Json數(shù)據(jù)但是用FlatBuffers特有的數(shù)據(jù)格式文件repos_flat.bin。耗時是<10ms。FlatBuffers“解析”的過程，Loading菊花一直保持著流暢的轉(zhuǎn)動。

?

FlatBuffers到底有什么樣的魔術，能比JSON快這么多呢？

其實FlatBuffers實際并沒有做數(shù)據(jù)的解析，repos_flat.bin是按照FlatBuffers數(shù)據(jù)組織格式生成的Byte數(shù)組。

FlatBuffer的數(shù)據(jù)解析是靠一層層的offset偏移量的組合計算定位到數(shù)據(jù)在Byte數(shù)組的位置，進而獲取目標數(shù)據(jù)的值 。所以FlatBuffer是需要什么數(shù)據(jù)，才解析什么數(shù)據(jù)，并不需要全量解析。

簡單說，FlatBuffers分為vtable區(qū)和數(shù)據(jù)區(qū)。vtable區(qū)保存的是數(shù)據(jù)的偏移值，數(shù)據(jù)區(qū)保存的是具體的數(shù)據(jù)值。

?

FlatBuffers的優(yōu)點和缺點

優(yōu)點：

1. 數(shù)據(jù)都是從Byte數(shù)組中獲取，減少解析過程的內(nèi)存占用，減低了GC發(fā)生概率。

? ??Memory Efficient Serialization Library，FlatBuffers是這么描述自己的。

? ??這里有別人做的內(nèi)存檢測的數(shù)據(jù)。

2. 無需全量解析，用到的數(shù)據(jù)才需要解析。

? ? 想象一個很長的ListView，并不需要在初始狀態(tài)就把所有的數(shù)據(jù)都解析出來。滾動到可見狀態(tài)的item的數(shù)據(jù)，才需要被解析。

缺點：

1. 數(shù)據(jù)獲取都是偏移量計算的解析過程，嵌套層級深的數(shù)據(jù)，可能帶來性能問題。

2. 不自行做數(shù)據(jù)緩存的話，每次獲取同樣的數(shù)據(jù)會有重復計算。

3. Byte數(shù)據(jù)安全性和完整性有顧慮。也有人專門寫博客表明不會用FlatBuffer哈哈。

?

FlatBuffers的應用

FlatBuffers還可以“解析”JSON，實際是把JSON數(shù)據(jù)生成FlatBuffers格式的Byte數(shù)組。

如上圖，中間的按鈕“PARSE JSON(FLATBUFFERS)”點擊執(zhí)行后解析468KB同樣的JSON文件，比Gson節(jié)省了約40%的耗時。

作為應用FlatBuffers的切入點，參考著的frogermsc GitHub Demo，我嘗試把FlatBuffer解析JSON應用到工作項目中。

步驟：

1. 使用FlatBuffers需要引入2個SO和一個JAR，合計1MB；

2. 根據(jù)待解析的數(shù)據(jù)，要寫一個schema文件如下，類似于protocolBuffer的.proto文件的作用；

namespace RankDetail;table RankDetail {code : int;msg : string; }root_type RankDetail;

3. 通過命令行，根據(jù)schema生成相關解析后數(shù)據(jù)讀取的Java類，這個步驟也類似protocolBuffer；

?

遇到的問題：

1. schema文件的Key-value對的Key不能數(shù)字開頭，如下的123key是不符合要求的；

? ? 原因是因為，FlatBuffers是直接獲取schema文件內(nèi)的這種key-value的key的值作為方法名字和變量名字，阿拉伯數(shù)字開頭的變量名和方法名是不合法的。

namespace RankDetail;table RankDetail {code : int;msg : string;123key : string; }root_type RankDetail;

2. 解析是在SO的native代碼，遇到失敗就會native crash，缺少有用的解析失敗的日志信息，增加開發(fā)調(diào)試的難度和時間。

?

FlatBuffers最大的威力是解析他自家格式的Byte數(shù)組（參考文章開頭的GIF對比），應用到正式環(huán)境的功能，需要后臺請求返回的數(shù)據(jù)是FlatBuffers格式的Bytes數(shù)組。另外，FlatBuffers解析的容錯性目前還有待完善提升。但以后，FlatBuffers會是減少內(nèi)存占用、提升用戶體驗的利器。

轉(zhuǎn)載于:https://www.cnblogs.com/wingyip/p/5185593.html

總結(jié)

以上是生活随笔為你收集整理的FlatBuffers初探的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。