目前，除了一些特別簡單非聯(lián)網(wǎng)類應(yīng)用(比如計算器、鬧鐘等)，幾乎所有的應(yīng)用均是聯(lián)網(wǎng)應(yīng)用(比如新聞客戶端，微信等等)，這些app客戶端基本都只是負(fù)責(zé)用戶的交互與數(shù)據(jù)收集與展示，真正的數(shù)據(jù)和服務(wù)均存儲在云端。

那移動端究竟如何和后臺來交換數(shù)據(jù)并展示呢?我們打個比喻，其實整個過程跟去燒烤店兒擼串一樣一樣的。

拿任意一個新聞客戶端舉例，當(dāng)用戶刷新的那一刻(你萌生了吃燒烤的想法)，客戶端開始組織數(shù)據(jù)請求(你開始穿衣洗臉打扮，并思考該去哪一家吃呢)，當(dāng)用戶界面開始展示loading的時候(這個時候你正走在“馬大姐燒烤店”的路上)，經(jīng)過幾百毫秒的時間，這個時候請求數(shù)據(jù)已經(jīng)到了服務(wù)器(你已經(jīng)坐在了馬大姐燒烤店的桌子上)，服務(wù)器開始查看客戶端想要請求哪方面的數(shù)據(jù)，是請求財經(jīng)頻道的，還是請求汽車頻道的數(shù)據(jù)(服務(wù)員遞來了菜單，問你想吃啥)，服務(wù)器看懂了客戶端的想法開始準(zhǔn)備數(shù)據(jù)(你點了20個肉串，10個大腰子)，服務(wù)器看到你請求的是汽車頻道和財經(jīng)頻道的數(shù)據(jù)(光著膀子的烤串師傅開始烤這20個串和10個大腰子)，并給回到服務(wù)員，服務(wù)員一路小跑，將你要的串和腰子遞到你的面前，這個時候相當(dāng)于數(shù)據(jù)已經(jīng)傳回到了客戶端，客戶端loading消失，你看到了最新的兩個頻道的數(shù)據(jù)。

那客戶端和服務(wù)器之間傳輸數(shù)據(jù)的格式是怎么樣的呢?

現(xiàn)在流行的做法通常有兩種，一種是類似于PB(Protocol Buffer，Google定義的一個數(shù)據(jù)傳輸協(xié)議，以簡潔，省流，易用出名)的二進(jìn)制數(shù)據(jù)(二進(jìn)制數(shù)據(jù)的意思就是你打開這個文件你只能看到0和1組成的數(shù)字串，是沒辦法和你生活中任何認(rèn)識的字母聯(lián)系在一起的)傳輸，這種格式的好處是包小，重復(fù)的字段會被節(jié)省。另一種是JSON(JavaScriptObject Notation)，這也是一種輕量級的數(shù)據(jù)傳輸格式，就是用一堆中括號把數(shù)據(jù)組織起來，不像二進(jìn)制，這種格式是人可讀的，并且比較輕巧，所以也有大量的應(yīng)用場景。下面這段數(shù)據(jù)就是JSON格式，簡單解讀一下，就是people對應(yīng)了三個人，三個人分別是中括號間的三個花括號中的人。

總結(jié)起來，十分簡單，移動端提出需求，服務(wù)器按要求組織好數(shù)據(jù)發(fā)給你，針對不同的格式，移動端自己解析，展示，完活兒。其實，不止移動端，前端網(wǎng)頁和后臺，后臺和后臺之間也是這個道理。至于在傳輸?shù)倪^程中都經(jīng)歷了什么，我們找機會再細(xì)聊。