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

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

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

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

現(xiàn)在流行的做法通常有兩種，一種是類似于 PB（Protocol Buffer，Google 定義的一個(gè)數(shù)據(jù)傳輸協(xié)議，以簡潔，省流，易用出名）的二進(jìn)制數(shù)據(jù)（二進(jìn)制數(shù)據(jù)的意思就是你打開這個(gè)文件你只能看到 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)了三個(gè)人，三個(gè)人分別是中括號間的三個(gè)花括號中的人。

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