產品經理提出的需求經常需要終端,后臺之間相互協作才能完成,而在功能開發的過程中經常會聽到“定協議”這樣的詞,對這個詞大致的印象就是“兩個開發之間商量好怎么發數據,然后就可以開始調試,逐漸完成功能了”。
對于邏輯上的協議,產品經理可能并不陌生(甚至有些協議直接出自產品經理之手),對協議內容的描述類似于“0表示關閉功能,1表示開啟功能,用個type標識來源...”。一旦邏輯上的協議確定了,不同的開發和產品之間相當于在思想上達成了一致,然后圍繞協議來書寫各自的業務邏輯。
這一切似乎很自然,就如我們走路一般。正因為太自然,所以我們經常會忽略一些基礎設施,就如我們腳下的路一般。仔細想想,雖然邏輯上的協議確定了,終端和后臺之間還需要跨越網絡,甚至還需要跨越平臺的進行協議的傳輸和解析,那么邏輯上制定的那些協議又要如何在復雜的環境中正確的傳輸和解析呢?
先來了解一下基本數據類型。各種編程語言中都有自己的基本數據類型(大同小異),比如bool(布爾型),int(整形),float(浮點型),String(字符串)等等,這些數據都是可以在內存中存儲,計算的,對計算機來說都是一種二進制的數據表示(計算機只懂二級制)。我們把這些基本數據類型按照業務的需要組合起來形成更大的數據結構體。像制定的協議,也是數據結構體的一種,所以協議經常是這個樣子:
Protocol
{
boolean isEnable;
int from;
String message;
...
}
雖然這里的數據結構體比基本數據類型復雜了一些,但是對計算機來說只是把幾個二進制數據表示拼接到一起了而已。使用基本數據類型或基本數據類型的組合的好處就是計算機可以方便的讀寫(因為都是二進制),這里強調基本數據類型是為了引入一個概念————序列化。
序列化就是將數據對象轉成二進制串,反序列化就是將二進制串還原成數據對象,能夠被序列化是數據對象能夠持久化(保存到硬盤)或是在網絡中,不同平臺間互相傳輸的先決條件。當然,不僅僅是基本數據類型,只要能夠被表示成二進制的對象都是可以序列化的,比如一張圖片,在計算機中圖片是用bitmap表示的,同樣也是二進制串。你可能會問,那什么是不能夠被序列化的呢?比如按鈕(Button)這種對象就不能被序列化,你沒聽說要把一個按鈕保存到文件里面,或者把一個按鈕傳到服務器吧。
能夠被序列化僅僅解決了協議傳輸的問題,但是為了協議的收發雙方能夠方便的解析協議,還需要遵循一些通用的協議表示的規范。基本數據類型里擴展性最好的就是字符串,管你什么bool,int,float,字符串都能間接表示,比如1->"1",true->"true",3.14->"3.14"醬紫,所以在此基礎上,出現了一些用字符串來表示數據結構對象的協議,比如XML,JSON(一步一步寫爬蟲之JSON解析)等,使用這種協議的收發雙方在語義上都是使用的可理解的字符串傳輸,通過一些特殊的標記、分隔符來模塊化數據表示。
所以協議的收發過程變成了,發送方將協議制定的字段寫成XML或者JSON格式的字符串,序列化之后傳輸,接收方反序列化還原出字符串,然后按照XML或者JSON格式取出傳過來的各個協議字段。如果要求苛刻一點就會發現這兩種協議序列化后大部分情況下有空間浪費,比如協議中的數據都是可以通過byte來表示的,即用1,2,3這種簡單的數字形式來表示,這時用字符串表示顯然有些空間浪費了,所以很多公司在序列化反序列化的理論基礎上做了自己的解析協議,盡可能的減少協議存儲和傳輸的大小,那么在協議多,用戶量大的情況下,傳輸數據量的節省就非常可觀了。
云恒網絡www.xyzqw.net版權所有 備案號:魯ICP備19021997號-1 淄博高端網站建設、網絡營銷知名品牌 網絡整合傳播機構