目前趣苏，除了一些特別簡單非聯(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ì)聊线梗。
