宗心：淘寶無線事業部資深開發工程師，手機淘寶iOS架構組開發工程師，2012年底參與開發手機淘寶iOS3.0版本，經歷大小幾十個版本的變遷，針對手機淘寶總體設計架構，hybrid框架解決方案，插件化解決方案以及手機淘寶核心業務組件均有參與和貢獻。（阿里巴巴無線事業部：負責手機淘寶并為阿里巴巴各條無線產品線提供基礎技術和設施）。
2014年手機淘寶經歷了自誕生以來最大規模的一次重構。經歷了去年業務的爆炸性增長，以及性能穩定性等多方面挑戰后，手機淘寶在開發模式，客戶端架構上面都必須做到輕量，透明，延展，敏捷。本內容會重點介紹手機淘寶iOS基礎架構的第三代架構如何演進落地，實現多條業務線間獨立并行、研發效率提升的目標，以及如何應對未來可能變化。以下是關于手機淘寶客戶端架構探索實踐的精彩內容：
如圖所示，手機淘寶從1.0用單工程編寫開始，東西非常簡陋；到2.0為索引許多三方庫的龐大的單工程；再到3.0打破了單工程開發模式實現業務復用，包括承載充值，聚劃算，航旅等業務，由于業務越來越多，我們想到了插件化的方案，就是制定一套業務的規則和標準，讓這些插件按照我們的標準，我們提供的庫進行開發。
我們遇到了產品和技術上的挑戰和開發的痛點，協同方式上的迭代依賴和分支管理困難，合并依賴關系過于復雜！調試自測效率低——模塊依賴下的不穩定因素，業務多，回歸成本大，測試資源嚴重不足！其他模塊引起的不穩定性因素。發布的靈活性不足——版本發布無法快速響應，線上已發布版本穩定性，灰度以及線上版本crash難以修復！由于很多APP集成到客戶端，各個業務的對接有一定的難度，自己的業務開發完全不夠支持這些功能，十余個團隊的代碼整合也不易，業務持續增長的量變將會導致質變。
2014年是手機淘寶自誕生以來最大規模的底層重構，改變了開發方式、工程結構、結構模型、打包方式。我們將圍繞開發效率和性能穩定性等一系列問題探索新的路線，主要有：
工程拆分——支持多團隊并行開發
多個業務團隊更改一個或多個文件，交叉管理時，底層的東西不穩定就沒有辦法進行上層開發，所以首先進行業務解耦；其次要進行獨立調試；最后修改配置完成集成。拆分的結果如圖所示，實踐證明，工程拆分以后，整體業務的盆跑速度有了明顯提升。
工程拆分分為三個階段：
- 開發階段：提供穩定的開發環境（底層庫，接口），各個業務方獨立開發；
- 測試階段：單獨業務獨立打包，針對該業務的測試回歸；
- 集成階段：修改podfile進行集成測試，針對整體流程做回歸。
架構重構——重新梳理容器和總線規則。
架構重構需要解決幾個問題：迭代開發，并行開發能力差；
耦合嚴重，核心功能（URL導航）復雜；試錯成本過高，增加減少業務帶來的成本；快速迭代下的穩定性問題。架構重構的指導思想如圖所示，我們制定規范，讓各個業務方自己運行，依照規范直接集成進來或出去。核心的架構在容器層，初始化在容器層統一管理，總線是一個核心的解耦方案，通過圖2中三種方式進行解耦。容器之上下全部為bundles，每一個業務全部做成bundle以后，當耦合度解的很好的時候，任何的bundles都可以拼成一個APP。
用總線的方式解除耦合，制定標準。
URL總線（跨平臺統一URL尋址方式）：三平臺統一URL，自動降級，中心分發（支持hook）。
服務總線 ：根據服務接口提供穩定服務。
消息總線 ：中心分發，按需加載。
總線也是為了分而治之的原則，各個業務方對其他業務方都是透明的，減少了以前全在一起的中心總線的復雜度問題。只需要遵守規則，不關心底層/其他業務實現。下圖是一個總線圖，
減少新業務接入/移除成本：
標準化：統一的通信調用標準，bundle間互通的基礎；無法回避的瘦身問題。
靈活性：Bundle自由組裝（淘寶生活，碼上淘），中間件基礎庫自由引入。
下圖為一個bundlapp,將手機淘寶等的部分bundles拿出來作一個配置 ，將業務bundles，底層bundles作一個重組，組出一個app手機窗口，目的是做一個bundle的復用。
及時響應線上問題如下所示
『Move fast and break things』
via Hot Patch
- 線上嚴重問題快速修復（小時級的響應時間）
AOP編碼形式 - Before/After/Replace 某個方法
- 編寫容易，發布規范
配套工具——使用有力工具增加開發效率。
工程拆分遇到的問題：頻繁的更換spec；源碼引入造成的pod update緩慢等原因；開發階段集成階段等問題。
工具解決：摩天輪自動打包平臺（自動生成spec，framework引入）；開發-集成-灰度，多階段管理。
其他工具解決的問題：核心鏈路性能監控平臺；Crash分析平臺。
6月初上線以來，重構結果為：集成 Bundle：30+；改造為服務：10+（登錄、緩存、搜索組件）；Hot Patch 修復線上嚴重故障 10+ 起；Patch 最大6KB，大部分不到1KB（iOS）。最大的陣痛是底層依賴遷移引起的編譯失敗，主要是由于底層庫的pod依賴規則不同步造成問題。
關于重構之后的未來探討如圖所示
PPT下載地址：http://club.alibabatech.org/resource_detail.htm?topicId=153
