中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

產品經理有三大領域的技術是需要去攻克的，分別是：客戶端相關技術、服務端相關技術、交互相關技術

一、客戶端相關技術

1．iOS和安卓產品差異

1.1 應用的設備不同：

IOS和安卓最大的區別在于本身所應用的設備不同。IOS系統主要是應用在iPhone、IPad、itouch設備上的操作系統，安卓系統主要是應用在安卓智能手機上的操作系統。

1.2 面向人群不同：

IOS系統面向的是中高層收入的人群，有人稱它為“高富帥”系統，而安卓系統則是面試中低層的大眾人群，有人稱它為“屌絲系統”。

1.3系統的開放性區別：

安卓擁有自己的開源計劃AOSP(Android Open Source Project)，只要遵循GPL和Apache Licence 2.0開源協議，那么你就可以使用安卓源代碼進行二次開發。而安卓由于源代碼開放，自然可玩性也比iOS高。此外，安卓比iOS開放了更多的應用接口API，可以很自然地利用安卓實現很多在iOS上不折騰就沒法做的功能。在安卓，可以隨心隨意地更換輸入法，隨意用任何瀏覽器打開鏈接，隨意從任何途經安裝程序，隨意調用第三方程序分享文件——這些在iOS上不越獄都做不到，即使越獄也未必比安卓做得更好。

1.4系統的安全性區別：

IOS系統是一款比較強大的操作系統，在IOS系統運行的程序不管程序多大都不會造成死機，玩起來非常的流程，而且系統的安全性比較高。

安卓系統是屬于代碼系統，如果所有的應用程序需要下載下來之后才能玩，系統用久之后會經常出現卡機或者是死機的現象，而且安卓系統還存在惡意的插件在系統上自動運行，系統漏洞多，導致個人資料被盜、系統耗電大，流量消耗大等，系統安全性相對來說比較低。

1.5開發難度不同：

蘋果提供完整高效xcode,sdk等開發環境，ios系統一脈相承，ios版本之間的軟件通用，即開發一款產品蘋果所有設備都能運行。其硬件的強大也讓開發變的更加容易。

2．Web前端技術-HTML、CSS、JavaScript

• HTML、CSS、JavaScript共同構建了你看到的任何一個網頁展示和交互：
• HTML(HyperTextMarkup Language)超文本標記語言
• CSS（Cascading Style Sheets）級聯樣式表
• JavaScript一種腳本語言，主要用于前端頁面的DOM處理

文本的意思，應該大家都明白，就是你隨手在桌面上建立一個txt，這就是一個文本文件。

那什么是HTML超文本標記語言呢？超文本就是超越文本的意思唄，超越文本的意思就是它已經不僅僅是簡單的文本，比普通的txt要高級一些，那到底高級在哪里呢，是第二個詞Markup（標記的意思），就是對一個普通的txt里面的文字進行標記，標記其中的一段為title，標記另一段應該另起一行，標記任意一段為某個意思。最后超越了普通文本的標記，這些記號對普通文本的修飾，就構成了一套規則，這套規則就是html。

CSS中文名叫級聯樣式表，也是一個超別扭的名字，但是樣式大家都應該懂，就是長什么樣子，類比到生活中，就是HTML只是你的肉體，你總要穿上衣服，戴上牙套，穿雙鞋再出門吧。再舉剛才蓋房子的例子，你定義好了各個空間，并且房子也蓋起來了，你要裝修，比如客廳用什么壁紙，臥室的地板用什么樣子，CSS就是起裝修作用的，必須要和HTML一起配合使用。

JavaScript是一種腳本語言，他在網頁中使用的主要場景是控制HTML中的每一個元素，有時候可以把有些元素刪除，有時候要添加新元素，你常常遇到過這樣的場景，點了一個按鈕，這個時候會有一個網頁上從沒有過的元素出來，其實就是利用JavaScript實現的。你的房子已經裝修好，貼上了墻紙，鋪上了地板，桌子，板凳，沙發都已經擺好了，一切都完美了，可是一切都是靜態的，作為一個有生活情趣的人，你總是要買些新家具，或者想把茶幾換個位置，這個時候這種在這個屋子里的所有移動，添加，減少物件就只能靠JavaScript實現。

當前互聯網上的任何一個網頁，都是由他們三個構建起來的，雖然簡單，但你不可不知。

3．實時更新移動客戶端技術–React Native

做為一名產品經理，你是否遇到過這樣的窘境，“幫我把字體調成16號唄，顏色變成#FFFF00FF，老大說這里最好改一下”，作為一名app的開發只能無奈但心里竊喜的告訴你，“只能等下個版本了，必須要重新發布才能改”，如果你問為什么不能改了就生效啊，那說明你對技術的理解要么真的很差，要么你就是知道這項React-Native新技術所爆發出來的力量。

React Native是Facebook推出的一個用JavaScript語言就能同時編寫ios，android，以及后臺的一項技術，2015年9月發布了android版本，又在程序員里面掀起了一波小高潮，不斷有喜歡嘗鮮的程序員投入到這個領域。用大白話說，就是從此一名程序員自己就可以創業了，他只用這一門技術，就可以同時寫出androidapp，ios app，以及后臺應用程序，并且，請注意這里，它可以做到實時熱更新（就像網頁一樣，改了一個字體，隨時可上線），app也能做到隨時都能更新了，第一段講的那個需求可以分分鐘秒殺解決，不用新發版本，只需在服務器改動一下代碼即可，真的很牛逼。

4．Android應用權限

目前國內Top 100的熱門應用，來看看它們最喜歡的申請的權限是什么，以及拿到這些權限后可用做些什么事情：

網絡訪問權限

互聯網產品，當然要聯網才行啦，所以每個應用都申請了這個權限

修改或刪除外置存儲中的內容

往用戶的SDCard上隨意讀寫文件的權限。當你的手機用了一段時間后，發現SDCard上面亂糟糟的，什么奇怪的文件名都有，就是因為這個權限，每個應用都想著你手機里留下一些痕跡。其實為了存儲數據，系統給了特定的存儲空間，這并不是應用必須要用的權限。

讀取手機狀態和身份

有了這個權限，可以獲取到手機的唯一識別碼IMEI，很多應用用它來做為單一用戶的標識，沒什么可怕的。

查看WLAN連接

可以查看用戶當前的WiFi接入點信息

控制振動

這個沒什么好說，就是要讓你手機有動次達次的效果

檢索正在運行的應用

可以查看用戶當前運行了哪些應用，瞅瞅你平時喜歡用些什么應用，也可以看看競品的活躍程度:)

防止手機休眠

在鎖屏后為了降低功耗系統會進入休眠狀態，但是很多應用為了維持后臺運行，就會申請這個權限，這也是Android系統比較耗電的原因之一，都是應用希望知道用戶的位置（基于網絡），O2O這么火的年代，為了提供更個人化的服務，各路應用都希望知道用戶的當前位置。

開機啟動

要想日日夜夜的陪伴，那就得一開機就啟動，也是耗電的罪魁

相機

幫你打開相機，掃一掃二維碼，拍一拍片片

在其他應用之上顯示內容

桌面上那些飄來飄去的東西，或者你正用著一個應用，其它某個APP又突然蹦了出來蓋在上面，都是用的這個權限

精確位置（基于GPS和網絡）

三胖想定點轟炸你，就得用這個權限，獲取精確的GPS位置

安裝快捷方式

很多應用希望用戶更方便的啟動自己，都喜歡往桌面上發送一個快捷圖標，更有喪心病狂的應用，會發送多個圖標到桌面。往往新買一個手機，安裝10個應用，桌面上會出現20個以上圖標的，就是因為它

錄音

每個應用都有一個成為微信的夢想

卸載快捷方式

悄悄的將自(友)己(商)的圖標刪掉:)

讀取聯系人信息

大家都對這個權限很敏感，應用有了這個權限，就可以讀取你的通訊錄，不懷好意的應用還會偷偷上傳，哪天你收到垃圾短信也不必奇怪，也許是你的某個好基友“出賣”了你

停用屏幕鎖定

你得一直看著我，不要讓屏幕鎖定了

發送短信

有了這個權限，就可以花用戶的錢，給自己發條短信。感覺應用都沒有什么正當理由來獲取這個權限

讀取短信

查看用戶的短信，感覺這是老大哥干的事，普通應用拿來是夠惡心的

5．Android休眠狀態

（1）任何一個應用申請了wakelock鎖，待機（按：什么是待機？待機與屏幕黑、鎖屏、休眠的關系是什么？）時沒有釋放掉，系統是不會進入待機的，直到所有應用的wakelock鎖都釋放掉了，才會進入待機。

（2）如果不進行特別的設置，Android會在一定時間后屏幕變暗，在屏幕變暗后一定時間內，CPU也會休眠，大多數的程序都會停止運行，從而節省電量。

（3）Android手機有兩個處理器，一個叫Application Processor（AP），一個叫Baseband?Processor（BP）。非通話時間，BP的能耗基本上在5mA左右，而AP只要處于非休眠狀態，能耗至少在50mA以上，執行圖形運算時會更高。一般手機待機時，AP、LCD、WIFI均進入休眠狀態，這時Android中應用程序的代碼也會停止執行。Android為了確保應用程序中關鍵代碼的正確執行，提供了Wake Lock的API，使得APP可以通過之阻止AP進入休眠。但不一定必要，首先，完全沒必要擔心AP休眠會導致收不到消息推送。通訊協議棧運行于BP，一旦收到數據包（按：收到TCP數據包才會喚醒AP，UDP包不會喚醒），BP會將AP喚醒，喚醒的時間足夠AP執行代碼完成對收到的數據包的處理過程。其它的如Connectivity事件觸發時AP同樣會被喚醒。那么唯一的問題就是程序如何執行向服務器發送心跳包的邏輯。你顯然不能靠AP來做心跳計時。Android提供的Alarm Manager就是來解決這個問題的。Alarm應該是BP計時（或其它某個帶石英鐘的芯片，不太確定，但絕對不是AP），觸發時喚醒AP執行程序代碼。那么Wake Lock API有啥用呢？比如心跳包從請求到應答，比如斷線重連重新登陸這些關鍵邏輯的執行過程，就需要Wake Lock來保護（按：只在這些關鍵邏輯時，需要Wake Lock API確保不休眠）。而一旦一個關鍵邏輯執行成功，就應該立即釋放掉Wake Lock了。兩次心跳請求間隔5到10分鐘，基本不會怎么耗電。除非網絡不穩定，頻繁斷線重連，那種情況辦法不多。

（4）Android設置–> WLAN–>點擊菜單鍵選擇高級–>休眠狀態下保持WLAN連接的下拉列表{始終、僅限充電時、從不(會增加數據流量)}，如果設置不為始終，那么我們鎖屏休眠后，程序將會處于無網絡狀態，相應的app用戶會一直處于離線模式。

（5）可以設置不同的模式，讓其產生不同的休眠，比如讓cpu保持運行。

• Flag Value CPU Screen Keyboard
• PARTIAL_WAKE_LOCK On Off Off
• SCREEN_DIM_WAKE_LOCK On Dim Off
• SCREEN_BRIGHT_WAKE_LOCK On Bright Off
• FULL_WAKE_LOCK On Bright Bright

6．app推送原理

傳統的app架構里，通常是app主動向服務器請求數據，服務器被動的提供數據。以新聞客戶端app為例：app被用戶打開的時候，會通過網絡(無論3g、4g還是wifi)連接到服務器上，向服務器請求最新的新聞。服務器收到請求，從自己的數據庫里查詢最新的新聞，返回給app。app收到服務器返回的數據，經過一系列的解析處理操作，最終把最新的新聞呈現給用戶。一次通信就完成了。

然而如果此時服務器上又有了新的新聞，無論多么重要，在用戶沒有主動刷新的情況下，是沒有辦法讓用戶看到的。推送就是為了解決這樣的困境的，它給了服務器一個展示自我的機會，主動連接上所有的app，告訴他們我有新的新聞了，你們再來請求一次吧，于是收到推送的app（即時此時已經被用戶關閉了）又去服務器請求最新的新聞，這樣用戶就能看到最新的新聞了。

從技術上來講，實現一個推送系統需要服務器端和終端的配合。一種方法是輪詢，也就是不停的向服務器發起請求。這其實很好理解，作為app，我既然不知道什么時候會發生新的新聞，那我一遍一遍的問好了，而且我知道這樣一定會成功的。顯而易見，這種方法app端費時費力不說，電量流量也扛不住啊，服務器要處理如此量大的請求，必然也是非常頭疼的。

另一種方法是服務器和app建立一個長時間連接的通道，通過這個通道，不僅app可以向服務器請求數據，服務器也可以向app發送數據，看起來非常完美，但是如果app被用戶關閉的話，通道就斷掉了。好在android系統給app提供了一個這樣的環境，app可以啟動一個后臺服務來維持這個通道，即使app被關掉了，服務依然可以運行，通道依然還在工作（ios后面會講）?；氐角懊娴睦?，你在睡覺前關掉了淘寶，但是并沒有關閉淘寶的后臺服務，淘寶依然可以接收服務器推送來的指令，把自己的喚醒。

那么如何維持這樣的一條長時間連接的通道呢？就好比兩個人打電話，一開始聊的熱情有來有往，后來慢慢沉默下來了，幾分鐘之后，電話的另一頭沒有任何動靜，如何知道那邊的人還在呢？很簡單，只需要另一頭的人每隔幾分鐘說一個字就行。同樣的道理，app會每隔一段時間向服務器報告自己還活著，就像心跳一樣，服務器收到后，就知道這個通道是可以繼續使用的了。

然而天下沒有免費的午餐，發送心跳是有代價的，一般手機鎖屏之后，為了省電CPU是出于休眠狀態的，然而發送心跳就會喚醒CPU，必然會增加電量的消耗。這還只是一個長連接通道的情況，如果手機里裝了2、30個帶有推送的app呢？先別急著抱怨，聰明的android工程師和ios工程師早就想到了這一點，他們分別設計了GCM和APNS來解決多個app有多個長連接通道的問題。

以APNS為例，ios開通了一條系統級別的長連接通道，通道的一端是手機的所有app，另一端是蘋果的服務器。app的服務器如果有新的消息需要推送的話，先把消息發送到蘋果的服務器上，再利用蘋果的服務器通過長連接通道發送到用戶手機，然后通知具體的app。這樣就做到了即使手機安裝了100個app，也只需要向一條通道里發送心跳。

回到Android，系統提供的GCM只能在Android2.2以上才能使用，3.0以下必須要安裝Google play并登陸了Google賬號才能支持。而國內發行的手機大多是閹割掉了google服務的。因此，對于Android系統來說，各家app只能各顯神通，開發自己的專用長連接通道了。然而這時候他們遇到了app的天敵：管家和衛士們。

前文說了，app想要及時收到服務器推送的消息，關鍵在于自己與服務器的長連接通道不被關閉，也就是自己的后臺服務可以一直在后臺運行，而管家和衛士們的一鍵清理功能就是專治這種“毒瘤”的。道高一尺魔高一丈，app在與管家和斗士們的長期斗爭中，總結了一系列躲避被清理掉的方法，什么定時自啟能力、什么相互喚醒、什么前臺進程等等，當然這就是另一個話題了，我們后面會講到。

總結起來，app和后臺的連接方式有兩種。一種叫pull，也叫輪詢，就是定期的不斷向后臺請求，缺點是耗電，費流量，不環保。對于一名有追求的程序員，他應該會比較惡心這種方式的，你千萬不要對他說，我不管你怎么實現，我就要這種效果這種笨蛋話了，凡事應該找到最優路徑。

另一種叫push，app和后臺一直維持了一條通信通道，兩端不定期的就會偷摸的約會，告訴對方“I‘m Here”，也能順帶把信息互相攜帶了。缺點是要維持一條長連接通道，這條通道容易被其他程序殺死，要多想復活辦法。

7．應用程序、進程和線程

應用程序都是用來“應用”的，也就是我們平時所說的“打開”、“運行”某個應用程序。

在每個平臺上，應用程序都會有一個供操作系統使用的“入口”，這個“入口”就是讓系統通知應用程序“運行”的關鍵所在，也就是系統啟動應用程序的門戶。當我們點擊桌面上應用的圖標，系統就會收到一條指令：“啟動XX應用”，這時系統的應用加載器就會找到應用程序的安裝目錄，并為應用程序創建一個“進程”，進程創建后，系統就會利用“入口”把應用程序的“邏輯”和“數據”加載起來，并根據應用程序的需要為進程分配資源，如內存、cpu等，這樣，應用程序“運行”的條件就滿足了。

進程中會包含若干“線程”，這些“線程”共享進程的資源，并且按照應用程序中指定的“邏輯”完成既定的任務，如啟動閃屏，播放視頻，響應用戶的交互操作等。

8．同步和異步

有一天，你找到公司剛來的程序員小 T，跟他說：“我們要加個需求，你放下手里的事情優先支持，我會一直等你做完再離開”。小 T 微笑著答應了，眼角卻滑過一絲不易覺察的殺意。

切入正題。世界上的所有事情大致可以分為同步去做和異步去做兩種。你打電話去訂酒店，電話另一邊的工作人員需要查下他們的管理系統才能告訴你有沒有房間。這時候你有兩種選擇，一種是不掛電話一直等待，直到工作人員查到為止（可能幾分鐘也可能幾個小時，取決于他們的辦事效率），這就是同步的。另一種是工作人員問了你的聯系方式就掛斷了電話，等他們查到之后再通知你，這就是異步的，這時候你就可以干點其他事情，比如把機票也定了之類的。

同步和異步的區別就在于，在下達了執行任務的命令后，是等到執行完成之后才能得到結果呢，還是馬上就知道了結果（盡管是不確定的答案）。

計算機世界也是如此。我們寫的代碼是交給CPU去執行的，在這個過程中經常面臨是讓CPU同步執行還是異步執行的選擇。比如我寫了一個APP，它可以幫你下載網絡上的一個文件。當你輸入一個文件的網址，按下下載按鈕的一瞬間，CPU就收到了一個下載文件的任務。

我們先想象一下同步執行時什么情況。CPU立刻停掉了手頭的事情，包括繪制界面、對用戶的點擊做出響應等等，傾盡全力去幫你下載文件。但是，這時候你會發現，你的屏幕再也沒有響應了，整個系統就像死了一樣（廢話，CPU都被你的下載任務搶走了）。過幾秒鐘，如果是Android系統則會彈出一個的提示，用戶非常感動，然后無情的卸載了這個APP（尼瑪褲子都脫了，你讓我看這個）。同樣的情況異步執行要好很多。CPU馬上告訴你任務已經被受理了，等下載完成我會通知你的。于是呢，屏幕照樣刷新，用戶點擊都能做出處理，就好像沒有下載過一樣。然而CPU并沒有閑著，它開啟了一個線程，專門處理這個下載任務（還記得之前講過的線程的概念嗎？不用擔心我們下面會詳細講）。過了幾個小時下載完了，你會收到一個通知，告訴你任務執行的結果。

一般情況下計算機通過多線程來實現同步，你可以把線程看做是富土康生產iPhone的一條生產線。它給生產一臺完整的iPhone提供了所有必須的資源：包括人力，原料，設計圖紙等等。生產任務來的時候，如果是同步的，那一條生產線就夠了，所有的小伙伴們蜂擁而上，不一會兒就搞定了。如果是異步的，那就必須新建一條生產線（好在CPU創建線程的成本并不高），分一部分資源到新的生產線上，這樣可以同時生產兩臺手機。那么生產線可以無限制增加嗎？答案是不行的。一是異步會面臨資源競爭的問題。比如說8條生產線都要組裝電池，但是電池原料只有4份，那么必然會存在其他4條生產線等待的其情況，如果資源競爭比較頻繁，甚至異步的執行效率要低于同步。二是異步會導致狀態難以管理。比如車間主任想要統計一共生產了多少iPhone，就必須要詢問完所有生產線才能得出結論，而且這個詢問過程必須要停掉所有的生產線，同步來做。

講到這里，回調的概念呼之欲出。上面異步任務的整個過程是首先你要把自己的信息給異步任務執行者，等執行完成的時候，執行者可以通過這些信息找到你，并給你一個通知。把自己信息給別人的過程叫做注冊，別人找到你給你通知的過程就叫做回調。上面的例子，你把自己的聯系方式給了酒店工作人員叫做注冊，工作人員完成任務后聯系你叫做回調。但是回調的概念其實非常廣，這里可以抽象成先把要做的事情注冊給別人，等條件滿足的時候別人再回過頭來調用你的模型。程序上響應一個按鈕點擊之后要做的事情也是用回調來做的。程序員先把用戶點了按鈕要做的事情先寫好（比如要下載文件），注冊給系統。等用戶點擊到按鈕的時候，系統就會回調你下載文件的代碼。

回到前文，了解了同步、異步以及回調之后，你會這樣跟小 T 說：” 我們要加個需求，你抽時間支持下，等你做完了記得通知我?！靶?T 欣然接受，眼角閃過理解萬歲的淚光，回頭就把這事兒忘了。

9．渲染

計算機、瀏覽器、手機app的渲染道理一模一樣，你在顯示器上看到的一切也都經歷了類似的過程，大致分為三步：測量、排版、繪制。拿支付寶手機App舉例，我們進入界面之后看到了那么多按鈕或TAB，計算機是如何知道哪個按鈕該擺在何處，應該多寬多高，以及程序啟動的時候應該是呈現出什么樣子呢？

計算機里面存儲的全部是01組成的串（這些串既有程序代碼也有相應的數據），他們靜靜的躺在你的硬盤或sd卡中，當你點擊手機app上的支付寶圖標的時候，這個時候存儲設備中的代碼和數據迅速被載入內存，并加載執行。當程序運行到構造界面的時候，這個時候計算機像畫家一樣開始測量，每一個按鈕的寬高（其中是有一大堆算法或者說規則在默默的計算，比如一個按鈕在另一個上方，如何不和其他的按鈕重疊等等）。知道了多寬多高之后，計算機開始計算每一個按鈕應該擺在屏幕上的什么位置。大小、位置都明確之后，計算機開始繪制，也就是把相應的顏色或者圖片資源從CPU輸送到顯卡，顯卡把這些數據發送給顯示器的緩沖區，屏幕的下一次刷新將這些新數據更新到顯示器上，整個渲染(呈現)過程結束。

說了很多廢話，想說清楚的是，渲染是通過一些列計算并呈現的過程，其中包括測量、排版、繪制。你在任何屏幕上看到的任何一個圖形，無一例外，都經過了這三個過程。下次和程序界的朋友溝通展示慢，頓問題的時候，你可以很隨意的說句，感覺整個渲染過程不是很流暢，保證你們的交流會很得心應手。

10．QQ快的原因

（1）QQ會在用戶上傳、下載圖片等連接服務器操作時，結合其網絡情況選擇周邊最快的服務器；

（2）QQ會對用戶每天使用的網絡進行記錄和分析，預測出用戶在哪個時段可能用哪個網絡（如3G/4G/WIFI），并在相應時段自動連接相應情況下最優的服務器；

（3）圖片下載優化：

1. 漸進傳輸：先傳輸圖片部分數據和像素模糊顯示，后續再將剩余數據和像素傳輸完成從而清晰顯示;
2. 圖片轉碼：同等圖片質量下圖片更小的編碼技術；
3. 圖片適配：較慢網絡如2G或較低像素終端情況下，下載較低質量但更小的圖片，前者為提高速度，后者為節省流量；
4. 預加載：為方便用戶快速打開而預加載一些大圖，可通過銀行家算法加以控制，用戶看了的話就加載對了，沒看的話就說明無效加載了，累計的無效加載到一定閥值就不再進行預加載。

11．圖片資源處理

相信廣大的產品經理同學肯定希望自己的產品UI能夠美美的，讓用戶們賞心悅目。要做到這一點，主要就靠咱們偉大的視覺設計師出的各種圖片資源。小到應用程序的圖標或者按鈕，大到啟動時的閃屏，無不是出自設計師之手。當圖片被打包到程序中后，他們就被正式的賦予了為廣大用戶謀眼福的使命。

然而，圖片的大小是固定的，而使用圖片的設備分辨率卻千變萬化。比如一張1280×720分辨率的全屏閃屏圖片，可能會被加載到1080P、720P、480P甚至320P的設備上，除了720P的設備外，在其他三款設備上1280×720的圖片都會產生“縮放”。我們都知道，圖片的內容都是由像素組成的，比如1280×720的圖片由921,600個像素構成，720P的顯示設備屏幕上也正好是921,600個像素，這樣圖片的每一個點都可以與屏幕上的點一一對應，進而完美的呈現圖片的細節。480P乃至320P的設備，他們屏幕上的像素點個數遠遠小于921,600(480P設備38萬個像素點，320P設備15萬個像素點)，屏幕上的像素無法做到與1280×720圖片像素的一一對應，這種情況下，為了讓低像素數的屏幕能夠完全呈現高像素數圖片的內容，圖片的一些細節（像素）就會被丟棄，以480P的設備為例，1280×720的圖片就會被顯示成800×480個像素，圖片看起來被“縮小”了，也就是系統對圖片進行了“縮放”。這種“尺寸”（分辨率）從大到小的縮放會丟失一些細節。

當1280×720的圖片被加載到1080P（207萬像素）時，情況就更糟了。我們期望自己的圖片可以占滿用戶的屏幕，但是即便把圖片中的每一個像素都一一對應的填充到屏幕上，還是會有一半的像素沒有內容，這種效果大家可以想象。不過好在聰明的軟件工程師們早就實現了一系列的方法來讓大家避免陷入這種圖片被“放大”或“縮小”后圖片質量變差的窘境，這些方法被叫做“插值算法”。

顧名思義，“插值算法”就是在原有的像素值基礎上，插入或修改一些像素值，并盡最大可能保證原圖的特征。當前比較流行的插值算法主要有“鄰近插值”和“雙線性插值”，具體的算法這里不再冗述，感興趣的同學可以在網上隨處搜到。

通過上面兩段的描述，我們可以看到，當圖片的內容無法與屏幕上的像素點進行一一對應的時候，就會產生“縮放”，雖然當前有一些手段可以盡量的避免縮放對圖片質量造成的影響，但顯示效果或多或少都會收到影響，并且縮放的程度越大，效果損失的越嚴重。所以有的系

統會提供另外的機制盡量避免“縮放”的產生，或者把“縮放”帶來的副作用降低到最小。比如安卓系統就為應用程序的圖片資源定義了一組文件夾，每個文件夾對應一種屏幕的像素密度/分辨率，在不同像素密度/分辨率的設備上從對應的文件夾中取圖片資源，盡量的減少或避免“縮放”，進而最大化的還原設計師們的原始設計。

12．Cookie和廣告聯盟

相信大家都有相同的經歷，在瀏覽網頁的時候，有的廣告竟然知道我近期搜索過的關鍵詞，也有一些廣告竟然知道我近期要買的東西。那到底是什么東西悄悄的把我們的信息出賣了呢？答案就是本文的主角：Cookie。

之前的文章講過我們瀏覽一個網頁的時候，瀏覽器在做什么事情。它不斷的向服務器請求數據，服務器不斷的回答數據。但是這個過程有個缺點，就是每次請求都是獨立的，服務器并不會記下客戶端的信息。打個比方說，你每天都去樓下馬大姐那里吃烤串兒，但是馬大姐記性不好，你一走她就不認識你了。這時候你就想，如果我每次去吃烤串的時候，主動給馬大姐提供一些自己的身份信息，說不定還能打個折呢。這個身份信息，在技術上就叫做Cookie。

Cookie是瀏覽器每次向網站服務器請求數據的時候，攜帶的一些額外信息，這些信息一般非常少（最多4KB），主要就是為了解決服務器記性不好的問題。當然Cookie究竟需要攜帶什么信息，其實是由服務器決定的，比如你登錄了新浪微博之后，服務器就會要求瀏覽器把你的賬號寫到Cookie里，下次你請求你的關注列表，瀏覽器就會帶上這個Cookie，一起發送到服務器，這樣服務器就會知道你是誰了。

Cookie每個網站都會有很多，但它們是隔離開的。也就是說，百度只能訪問到百度存在瀏覽器的Cookie，微博只能訪問到微博存在瀏覽器的Cookie，百度是拿不到微博的Cookie的，這一點由瀏覽器保證。

現在我們來看下開頭廣告的事情。我們的搜索關鍵詞被百度保存在了瀏覽器的Cookie里，但是這個廣告是出現在一個博客網站上的，按上文的理論，這個博客網站只能訪問到它自己存在我們瀏覽器的Cookie，為什么能訪問到百度的Cookie呢？這時我不禁想起程序界有一位祖師爺的教訓：你所有的痛苦和困惑，都可以從源代碼里找到答案（read the?fucking source code）。小弟看了下這個頁面源碼后，發現廣告其實是博客網站的程序員從百度那里拿了一段代碼放到自己的頁面上，用戶在請求廣告圖片的時候，還是去百度請求的，自然百度也就能拿到帶著搜索關鍵詞的Cookie了。拿到Cookie的百度就可以根據關鍵詞匹配他們的廣告推薦給你，這種廣告因為推送的都是用戶感興趣的內容，殺傷力特別大，被稱為精準廣告。

成千上萬的網站加入了搜索引擎的廣告聯盟，這樣你在瀏覽其他網站的時候，都會看到帶有自己關鍵詞的廣告，哪天你搜索了一些不想讓人知道的東西，嘿嘿，這些廣告就會跳出來出賣你。

13．動畫原理

我們先來說幾個簡單的概念。動畫過程中的某一張靜止畫面叫做一幀(Frame)，一個動畫每秒鐘播放的幀數叫做幀率(單位是FPS)，一般來說當幀率達到30幀每秒的時候，人們就會覺得這個動畫很連貫了，當幀率達到60幀每秒的時候，這個動畫就會非常流暢了。像下面這個點擊按鈕彈出菜單的動畫，要達到每秒鐘60幀的幀率流暢運行，每一幀要花多久來展示呢？如果我沒算錯的話，應該是16毫秒左右。

16毫秒，也就是留給是你的手機渲染一幀的時間。還記得我們之前講過的渲染的概念嗎？在這16毫秒期間，你需要為屏幕上的所有圖片、按鈕、文字測量好大小，排布好位置，然后交給顯卡繪制出來。現在手機配置越來越強大，但是屏幕分辨率也越來越大。分辨率越大意味著每一幀要畫的像素越多，CPU和顯卡的負擔也越重。這時候萬一哪個2B程序員插了一段從網絡上同步下載蒼老師.avi的代碼進去，導致每一幀繪制都需要100多毫秒，這時候用戶就會看到動畫一卡一卡的，這個用戶多半是要流失了。

那么從技術上來講如何實現一個動畫呢？這里需要操作系統提供三個東西，一個是刷新屏幕的命令，我們假設叫refresh，我們的程序發出了這個命令后，手機就會刷新一次屏幕。另一個是繪制圖形的命令，假設叫drawFrame，這個是一個代表，具體可以是drawCircle(在屏幕上畫個圓圈)、drawRect(畫個長方形)、drawText(畫一段文字)等等。最后一個是定時器，假設叫scheduleNextFrame，它的作用是告訴操作系統下一幀的時間。

假設我們要繪制一個500毫秒的動畫，它展示一個圓放大30倍的動畫過程。程序員會這樣

• 寫程序：
• 動畫開始：
• 第一幀:drawCircle(1倍)—>refresh—>scheduleNextFrame
• 第二幀: drawCircle(2倍)—>refresh—>scheduleNextFrame
• 第三幀: drawCircle(3倍)—>refresh—>scheduleNextFrame
• …
• 第30幀: drawCircle(30倍)—>refresh
• 動畫結束。

這種動畫實現起來非常簡單，iOS和Android都內置了幾種常見動畫類型，如縮放、平移、漸變、旋轉等等。程序員只需要設置好動畫時長(前面的500毫秒),動畫中要變化的東西(前面放大多少倍)，然后發出start的命令就可以了。

還有一種動畫叫有交互的動畫。它由用戶手指的操作觸發刷新屏幕，一個典型的場景是我們滑動朋友圈列表的時候，列表之所以跟著手指動，就是因為手指的移動觸發了屏幕的刷新。這個場景延伸出去就是游戲了，游戲的界面刷新也是由用戶控制的。從實現成本上來說，程序要要實現一個沒有交互的動畫很簡單的，如果動畫不是特別復雜，基本上從設計師那里拿到資源和設計稿，就可以大概做出個雛形。有交互的動畫因為要處理用戶手指的觸摸事件，會稍微麻煩一點，但基本原理都是相通的。

二、服務端相關

1. 302狀態碼

在互聯網世界里面，已經存在數億量級的網頁，如何管理及標識每一個網頁以及方便瀏覽器尋址到此網頁并展示呢？其中，每個網頁都對應著一個URL（Uniform?ResourceLocation）地址，也叫網址，類似于一個真實世界中的門牌地址一樣，真實世界中標識了物理地址（如北京市朝陽區某小區張大媽家的門牌號）。同樣道理，網址標識了一個web頁面所在的互聯網里面的真實地址（這個頁面處于www.baidu.com/file/1.html,處于baidu服務器file路徑下的1這個文件）。

當你用瀏覽器點擊一個頁面鏈接的時候，隨即你看到了一個新的網頁展示在瀏覽器內，在這個過程中，瀏覽器其實是在不斷的接收服務器端的應答（這個應答是服務器端的狀態，所以返回碼叫狀態碼），從而來決策下一步來做什么（盡管大部分情況下，你毫無感知的就打開了你想要的頁面），這個應答即狀態碼（status code），在http協議里面，以三位數標識，共分為五類：分別為1××，2××，3××，4××，5××。一些常用狀態碼如下所示：

301和302表示重定向，301表示這個網頁已經永久的由服務器的A路徑下移動到路徑B下，而302表示臨時移動到B路徑下，對應到Url地址也即http://baidu.com/file/A/1.html到http://baidu.com/file/B/1.html，當瀏覽器訪問前面一個地址的時候，這個時候服務器會告知瀏覽器，請到B路徑下獲取這個文件，隨后瀏覽器重新發起網絡請求，請求B路徑下的頁面，經過渲染，呈現給用戶，例如淘寶的例子，請求taobao.com，收到302，從而瀏覽器再次請求www.taobao.com獲得頁面內容。

2.升級及下載加速原理

升級檢測和升級方式

動檢測或者用戶點擊檢查更新以后，會像云端檢索最新的版本號，md5等等。然后與本地的版本號核對。若一致，則告訴用戶”您正在使用的是最新版本“若不一致，就下載最新版本。這兒分兩種。

一種是全部下載。換句話說就和你當初安裝這個軟件出不多，只是下載那步他幫你完成了。數據也得到了保留。

一種是增量升級。其實增量升級的原理很簡單，即首先將應用的舊版本Apk與新版本Apk做差分，得到更新的部分的補丁，例如舊版本的APK有5M，新版的有8M，更新的部分則可能只有3M左右(這里需要說明的是，得到的差分包大小并不是簡單的相減，因為其實需要包含一些上下文相關的東西)，使用差分升級的好處顯而易見，那么你不需要下載完整的8M文件，只需要下載更新部分就可以，而更新部分可能只有3、4M，可以很大程度上減少流量的損失。

增量更新原因

增量更新對于版本更新不是很頻繁的軟件來說還可以，但對于更新較頻繁的軟件，使用增量更新每更新一次工作量都會很大，因為你需要考慮各個版本升級到最新版本的兼容性問題。比如一個APP有V1.0、V1.1、V1.2、V1.3、V1.4、V1.5幾個版本，現在有V2.0需要發布，如果做增量升級的話需要做之前每個版本升級到V2.0的差分包，因為你不能保證用戶手中的APP都是V1.5版本，這對于測試驗證來說工作量太大了，并且管理起來也很麻煩。

升級離線下載原理

假如，你現在要下載QQ，普通下載，使用普通下載（瀏覽器），只能從騰訊服務器下載，并且只有一條下載路徑。就好比上學的時候缺錢，只能從老爸手上要錢。如果你使用迅雷下載，就有機會同時獲得以下幾種加速方式：

多線程下載（免費）

依舊只能從騰訊服務器下載，但是能夠獲得多條下載路徑，提升下載速度。

偶然知道生活拮據，姑姑伯伯舅舅開始偷偷塞錢給你，你手中的現金開始富余。

P2S下載（免費）

P2S＝Point to Server點對服務器

除了多線程下載之外，迅雷支持從全網的其他有QQ軟件的服務器下載，比如金山服務器等等，提升下載速度。

后來你認識了富二代的朋友，他們時不時請你吃飯，給你買單，你幾乎不用從老爸（原始地址）那里要錢了。

P2P下載（免費）

p2p＝Peer to Peer點對點

有了多線程和P2S加速之后，當其他用戶同時在下載QQ時，你也可以直接從對方PC下載，而不用經過服務器。（目前手機暫不支持P2P）

再后來，你有能力了，開始計劃創業了，幾個天使投資人對你感興趣，給你投資，你再也不用找家里人要錢。

會員高速CDN下載（迅雷會員）

CDN＝Content Delivery Network內容分發網絡

通過購買服務器，迅雷在用戶下載的同時，把文件快速下載到迅雷服務器（強大的帶寬和網速），用戶再從距離最近的迅雷服務器進行下載（從迅雷服務器到迅雷客戶端的下載速度極快）。

然后你公司慢慢做大做強，幾個大型的投資機構，如日本軟銀、紅杉資本又給你注入了資金，你已經向高富帥邁進了！

DCDN加速（迅雷會員）

DCDN＝CDN 2.0

用戶通過協議之后，迅雷會把相關資源片段存儲在用戶PC，把每一臺PC都當成服務器，其他用戶下載QQ時，可以獲得極快下載速度。在此過程中，迅雷須向提供存儲空間的用戶付費，作為對用戶的一種補償。

最后，突然發現巴菲特是你失散多年的干爹！于是，化身高富帥，贏取白富美，你登上了人生巔峰！！！

以上是迅雷加速的幾種原理，用戶能夠獲得遠遠高于原始下載的速度，這也是迅雷下載如此迅速的原因。

3.代理服務器

代理就是代為處理的意思，現實生活中有很多事情我們不想自己親自動手，就花點錢找個代理擺平，說的就是這個意思。這年頭，各種各樣的代理都有。你看到別人名片上寫著阿迪王北京總代理，就應該知道他是替阿迪王公司賣鞋的；看到有人喜當爹了，就應該知道他是在替別人的孩子當爸爸。他們有個共同特點，就是代理和本人干的是一樣的事情，外人很難分辨出來。

切入正題，今天我們要講的代理服務器，是指在我們上網的過程中訪問某個服務器的時候，并不是親自訪問真正的服務器，而是先找了一個代理，由它向真正的服務器發出請求。到這里各位看官應該明白了，代理服務器架在客戶端和真正服務器中間，干的是替客戶端訪問真正服務器的工作。

那么這里有人要說了，不對啊，小學語文老師教過我們兩點之間線段最短，為什么你們不直接去真正服務器拿數據，還要到代理服務器里繞個路呢？這里可能有幾種情況：一是真正的服務器藏于千里之外，我們連接不上。二是我們訪問真正的服務器的速度太慢，比不上我們訪問代理服務器+代理服務器訪問真正服務器的速度。還有一種情況，就是通過代理服務器訪問真正服務器可以隱藏訪問者的身份，保護訪問者。同理，我們在網絡世界中一定要懂得保護自己，一次看似不經意的瀏覽，背后可能有好多雙眼睛在盯著你。他們可以通過各種途徑查到你的IP地址，然后上門找到你。所以請記住一句話，代理用的好，不怕查水表。

光說理論太枯燥，我們看幾個例子。下面的截圖是我們通過百度搜索點開了一個網站，上面提示“原網頁已由百度轉碼，已方便在移動設備上查看”。也就是說，這時候我們訪問的并不是這個網站真正的服務器，而是百度提供的代理服務器。這個代理服務器把真正服務器的內容返回給我們的時候，把原網頁的內容改成了現在這個樣子，“順便”還插入了自己的廣告（下方紅框）。

現在很多手機瀏覽器都有省流加速功能，其實就是通過代理服務器來達到節省流量的目的。假如我要訪問的原網頁A需要800K的流量，但是我開啟了省流加速功能后，瀏覽器會幫我自動連接上A的代理服務器B，B從A拿到真正的數據后，進行一些數據的壓縮操作，那么我再訪問代理服務器B的時候，可能只需要100K就可以瀏覽網頁A的內容了。

4.輕量級虛擬機–DOCKER

軟件開發中需要面對的一個挑戰就是環境管理問題，因為軟件并不是獨立運行的，它依賴了很多其它的軟件，包括操作系統、運行時、依賴庫等等，而且對每個依賴軟件還有版本要求，有一個依賴關系稍微不對，那就可能造成軟件的運行異常。產品同學應該有過這種經歷，從開發哥那里要一個最新版的軟件來體驗功能，結果裝在自己的電腦上打開就掛掉，這個時候找開發哥來解決，開發哥一看就會說“哦，你這環境不對，換個Win8吧，這軟件只能在Win8以上運行”，或者說“這個軟件需要.Net框架，你裝個.Net就好了”。

其實解決依賴環境的辦法很簡單，那就是所有機器都用同一套環境。但是對于一些web服務，它所依賴的軟件及關聯軟件可能有上百個，讓你去配一臺機器已經要吐血了，如果讓你把這個服務發布到100臺不同的機器上，那么你就應該會陣亡了。同時，很有可能因為不同的機器已有的環境不同，你安裝這些依賴的同時還要保證不能影響其它已有應用。

說了這么多，其實就是三個大問題，如何解決環境依賴？如何解決大規模部署？如何解決應用與應用的互相影響？Docker就是這些問題的一種解決方案，它是一個容器，也可以說是一個軟件集裝箱，這個箱子里面可以塞入特定版本的操作系統、數據庫、服務器程序和web應用，這樣一套完整的web服務就集成在這個箱子里面了，當要發布服務的時候，直接將這個集裝箱放在我們的服務器船上。如果你想發布到100臺機器上，沒問題，只需要ctrl-c、ctrl-v，將這些集裝箱復制到100臺機器上，它不會在乎船的配置高低，只要能放得下就行。

如果你想發布10個不同的服務，還是沒問題，你只需將這10個不同的集裝箱依次排列在服務器船上，它們之間完全不會互相影響，因為各自被鎖在不同的箱子里。

有的同學可能會說了，這不就是虛擬機嘛…是的，Docker算是一種輕量級的虛擬機，它比起傳統的虛擬機更快，更節省資源。打個比方，虛擬機就是輪船上的豪華包間，即使它用不了這么多資源，它也霸占著不讓別人使用，而Docker容器就是一個簡單的集裝箱，它只占據它需要的資源。

三、交互相關

1.網頁與原生App如何交互

想想平時用的 App，你非常確信在瀏覽一個網頁，然而需要登錄時，它卻喚起了你手機里的 QQ 或是微信，你不再需要輸入帳號和密碼就可以讓你瀏覽的網頁獲取你的登錄信息，這一切只發生在你指尖的兩次點擊。

而在手機上，網頁越來越炫酷，你都很難區分你在點擊的是一個原生界面（指 Native 應用程序，說人話就是 android app 或 ios 應用）或僅僅是一個 H5 頁面。你的操作一直穿梭在網頁與原生界面之間，比如一個網頁中的電話號碼，點擊就可以撥打電話，這種網頁和 app 交互這一切是如何實現的呢？

這項能力在安卓中叫做Js2Java（ios上也提供類似的技術），很好理解，從Js到Java，從網頁到app，他們是雙向通信，可互相調用的，市面上大量的App程序，都在利用這項技術，微信更是本質上利用這項技術打造了公眾帳號整個體系，使得創業者用一個簡簡單單的網頁就打通了帳號、身份、支付、客服、售后等一系列操作，雖然簡單，但是真的將移動互聯網的Web生態囊括了更廣闊的內容，也是移動互聯網較PC互聯網更優越、更猛烈的點之一。

以Android系統為例，Android手機上的App是使用Java語言編寫的，而網頁中則運行著一些Html、Javascript編寫的代碼。Android的App是通過WebView（請親理解成一個組件，想象WebView就是一個沒有任何操作按鈕的瀏覽器，你輸入baidu.com他就打開了百度的頁面）來展示一個網頁的，同時WebView為網頁和原生App建立一個橋梁，讓網頁和原生App能夠看到彼此暴露的一些方法，從而達到互相操作的目的。

當然，這些操作是需要前端頁面和終端程序互相協商的。雖然很多App遵守了一些相同的原則，使網頁在不同的APP中都能具備相同的能力，但是如果你看到同一個網頁在一個App中能夠調用一些安卓系統的能力，而在另一個APP中卻沒有對應的能力也不要覺得奇怪（找對應App的開發勾兌一下就好了）。

一個原生應用為網頁開放的能力越多，網頁對原生系統的操作能力就越強，就越能做出逼近原生應用的體驗。但是，這卻是一把雙刃劍，因為原生App開放的能力有可能會被惡意的頁面利用，對用戶造成傷害，如何控制能力的開放，也是需要產品和開發一起思考的問題。

例如微信是一個終端能力的宿主，擁有支付，登錄，分享，獲取App信息等能力，并以Js接口的形式提供給前端頁面使用，前端開發則需要在微信申請對應的Js接口使用權限，才能夠在微信中正常使用對應的能力。

最后總結一下，網頁塑造界面的優勢在于靈活，隨時可以更新，而原生APP塑造的界面則能夠提供更流暢的用戶體驗，但是卻無法熱更新，只能依靠發布版本來提供新功能。通過上面說的這種技術，就可以利用各自的優勢，規避各自的劣勢來提供更好用戶體驗，例如在微信中購物的展示是網頁形式的，方便運營快速更新，通過Js接口調用起原生的支付界面，給用戶更流暢的支付體驗，提高支付成功率。

2.應用下載劫持

其實一次網絡下載的過程，就像一次“網購”，當我們點擊下載按鈕時，就跟下載服務器下了一份“訂單”，“訂購”了一個文件（當然大部分是免費的），服務器確認“訂單”后，就會將文件在網絡中“快遞”（傳輸）到用戶的終端（手機、PC等）。下載劫持一般出現在“下訂單”的過程中。

舉個栗子，假設我們通過微信官網的鏈接下載微信安卓版本的客戶端。鏈接地址為：http://dldir1.qq.com/weixin/android/weixin637android660.apk，整個流程大概是這個樣子：

當點擊了下載按鈕后，客戶端會通過url中的“域名”“dldir1.qq.com”來向DNS服務器獲取確認“訂單（下載）服務器”的IP地址，IP地址在互聯網中相當于日常生活中“電話號碼”，有了它，就可以連接到這臺“訂單（下載）服務器”，而DNS服務器就像一個存貯著大量“姓名”（域名）和“電話號碼”（IP地址）的黃頁。當客戶端獲得了“訂單（下載）服務器”的“電話號碼”（ip地址）后，就會連接“訂單（下載）服務器”，并告知“訂單（下載）服務器”客戶端需要獲取服務器上的“微信安卓版”apk文件，一般情況下，服務器在這個階段確認了“訂單”后，就會向客戶端“快遞”（傳輸）對應的apk文件，當客戶端將文件下載完畢后，這次“網購”也就完成了。

下面，我們引入運營商（電信、聯通等）網關的概念。運營商網關可以類比成日常生活中的“總機”，接入運營商的互聯網設備想要能夠“上網”，都需要經過“總機”（運營商網關）的轉接。也就是說，在上圖中的第二步，我們并不能直接通過“訂單（下載）服務器”的“電話號碼”（IP地址）聯系到“訂單（下載）服務器”，而是需要先連接到“總機”（網關），并且告訴它，我們要向某某某服務器下“訂單”，經過“總機”的轉接，我們才能真正連接到“訂單（下載）服務器”。整個過程如下圖：

可以發現，DNS服務器和網關的決策，確定了客戶端“訂單”（下載請求）的走向。而“下載劫持”也就發生在這兩個關鍵節點上。

假設客戶端獲取下載服務器“電話號碼”的DNS服務器被篡改，那么客戶端可能會通過“dldir1.qq.com”查詢到一個“騙子服務器”的“電話號碼”（IP地址），當我們聯系到這個“騙子服務器”時，我們的“訂單”（下載請求）可能會換來一些奇奇怪怪的“商品”。

當我們遇到這種情況時，可以手動修改DNS服務器IP（具體方法請問度娘）來解決。然而當運營商的“總機”（網關）“出了問題”（這些“問題”一般是運營商主動造成的）時，就沒那么容易解決了。假設當客戶端拿著“訂單（下載）服務器”的電話號碼要求“總機”（網關）轉接到我們指定的“訂單（下載）服務器”時，“總機”（網關）對客戶端說“哎呀，不要去A家下載微信了，你去我給你介紹的B家下載“XX助手”吧，比微信好用”（這個過程在技術上是被一個叫做302跳轉的機制完成的，如果你不知道什么是302，出門左轉，查詢我們星期一的文章）?？蛻舳耸莻€實在人，就這樣被“引誘”到B家的服務器上下載了。

“總機”（網關）和服務器B就這樣沆瀣一氣，來騙客戶端的下載量。

3.前端和后臺的數據交互與協議

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

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

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

那客戶端和服務器之間傳輸數據的格式是怎么樣的呢？

現在流行的做法通常有兩種，一種是類似于PB（Protocol?Buffer，Google定義的一個數據傳輸協議，以簡潔，省流，易用出名）的二進制數據（二進制數據的意思就是你打開這個文件你只能看到0和1組成的數字串，是沒辦法和你生活中任何認識的字母聯系在一起的）傳輸，這種格式的好處是包小，重復的字段會被節省。

另一種是JSON（JavaScriptObject?Notation），這也是一種輕量級的數據傳輸格式，就是用一堆中括號把數據組織起來，不像二進制，這種格式是人可讀的，并且比較輕巧，所以也有大量的應用場景。下面這段數據就是JSON格式，簡單解讀一下，就是people對應了三個人，三個人分別是中括號間的三個花括號中的人。

總結起來，十分簡單，移動端提出需求，服務器按要求組織好數據發給你，針對不同的格式，移動端自己解析，展示，完活兒。其實，不止移動端，前端網頁和后臺，后臺和后臺之間也是這個道理。

#專欄作家#

給產品經理講技術，微信公眾號（pm_teacher），人人都是產品經理專欄作家。資深程序猿，專注客戶端開發若干年，對前端、后臺技術略懂，熱衷于對新的科技領域的探索。

本文原創發布于人人都是產品經理，未經許可，不得轉載。