本文爲攜程移動開發總監陳浩然在2015年10月份的ArchSummit全球架構師峯會上的演講總結。由於面向受衆爲架構師，因此不會涉及到很多技術細節。通過本文，你可以瞭解攜程通過哪些手段來優化它的App架構的。
『攜程旅行App』作爲攜程超級App產品，是公司全品類旅行產品的核心售賣入口，過去兩年爲了更好支撐無線業務的快速發展，攜程移動App在產品和技術架構方面也做了大量的優化。
產品
產品方面，攜程App從原先的iPhone、iPad、Android Phone、Android Pad和Windows Phone共五個版本精簡爲Universial iOS和Universial Android兩個版本，以便於集中研發和市場資源發佈新產品。
無線後端服務架構
無線後端服務架構方面，原有的無線架構（圖一）是所有無線服務耦合成一個統一的服務模塊，囊括了所有提供給客戶端訪問的API。
（圖一）
在統一服務模塊功能較少的時候，這套架構完全符合業務功能需求，但當功能迭代加快，問題不斷出現：
-
每個API都是DLL動態庫形式（.net）實現，在某些公共邏輯接口發生變化時，不同時期上線的API可能使用了不同版本的邏輯接口定義，會導致運行時出現詭異結果或者進程Crash，影響穩定性；
-
每次大版本發佈上線，從測試到全面發佈完畢，都需要全量回歸測試過程，開發和測試進度嚴重耦合，影響發佈效率；
-
新增的低優先級API可能穩定性不好，出現問題時會影響到整個服務進程的穩定性。
除了這種完全耦合的弊端之外，還存在其他諸如缺少負載均衡、越少監控、缺少熔斷等影響後端穩定性的問題。於是我們開始嘗試使用一種新的無線架構：Gateway（圖二）。
（圖二）
攜程基於Netflix的開源項目Zuul開發了無線Gateway（曾在2015年QCon上海會議中分享）。Gateway的職能是負責接收來自無線端的所有API請求，並將他們路由到正確的目標應用服務器，並且提供限流、隔離、熔斷等功能，保證了無線服務的長期穩定運行，擁有的彈性容錯機制也減少了日常運維工作。同時該Gateway提供了多維度的監控數據，並與報警系統對接，實時監控線上情況，達到運維自動化。
App工程架構
App工程架構方面，原先的App開發還是單工程單構建的方式，各產品間的代碼耦合嚴重，於是進行了App工程的解耦（圖三和圖四）。
（圖三）
（圖四）
解耦後各產品間代碼完全獨立，相互頁面和功能的跳轉走數據總線或者URL總線方式來實現，打包時的資源問題可以通過Run Script（iOS）和Gradle（Android）來定製化解決。
在App工程架構解耦後，緊接着是兩個問題：
-
開發框架是否滿足產品開發需求？
-
性能和質量是否達到用戶體驗要求？
爲了解決第一個問題，我們梳理了現有的App功能，將通訊、定位、Hybrid框架、數據庫、登錄、分享、基礎庫等核心功能實現了SDK化，也提供給公司其他App直接使用；同時將App內部的公共業務組件例如地圖、日曆、城市、圖片、通訊錄等實現了統一。
要解決第二個問題『App性能和質量』，首先需要了解App性能的現狀，即App端性能的採集。常規做法有兩種：1. 使用第三方性能採集SDK，例如OneAPM、聽雲等第三方工具；2. 自建。攜程爲了完整掌握用戶數據採用了自建的方式：App通過日誌SDK採集日誌，上傳至日誌服務端，日誌消息經Kafka消息隊列存入HDFS（RCFile格式）分佈式文件存儲系統，後期的數據查詢均基於Hive系統來實現。
App端的性能數據會在多種緯度（操作系統、App版本、網絡狀況、位置）下采集網絡（網絡服務成功率、平均耗時、耗時分佈等）、定位（經緯度成功率、城市定位成功率等）、啓動時間、內存流量等各類指標。其中像網絡服務性能是對於用戶體驗至關重要的端到端性能，也是優化的核心依據。
性能數據採集後需要採用簡單直觀的Portal進行展示，攜程爲無線業務開發了Web端和App端性能展示Portal，圖五是網絡性能的截屏，數據會每小時進行更新聚合並展示。
（圖五）
基於完備的性能採集數據，很多App性能便可以依據數據進行迭代優化，例如App網絡服務方面，攜程App採用了以下多種優化手段：
-
使用TCP長連接實現網絡服務，減少網絡連接時間
-
根據網絡狀況2G/3G/4G/WIFI進行調優參數
-
根據連接/讀/寫不同階段使用重試機制
-
使用IP列表避免DNS解析失敗或者劫持，無需進行DNS解析
-
根據網絡延遲選擇服務端IP（使用Ping）
-
使用ProtocolBuffer+Gzip減少Payload
經過這些優化手段，攜程App的端到端網絡服務成功率從最初很差的95.32%提升至99.87%，用戶體驗得到明顯提升。
攜程App的Hybrid框架也是經過多個版本的迭代，已經支持強大的插件功能，已經做到凡是可以用Native的組件通通使用Native組件來優化Hybrid業務的體驗。攜程Hybrid框架在設計之初即採用了離線包功能：Hybrid業務整體打包在App中，節省了用戶打開頁面時的資源加載時間；同時離線包支持查分增量更新，並通過7z壓縮方式進一步降低了增量更新包的大小，相對zip壓縮減少30%大小。
Native的插件化和HotFix
Native的插件化和HotFix方面，我們在iOS端使用開源的解決方案JSPatch，在Android端採用了自研的解決方案DynamicAPK，可以支持各組件的資源及代碼的更新。DynamicAPK方案無需做任何activity/fragment/resource的proxy實現，使得原有的業務代碼無需修改即可支持，遷移代碼很小，同時可以提升App啓動時間，詳情請參考GitHub。
其他優化都是針對特定的業務場景展開，例如Android的海外地圖沒有好的解決方案，iOS的地圖控件又存在人在國外看國外和人在國外看國內地圖數據精度低的問題，攜程基於Google地圖開發了Hybrid版地圖，用於在特定場景的業務需求；Hybrid網絡性能優化，通過Hybrid接口發送Native網絡服務，可以避免DNS劫持並且利用Native端的TCP長連接；海外網絡性能優化，通過TCP海外加速產品實現鏈路優化；圖片性能優化方面使用了WebP圖片格式，可以降低30-40%圖片大小，圖片分片上傳等。
移動端技術發展很快，攜程也在積極嘗試新技術，例如React Native（已在賬戶信息部分頁面使用），新的網絡協議SPDYHTTP/2.0，Apple/Huawei/Samsung Watch App等都做了大量嘗試，以期能夠提升產品品質。
總之，App架構的技術優化沒有盡頭，我們會繼續以開發效率、性能、質量、新技術幾個緯度不斷推進，希望未來可以有更多內容分享給業內同行。
轉自：移動開發前線