1、手機淘寶客戶端架構探索實踐關于于佳（宗心）2011 : 阿里巴巴中文站 阿里巴巴手機客戶端 android/iOS 開發2012：阿里巴巴無線事業部 手機淘寶客戶端 iOS 開發阿里巴巴無線事業部負責手機淘寶并為阿里巴巴各條無線產品線提供基礎技術和設施發展歷程201020122013Android: 披著App外衣的Mobile WebiOS: 圍繞購物主鏈路的基本功能業務：單工程多分支開發底層：獨立的中間件工程Android：Atlas插件框架iOS：多工程插件化開發1.02.03.0產品挑戰承載并整合多樣化的業務生態研發挑戰 去年All-In的時候 大量業務的同時涌入 火車模型的懸崖效應

2、10余個團隊的代碼整合量變呼喚質變！痛點 協同方式 迭代依賴 分支管理合并依賴關系過于復雜！ 調試自測效率 模塊依賴下的不穩定因素 業務多，回歸成本大測試資源嚴重不足！其他模塊引起的不穩定性因素 發布的靈活性 版本發布無法快速響應 線上已發布版本穩定性灰度以及線上版本crash難以修復！2014手機淘寶自誕生以來，最大規模的底層重構改變：開發方式，工程結構，架構模型，打包方式探索新的路線圍繞著開發效率和性能穩定性等一系列問題工程拆分支持多團隊并行開發架構重構重新梳理容器和總線規則配套工具使用有力工具增加開發效率工程拆分并行開發業務解耦獨立調試集成之前，在穩定環境下測試易于集成修改配置完成集成工

3、程拆分開發階段 提供穩定的開發環境（底層庫，接口） 各個業務方獨立開發測試階段 單獨業務獨立打包 針對該業務的測試回歸集成階段 修改podfile進行集成測試 針對整體流程做回歸架構重構 需要解決的問題 迭代開發，并行開發能力差。 耦合嚴重，核心功能（URL導航）復雜 試錯成本過高，增加減少業務帶來的成本。 快速迭代下的穩定性問題。指導思想分而治之并行開發一切皆組件BundleApp解除耦合，制定標準總線 URL總線（跨平臺統一URL尋址方式）：三平臺統一URL，自動降級，中心分發（支持hook） 服務總線 ：根據服務接口提供穩定服務 消息總線 ：中心分發，按需加載開發透明 只需要遵守規則，不

4、關心底層/其他業務實現Bundle (deployable unit)RuntimeBus (UI & Service & Message)Lifecycle ManagementBundle ManagementUIsServicesApp/Service ProjectRuntimeProjectBus LibraryLibrariesLibraries減少新業務接入/移除成本標準化統一的通信調用標準，bundle間互通的基礎無法回避的瘦身問題靈活性Bundle自由組裝（淘寶生活，碼上淘）中間件基礎庫自由引入及時響應線上問題Move fast and break thing

5、svia Hot Patch線上嚴重問題快速修復（小時級的響應時間）AOP編碼形式Before/After/Replace 某個方法編寫容易，發布規范配套工具工程拆分遇到的問題：頻繁的更換spec源碼引入造成的pod update緩慢等原因開發階段集成階段等問題工具解決摩天輪自動打包平臺（自動生成spec，framework引入）開發-集成-灰度，多階段管理其他工具解決的問題：核心鏈路性能監控平臺Crash分析平臺耗時2個月完成 6月初上線以上 集成 Bundle：30+ 改造為服務：10+（登錄、緩存、搜索組件） Hot Patch 修復線上嚴重故障 10+ 起 Patch 最大6KB，大部分不到1KB（iOS） 最大的陣痛：底層依賴遷移引起的編譯失敗Bundle重組，互通有無。業務復用，減少人力基礎復用，做深做精敏捷開