|
|
說起手機操作平臺的發(fā)展先要說移動終端的發(fā)展，因為平臺的發(fā)展離不開移動終端，近十年移動終端發(fā)展和未來移動終端趨勢大體可分為以下四個個階段：
第一個階段：功能終端。滿足用戶基本通信需求，如發(fā)短信、打電話，附加些貪食蛇、推箱子小游戲。
第二個階段：智能化的終端。可擴展第三方應(yīng)用，實現(xiàn)上網(wǎng)瀏覽等互聯(lián)網(wǎng)基礎(chǔ)功能，以諾基亞S60手機為代表的。
第三個階段：互聯(lián)網(wǎng)和平臺化的終端。手機和互聯(lián)網(wǎng)更加緊密，瀏覽器、流媒體更加強大，互聯(lián)網(wǎng)應(yīng)用和手機系統(tǒng)特性結(jié)合的更加緊密；手機成為了一個平臺，用戶可以通過下載第三方應(yīng)用來DIY這款終端，如偏好音樂，可以下載音樂類型的應(yīng)用。代表為iPhone、Android和Windows Phone 7。
第四個階段（未來趨勢）：物聯(lián)網(wǎng)化的智能終端。此階段的特點是現(xiàn)實生活和網(wǎng)絡(luò)通過傳感設(shè)備結(jié)合的更加緊密。
目前我們處于第三個階段，對用戶而言，由于收入不同、興趣愛好不同、需求偏好的不同以及手機私人屬性和隨身性的特點，產(chǎn)生了不同的用戶體驗；對各個廠商而言，由于目標市場的定位不同、商業(yè)利益的不同、技術(shù)背景不同，造就了不同的手機操作系統(tǒng)。最終形成了手機操作平臺多元化的局面。
目前主流手機操作平臺可分為：Symbian、Android、iPhone OS 、MTK、Windows mobile、Wp7六種。下面分別簡述下這六個平臺的情況。
Symbian：昔日王者，雖然眼下受到了Android和iPhone的強勢狙擊，被其瓜分了部分市場，但是價格低，易用性強，應(yīng)用程序多，加上諾基亞的品牌、渠道等優(yōu)勢，在短期內(nèi)智能機霸主地位很難撼動。中期來看市場中心下移走中低端智能機路線，長期來看，有可能被WP7取代。如果它不革自己的命，那么很可能被別人革命。
Android：勢如破竹，據(jù)國外媒體報道Android在去年第四季度已超過Symbian成為全球最大智能手機平臺，結(jié)束了在Symbian在智能機領(lǐng)域長達10年的統(tǒng)治地位。作為后來者，Android借鑒了iPhone的操作體驗，但是由于Android完全開源，對于手機廠商和運營商來講，很容易定制成自己特色和服務(wù)的手機，加上Android強大的互聯(lián)網(wǎng)功能，因而獲得二者的青睞。完全開源是把雙刃劍，由于各廠商分別定義了各自的產(chǎn)品，這種不標準和不統(tǒng)一會給第三方軟件適配帶來門檻，會導致在單個某型號的移動終端Android應(yīng)用偏少，所以Android有可能成為智能手機中的山寨機。
iPhone OS：神話締造者，從熱銷的程度我們可以看出iPhone 4創(chuàng)造的奇跡。超炫的UI設(shè)計，良好的交互操作，海量的應(yīng)用，牢牢占領(lǐng)高端市場。從短期來看，iPhone 4突出的優(yōu)勢會讓它再火一段時間。但是由于是自有系統(tǒng)，市場占有量取決于蘋果手機終端用戶認可情況，所以長期看，主要取決于蘋果手機發(fā)展和競爭對手的變化。
Windows mobile：廉頗老矣，尚能飯否？無論從UI視覺效果，還是從易用性，還是第三方應(yīng)用，Windows mobile 都完敗Iphone和Android。壯士暮年，該退隱江湖了。
MTK：山寨大王， MTK是一個封閉的環(huán)境，不支持可擴展的應(yīng)用，同時原功能也不完善，總之是個半成品。需要中間廠商來完善。相比較來講，第三方程序少，易用性一般。山寨機的價格和功能形成的性價比優(yōu)勢，占據(jù)低端市場。
WP7：救世主，作為微軟和諾基亞的救命稻草是值得期待的，筆者曾經(jīng)體驗過WP7，采用卷軸式UI設(shè)計風格，使UI體驗別具一格。系統(tǒng)和互聯(lián)網(wǎng)應(yīng)用的緊密結(jié)合，加上諾基亞和微軟的強力支持。這個操作系統(tǒng)是值得期待的，有望在智能機領(lǐng)域形成WP7、Android、iPhone三足鼎立的局面。
上述六大平臺分別對應(yīng)不同的體驗和功能實現(xiàn)。對產(chǎn)品設(shè)計人員和開發(fā)人員而言，它們通常會參照移動終端的UI設(shè)計規(guī)范。因為移動終端系統(tǒng)本身定義了一些常用的控件和響應(yīng)方式。產(chǎn)品保持與終端系統(tǒng)的一致，不但可以降低開發(fā)成本，而且易于用戶學習和使用。面對諸多平臺，尤其是各個平臺功能特點不盡相同，操作方式不同，屏幕大小不同，而每個主流平臺又有相當規(guī)模的用戶群，擁有眾多不同的UI規(guī)范，這對于全平臺的產(chǎn)品而言，無疑是具有災難性的。
本文就人人網(wǎng)移動開發(fā)中不同終端平臺的差異和架構(gòu)統(tǒng)一問題，以及相關(guān)服務(wù)器架構(gòu)進行探討。
移動終端之江山一統(tǒng)
歷史歷歷在目
人人網(wǎng)www.renren.com（原名:校內(nèi)網(wǎng)），從０８年下半年開始手機軟件的研發(fā)，當時國內(nèi)一二線的互聯(lián)網(wǎng)公司也已經(jīng)開始了移動互聯(lián)網(wǎng)的布局，但已發(fā)布并可供參考的產(chǎn)品并不多，尤其是SNS本身也還是一個新的互聯(lián)業(yè)務(wù)，讓我們的用戶可以在手機上方便地訪問SNS，這可一下把我們難住了。為了可以快速推出第一個版本試水，我們先是選擇JavaME平臺來開發(fā)第一個人人的手機客戶端。
人人網(wǎng)的主要業(yè)務(wù)包括新鮮事，個人主頁（狀態(tài)，日志，相冊，留言），好友，站內(nèi)信，聊天，游戲等等，這些業(yè)務(wù)都互相關(guān)聯(lián)與襯托，并圍繞好友關(guān)系（Social Graph），如果要把這些業(yè)務(wù)都搬到手機，短時間內(nèi)根本無法完成，因為客戶端類的軟件與瀏覽器的網(wǎng)頁在展現(xiàn)與交互上有非常大的差異，手機的屏幕大小限制也給設(shè)計帶來了很大的困難，無疑是雪上加霜。當時我們挑選了用戶常用的幾個業(yè)務(wù)，新鮮事，個人主頁（狀態(tài)，日志，相冊，留言），好友，站內(nèi)信，按主站頂部導航的排版方式，設(shè)計了一多標簽的導航界面，每個標簽一個業(yè)務(wù)，頁面跳轉(zhuǎn)同主站，如下圖：
圖1
看上去這個設(shè)計非常簡約明到幾乎完美，代碼也非常好實現(xiàn)，大家激情澎湃，斗志昂揚準備迎接移動互聯(lián)網(wǎng)的又一個奇跡，也許你和我以及我們的產(chǎn)品經(jīng)理一樣，低估了這一切，人人網(wǎng)的業(yè)務(wù)可不像聊天軟件那樣單純，當我們的工程師各自完成自己的分配到的業(yè)務(wù)，并開始處理不同業(yè)務(wù)之間界面的跳轉(zhuǎn)時，不詳?shù)念A感籠罩了整個團隊，當時的輕率導致了嚴重危機，大家知道，在我們通過瀏覽器訪問網(wǎng)頁，頁面中超鏈接可以讓你隨意跳轉(zhuǎn)到任何一個頁面，且這些頁面并不一定是同一個業(yè)務(wù)的相關(guān)頁面，如我從個人主頁也可以直接跳轉(zhuǎn)到好友（跨標簽），而且通過瀏覽器的后退按鈕可以返回前面的頁面，客戶端類軟件可不能做成這樣的自由，我們應(yīng)該怎么處理不同業(yè)務(wù)界面的跳轉(zhuǎn)呢？
當時大家理解的跳轉(zhuǎn)，根本沒有考慮到不同業(yè)務(wù)之間后退的問題，而且瀏覽器的頁面跳轉(zhuǎn)，瀏覽器本身是不用知道下個界面是哪個業(yè)務(wù)，而客戶端必須知道，否則根本無法處理事件交互。技術(shù)慌了，產(chǎn)品經(jīng)理也慌了，眼看承諾的交付時間一天天臨近，大家還是沒有想出一個非常好的辦法，多次嘗試失敗，有的方案，頁面的跳轉(zhuǎn)連我們自己都暈過去了，最后我們的第一個版本的JavaME 客戶端１.０以失敗告終。
首戰(zhàn)不利，大家心里都不是滋味，雖然通過后幾個月的努力，最后我們決定將１.２版本的客戶端以beta 版本的形式發(fā)布，并公開提供了下載，除了拍照上傳這個功能讓我們值得高興一下之外，其它功能也許只是讓我們感覺能用而已。JavaME的失利讓我們從自負中清醒，驕兵必敗。經(jīng)過一段時間的討論與分析，大家一致認為，我們需要一個手機瀏覽器，人人的業(yè)務(wù)不論在PC端還是手機端，最理想的展現(xiàn)方式還是瀏覽器，于是我們開始手機瀏覽器研發(fā)道路，我們花了３-4個月的時間，開發(fā)出了我們第一個基于JavaME的瀏覽器引擎，代號：Across（為什么起這個名，后面說）。瀏覽器引擎架構(gòu)參考Webkit，如下圖：
圖2 Across瀏覽器結(jié)構(gòu)圖
上圖中藍色部分是我們引擎的實現(xiàn)部分，紅色的JS,CSS及Plug-in是未來的計劃，從技術(shù)角度看來，這個架構(gòu)看上去非常的美，模塊功能劃分清晰且擴展性強，我們只要重寫Render Engine可以把一個普通的頁面渲染成我們想要的任何效果，遺憾的是最終我們還是沒有把瀏覽器這個解決方案應(yīng)用到正式發(fā)布的人人客戶端版本，原因很簡單，它還不是很完善。
我們預先做了大量的測試用例，在完成開發(fā)以后，我們按測試用例逐條進行了測試，最終結(jié)論雖然在性能和xhtml標簽支持上達到了我們的預期，但穩(wěn)定性和包體積卻并沒有達到理想的狀態(tài)：運行時內(nèi)存消耗在xhtml頁面大小的8-10倍左右，如一個30K的xhtml頁面完成解析，渲染必須保證有300K左右的空閑內(nèi)存，如果渲染多個頁面或頻繁渲染新的頁面，就很容易出現(xiàn)崩潰（后來我們發(fā)現(xiàn)代碼中還有存在一些內(nèi)存泄漏的地方）；另外，打包以后200k的體積對于JavaME手機來說已經(jīng)大了。09年上半年，Android發(fā)布了1.5的SDK,iPhone入華的消息也是傳得到處都是，顯然，在這樣的行業(yè)形勢下，公司管理層已經(jīng)對我們在JavaME上做瀏覽器引擎的計劃失去興趣，我們的工程師被重新安排了新的任務(wù)，Across沒有見到用戶就成了歷史，瀏覽器沒有救得了我們。
痛苦中反思
09年上半年是我們最痛苦的一段時間，折騰了大半個年頭，結(jié)果我們沒有發(fā)布一個值得驕傲的產(chǎn)品，市場卻快速變化著，iPhone，Android帶著閃耀的光芒進入了大家的視野，我們也不得不做出調(diào)整，開始分兵投入iPhone及Android的陣營。我們開始反省前面的失敗，我們似乎走了兩個極端，第一次在考慮產(chǎn)品及技術(shù)的架構(gòu)時過于的簡單草率，以致后期面臨強大的心理壓力，第二次卻是一個典型的過度設(shè)計案例，雖然從技術(shù)角度看這是一個非常有挑戰(zhàn)且非常有意思的項目，當時我們的設(shè)想是先完成JavaME平臺的瀏覽器，然后移植Symbian等其它平臺，統(tǒng)一架構(gòu)。但是移動互聯(lián)網(wǎng)市場近幾年的急速變化，不論從人力和時間上都不允許我們再把瀏覽器項目繼續(xù)下去。
為什么我們要統(tǒng)一架構(gòu)？
人人網(wǎng)的業(yè)務(wù)種類非常多，而且PC端都基于瀏覽器網(wǎng)頁的模式，不論內(nèi)容還是排版都經(jīng)常需要優(yōu)化變更，如果我們通過純客戶端的形式把全部現(xiàn)有業(yè)務(wù)遷移到到手機端，那么，當我們完成第５個業(yè)務(wù)的遷移時，可以前兩個業(yè)務(wù)主站已經(jīng)發(fā)生了變更，或者客戶端剛剛上線之前的某個業(yè)務(wù)已經(jīng)需要兼容運行了，在這種情況下，要么我們能快速迭代客戶端版本，趕上主站的業(yè)務(wù)的迭代速度，要么我們使用瀏覽器或類似瀏覽器的模式，所有業(yè)務(wù)放在服務(wù)器做，這就是我們?yōu)槭裁纯紤]開發(fā)Across，名字意在橫跨所有手機終端平臺。
真的可以統(tǒng)一架構(gòu)嗎？
可以，瀏覽器本身就是一個非常優(yōu)秀的跨平臺解決方案，但這個方案的前期投入非常大，且項目執(zhí)行風險過高，人人網(wǎng)的業(yè)務(wù)大都是基本動態(tài)網(wǎng)頁實現(xiàn)，使用了大量的AJAX及Flash技術(shù)，最終我們放棄了瀏覽器方案，我們要的統(tǒng)一架構(gòu)肯定不是這個。
山窮水盡,柳暗花明
放棄了瀏覽器的方案，我們可謂山窮水盡，難道還有第三個方案？Facebook的iPhone應(yīng)用給了我們很大靈感，看圖：
圖３
從產(chǎn)品的角度看，這個圖顯示的布局與我們第一次嘗試的設(shè)計沒什么區(qū)別，深入一點我們會發(fā)現(xiàn)，這個設(shè)計與之前的設(shè)計最大區(qū)別在于頁面跳轉(zhuǎn)，每個標簽都有獨立的一個視圖棧，理論上無限大，通過當前棧頂視圖可以打開新的視圖后自動壓棧保存，當前視圖如果要后退默認退回視圖棧里保存的上一個視圖的內(nèi)容。那如果是標簽１的頁面需要跳轉(zhuǎn)到標簽２對應(yīng)的頁面怎么辦呢，是否自動切標簽？
答案是不切，標簽只是用于業(yè)務(wù)導航，且有獨立的視圖棧，視圖棧中的頁面可以與業(yè)務(wù)無關(guān)，打個很好理解的比方：當我們在使用Chrome的瀏覽器時，我們同時在多個標簽分別打開多個不同網(wǎng)站或頁面，也可以打開同樣的網(wǎng)站或頁面，每個標簽都有一個獨立的后退的記錄，這種設(shè)計非常有規(guī)律，用戶容易理解不容易暈，現(xiàn)在頁面跳轉(zhuǎn)及后退的問題很好的解決了。不論JavaME，還是iPhone或者Android的客戶端，我們都使用了同樣的設(shè)計。
數(shù)風流人物，還看今朝
當我們客戶端都使用了這種標簽+視圖棧的方案以后，我們的各平臺在設(shè)計上基本達到了統(tǒng)一，并在現(xiàn)有設(shè)計上快速迭代演進。大家可能想了，在代碼層統(tǒng)一這才叫本事，也許你沒錯，但是我們不會輕意再做這樣高風險的嘗試，如今手機平臺的差異相當?shù)拇螅蛷闹髁髌脚_的開發(fā)語言看就夠你折騰了，JavaME及Android是使用的Java , iPhone使用的是 Objective-C，Symbian是純C++, 現(xiàn)在諾基亞與微軟聯(lián)姻WP7，可WP7將不再支持C/C++的開發(fā)，主推C# + Silverlight，好吧，我們只能再觀察一下了。
在接下來的一到兩年，移動互聯(lián)網(wǎng)將以前所未有的速度發(fā)展，大部分互聯(lián)網(wǎng)公司都開始了或已經(jīng)推出了較成熟的移動終端的解決方案，創(chuàng)業(yè)公司也會層出不窮，推出各種優(yōu)秀的移動終端應(yīng)用：移動支付，LBS，基本通訊簿的即時通信，手機音樂，手機視頻，手機閱讀等等，iPad點燃平板電腦的硝煙，平板的設(shè)計再次給了我們很大的挑戰(zhàn)，數(shù)風流人物，還看今朝。
高可靠性和可擴展的服務(wù)
現(xiàn)在移動互聯(lián)網(wǎng)拼的都是服務(wù)，客戶端良好的用戶體驗背后，都有強大的服務(wù)器技術(shù)支撐，人人網(wǎng)也不外如是。
業(yè)務(wù)層次模型
人人網(wǎng)采用JavaEE技術(shù)作為主要的業(yè)務(wù)解決方案，基本按照通用的JavaEE模型進行架構(gòu)設(shè)計，如下圖：
圖4 人人網(wǎng)業(yè)務(wù)層次模型
- WEB層基于REST風格和MVC設(shè)計模式，為用戶提供基于WEB的訪問接口
人人網(wǎng)采用的是自己開發(fā)的WEB框架 Rose，該框架基于Spring Framework，類似RoR框架，增強了對Controller編碼部分的默認約定和REST風格URL的支持，該項目前已開源，下載地址為http://code.google.com/p/paoding-rose/
- 業(yè)務(wù)層封裝業(yè)務(wù)邏輯，為WEB層提供業(yè)務(wù)接口，操作數(shù)據(jù)訪問層提供的數(shù)據(jù)。
人人網(wǎng)開發(fā)了自己的SOA框架XOA以支持業(yè)務(wù)層抽象，該框架結(jié)合Rose框架，以REST風格對業(yè)務(wù)進行分類、消息格式封裝和路由，如以下URL：
xoa://blog.xoa.renren.com/photo/{user-id}/{photo-id}
該URL代表某用戶的某個照片，操作 GET/PUT/POST/DELETE分別對應(yīng)對應(yīng)照片資源的讀、修改、新增、刪除。即通過資源+操作的方式對外提供Service。
XOA支持遠程調(diào)用，并可以通過簡單添加服務(wù)器的方式進行橫向擴展。該框架目前準備開源，敬請關(guān)注。
- 數(shù)據(jù)訪問層提供對數(shù)據(jù)庫訪問的封裝
人人網(wǎng)使用Java語言開發(fā)了自己的Object-Relation Mapping框架JADE（Java Database Engine），并支持數(shù)據(jù)庫的水平橫向切分。該框架和Rose框架一體開源，下載地址相同。
- 數(shù)據(jù)持久層數(shù)據(jù)的持久存儲，主要采用MySQL數(shù)據(jù)庫，并且開發(fā)了自己的海量存儲系統(tǒng)Nuclear。
Rose、Jade、XOA作為集成度很高的一整套解決方案，在人人網(wǎng)大量采用，大大降低了開發(fā)成本，并在框架級解決了服務(wù)于企業(yè)解決方案的JavaEE技術(shù)在互聯(lián)網(wǎng)領(lǐng)域的適用性。
可擴展的高性能系統(tǒng)
人人網(wǎng)每天都要承受億級PV海量用戶的并發(fā)壓力，和其它大型互聯(lián)網(wǎng)站點類似，服務(wù)器架構(gòu)方面做了很多工作。
高性能數(shù)據(jù)存儲系統(tǒng)
在數(shù)據(jù)存儲方面，人人網(wǎng)做了以下工作：
- 和其它互聯(lián)網(wǎng)大型站點相同，MySQL數(shù)據(jù)庫做水平拆分以支持橫向擴展
- 人人網(wǎng)作為國內(nèi)第一大SNS網(wǎng)站，欲存海量UGC數(shù)據(jù)，必有海量存儲系統(tǒng)。Nuclear存儲系統(tǒng)在高性能、高可靠、可擴展的海量數(shù)據(jù)存儲需求下橫空出世。
Nuclear本身的數(shù)據(jù)存儲基于Key-Value形式，底層可以使用MySQL/Memory, Cassandra, TC, Redis等存儲引擎，提供弱結(jié)構(gòu)化的查詢功能。
- 高擴展性
一個Nuclear集群支持1到n(n<264)個節(jié)點(Node)的規(guī)模
- 高可靠性
單個節(jié)點的crash永遠對系統(tǒng)的運行造成影響，不存在單點風險。系統(tǒng)永遠可寫入。
- 高性能
在4個節(jié)點、一般服務(wù)器配置情況下有測試數(shù)據(jù)表明單節(jié)點訪問可達15862 req/s, 平均單次請求耗時僅5ms。
可擴展的高性能業(yè)務(wù)服務(wù)系統(tǒng)
人人網(wǎng)的業(yè)務(wù)層是支持分布式、可橫向擴展的。
- 人人網(wǎng)主要使用JavaEE架構(gòu)進行業(yè)務(wù)開發(fā)，其中Spring提供的IoC和AOP功能分別起到了業(yè)務(wù)對象裝配和橫向關(guān)注點分離的良好抽象。XOA框架基于Spring和NETty，使用google的spdy協(xié)議作為網(wǎng)絡(luò)傳輸協(xié)議，除享受到Spring紅利之外，也提供了基于Java NIO的網(wǎng)絡(luò)高性能服務(wù)器環(huán)境。單個XOA服務(wù)是無狀態(tài)的，具有冪等性，XOA客戶端使用Java NIO、通過Keep alive保持對各個后臺服務(wù)器的TCP長連接，可實時監(jiān)測后臺服務(wù)器的健康狀況，并把用戶請求負載分散到各個后臺服務(wù)器上，在單個節(jié)點失效的情況下不影響服務(wù)，如圖5所示：
圖5 XOA負載均衡
- 很多關(guān)鍵性的業(yè)務(wù)對性能要求特別高，也需要借助很多Linux操作系統(tǒng)的特性，這時Java的優(yōu)化已經(jīng)不能滿足需求，需要使用 C++語言進行開發(fā)。人人網(wǎng)采用ICE框架，進行這部分業(yè)務(wù)的開發(fā)，它解決了Java、C++等多種語言開發(fā)的框架和通訊問題。人人網(wǎng)目前使用ICE進行開發(fā)的業(yè)務(wù)層稱之為中間層，主要解決類似搜索、用戶好友關(guān)系計算等性能要求苛刻的底層關(guān)鍵性業(yè)務(wù)問題。其運維模式和XOA類似。
和其它大型網(wǎng)站一樣，業(yè)務(wù)層使用Memcached作為業(yè)務(wù)層的分布式數(shù)據(jù)緩存，且根據(jù)業(yè)務(wù)將緩存集群劃分為多個池，集中進行管理，如圖6所示：
圖6 Memcached Pool
- 在WEB層，使用目前性能最高的Servlet容器產(chǎn)品Resin作為HTTP Server，使用自行開發(fā)的Java WEB MVC框架Rose對用戶請求請求分發(fā)。負載均衡方面使用了F5或者nginx。為了減少Session復制同步的開銷，每臺WEB Server都禁用Servlet Session, 即每臺服務(wù)器都是無狀態(tài)的，單個Web Server失效后，不會發(fā)生用戶狀態(tài)丟失的問題。用戶狀態(tài)的跟蹤由中間層統(tǒng)一處理。
對移動終端的支持
服務(wù)器對移動終端的支持主要是通過HTTP協(xié)議提供json數(shù)據(jù)接口實現(xiàn)的，服務(wù)器基本采用了人人網(wǎng)共同的架構(gòu)：
- HTTP WEB層做了更多的MVC抽象，除了提供基于html的Page View之外，還生成只提供json或者其他數(shù)據(jù)格式的Feed View。
- 服務(wù)器通過gzip壓縮減少流量，節(jié)省用戶資費。
- 客戶端構(gòu)建REST風格的HTTP請求，WEB服務(wù)器下發(fā)數(shù)據(jù)完成遠程調(diào)用。
3G的API層直接面向移動終端，提供基于HTTP和其他Socket協(xié)議的服務(wù)器訪問接口，并在業(yè)務(wù)層抽象出3G部門自己的公共平臺，如圖4所示：
圖7 3G API架構(gòu)
除此之外，針對移動終端的特點和中國特色的移動互聯(lián)網(wǎng)環(huán)境，做了一些特殊的工作：
- 低端機型運算能力和內(nèi)存資源都有限，API平臺做了相應(yīng)優(yōu)化
- 為了減少用戶資費，傳輸流量進行了控制
- nginx開啟gzip壓縮，減少網(wǎng)絡(luò)傳輸流量。
- 中國移動的cmwap網(wǎng)關(guān)會自動對服務(wù)器輸出的gzip流進行解壓縮，從而使nginx的zip壓縮失去了意義。這種情況下，api服務(wù)器對輸出進行g(shù)zip壓縮后，作為普通二進制流進行響應(yīng)輸出。
- 除了純文本的json之外，api服務(wù)器也支持基于google protocol buffers格式的輸出，從而提供更緊湊的格式輸出。
- 提高客戶端訪問速度
- Api平臺支持基于邏輯時序的批處理操作，將多個api的網(wǎng)絡(luò)接口調(diào)用合并為一個，減少多次tcp握手造成的巨大時間損耗，提高客戶端每個UI界面的響應(yīng)和顯示速度。
it知識庫：人人網(wǎng)移動開發(fā)架構(gòu)，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
