零。前言
這里講的移動(dòng)APP主要指的是安卓平臺(tái)，大部分情況也適用于IOS等移動(dòng)平臺(tái)，可能重點(diǎn)嘛會(huì)在后半部分呢。
一。嵌入多SDK存在的隱患
但凡一個(gè)常用的APP都會(huì)嵌入至少一個(gè)SDK，不同來源或同一來源，有廣告SDK，有推送SDK，有性能匯報(bào)SDK，有用戶跟蹤SDK，有統(tǒng)計(jì)流量SDK等，有支付SDK等等。雖然帶來了功能的復(fù)用和解耦，便于縱向擴(kuò)展，但可能會(huì)存在：
- 一個(gè)SDK可以看做一個(gè)后臺(tái)Service，多個(gè)SDK多個(gè)Service存在（粗略上計(jì)算）
- 運(yùn)行緩慢的問題，多個(gè)SDK或多功能的模塊（若不按需加載的話）會(huì)導(dǎo)致運(yùn)行緩慢，符合木桶理論，最慢的那個(gè)拖慢了總體步伐
- 每一個(gè)SDK都有自己核心訴求，各自為政，實(shí)現(xiàn)方式各異。總體架構(gòu)是否合適，帶來了隱形的兼容成本
- 彼此協(xié)調(diào)運(yùn)作兼容性問題，一旦出現(xiàn)某個(gè)隱含BUG，會(huì)不會(huì)導(dǎo)致連鎖反應(yīng)
- CPU、內(nèi)存、網(wǎng)絡(luò)等資源競(jìng)爭(zhēng)問題，想?yún)f(xié)調(diào)都很難
- 網(wǎng)絡(luò)資源各自為政，無法共享，更不用提連接復(fù)用
若是同一來源的SDK，當(dāng)問題發(fā)生的時(shí)候還能夠有所協(xié)作稍作調(diào)整，雖然這也是比較理想的情況。外部的SDK可能問題反饋和BUG修正，時(shí)效性就不太好說了。
解耦雖然帶來了功能的擴(kuò)展性，帶隨之帶來了資源利用方面的重復(fù)和浪費(fèi)，愈多的SDK嵌入越有可能導(dǎo)致總體運(yùn)行緩慢，需要謹(jǐn)慎使用。
二。APP后臺(tái)Service數(shù)量很多
一般安卓手機(jī)會(huì)提供后臺(tái)進(jìn)程的查看，一般APP會(huì)啟動(dòng)多個(gè)后臺(tái)服務(wù)，比如愛奇藝APP就很變態(tài)，5個(gè)服務(wù)存在（優(yōu)酷APP也好不了哪去，3-4個(gè)服務(wù)存在）：
一般較大公司，都會(huì)自己開發(fā)SDK，但礙于KPI等業(yè)績(jī)考核，很少有人會(huì)認(rèn)真從總體上考慮把多個(gè)Serice服務(wù)合并為一個(gè)，節(jié)省一點(diǎn)用戶的資源占用，不過那需要考驗(yàn)研發(fā)人員的架構(gòu)能力了。
雖然小白用戶不一定會(huì)查看后臺(tái)服務(wù)，但若干個(gè)后臺(tái)服務(wù)，每一個(gè)都需要維護(hù)自身服務(wù)存活檢測(cè)，每一個(gè)都會(huì)占用若干內(nèi)存，若合并為一個(gè)，自然減少了CPU占用和內(nèi)存資源占用，以及維護(hù)成本，還是有些小必要的。
三。HTTP短連接請(qǐng)求過于頻繁
一般來講，打開一個(gè)APP的時(shí)候，通過Wireshark抓包工具可以看到若干個(gè)HTTP連接瞬間建立，諸如淘寶，天貓，美團(tuán)，優(yōu)酷等APP，滿屏的都是HTTP請(qǐng)求，看著讓人感覺有些小恐怖，業(yè)務(wù)數(shù)據(jù)、設(shè)備信息上傳、SDK信息抓取、埋點(diǎn)跟蹤、頭像圖片、HTML資源等，那叫一個(gè)龐大。
但也沒辦法，業(yè)務(wù)展示那么豐富，需要消耗過多的資源。大部分請(qǐng)求都只專注于一部分?jǐn)?shù)據(jù)。針對(duì)單一顯示界面屏幕，可以通過一個(gè)請(qǐng)求獲得合并后的響應(yīng)結(jié)果，減少網(wǎng)絡(luò)資源消耗。
手機(jī)淘寶和手機(jī)QQ，在HTTP請(qǐng)求優(yōu)化方面，已經(jīng)在使用IP直連、HTTP長(zhǎng)連接、SPDY等進(jìn)行加速處理，值得學(xué)習(xí)。
四。TCP長(zhǎng)連接利用率不高
這里所說長(zhǎng)連接，更多的是指TCP方式連接，也包括HTTP方式的長(zhǎng)連接，但更多指的是具有雙向通道的長(zhǎng)連接。單通道的方式，協(xié)議所限，資源利用率不是那么高。
當(dāng)前TCP長(zhǎng)連接在其存活期間，大都只專注于傳輸一類具體業(yè)務(wù)內(nèi)容，比如PUSH推送，一臺(tái)手機(jī)連接一天，也接收不了幾條消息，最頻繁的就是心跳保活數(shù)據(jù)包傳送了。
一旦涉及到新的業(yè)務(wù)，大家都是要新建一條全新TCP連接，彼此業(yè)務(wù)不關(guān)聯(lián)嘛，看上去很耦合啊，但卻造成了企業(yè)大量的重復(fù)資源浪費(fèi)：新的業(yè)務(wù)需要處理另外的連接接入，資源重復(fù)投入，業(yè)務(wù)層面嘛，也會(huì)存在一半左右的重疊。當(dāng)然，若不在乎這些的話，就另當(dāng)別論了，但是你要是能夠?yàn)橄M(fèi)者手機(jī)的資源消耗考慮，那便是用戶的福音了。
長(zhǎng)連接的業(yè)務(wù)層面多路復(fù)用，支持類似于搖一搖、搶紅包、客服、客服咨詢等，同一個(gè)連接傳輸不同類型的數(shù)據(jù)，即節(jié)省了服務(wù)器資源，又提高了網(wǎng)絡(luò)連接利用率，兩端的維護(hù)成本降低。針對(duì)客戶端而言，多路業(yè)務(wù)復(fù)用在一條TCP連接上傳輸，需要業(yè)務(wù)路由 + 相應(yīng)業(yè)務(wù)處理即可。服務(wù)器端嘛，接入不同的業(yè)務(wù)處理，依靠業(yè)務(wù)路由進(jìn)行消息分發(fā)。
題外話，舉一個(gè)例子，平時(shí)任一時(shí)間點(diǎn)約3000千萬用戶連接，按每臺(tái)接200萬計(jì)算，10-20臺(tái)機(jī)器接入處理足可，推送啊，聊天啊，客服咨詢，平常再來一個(gè)好運(yùn)搖一搖都行。年底了要擴(kuò)容到1億左右用戶搖啊搖的搶東搶西搶紅包，還是同一個(gè)連接的方式，不過增加了新的業(yè)務(wù)類型數(shù)據(jù)傳遞，服務(wù)器嘛，擴(kuò)展到50-80臺(tái)就很OK了。用戶量一旦降落，撤下多余機(jī)器就行。或許，有空可以寫一篇供一億用戶在線的系統(tǒng)架構(gòu)的方法 :))
五。HTTP 持久連接使用
針對(duì)HTTP/1.1可能很多人的思維方式，還停留在瀏覽器環(huán)境，一般瀏覽器有不支持或支持不夠好，但在非瀏覽器環(huán)境下，針對(duì)APP應(yīng)用的環(huán)境，少了很多傳統(tǒng)瀏覽器環(huán)境的限制，但要完全發(fā)揮和釋放HTTP/1.1協(xié)議所帶來的持久特性，這便需要深度理解協(xié)議規(guī)范和具體的使用環(huán)境等進(jìn)行抉擇。
1. HTTP/1.1 KeepAlive特性使用
雖說HTTP/1.1 Keep-Alive特性支持多個(gè)請(qǐng)求在同一個(gè)連接上排隊(duì)發(fā)送，在瀏覽器端正常的HTML等資源請(qǐng)求，會(huì)帶來線頭阻塞弊端，后一個(gè)請(qǐng)求依賴于前一個(gè)請(qǐng)求完成，一旦出現(xiàn)阻塞，后續(xù)請(qǐng)求只能排隊(duì)等待。
但若針對(duì)非瀏覽器、業(yè)務(wù)模型不是很復(fù)雜的環(huán)境，比如日志采集/跟蹤等常見業(yè)務(wù)，屬于簡(jiǎn)單循環(huán)的請(qǐng)求-響應(yīng)模型，響應(yīng)僅僅需要HTTP 200狀態(tài)碼即可（這要求服務(wù)器端接收之后異步處理直接返回200狀態(tài)），后續(xù)的請(qǐng)求只需要排隊(duì)，并且不會(huì)對(duì)延遲有苛刻要求，那么Keep-Alive特性就很適合。一般出現(xiàn)阻塞，那就意味著網(wǎng)絡(luò)狀況不容樂觀，關(guān)閉然后重鍵一個(gè)HTTP持久連接就行。
有些環(huán)境，只需要發(fā)送數(shù)據(jù)，客戶端不關(guān)心有沒有響應(yīng)（或不接收響應(yīng)），類似于UDP的方式，比如實(shí)時(shí)日志（突出實(shí)時(shí)特性），但這需要客戶端異步處理響應(yīng)。
一般視頻網(wǎng)站都會(huì)有實(shí)時(shí)跟蹤用戶正在播放中的視頻播放狀態(tài)，那就需要建立一個(gè)持久的HTTP/1.1連接，即時(shí)、持續(xù)傳遞視頻觀看事件，自然就避免了短連接多次創(chuàng)建、關(guān)閉的開銷。
2. HTTP/1.1 Pipelining
建立在Keep-Alive持久化基礎(chǔ)之上，中文譯為管線化，支持連續(xù)的冪等的GET/HEAD方法請(qǐng)求，實(shí)際環(huán)境下，并沒有被瀏覽器所支持。
同一個(gè)連接，處理同樣的三次請(qǐng)求-響應(yīng)，Keep-Alive和Pipelining方式不同：
瀏覽器環(huán)境不支持的特性，在應(yīng)用環(huán)境下或許可以找到其適用空間。比如具有通過GET方式提交數(shù)據(jù)的情況（比如GET方式匯報(bào)地理位置，GET方式提交用戶設(shè)備信息，GET方式匯報(bào)用戶手機(jī)抖動(dòng)情況等），多個(gè)請(qǐng)求批量發(fā)送。
但換一個(gè)思維方式，若能夠合并批量請(qǐng)求為一個(gè)POST提交，不走管線化方式，可能會(huì)更合適一些。
針對(duì)不太重要數(shù)據(jù)，發(fā)送完畢，不用等待響應(yīng)。
3. HTTP/2
若想了解HTTP/2的規(guī)范，可以參考本博客的其它文字。目前客戶端庫(kù)和服務(wù)器端庫(kù)，支持都不太好，需要觀察一段時(shí)間，公司實(shí)力夠，完全可以自主開發(fā)，或基于SPDY 2.0也可，目前淘寶APP、騰訊手QQ等，也都在使用。
HTTP/1.1能夠完全解決的問題，就沒有必要使用HTTP/2，后者造成了實(shí)現(xiàn)有些復(fù)雜，可能中介設(shè)備（網(wǎng)關(guān)、代理、CDN等）都還沒有為之做好準(zhǔn)備呢，但HTTP/2畢竟是趨勢(shì)。
雖然規(guī)范只定義一個(gè)Hostname只允許一個(gè)連接，可能實(shí)際情況下會(huì)需要2-3條長(zhǎng)連接以爭(zhēng)奪較多的網(wǎng)絡(luò)帶寬資源。
六。小結(jié)
怎么說呢，在當(dāng)前移動(dòng)APP環(huán)境下：
- TCP長(zhǎng)連接的通道用途的傳輸潛力和利用率很低
- HTTP/1.1的持久特性很容易被人忽略，未能正確使用
- HTTP/2多路復(fù)用值得期待
無論哪一種方式，都需要熟悉協(xié)議和網(wǎng)絡(luò)，適合的環(huán)境使用適合的協(xié)議特性，才能夠發(fā)揮出潛在的性能出來。