前言
之前一直忙于移動(dòng)端日志SDK Trojan的開源工作，已十分穩(wěn)定地運(yùn)行在餓了么團(tuán)隊(duì)App中脏毯，集成了日志加密和解密功能。哎呀幔崖，允許我賣個(gè)狗皮膏藥食店，不用不知道，用了就知道赏寇，從此愛不釋手吉嫩，Trojan其實(shí)是一個(gè)很好用的膏藥，甚至是一劑不可或缺的良藥嗅定，能幫助我們跟蹤在線用戶自娩，解決疑難雜癥。
閑話少說渠退，進(jìn)入今天的正題忙迁，Protobuf，可能大家對(duì)此很陌生碎乃，還未接觸過姊扔，不過不要緊，看完這篇博客梅誓，相信你一定有所感觸恰梢。起初為了節(jié)約流量佛南，在我們千里眼后端接口率先使用Protobuf替代Json，支持Java嵌言、C++嗅回、Python等語言，就嘗到甜頭了呀页，簡(jiǎn)單好用還節(jié)省內(nèi)存流量妈拌，基于這個(gè)特性，英雄豈無用戶之地蓬蝶。后面尘分，我們推廣到Sqlite、SharedPerference等領(lǐng)域丸氛，利用Protobuf進(jìn)行改造培愁，替換原有的Json或者XML存儲(chǔ)方式!
Protobuf
說了這么久，Protobuf到底是什么呢缓窜，借花獻(xiàn)佛定续，引用Protobuf官網(wǎng)的解釋：
Protocol buffers are a flexible, efficient, automated mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages. You can even update your data structure without breaking deployed programs that are compiled against the "old" format.
本人英語水平有限，就在此簡(jiǎn)單翻譯一下禾锤，大意是：
Protobuf是一種靈活高效可序列化的數(shù)據(jù)協(xié)議私股，相于XML，具有更快恩掷、更簡(jiǎn)單倡鲸、更輕量級(jí)等特性。支持多種語言黄娘，只需定義好數(shù)據(jù)結(jié)構(gòu)峭状，利用Protobuf框架生成源代碼，就可很輕松地實(shí)現(xiàn)數(shù)據(jù)結(jié)構(gòu)的序列化和反序列化逼争。一旦需求有變优床，可以更新數(shù)據(jù)結(jié)構(gòu)，而不會(huì)影響已部署程序誓焦。
從上面我們可以總結(jié)出胆敞，Protobuf具有以下優(yōu)點(diǎn)：
- 代碼生成機(jī)制
syntax = "proto3";
package me.ele.demo.protobuf;
option java_outer_classname = "LoginInfo";
message Login {
string account = 1;
string password = 2;
}
這是一個(gè)用戶登錄信息的數(shù)據(jù)結(jié)構(gòu)，通過Protobuf提供的Gradle Plugin就可以在me.ele.demo.protobuf目錄下編譯自動(dòng)生成LoginInfo類杂伟，并有序列化和反序列化等Api竿秆。
- 高效性
用千里眼項(xiàng)目中跑出來的數(shù)據(jù)進(jìn)行對(duì)比，更具說服力稿壁。
序列化時(shí)間效率對(duì)比：
| 數(shù)據(jù)格式 | 1000條數(shù)據(jù) | 5000條數(shù)據(jù) |
|---|---|---|
| Protobuf | 195ms | 647ms |
| Json | 515ms | 2293ms |
序列化空間效率對(duì)比：
| 數(shù)據(jù)格式 | 5000條數(shù)據(jù) |
|---|---|
| Protobuf | 22MB |
| Json | 29MB |
從上面的數(shù)據(jù)可以看出來，Protobuf序列化時(shí)歉备，和Json對(duì)比傅是，不管在時(shí)間和空間上都是更加高效。由于篇幅的原因就不展示反序列化的數(shù)據(jù)對(duì)比了。
- 支持向后兼容和向前兼容
當(dāng)客戶端和服務(wù)器同事使用一塊協(xié)議的時(shí)候喧笔， 當(dāng)客戶端在協(xié)議中增加一個(gè)字節(jié)帽驯，并不會(huì)影響客戶端的使用
- 支持多種編程語言
在Google官方發(fā)布的源代碼中包含了c++、java书闸、Python三種語言
至于缺點(diǎn)尼变，Protobuf采用了二進(jìn)制格式進(jìn)行編碼，這直接導(dǎo)致了可讀性差浆劲；缺乏自描述嫌术，Protobuf是二進(jìn)制格式的協(xié)議內(nèi)容，要是不配合proto結(jié)構(gòu)體根本看不出來什么來牌借。
接入
在項(xiàng)目的根gradle配置如下
dependencies {
classpath 'com.google.protobuf:protobuf-gradle-plugin:0.8.0'
}
在gradle中配置如下：
apply plugin: 'com.google.protobuf'
android {
sourceSets {
main {
// 定義proto文件目錄
proto {
srcDir 'src/main/proto'
include '**/*.proto'
}
}
}
}
dependencies {
// 定義protobuf依賴度气，使用精簡(jiǎn)版
compile "com.google.protobuf:protobuf-lite:3.0.0"
compile ('com.squareup.retrofit2:converter-protobuf:2.2.0') {
exclude group: 'com.google.protobuf', module: 'protobuf-java'
}
}
protobuf {
protoc {
artifact = 'com.google.protobuf:protoc:3.0.0'
}
plugins {
javalite {
artifact = 'com.google.protobuf:protoc-gen-javalite:3.0.0'
}
}
generateProtoTasks {
all().each { task ->
task.plugins {
javalite {}
}
}
}
}
apply plugin: 'com.google.protobuf'是Protobuf的Gradle插件，幫助我們?cè)诰幾g時(shí)通過語義分析自動(dòng)生成源碼膨报，提供數(shù)據(jù)結(jié)構(gòu)的初始化磷籍、序列化以及反序列等接口。
compile "com.google.protobuf:protobuf-lite:3.0.0"是Protobuf支持庫(kù)的精簡(jiǎn)版本现柠，在原有的基礎(chǔ)上院领，用public替換set、get方法够吩，減少Protobuf生成代碼的方法數(shù)目比然。
定義數(shù)據(jù)結(jié)構(gòu)
還是以上面的例子來展開：
syntax = "proto3";
package me.ele.demo.protobuf;
option java_outer_classname = "LoginInfo";
message Login {
string account = 1;
string password = 2;
}
在這里定義了一個(gè)LoginInfo，我們只是簡(jiǎn)單的定義了account和password兩個(gè)字段废恋。這里注意谈秫，在上例中， syntax = "proto3";聲明proto協(xié)議版本鱼鼓，proto2和proto3在定義數(shù)據(jù)結(jié)構(gòu)時(shí)有些差別拟烫，option java_outer_classname = "LoginInfo";定義了Protobuf自動(dòng)生成類的類名，package me.ele.demo.protobuf;定義了Protobuf自動(dòng)生成類的包名迄本。
通過Android Studio clean硕淑，Protobuf插件會(huì)幫助我們自動(dòng)生成LoginInfo類，類結(jié)構(gòu)如下：
Protobuf幫我們自動(dòng)生成LoginOrBuilder接口嘉赎，主要聲明各個(gè)字段的set和get方法置媳；并且生成Login類，核心邏輯這個(gè)類中公条，通過writeTo(CodedOutputStream)接口序列化到CodedOutputStream拇囊，通過ParseFrom(InputStream)接口從InputStream中反序列化。類圖如下：
原理分析
上文提到靶橱，Protobuf不管在時(shí)間和空間上更高效寥袭，是怎么做到的呢路捧？
消息經(jīng)過Protobuf序列化后會(huì)成為一個(gè)二進(jìn)制數(shù)據(jù)流，通過Key-Value組成方式寫入到二進(jìn)制數(shù)據(jù)流传黄，如圖所示：
Key 定義如下：
(field_number << 3) | wire_type
以上面的例子來說杰扫，如字段account定義：
string account = 1;
在序列化時(shí)，并不會(huì)把字段account寫進(jìn)二進(jìn)制流中膘掰，而是把field_number=1通過上述Key的定義計(jì)算后寫進(jìn)二進(jìn)制流中章姓，這就是Protobuf可讀性差的原因，也是其高效的主要原因识埋。
數(shù)據(jù)類型
在Java種對(duì)不同類型的選擇凡伊，其他的類型區(qū)別很明顯，主要在與int32惭聂、uint32窗声、sint32、fixed32中以及對(duì)應(yīng)的64位版本的選擇辜纲，因?yàn)樵贘ava中這些類型都用int(long)來表達(dá)笨觅，但是protobuf內(nèi)部使用ZigZag編碼方式來處理多余的符號(hào)問題，但是在編譯生成的代碼中并沒有驗(yàn)證邏輯耕腾，比如uint的字段不能傳入負(fù)數(shù)之類的见剩。而從編碼效率上，對(duì)fixed32類型扫俺，如果字段值大于2^28苍苞，它的編碼效率比int32更加有效；而在負(fù)數(shù)編碼上sint32的效率比int32要高狼纬；uint32則用于字段值永遠(yuǎn)是正整數(shù)的情況羹呵。
編碼原理
在實(shí)現(xiàn)上，Protobuf使用CodedOutputStream實(shí)現(xiàn)序列化疗琉、CodedInputStream實(shí)現(xiàn)反序列化冈欢，他們包含write/read基本類型和Message類型的方法，write方法中同時(shí)包含fieldNumber和value參數(shù)盈简，在寫入時(shí)先寫入由fieldNumber和WireType組成的tag值(添加這個(gè)WireType類型信息是為了在對(duì)無法識(shí)別的字段編碼時(shí)可以通過這個(gè)類型信息判斷使用那種方式解析這個(gè)未知字段凑耻，所以這幾種類型值即可)，這個(gè)tag值是一個(gè)可變長(zhǎng)int類型柠贤，所謂的可變長(zhǎng)類型就是一個(gè)字節(jié)的最高位(msb香浩，most significant bit)用1表示后一個(gè)字節(jié)屬于當(dāng)前字段，而最高位0表示當(dāng)前字段編碼結(jié)束臼勉。在寫入tag值后邻吭，再寫入字段值value，對(duì)不同的字段類型采用不同的編碼方式：
對(duì)int32/int64類型宴霸，如果值大于等于0镜盯，直接采用可變長(zhǎng)編碼岸裙，否則，采用64位的可變長(zhǎng)編碼速缆，因而其編碼結(jié)果永遠(yuǎn)是10個(gè)字節(jié)，所有說int32/int64類型在編碼負(fù)數(shù)效率很低恩闻。
對(duì)uint32/uint64類型艺糜，也采用變長(zhǎng)編碼，不對(duì)負(fù)數(shù)做驗(yàn)證幢尚。
對(duì)sint32/sint64類型破停，首先對(duì)該值做ZigZag編碼，以保留尉剩，然后將編碼后的值采用變長(zhǎng)編碼真慢。所謂ZigZag編碼即將負(fù)數(shù)轉(zhuǎn)換成正數(shù)，而所有正數(shù)都乘2理茎，如0編碼成0黑界，-1編碼成1，1編碼成2皂林，-2編碼成3朗鸠，以此類推，因而它對(duì)負(fù)數(shù)的編碼依然保持比較高的效率础倍。
對(duì)fixed32/sfixed32/fixed64/sfixed64類型烛占，直接將該值以小端模式的固定長(zhǎng)度編碼。
對(duì)double類型沟启，先將double轉(zhuǎn)換成long類型忆家，然后以8個(gè)字節(jié)固定長(zhǎng)度小端模式寫入。
對(duì)float類型德迹，先將float類型轉(zhuǎn)換成int類型芽卿，然后以4個(gè)字節(jié)固定長(zhǎng)度小端模式寫入。
對(duì)bool類型浦辨，寫0或1的一個(gè)字節(jié)蹬竖。
對(duì)String類型，使用UTF-8編碼獲取字節(jié)數(shù)組流酬，然后先用變長(zhǎng)編碼寫入字節(jié)數(shù)組長(zhǎng)度币厕，然后寫入所有的字節(jié)數(shù)組。
對(duì)bytes類型(ByteString)芽腾，先用變長(zhǎng)編碼寫入長(zhǎng)度旦装，然后寫入整個(gè)字節(jié)數(shù)組。
對(duì)枚舉類型(類型值
WIRETYPE_VARINT)摊滔，用int32編碼方式寫入定義枚舉項(xiàng)時(shí)給定的值（因而在給枚舉類型項(xiàng)賦值時(shí)不推薦使用負(fù)數(shù)阴绢，因?yàn)閕nt32編碼方式對(duì)負(fù)數(shù)編碼效率太低）店乐。對(duì)內(nèi)嵌
Message類型(類型值WIRETYPE_LENGTH_DELIMITED)，先寫入整個(gè)Message序列化后字節(jié)長(zhǎng)度呻袭，然后寫入整個(gè)Message眨八。
ZigZag編碼實(shí)現(xiàn)：
(n << 1) ^ (n >> 31) / (n << 1) ^ (n >> 63);在CodedOutputStream中還存在一些用于計(jì)算某個(gè)字段可能占用的字節(jié)數(shù)的compute靜態(tài)方法，這里不再詳述左电。
在Protobuf的序列化中廉侧，所有的類型最終都會(huì)轉(zhuǎn)換成一個(gè)可變長(zhǎng)int/long類型、固定長(zhǎng)度的int/long類型篓足、byte類型以及byte數(shù)組段誊。對(duì)byte類型的寫只是簡(jiǎn)單的對(duì)內(nèi)部buffer的賦值：
public void writeRawByte(final byte value) throws IOException {
if (position == limit) {
refreshBuffer();
}
buffer[position++] = value;
}
對(duì)32位可變長(zhǎng)整形實(shí)現(xiàn)為：
public void writeRawVarint32(int value) throws IOException {
while (true) {
if ((value & ~0x7F) == 0) {
writeRawByte(value);
return;
} else {
writeRawByte((value & 0x7F) | 0x80);
value >>>= 7;
}
}
}
對(duì)于定長(zhǎng)，Protobuf采用小端模式栈拖，如對(duì)32位定長(zhǎng)整形的實(shí)現(xiàn)：
public void writeRawLittleEndian32(final int value) throws IOException {
writeRawByte((value ) & 0xFF);
writeRawByte((value >> 8) & 0xFF);
writeRawByte((value >> 16) & 0xFF);
writeRawByte((value >> 24) & 0xFF);
}
對(duì)byte數(shù)組连舍，可以簡(jiǎn)單理解為依次調(diào)用writeRawByte()方法，只是CodedOutputStream在實(shí)現(xiàn)時(shí)做了部分性能優(yōu)化涩哟。這里不詳細(xì)介紹索赏。對(duì)CodedInputStream則是根據(jù)CodedOutputStream的編碼方式進(jìn)行解碼，因而也不詳述染簇，其中關(guān)于ZigZag的解碼：
(n >>> 1) ^ -(n & 1)
repeated字段編碼
對(duì)于repeated字段参滴，一般有兩種編碼方式：
每個(gè)項(xiàng)都先寫入tag，然后寫入具體數(shù)據(jù)锻弓。
先寫入tag砾赔，后count，再寫入count個(gè)項(xiàng)青灼，每個(gè)項(xiàng)包含length|data數(shù)據(jù)暴心。
從編碼效率的角度來看，個(gè)人感覺第二中情況更加有效杂拨，然而不知道處于什么原因考慮专普，Protobuf采用了第一種方式來編碼，個(gè)人能想到的一個(gè)理由是第一種情況下弹沽，每個(gè)消息項(xiàng)都是相對(duì)獨(dú)立的檀夹，因而在傳輸過程中接收端每接收到一個(gè)消息項(xiàng)就可以進(jìn)行解析，而不需要等待整個(gè)repeated字段的消息包策橘。對(duì)于基本類型炸渡，Protobuf也采用了第一種編碼方式，后來發(fā)現(xiàn)這種編碼方式效率太低丽已，因而可以添加[packed = true]的描述將其轉(zhuǎn)換成第三種編碼方式(第二種方式的變種蚌堵，對(duì)基本數(shù)據(jù)類型，比第二種方式更加有效)
- 先寫入tag，后寫入字段的總字節(jié)數(shù)吼畏，再寫入每個(gè)項(xiàng)數(shù)據(jù)督赤。
目前Protobuf只支持基本類型的packed修飾，因而如果將packed添加到非repeated字段或非基本類型的repeated字段泻蚊，編譯器在編譯proto文件時(shí)會(huì)報(bào)錯(cuò)躲舌。
結(jié)束
以上是Protobuf的詳細(xì)介紹，基于源碼的分析這里并未展開性雄，請(qǐng)大家多多指教孽糖！最后，非常感謝大家對(duì)本篇博客的關(guān)注毅贮！
參考文獻(xiàn)
https://developers.google.com/protocol-buffers/docs/overview
http://www.blogjava.net/DLevin/archive/2015/04/01/424011.html
