APP運(yùn)行緩慢與人們需求斷層

作為IT類媒體人士，筆者特別調(diào)研了一些數(shù)據(jù)，發(fā)現(xiàn)APP緩慢運(yùn)行的現(xiàn)象較為普遍，并嚴(yán)重影響到人們的使用：

79%的移動(dòng)APP用戶在使用APP的第一次出現(xiàn)問題后，只會(huì)額外再嘗試1到兩次;

78%的移動(dòng)APP用戶期望著使用移動(dòng)APP的速度會(huì)快于訪問移動(dòng)網(wǎng)站的速度;

61%的移動(dòng)APP用戶能接受最多4秒鐘的load等待時(shí)間;

49%的移動(dòng)APP用戶期待APP能在兩秒內(nèi)給出響應(yīng)。

APP運(yùn)行緩慢的原因分析：移動(dòng)最后一英里

筆者就是那種只能接受最多4秒鐘的load等待時(shí)間，并期待APP能在兩秒內(nèi)給出響應(yīng)的用戶之一，盡管要求較高，但移動(dòng)網(wǎng)絡(luò)有自己的特征：比如容易出現(xiàn)連接頻繁中斷、傳輸失敗與丟包等問題，這是相比較網(wǎng)絡(luò)寬帶出現(xiàn)的新問題。

實(shí)際上，無線網(wǎng)絡(luò)傳輸給移動(dòng)應(yīng)用的速度和可靠性帶來了新的挑戰(zhàn)。有數(shù)據(jù)表明：“移動(dòng)最后一英里”占移動(dòng)應(yīng)用總延遲(往返時(shí)間)的70%。最主要的表現(xiàn)是會(huì)話中斷與移動(dòng)延遲。

會(huì)話中斷：間歇性移動(dòng)連接是移動(dòng)應(yīng)用程序必須處理的事實(shí)。在會(huì)話期間中斷要求應(yīng)用程序重復(fù)操作，減慢對(duì)用戶請(qǐng)求的響應(yīng)速度。

移動(dòng)延遲：由于必須通過蜂窩和WiFi網(wǎng)絡(luò)到達(dá)公共互聯(lián)網(wǎng)，移動(dòng)應(yīng)用程序不得不面對(duì)一個(gè)額外延遲層。由移動(dòng)網(wǎng)絡(luò)導(dǎo)致的額外往返使應(yīng)用程序崩潰，進(jìn)而無響應(yīng)。

由于“移動(dòng)網(wǎng)絡(luò)最后一公里占據(jù)了整體時(shí)延的70%”，并且伴有大量的連接中斷和數(shù)據(jù)包丟失。因此，會(huì)話阻斷間歇性中斷的移動(dòng)網(wǎng)絡(luò)狀況這個(gè)事實(shí)是所有移動(dòng)App都需要面對(duì)的并需要設(shè)法解決的。這樣的中斷問題體現(xiàn)在靜態(tài)內(nèi)容分發(fā)上表現(xiàn)為速度緩慢，體現(xiàn)在API 調(diào)用這類動(dòng)態(tài)應(yīng)用上則為失敗。移動(dòng)網(wǎng)絡(luò)時(shí)延移動(dòng)App不得不接受由于蜂窩網(wǎng)絡(luò)、WiFi網(wǎng)絡(luò)引入的額外的時(shí)延，以及由于切換移動(dòng)網(wǎng)絡(luò)基站帶來的額外的Round Trip時(shí)間。

如何解決上述問題?這是筆者非常期望能解開的迷題。

解開移動(dòng)應(yīng)用加速的技術(shù)迷題

筆者近日在藍(lán)汛(ChinaCache)與美國(guó)公司PacketZoom達(dá)成戰(zhàn)略合作的一次媒體發(fā)布會(huì)上，采訪到了PacketZoom首席執(zhí)行官ShlomiGian先生，并得到了關(guān)于移動(dòng)應(yīng)用加速的答案。

上圖為：PacketZoom首席執(zhí)行官ShlomiGian

hlomiGian說：“PacketZoom解決移動(dòng)應(yīng)用加速問題的方法是：將軟件開發(fā)包(SDK)嵌入到 APP 時(shí)會(huì)使用到PacketZoom提供的 App id 和API 密匙，當(dāng)打開嵌入了PacketZoom軟件開發(fā)包(SDK)的 APP 時(shí)，軟件開發(fā)包(SDK) 會(huì)連接到分布在全球的 PacketZoom 服務(wù)器。在得到PacketZoom某一臺(tái)服務(wù)器發(fā)送的確認(rèn)之后，APP 中嵌入的 PacketZoom SDK 才會(huì)開始運(yùn)行，與此同時(shí)軟件開發(fā)包(SDK)開始代理并加速此 APP 的請(qǐng)求。“

而當(dāng) SDK 代理請(qǐng)求時(shí)，它會(huì)根據(jù) PacketZoom 控制面板中客戶設(shè)定的匹配規(guī)則(正則表達(dá)式)進(jìn)行匹配，并將匹配條件的請(qǐng)求發(fā)送到 PacketZoom ，或根據(jù)設(shè)定的匹配規(guī)則的結(jié)果使用 APP 默認(rèn)行為。PacketZoom接收到請(qǐng)求后，會(huì)將請(qǐng)求轉(zhuǎn)發(fā)到離用戶端最近的一臺(tái)PacketZoom服務(wù)器上并從這里開始對(duì)客戶的加速服務(wù)。于此同時(shí)，PacketZoom服務(wù)器會(huì)查看服務(wù)器本地是否有對(duì)應(yīng)的緩存數(shù)據(jù)，如果沒有則去客戶源站獲取到內(nèi)容后返回給客戶。Response 的數(shù)據(jù)將使用PacketZoom的協(xié)議被送到對(duì)應(yīng)的客戶端設(shè)備，不管數(shù)據(jù)是來自于服務(wù)器緩存還是源站。

PacketZoom 協(xié)議發(fā)送數(shù)據(jù)的速率由PacketZoom發(fā)送算法所決定。算法會(huì)根據(jù)網(wǎng)絡(luò)類型，地點(diǎn)，終端設(shè)備類型等因素來決定發(fā)送多少數(shù)據(jù)及以哪種速率發(fā)送到客戶端。在數(shù)據(jù)發(fā)送給客戶終端的同時(shí)，SDK 會(huì)周期性發(fā)送確認(rèn)信號(hào)，這些確認(rèn)會(huì)用來優(yōu)化發(fā)送速率，并通知服務(wù)器哪些數(shù)據(jù)包需要重傳。服務(wù)器持續(xù)優(yōu)化發(fā)送速率，以盡可能快地發(fā)送最多的數(shù)據(jù)，同時(shí)避免發(fā)送超過網(wǎng)絡(luò)所能處理能力的數(shù)據(jù)量。

ShlomiGian強(qiáng)調(diào)：“在這些功能當(dāng)中有些是 HTTP/TCP 已經(jīng)內(nèi)置的，但和PacketZoom 的存在明顯的差異。比如， TCP 也會(huì)發(fā)送確認(rèn)來通知服務(wù)器哪些數(shù)據(jù)包已收到。如果服務(wù)器已發(fā)送數(shù)據(jù)包 100-150，接收端沒有確認(rèn)收到包 110，TCP 會(huì)重新發(fā)送數(shù)據(jù)包 110-150。同樣的情況，PacketZoom只會(huì)重傳數(shù)據(jù)包 110，并在數(shù)據(jù)包 150 的位置繼續(xù)傳送數(shù)據(jù)。TCP 數(shù)據(jù)包沒有優(yōu)化 TCP 發(fā)送速率，它只是盲目發(fā)送數(shù)據(jù)，加倍傳送速率直到有丟包發(fā)生。移動(dòng)網(wǎng)絡(luò)繼承了這個(gè)特性，但反映出來的是移動(dòng)網(wǎng)絡(luò)的網(wǎng)絡(luò)擁塞。”

移動(dòng)應(yīng)用加速在中國(guó)

據(jù)筆者了解，基于PacketZoom在移動(dòng)應(yīng)用加速方面的能力，中國(guó)專業(yè)的互聯(lián)網(wǎng)內(nèi)容傳輸整體解決方案提供商藍(lán)汛ChinaCache近日與PacketZoom簽署了獨(dú)家合作協(xié)議。根據(jù)合作協(xié)議，藍(lán)汛ChinaCache享有中國(guó)建立適用于移動(dòng)設(shè)備的Packet Zoom Expresslanes™傳輸基礎(chǔ)架構(gòu)的專有權(quán)利，目的在于加速和提高中國(guó)移動(dòng)應(yīng)用內(nèi)容傳輸?shù)目煽啃浴?/p>

藍(lán)汛ChinaCache與PacketZoom合作后，中國(guó)的客戶也將享受到移動(dòng)加速的便捷服務(wù)，并得到移動(dòng)應(yīng)用的極大優(yōu)化：

移動(dòng)吞吐效率優(yōu)化：實(shí)現(xiàn)相對(duì)傳統(tǒng)Web協(xié)議的更高效的傳輸機(jī)制。通過減少通信的往返交互次數(shù)實(shí)現(xiàn)。通過關(guān)注移動(dòng)網(wǎng)絡(luò)環(huán)境特有的參數(shù)，比如網(wǎng)絡(luò)類型，連接時(shí)延，可用帶寬，丟包率和信號(hào)強(qiáng)度來降低TCP的緩慢啟動(dòng)帶來的性能降低。PacketZoom的服務(wù)器可以緩存靜態(tài)內(nèi)容，但對(duì)不可緩存的動(dòng)態(tài)內(nèi)容是工作在透明代理的模式。

智能內(nèi)容緩存：PacketZoom的App層和服務(wù)器層的內(nèi)容緩存技術(shù)，可以實(shí)現(xiàn)在向后端獲取內(nèi)容時(shí)減少對(duì)CDN或源站的往返交互的消耗。App層和PacketZoom服務(wù)器層的儲(chǔ)存都可以由用戶的工程師實(shí)現(xiàn)實(shí)時(shí)的管理和控制，比如緩存的大小和刷新狀態(tài)因?yàn)槲覀冎魂P(guān)注在移動(dòng)網(wǎng)絡(luò)環(huán)境的數(shù)據(jù)傳輸，所以PacketZoom是傳統(tǒng)Web CDN的絕好補(bǔ)充，無額外的運(yùn)營(yíng)成本。

會(huì)話保障：PacketZoom 會(huì)話保障功能工作在移動(dòng)設(shè)備到接入Internet的第一跳，更好的控制這之間的連通性以實(shí)現(xiàn)應(yīng)用層會(huì)話的可用性。隨著你的移動(dòng)用戶在相同運(yùn)營(yíng)商的網(wǎng)絡(luò)中移動(dòng)，甚至是在不同類型的網(wǎng)絡(luò)之間移動(dòng)(2G、3G、LTE或WiFi)，PacketZoom都可以做到數(shù)據(jù)傳輸順暢的、持續(xù)進(jìn)行。

全局網(wǎng)絡(luò)的知識(shí)認(rèn)知引擎：可以做到減少甚至消除TCP協(xié)議的慢啟動(dòng)、請(qǐng)求數(shù)據(jù)重連和重傳次數(shù) – 這些對(duì)于傳統(tǒng)的Web協(xié)議是沒法做到的。 通過使用PacketZoom的智能，移動(dòng)App可以在任何類型的移動(dòng)網(wǎng)絡(luò)中最大化利用網(wǎng)絡(luò)吞吐能力。使用平臺(tái)收集到并共享的詳細(xì)信息，移動(dòng)App可以節(jié)省自主偵測(cè)周邊網(wǎng)絡(luò)狀況的時(shí)間開銷。

失效轉(zhuǎn)發(fā)：PacketZoom的多播會(huì)話初始化進(jìn)程可以針對(duì)某個(gè)時(shí)刻、任意一個(gè)手持終端設(shè)備自動(dòng)找到對(duì)其來說最優(yōu)、最快的服務(wù)器，擇優(yōu)接入。

采訪小結(jié)

藍(lán)汛ChinaCache與PacketZoom的獨(dú)家合作，是將移動(dòng)應(yīng)用加速技術(shù)引入到中國(guó)的最快速的辦法，對(duì)于藍(lán)汛、PacketZoom或者是大量需要進(jìn)行移動(dòng)應(yīng)用加速的企業(yè)而言，都是利好。當(dāng)然，對(duì)筆者等最終用戶而言，移動(dòng)APP的使用將更普及，更快速!