前言

之前一直忙于移動(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)：

1. 代碼生成機(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。

2. 高效性

用千里眼項(xiàng)目中跑出來的數(shù)據(jù)進(jìn)行對(duì)比，更具說服力。

序列化時(shí)間效率對(duì)比：

序列化空間效率對(duì)比：

從上面的數(shù)據(jù)可以看出來，Protobuf序列化時(shí)，和Json對(duì)比，不管在時(shí)間和空間上都是更加高效。由于篇幅的原因就不展示反序列化的數(shù)據(jù)對(duì)比了。

3. 支持向后兼容和向前兼容

當(dāng)客戶端和服務(wù)器同事使用一塊協(xié)議的時(shí)候， 當(dāng)客戶端在協(xié)議中增加一個(gè)字節(jié)，并不會(huì)影響客戶端的使用

4. 支持多種編程語言

在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支持庫的精簡(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)如下：

LoginInfo類結(jié)構(gòu)

Protobuf幫我們自動(dòng)生成LoginOrBuilder接口，主要聲明各個(gè)字段的set和get方法；并且生成Login類，核心邏輯這個(gè)類中，通過writeTo(CodedOutputStream)接口序列化到CodedOutputStream，通過ParseFrom(InputStream)接口從InputStream中反序列化。類圖如下：

Login類圖

原理分析

上文提到，Protobuf不管在時(shí)間和空間上更高效，是怎么做到的呢？

消息經(jīng)過Protobuf序列化后會(huì)成為一個(gè)二進(jìn)制數(shù)據(jù)流，通過Key-Value組成方式寫入到二進(jìn)制數(shù)據(jù)流，如圖所示：

二進(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ù)類型

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ì)不同的字段類型采用不同的編碼方式：

1. 對(duì)int32/int64類型，如果值大于等于0，直接采用可變長(zhǎng)編碼，否則，采用64位的可變長(zhǎng)編碼，因而其編碼結(jié)果永遠(yuǎn)是10個(gè)字節(jié)，所有說int32/int64類型在編碼負(fù)數(shù)效率很低。

2. 對(duì)uint32/uint64類型，也采用變長(zhǎng)編碼，不對(duì)負(fù)數(shù)做驗(yàn)證。

3. 對(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ù)的編碼依然保持比較高的效率。

4. 對(duì)fixed32/sfixed32/fixed64/sfixed64類型，直接將該值以小端模式的固定長(zhǎng)度編碼。

5. 對(duì)double類型，先將double轉(zhuǎn)換成long類型，然后以8個(gè)字節(jié)固定長(zhǎng)度小端模式寫入。

6. 對(duì)float類型，先將float類型轉(zhuǎn)換成int類型，然后以4個(gè)字節(jié)固定長(zhǎng)度小端模式寫入。

7. 對(duì)bool類型，寫0或1的一個(gè)字節(jié)。

8. 對(duì)String類型，使用UTF-8編碼獲取字節(jié)數(shù)組，然后先用變長(zhǎng)編碼寫入字節(jié)數(shù)組長(zhǎng)度，然后寫入所有的字節(jié)數(shù)組。

9. 對(duì)bytes類型(ByteString)，先用變長(zhǎng)編碼寫入長(zhǎng)度，然后寫入整個(gè)字節(jié)數(shù)組。

10. 對(duì)枚舉類型(類型值WIRETYPE_VARINT)，用int32編碼方式寫入定義枚舉項(xiàng)時(shí)給定的值（因而在給枚舉類型項(xiàng)賦值時(shí)不推薦使用負(fù)數(shù)，因?yàn)閕nt32編碼方式對(duì)負(fù)數(shù)編碼效率太低）。

11. 對(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字段，一般有兩種編碼方式：

1. 每個(gè)項(xiàng)都先寫入tag，然后寫入具體數(shù)據(jù)。

2. 先寫入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ù)類型，比第二種方式更加有效)

3. 先寫入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