2015年7月24-25日，作為中國***影響的移動領(lǐng)域技術(shù)大會——WOT2015移動互聯(lián)網(wǎng)開發(fā)者大會在北京富力萬麗酒店圓滿落幕，這也是51CTO從2012年至今舉辦的第七屆技術(shù)大會。大會以“洞察移動互聯(lián)網(wǎng)用戶行為 分享移動應(yīng)用研發(fā)實踐”為主題，共設(shè)立“架構(gòu)與設(shè)計”、“平臺與技術(shù)”、“MDSA創(chuàng)新與創(chuàng)業(yè)”、“移動游戲”、“算法分析”、“HTML5專場”、“運維安全”、“新浪微博技術(shù)”等八大技術(shù)專場，并垂直整合了技術(shù)和體驗，深度服務(wù)于參會者與講師。

會上，來自阿里的高級無線技術(shù)專家徐昭先生帶來了關(guān)于《以小見大，見微知著 億萬級APP架構(gòu)演進之路》的精彩演講，并在會后接受了51CTO記者的采訪。

徐昭于2012年加入天貓成為技術(shù)核心，前后帶領(lǐng)過天貓賣家&導(dǎo)購詳情等多支技術(shù)團隊，親身打造并見證雙11成為電商行業(yè)的重要節(jié)日?，F(xiàn)任手機淘寶賣家生態(tài)團隊技術(shù)負(fù)責(zé)人，主要負(fù)責(zé)無線店鋪、微淘、小鋪、開放等賣家鏈路的技術(shù)架構(gòu)及研發(fā)工作。目前專注在無線整體架構(gòu)、大型復(fù)雜移動應(yīng)用構(gòu)建框架及無線技術(shù)開放等領(lǐng)域，同時關(guān)注新技術(shù)和開發(fā)模式在移動互聯(lián)網(wǎng)產(chǎn)品中的演進和落地。

采訪實錄如下：

51CTO：首先非常感謝您作為講師來參加本屆WOT峰會，請您介紹一下阿里無線事業(yè)部這個部門以及您所負(fù)責(zé)的主要工作。

徐昭：阿里無線事業(yè)部目前是承載整個阿里集團無線技術(shù)基礎(chǔ)架構(gòu)以及以手機淘寶為代表的APP研發(fā)為主的一支技術(shù)團隊，這支團隊的主要使命主要有兩個：一是，提供整個阿里集團無線化的基礎(chǔ)設(shè)施以及技術(shù)服務(wù)能力；二是，在APP層面上我們以手機淘寶為核心構(gòu)建整個大淘寶業(yè)務(wù)生態(tài)下的全新移動端業(yè)務(wù)平臺，并進而打造新的移動業(yè)務(wù)開放生態(tài)體系。

51CTO：在您的演講中主要是說億萬級APP架構(gòu)的演進之路，在這個演進過程中，阿里是如何保證大規(guī)模研發(fā)體系的效率和質(zhì)量的呢?

徐昭：這個過程也是逐步摸索和演進的過程。在早期階段，團隊規(guī)模相對較小，采用的是一個統(tǒng)一集成、整合迭代的研發(fā)模式。隨著PC業(yè)務(wù)的整體遷移、更多業(yè)務(wù)團隊無線化的參與以及整個研發(fā)人數(shù)和團隊規(guī)模的擴大，我們逐漸遇到一些瓶頸。包括整個發(fā)布周期、研發(fā)效率，最終產(chǎn)出的APP和功能模塊的質(zhì)量標(biāo)準(zhǔn)、用戶體驗等方面。在這個過程中，我們通過不同路徑的嘗試，最終采取客戶端組件化的架構(gòu)模式。通過對客戶端容器架構(gòu)的改造和工程拆分，延伸到整個研發(fā)的配套工具、發(fā)布體系、監(jiān)控平臺等一整套完整的鏈路改造，最終支撐了大規(guī)模、分布式的研發(fā)模式。

51CTO：具體進行了哪些改造呢?

徐昭：在核心改造方面，首先將移動端上的業(yè)務(wù)模塊和基礎(chǔ)中間件歸一化處理，基于端側(cè)容器拆分成多個組件的模式。這個過程相當(dāng)于把不同的業(yè)務(wù)和技術(shù)團隊所負(fù)責(zé)開發(fā)的業(yè)務(wù)模塊、基礎(chǔ)技術(shù)模塊進行拆分解耦。基于此，底層運行時容器能夠統(tǒng)一加載并管理不同組件的生命周期，從而促使上層業(yè)務(wù)團隊得以按照自身的節(jié)奏獨立研發(fā)、測試、集成。并基于這個模式來進一步實現(xiàn)整個研發(fā)過程的高效迭代、動態(tài)部署、智能發(fā)布等創(chuàng)新成果。

51CTO：在您看來現(xiàn)在的無線架構(gòu)和之前的PC架構(gòu)存在哪些差異性?

徐昭：我們的總結(jié)和思考可以歸納為五個方面：

首先，在整個部署模式上存在差異。我們知道服務(wù)端傳統(tǒng)的互聯(lián)網(wǎng)B/S架構(gòu)下，基本上整體研發(fā)方式上比較自由，能夠做到隨時開發(fā)、實時發(fā)布、靈活部署。在移動端，目前谷歌和蘋果代表了兩大核心的技術(shù)生態(tài)陣營，這兩個陣營***的移動終端技術(shù)體系下，APP的發(fā)布模式是受限的，承載APP的終端呈現(xiàn)碎片化現(xiàn)象，研發(fā)模式在較大程度上也依賴于整個APP開發(fā)框架，這就意味著需要將業(yè)務(wù)功能組裝成完整的APP，通過發(fā)布到對應(yīng)生態(tài)的應(yīng)用市場，來完成業(yè)務(wù)功能的發(fā)布和消費者觸達。在這個體系里怎么樣更好的執(zhí)行類似于服務(wù)端體系時代的靈活發(fā)布和部署機制，怎么樣能夠?qū)崿F(xiàn)在線問題、在線BUG、在線故障的動態(tài)修復(fù)和快速響應(yīng)，在這個維度上如何綜合利用native和web技術(shù)合理解決今天APP研發(fā)模式的效率和體驗問題，這是***部分區(qū)別。

第二，整個移動終端的碎片化帶來的挑戰(zhàn)。安卓陣營更為典型，設(shè)備本身碎片化嚴(yán)重，不同的廠商、不同的生態(tài)可能對Android體系都有一定的定制改造。在這個體系里面我們怎么樣能夠更好的利用研發(fā)技術(shù)支撐更高的研發(fā)效率，同時保證我們的應(yīng)用程序在多樣化的終端設(shè)備上有相對穩(wěn)定和一致的用戶體驗，以及確保應(yīng)用多端適配的兼容性(包括native以及h5兩個角度)。相對PC時代的瀏覽器兼容，適配是一個更富挑戰(zhàn)和瑣碎的工作。

第三，今天移動設(shè)備之所以是移動設(shè)備，本身跟PC傳統(tǒng)的瀏覽器是大大不同的，在這個體系里怎么樣更好地利用移動設(shè)備本身的一些硬件能力，怎么樣提供原有的PC時代不具備的體驗。

第四，更多是從質(zhì)量體系考慮，因為今天用戶在手持設(shè)備的場景下更關(guān)心的不僅僅是網(wǎng)頁能不能打開，夠不夠快，同時也很關(guān)注手機是不是發(fā)熱，流量是不是夠低，本身這個應(yīng)用是不是經(jīng)常會Crash，他會關(guān)注這些外延維度的一些特性的質(zhì)量，這些怎么樣更好的監(jiān)控和怎么樣確保質(zhì)量持續(xù)提升。

***，行為的差異。用戶不再像原來PC時代一樣，我們說PC時代的用戶是上網(wǎng)的過程，需要坐在電腦前瀏覽沖浪，但今天在移動端每個用戶的設(shè)備就代表背后的人，這個人本身是隨時在線，隨時可被觸達的，今天這種場景下怎么更好地利用終端能力去形成新的交互體驗。這幾個維度是我們概括下來移動時代在架構(gòu)、在整個技術(shù)體系里跟PC時代***的不同。#p#

51CTO：您剛剛提到在線的APP出現(xiàn)BUG需要進行處理，怎么樣更好的在用戶感覺不到的情況下處理這個BUG呢?或者是APP出現(xiàn)某個安全問題之類的，怎么做到用戶無感知呢?

徐昭：這是很好的問題，在早期階段技術(shù)很難去突破，因為移動端研發(fā)的特性和蘋果、谷歌的操作系統(tǒng)以及它的APP框架限制，我們發(fā)現(xiàn)了問題以后必須要重新迭代修復(fù)問題以后，生成一個新的應(yīng)用安裝包，以用戶下載和應(yīng)用更新的方式，升級安裝這個APP包以后才能修復(fù)問題，但是這個過程本身首先是沒有辦法保護用戶體驗(頻繁的應(yīng)用升級提醒)，同時沒有保證用戶的觸達率和更新覆蓋率，因為這是用戶自己選擇下載的過程，從流量考慮需要用戶確認(rèn)，很多情況下無法簡單地系統(tǒng)主動去更新。第二，這個更新周期非常漫長。蘋果的APP Store的整個審核過程是非常漫長的，所以這里有很多技術(shù)上和商業(yè)形態(tài)絕對的一些局限性。在這個過程中，我們嘗試的方式是盡可能考慮如何能夠通過動態(tài)化的方式去在運行期改變代碼的邏輯，使得能夠類似于微軟Windows熱補丁的方式，可以把補丁通過推送的方式，推送到終端的APP容器，形成一個增量的修復(fù)機制。在這個背景和技術(shù)方向的思考指引下，我們在安卓和iOS上分別實現(xiàn)了不同的動態(tài)加載機制。在安卓上，我們利用JAVA動態(tài)類加載器的機制，基于Android的DexClassLoader，實現(xiàn)運行時組件模塊的動態(tài)熱加載，具體實現(xiàn)可以參考github社區(qū)阿里開源項目Dexposed。在iOS有其他一些類似的方案在做這個事情，但機制上和JAVA稍有不同。

51CTO：APP在更新迭代時可能會增加一些新代碼，或者是以前功能不用了對應(yīng)的代碼沒有刪除，這時候出現(xiàn)了APP的臃腫。阿里是怎么為APP消腫呢?怎么能回到您所提到的APP時代的敏捷呢?

徐昭：這里是兩個問題，***個問題是怎么樣實現(xiàn)增量的推送，第二是怎么保證APP的瘦身效果，其實這兩個問題并不沖突。我們認(rèn)為***個問題里動態(tài)推送這個事情上也是分兩個不同場景，***是今天有兩個新的功能模塊上線，原來的版本的APP沒有這個模塊，這個模式我們叫做動態(tài)部署，這里的場景其實是APP本身新加一個功能模塊推送到客戶端上去。另外的場景可能是替換老的功能模塊，這兩種場景都存在?？赡軙?dǎo)致應(yīng)用最終的在線包會發(fā)生一些變化，但這是正常的過程。每次迭代APP新的版本出來，其新增或變更功能都會導(dǎo)致包容量大小的變化。剛才說的另一種熱補丁模式其實更適用在問題代碼修復(fù)的場景，因為我們熱補丁只是針對有問題的代碼進行替換，不是新增或改動功能。所以這部分的代碼量本身也控制的很小，所以我們會把補丁和動態(tài)部署兩個場景分開來看，雖然底層的技術(shù)會有一些共性。

關(guān)于瘦身的問題，目前來說這里不完全是技術(shù)上的因素決定的，因為本身可能跟業(yè)務(wù)增長有關(guān)。我們今天需要新增業(yè)務(wù)模塊，需要新增技術(shù)中間件，需要新增用戶體驗的創(chuàng)新功能，比如說虛擬化VR的一些場景功能。這里不可避免會引入一些新的代碼和資源進來。在這個角度上我們在策略上跟業(yè)務(wù)結(jié)合，一方面看今天在代碼的復(fù)用度上，怎么樣盡可能的去復(fù)用代碼模塊，比如說不同的業(yè)務(wù)功能模塊，設(shè)備基礎(chǔ)能力、端側(cè)公共API等沉降在中間件的層面上，盡量在底層復(fù)用這些能力。另一方面，如果需要新增的情況下我們會經(jīng)過嚴(yán)格的審核，本身這個功能是否是最合理的，一方面在業(yè)務(wù)上能夠帶來效果，另一方面在技術(shù)上它的包大小是否控制到***的限制，我們會有一個柵欄集成體系，在整個持續(xù)集成的過程中對整體包大小做嚴(yán)格的管控。我們也綜合考慮今天作為這么大量級的業(yè)務(wù)平臺，業(yè)務(wù)與功能模塊非常多，這個體系不可避免有很多功能模塊無法一次性完全集成為一體化的應(yīng)用安裝包。一方面部分非核心或者對用戶體驗要求沒有那么高的功能，可能我們會用H5頁面的方式去支撐，減少包的大小。另外一個策略可能在一些產(chǎn)品下有一些原生的功能，比如在虛擬試裝的過程當(dāng)中需要加載一些動畫庫，需要加載一些動態(tài)的模型和數(shù)據(jù)，這個過程中我們會基于動態(tài)下載的機制，通知用戶是否需要使用這個功能，然后自己選擇是否下載，將選擇權(quán)交給用戶。這是幾種模式和手段的結(jié)合。

51CTO：移動電子商務(wù)用戶常利用手機在碎片時間完成即興的瀏覽、比價、社會化推薦、收藏、快速購買，比如上班路上、下班路上、看電視、躺在床上、入睡前。那么阿里是如何解決***在線問題，并保證碎片化使用，從而實現(xiàn)用戶隨時隨地的無線購物?

徐昭：用戶的行為確實是非常有趣的現(xiàn)象。在無線化之后，手機淘寶的用戶量，增長超過了PC之后用戶行為比較大的變化，你會發(fā)現(xiàn)用戶行為的確是非常碎片化的。以前用戶在網(wǎng)購的場景下的訪問時段、訪問時長非常固定，可能到天貓、淘寶一逛就是十幾到幾十分鐘。但是，在移動端上，用戶行為是變成一天來多次，每次可能只是3到4分鐘，所以這是一個非常有意思的變化。今天，移動互聯(lián)網(wǎng)的特性決定了用戶就是隨時在線的，移動終端和移動互聯(lián)網(wǎng)本身的便利性決定了這樣的行為習(xí)慣，我們更多是技術(shù)上確保服務(wù)可用和體驗***。

我們考慮的更多是如何利用這些不同的場景，感知到用戶在不同場景和不同時段下使用的一些訴求，能夠如何更好的提供更多的內(nèi)容，更適應(yīng)場景化的內(nèi)容和服務(wù)，去提高用戶逛的效率，保證更好的用戶體驗。在這個層次上我們也結(jié)合了很多移動端特有技術(shù)進行了嘗試，包括我們的地理圍欄系統(tǒng)，包括個性化的推薦和場景的選擇，這里面會綜合結(jié)合多個維度，依托云端數(shù)據(jù)分析和客戶端用戶狀態(tài)反饋，嘗試做到給用戶推送的內(nèi)容會發(fā)生相應(yīng)的合理變化。

51CTO：你們是怎么感知到用戶是在坐車，或者是在上班，亦或是在家呢?

徐昭：這個技術(shù)上可以結(jié)合多種手段實現(xiàn)。包括基于大數(shù)據(jù)進行綜合的分析考慮。一方面我們會結(jié)合端上的一些特性和傳感器的功能，比如手持設(shè)備上的陀螺儀功能，訪問的時段特性，以及本身帶有的GPS定位信息等等綜合分析。在這里面我們在技術(shù)上會做大量創(chuàng)新和優(yōu)化，例如定位更多是一個被動定位的模式。我們會構(gòu)建一個地理圍欄的概念，基于特定信號源節(jié)點圍出一個特定區(qū)域出來，只有用戶觸發(fā)這些區(qū)域邊界的時候我們會進行一個被動的感知，確定用戶所處位置場景等，同時也確保他的隱私信息不會被濫用時此外這個過程當(dāng)中我們會嚴(yán)格控制用戶設(shè)備的功耗，而不是始終開著GPS不斷更新和掃描他的位置，這里面會結(jié)合商用場景和用戶體驗、用戶隱私各個綜合的維度去看。類似在家里或者上班等具體場景化的分析，我們更多考慮可以基于大數(shù)據(jù)進一步結(jié)合，從云端再去進行發(fā)掘，用戶行為所處不同的時段以及日期可能本身已經(jīng)反映其通常所處的環(huán)境，這里面可以有相應(yīng)的模型計算、算法對比以及多個維度疊加判斷的過程，所以這是一個場景化數(shù)據(jù)化的技術(shù)體系。

51CTO：您在無線客戶端框架設(shè)計及研發(fā)當(dāng)中曾經(jīng)遇到***的困境是什么，您是如何解決的呢?

徐昭：不同的階段應(yīng)該困境會不一樣，可能在前期階段我們整體上的很大問題在于研發(fā)模式。如何能夠盡可能的提升效率，如何將大規(guī)模研發(fā)團隊從職能上合理劃分，在研發(fā)模式上能夠支撐到不同的業(yè)務(wù)團隊之間有不同的迭代速度、不同的迭代控制力，能夠更高效更快速的響應(yīng)業(yè)務(wù)需求。展望未來，新的挑戰(zhàn)依然是前面說的移動架構(gòu)和PC架構(gòu)維度的差異性。在這五個差異性里我們未來集中需要重點解決的一些問題和挑戰(zhàn)在于，***，如何能夠讓我們的業(yè)務(wù)更快適應(yīng)用戶需求的變化，端上體驗和交互形態(tài)更動態(tài)。如何能夠利用更小的屏幕實現(xiàn)***的投放效率，例如基于不同地域的用戶、不同場景的用戶真正“千人千面”，能夠更靈活地去實現(xiàn)UI到內(nèi)容整體的動態(tài)和變化。第二是今天怎么樣能夠解決網(wǎng)絡(luò)層本身的效率、穩(wěn)定、復(fù)用等問題，包括到整個無線通訊協(xié)議層的更深度優(yōu)化和體驗提升。第三是在整個APP的開發(fā)框架層面上怎么樣更好的支撐多端并行的模式，包括在業(yè)務(wù)團隊層面，怎么樣能夠保障不同技術(shù)能力、不同經(jīng)驗背景的人員，能夠基于同一個框架產(chǎn)出更統(tǒng)一、更標(biāo)準(zhǔn)的質(zhì)量和用戶體驗。***，我們在質(zhì)量體系里面怎么樣更好更早的發(fā)現(xiàn)和預(yù)警線上的問題，更迅速地響應(yīng)用戶反饋的BUG或者問題等等。這些都是更深層次的挑戰(zhàn)。

51CTO：您認(rèn)為未來的移動生態(tài)架構(gòu)是怎么樣的?未來阿里無線有哪些什么計劃?

徐昭：我相信未來的移動生態(tài)一定是更加開放的生態(tài)。今天，WEB和Native技術(shù)在不斷地融合演進中，新技術(shù)產(chǎn)生也不斷推動業(yè)務(wù)和體驗層面的循環(huán)創(chuàng)新。對阿里來說，在電商的業(yè)務(wù)和技術(shù)形態(tài)上我們希望能夠進一步開放，包括我們很多在“云管端”架構(gòu)體系下所做的工作，希望能夠進一步開源、進一步分享給同行去復(fù)用。同時，我們也希望在整個移動技術(shù)演進的過程中，綜合思考今天和未來的移動研發(fā)模式如何去演進，什么樣的機制、框架、技術(shù)手段是最合理、最有價值的，我們相信未來一定是云管端架構(gòu)體系下APP生態(tài)的繁榮。