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

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

徐昭于2012年加入天貓成為技術核心，前后帶領過天貓賣家&導購詳情等多支技術團隊，親身打造并見證雙11成為電商行業的重要節日。現任手機淘寶賣家生態團隊技術負責人，主要負責無線店鋪、微淘、小鋪、開放等賣家鏈路的技術架構及研發工作。目前專注在無線整體架構、大型復雜移動應用構建框架及無線技術開放等領域，同時關注新技術和開發模式在移動互聯網產品中的演進和落地。

采訪實錄如下：

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

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

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

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

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

徐昭：在核心改造方面，首先將移動端上的業務模塊和基礎中間件歸一化處理，基于端側容器拆分成多個組件的模式。這個過程相當于把不同的業務和技術團隊所負責開發的業務模塊、基礎技術模塊進行拆分解耦?；诖耍讓舆\行時容器能夠統一加載并管理不同組件的生命周期，從而促使上層業務團隊得以按照自身的節奏獨立研發、測試、集成。并基于這個模式來進一步實現整個研發過程的高效迭代、動態部署、智能發布等創新成果。

51CTO：在您看來現在的無線架構和之前的PC架構存在哪些差異性?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

51CTO：您在無線客戶端框架設計及研發當中曾經遇到***的困境是什么，您是如何解決的呢?

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

51CTO：您認為未來的移動生態架構是怎么樣的?未來阿里無線有哪些什么計劃?

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