1、引言
作為一個重要業(yè)務(wù)妖滔，微信支付在客戶端上面臨著各種問題隧哮。
其中最核心問題就是分平臺實現(xiàn)導(dǎo)致的問題：
- 1）iOS 和安卓實現(xiàn)不一致：容易出 Bug、通過溝通保證不了質(zhì)量座舍；
- 2）擴(kuò)展性差且無法快速響應(yīng)業(yè)務(wù)需求：需求變更迭代周期長沮翔、數(shù)據(jù)上報不全面；
- 3）質(zhì)量保障體系不完善：缺少業(yè)務(wù)及設(shè)計知識沉淀曲秉、協(xié)議管理松散采蚀、缺少統(tǒng)一的自動化測試；
- 4）用戶體驗不一致：比如下圖就是之前安卓和 iOS 沒有統(tǒng)一前的收銀臺承二。
▲ 微信安卓片和iOS版榆鼠，沒有統(tǒng)一用戶體驗前的收銀臺功能
為了解決分平臺實現(xiàn)這個核心問題，并解決以往的技術(shù)債務(wù)亥鸠。我們建立起了一整套基于 C++ 的跨平臺框架妆够，并對核心支付流程進(jìn)行了重構(gòu)。微信支付跨平臺從 iOS 7.0.4 版本起， 安卓從 7.0.7 版本起全面覆蓋责静。
重構(gòu)后的軟件架構(gòu)原理如下圖所示：
本文分享了微信團(tuán)隊基于 C++ 的移動端跨平臺技術(shù)在重構(gòu)整個微信支付功能的過程中，對于移動端軟件架構(gòu)設(shè)計方面的思考和實踐總結(jié)盖桥。
術(shù)語約定：本文中的名詞 CGI 可以理解為一個網(wǎng)絡(luò)請求灾螃，類似HTTP請求。
擴(kuò)展閱讀：本文引用的所有圖片均來自《基于C++構(gòu)建微信客戶端跨平臺開發(fā)框架(PPT) [附件下載]》揩徊，如有需要可前往下載PPT原稿腰鬼。
2、關(guān)于作者
方秋枋：畢業(yè)于華中科技大學(xué)塑荒，現(xiàn)為微信客戶端高級工程師熄赡。目前主要負(fù)責(zé)微信支付的跨平臺開發(fā)框架與相關(guān)業(yè)務(wù)開發(fā)。
是開源項目 SwiftNotificationCenter 齿税，SwiftTimer 彼硫，SwiftCssParser 的作者。業(yè)余時間也喜歡混跡在 SwiftGG 翻譯組凌箕，老司機(jī) iOS 周報給大家翻譯文章拧篮，摘錄周報。喜歡 Simple and Stupid 的代碼牵舱。熱愛科技串绩、開源。
3芜壁、先感受一下本次重構(gòu)的線上效果指標(biāo)
以 iOS 上線情況為例礁凡。
3.1Crash 率
上線前后 Crash 率保持平穩(wěn)，沒有影響微信穩(wěn)定性慧妄，跨平臺支付無必現(xiàn) Crash顷牌，做到了用戶無感知切換。
舉個例子塞淹，大家可以用微信發(fā)一筆紅包韧掩，拉起的收銀臺和支付流程就是由基于C++編寫的跨平臺代碼所驅(qū)動的。
3.2效能提升
以核心支付流程代碼為例窖铡，跨平臺需要 3512 行疗锐，iOS 原生需要 6328 行。減少了近 45% 的代碼费彼。
以新需求開發(fā)為例：
- 1）7.0.4 版本需求一：收銀臺改版滑臊；
- 2）7.0.4 版本需求二：簡化版本收銀臺。
重構(gòu)后的軟件架構(gòu)對開發(fā)效率的提升對比：
- 跨平臺實現(xiàn)：iOS + 安卓 共計 3 人日箍铲，在封板時間前完成雇卷；
- 原生實現(xiàn)：iOS， 安卓封板時間后一周才基本完成；
- 跨平臺實現(xiàn)：iOS + 安卓共計 5 人日关划，在封板時間前完成小染；
- 原生實現(xiàn)：iOS， 安卓封板時間后一周才基本完成贮折。
那么支付跨平臺軟件架構(gòu)怎么樣有效進(jìn)行質(zhì)量保障裤翩，并且提升生產(chǎn)力呢？這是這篇文章的主要內(nèi)容调榄。
4踊赠、什么是軟件架構(gòu)
什么是軟件架構(gòu)？正如 Ivar Jacobson （UML 之父）說過的一樣每庆，找五個人來回答這個問題筐带，五個人可能都有各自不同的答案。
Ivar Jacobson博士：
現(xiàn)代軟件開發(fā)之父Ivar Jacobson博士被認(rèn)為是深刻影響或改變了整個軟件工業(yè)開發(fā)模式的幾位世界級大師之一缤灵。他是模塊和模塊架構(gòu)伦籍、用例、現(xiàn)代業(yè)務(wù)工程腮出、Rational統(tǒng)一過程等業(yè)界主流方法鸽斟、技術(shù)的創(chuàng)始人。Ivar Jacobson博士與Grady Booch和James Rumbaugh一道共同創(chuàng)建了UML建模語言利诺，被業(yè)界譽(yù)為UML之父富蓄。Ivar Jacobson 的用例驅(qū)動方法對整個OOAD行業(yè)影響深遠(yuǎn)，他因此而成為業(yè)界的一面“旗幟”慢逾。
架構(gòu)定義可以有很多種說法立倍，從代碼規(guī)范到發(fā)布流程都可以是架構(gòu)的一部分。
針對微信支付的業(yè)務(wù)特點(diǎn)侣滩，這里對架構(gòu)的定義是：架構(gòu)是系統(tǒng)的組成部件及其之間的相互關(guān)系（通訊方式）口注。這更符合我們程序員日常編寫業(yè)務(wù)代碼時對架構(gòu)的理解。也就是通俗意義上講的 MVC君珠，MVVM 等寝志。
5、為什么需要軟件架構(gòu)
早在 1986 年的時候策添，《人月神話》的作者在討論軟件的復(fù)雜性時材部，談到：軟件的本質(zhì)復(fù)雜性存在于復(fù)雜的業(yè)務(wù)需求中。
▲ 軟件工程不朽的經(jīng)典《人月神話》書籍(中文版)封面
而管理復(fù)雜性唯竹，最根本的手段就是職責(zé)分離乐导。為了實現(xiàn)職責(zé)分離，代碼重用浸颓，架構(gòu)慢慢地復(fù)現(xiàn)出來物臂。架構(gòu)的本質(zhì)是管理復(fù)雜性旺拉。
沒有架構(gòu)，我們所有的代碼都耦合在一起棵磷，人類的心智模型不擅長處理這種復(fù)雜性蛾狗，架構(gòu)的設(shè)立，和圖書館的圖書分類仪媒，公司的組織劃分等沉桌，本質(zhì)都是一樣的。是為了管理復(fù)雜性规丽，以取得更高的生產(chǎn)力蒲牧。
6撇贺、從0到1：構(gòu)建微信支付跨平臺軟件架構(gòu)
在移動客戶端領(lǐng)域赌莺，業(yè)界基于 C++ 來編寫業(yè)務(wù)代碼，并沒有成熟的架構(gòu)松嘶。即使使用 C++ 編寫業(yè)務(wù)邏輯艘狭，但都不涉及 UI，不涉及界面的跳轉(zhuǎn)流程翠订。
既然業(yè)界沒有一個成熟的架構(gòu)可借鑒巢音，那么是不是直接把業(yè)界通用的架構(gòu)簡單套用一下就好？
6.1抽象業(yè)務(wù)流程
現(xiàn)在業(yè)界通用的有 MVC , MVP, MVVM 尽超。這些大家都熟悉的軟件架構(gòu)官撼。但是這些軟件架構(gòu)都存在一個問題： 那就是沒有處理好業(yè)務(wù)流程， 界面轉(zhuǎn)場似谁。
微信支付的流程多傲绣。而流程就是由一個個的界面（ViewController，Activity）和相關(guān)的業(yè)務(wù)邏輯組合而成巩踏。
上面的 MV(X) 模式忽略了一個非常重要的一點(diǎn)秃诵，那就是業(yè)務(wù)流程，界面的轉(zhuǎn)場究竟由誰負(fù)責(zé)塞琼。也即 ViewController 與 ViewController 之間的關(guān)系由誰維護(hù)菠净，業(yè)務(wù)流程的邏輯寫在哪里。如果還按照傳統(tǒng)的 MVC 模式彪杉，那么 ViewController 自己負(fù)責(zé)和不同的 ViewController 通訊毅往。那么 ViewController 得不到復(fù)用，更致命的是業(yè)務(wù)流程的代碼非常不清晰派近，業(yè)務(wù)流程的代碼都被分散到各個 Controller 中煞抬， 而一個 Controller 又可能耦合了多個業(yè)務(wù)的代碼。
舉個例子：一個普通的轉(zhuǎn)賬流程构哺，可能會涉及風(fēng)控攔截革答，實名驗證战坤， 收銀臺， 綁卡残拐，支付成功頁等等途茫。如果是基于 MVC 這種架構(gòu)的話，很快代碼會變得難以維護(hù)溪食。
因此：為了適應(yīng)微信支付流程多囊卜，界面跳轉(zhuǎn)復(fù)雜的特點(diǎn)。架構(gòu)抽象的第一步就是將業(yè)務(wù)流程抽象為一個獨(dú)立的角色 UseCase错沃。同時, 把界面抽象為 UIPage栅组。 一個大的業(yè)務(wù)流程可以分解為一個個小的業(yè)務(wù)流程。
和剛才基于 MVC 混亂的架構(gòu)相比：
- 1）業(yè)務(wù)流程的代碼能夠聚合到 UseCase 中枢析，而不是分散到原來 iOS, 安卓的各個 ViewController玉掸，Activity 中；
- 2）業(yè)務(wù)流程和界面得到了復(fù)用醒叁；
- 3）契合微信支付多流程司浪，界面跳轉(zhuǎn)復(fù)雜的業(yè)務(wù)特點(diǎn)。
6.2加入路由機(jī)制
既然流程得到了抽象把沼，這個時候需要針對業(yè)務(wù)流程做更深的思考啊易。在開發(fā)支付業(yè)務(wù)流程時，開發(fā)者不可繞過的問題有下面這些饮睬。
流程之間租谈，頁面之間的流傳：
比如我們要給一個朋友轉(zhuǎn)賬，輸入金額捆愁，確認(rèn)支付,觸發(fā) Cgi 后割去。下一個流程是多變的。有可能用戶需要去實名牙瓢，有可能用戶要進(jìn)入一個安全攔截的 WebView劫拗，或者是正常拉起收銀臺。
注意：本文中的名詞 CGI 可以理解為一個網(wǎng)絡(luò)請求矾克，類似HTTP請求页慷。
那么以往在 iOS, 安卓分開實現(xiàn)時，都沒有一個統(tǒng)一的處理機(jī)制胁附。要么就是通過網(wǎng)絡(luò)回包的某個字段來判斷酒繁，要么就是本地維護(hù)一些狀態(tài)來決定下一步走什么流程等等。非常繁瑣控妻，易錯州袒。
特殊流程的處理：
支付業(yè)務(wù)流程還有個特殊的地方，那就是在正常流程的中間弓候，往往很多時候要需要插入一些特殊流程郎哭。比如有些地方要跳轉(zhuǎn) Webview, 有些地方要跳轉(zhuǎn)小程序他匪，有些地方要彈窗告知用戶風(fēng)險，或者終止當(dāng)前流程夸研，等等邦蜜。我們經(jīng)常需要在業(yè)務(wù)代碼里面不斷重復(fù)增加這樣的處理。
這些問題亥至，引導(dǎo)我想到悼沈，微信支付需要一個路由機(jī)制。
首先了解一下路由機(jī)制：
路由機(jī)制的核心思想姐扮，就是通過向路由傳遞數(shù)據(jù)絮供，然后路由解析數(shù)據(jù)，并響應(yīng)茶敏。
結(jié)合微信支付和網(wǎng)絡(luò)密切相關(guān)的特點(diǎn)壤靶。創(chuàng)新地將支付領(lǐng)域模型作為傳遞的數(shù)據(jù)。
那么怎么建立這個支付領(lǐng)域模型的呢睡榆？
建模萍肆，就是建立映射袍榆。領(lǐng)域知識 + 建模方法 = 領(lǐng)域建模胀屿。那么這里的領(lǐng)域知識，就是對支付業(yè)務(wù)流程的理解包雀。建模方法宿崭，我采用了 UML 建模。最終會落地為 Proto 協(xié)議供客戶端和后臺一起使用才写。
首先：微信支付業(yè)務(wù)特點(diǎn)就是和網(wǎng)絡(luò)密切相關(guān)葡兑，流程和頁面往往是由 Cgi 串聯(lián)起來。因此建立模型時赞草，最外層便是網(wǎng)絡(luò)回包讹堤。對于路由機(jī)制，這里我們只關(guān)心路由數(shù)據(jù)模型厨疙。
路由數(shù)據(jù)模型由路由類型洲守，還有各個路由類型所需要的信息組合成。
路由類型清晰的定義了要觸發(fā)的行為沾凄。究竟是要開啟一個 UseCase梗醇，還是要打開一個界面，或者 網(wǎng)頁撒蟀，小程序叙谨，彈窗等等。
然后：就是這些行為所需要的數(shù)據(jù)保屯。比如打開小程序所需要的參數(shù)手负，彈窗所需要的參數(shù)等涤垫。
建立支付領(lǐng)域模型后，我們路由的解析就變得非常清晰了竟终。路由解析之后雹姊，會根據(jù)路由類型，觸發(fā)不同的動作衡楞。
比如流程吱雏，界面流轉(zhuǎn)，會交給 UseCase 處理瘾境。
而特殊流程歧杏，比如打開小程序，打開 webview, 彈窗這些行為會統(tǒng)一進(jìn)行處理迷守。
我們在第一步把業(yè)務(wù)流程抽象為 UseCase犬绒。第二步則加入了路由機(jī)制。
加入路由機(jī)制后兑凿，支付跨平臺的軟件架構(gòu)演進(jìn)為這個樣子：
加入路由機(jī)制后凯力，對比微信的iOS、安卓原來的舊架構(gòu)：
- 1）統(tǒng)一了流程礼华，頁面的流轉(zhuǎn)咐鹤。清晰，易維護(hù)圣絮；
- 2）統(tǒng)一了特殊流程的處理祈惶，減少重復(fù)工作；
- 3）在加入路由機(jī)制的時候扮匠，結(jié)合微信支付和網(wǎng)絡(luò)密切相關(guān)的特點(diǎn)進(jìn)行了支付領(lǐng)域建模捧请。支付后臺協(xié)議重構(gòu) 2.0 的核心思想也是圍繞著這個路由機(jī)制展開。
再來看一下棒搜，加入路由機(jī)制后疹蛉，對生產(chǎn)力的提升。以支付流程打開 WebView,力麸、小程序為例可款，減少將近 83% 的代碼。更重要的是末盔，這里的特殊流程筑舅，是在路由機(jī)制里面統(tǒng)一處理的，沒有耦合到業(yè)務(wù)代碼中陨舱，并且是可復(fù)用的翠拣。
6.3管理網(wǎng)絡(luò)請求
首先看看原來 iOS 處理支付網(wǎng)絡(luò)請求的缺陷：
原來支付的請求，都是通過一個單例網(wǎng)絡(luò)中心去發(fā)起請求游盲，然后收到回包后误墓，通過拋通知蛮粮，或者調(diào)用閉包的方式回調(diào)給業(yè)務(wù)側(cè)。
會存在這樣兩個問題谜慌。
1）CGI 一對多通訊問題：
舉個之前遇到的問題：
如上圖所示然想，錢包發(fā)起的 Cgi 的回包會覆蓋收付款頁面的數(shù)據(jù)。之前在 iOS 只能通過修修補(bǔ)補(bǔ)欣范，增加場景值变泄，增加些標(biāo)記位來解決∧涨恚可能某一天就會又出現(xiàn)新的坑妨蛹。
具體的問題流程是：
- a. 進(jìn)入錢包頁面后，發(fā)起了一個 Cgi晴竞；
- b. 然后進(jìn)入收付款頁面也發(fā)起同一個 Cgi蛙卤；
- c. 如果收付款發(fā)起的回包先到；
- d. 然后錢包首頁的回包再到噩死。
2）CGI 生命周期問題：
如上圖所示颤难，不時會有用戶反饋一下，怎么沒有做什么操作已维，突然就會彈出網(wǎng)絡(luò)報錯行嗤。
原因就是 Cgi 的生命周期有問題，在業(yè)務(wù)結(jié)束后衣摩，Cgi 的回包仍然得到了處理昂验。
在我們的解決方案里捂敌，將在構(gòu)架的如下兩個方面進(jìn)行優(yōu)化和處理艾扮。
1）將 Cgi 抽象為獨(dú)立對象：
在架構(gòu)設(shè)計上來說，舊架構(gòu)是通過單例模式實現(xiàn)的集約型 API占婉，而我們新的架構(gòu)則是通過命令模式實現(xiàn)的離散型 API泡嘴。
也就是將 Cgi 封裝為獨(dú)立對象。我們把 Cgi 相關(guān)屬性和能力內(nèi)聚起來逆济。開發(fā)業(yè)務(wù)時酌予，只需簡單繼承 BaseCgi，設(shè)置一下參數(shù)即可奖慌。
2）劃分職責(zé)抛虫，明確生命周期：
關(guān)于 Cgi 由誰發(fā)起，之前安卓和 iOS 都沒有一個統(tǒng)一的做法简僧。有些人會放到 Activity建椰，ViewController，和 UI 代碼耦合起來岛马。
因此棉姐，在跨平臺軟件架構(gòu)中屠列，我們統(tǒng)一由業(yè)務(wù)流程 UseCase 進(jìn)行發(fā)起。并且生命周期是一對一的伞矩，一個 Cgi 只會有一個 UseCase 處理笛洛， UseCase 銷毀后，Cgi 也隨之銷毀乃坤。
對比舊架構(gòu)：
- a. 杜絕了一對多通信造成的 Bug苛让；
- b. 生命周期和業(yè)務(wù)邏輯綁定，不會出現(xiàn)業(yè)務(wù)結(jié)束湿诊，Cgi 回來后再觸發(fā)動作蝌诡；
- c. 高內(nèi)聚，低耦合枫吧。將 Cgi 相關(guān)的數(shù)據(jù)浦旱，能力集中處理，業(yè)務(wù)側(cè)無需感知九杂；
- d. 提供統(tǒng)一的緩存颁湖，加密能力。
在上述第a步和第b步例隆，我們抽象了業(yè)務(wù)流程甥捺，加入了路由機(jī)制：
在上述第c步管理網(wǎng)絡(luò)請求后，我們的軟件架構(gòu)演進(jìn)為這樣子：
6.4規(guī)范數(shù)據(jù)傳遞
iOS 和安卓的舊架構(gòu)都存在信息傳遞不當(dāng)和數(shù)據(jù)污染問題镀层。這個問題最嚴(yán)重镰禾。iOS 和 安卓都出過不少 bug。
首先我們來看看最近現(xiàn)網(wǎng)出現(xiàn)過的問題：
之前 iOS 出現(xiàn)唱逢，不少內(nèi)部同事吴侦，外部的用戶都在反饋：進(jìn)行零錢頁后，會無故彈空白框坞古。而支付又和金錢有關(guān)备韧，引起用戶的恐慌（見下面的演示視頻所示）。
https://player.youku.com/embed/XNDU5OTQ2NTMzNg==
大致的原因痪枫，如下圖所示：
织堂！[圖片上傳中...(image-d9074e-1601988280429-5)]</ignore_js_op>
具體原因就是:
- 1）進(jìn)入支付首頁時咧栗，后臺返回了數(shù)據(jù)蓬戚，然后被寫入到一個公共的 Model商架；
- 2）然后進(jìn)入錢包頁骗污，再進(jìn)入零錢頁御毅。這個公共 model 一路被傳遞過去坪稽；
- 3）然后零錢頁讀取了公共 Model 的數(shù)據(jù)碉怔，但是代碼無法處理捷泞，導(dǎo)致出現(xiàn)了這個讓用戶恐慌的問題。
除此之外黑竞，之前還有有很多發(fā)生在安卓捕发，iOS ，像錢包頁零錢展示錯誤很魂。付款的時候扎酷。銀行卡失效等等問題。
這些問題五花八門遏匆，看起來發(fā)生的地方法挨，場景都不一樣。每次遇到這類問題的時候幅聘，就只能去修修補(bǔ)補(bǔ)凡纳。
但是深究下去，會發(fā)現(xiàn)真正的原因帝蒿，是軟件架構(gòu)上存在的問題：
支付舊的架構(gòu)采用了黑板模式荐糜，雖然方便了數(shù)據(jù)讀寫，但是帶來的問題和收益完全不成正比葛超。
具體存在以下問題：
- 1）存在公共讀寫的數(shù)據(jù)類型：安卓傳遞的數(shù)據(jù)類型是一個字典暴氏，而 iOS 則是一個 Model 對象。所有的界面绣张，業(yè)務(wù)邏輯都共用一個數(shù)據(jù)答渔；
- 2）無序的數(shù)據(jù)流動：數(shù)據(jù)的流動是不可追溯的，數(shù)據(jù)的修改可以發(fā)生在任意使用公共數(shù)據(jù)的地方侥涵。
那么支付跨平臺軟件架構(gòu)沼撕，為了杜絕這樣的問題，我是這么做的:
具體的思路是：
- 1）去掉公共讀寫的數(shù)據(jù)類型芜飘；
- 2）傳遞值類型（Value Type）的數(shù)據(jù), 后面流程修改數(shù)據(jù)時务豺，不影響前面的流程；
- 3）單向傳遞數(shù)據(jù)燃箭，只依賴注入必要數(shù)據(jù)冲呢；
- 4）如果數(shù)據(jù)修改需要通知前序流程，使用代理模式通訊招狸。
上述的前面三步，我們抽象了業(yè)務(wù)流程邻薯，加入了路由機(jī)制裙戏，統(tǒng)一管理網(wǎng)絡(luò)請求：
那么規(guī)范數(shù)據(jù)傳遞后，我們軟件架構(gòu)就演進(jìn)為這樣子：
規(guī)范數(shù)據(jù)傳遞后厕诡，對比舊架構(gòu):
- 1）從架構(gòu)上根本解決了困擾微信支付已久的數(shù)據(jù)污染的問題累榜；
- 2）數(shù)據(jù)的流動變?yōu)閱蜗颍瑪?shù)據(jù)流動變得可追溯。
7壹罚、本文小結(jié)
軟件的本質(zhì)復(fù)雜性存在于復(fù)雜的業(yè)務(wù)需求中葛作。而軟件架構(gòu)的本質(zhì)就是管理復(fù)雜性，因此真正的好的架構(gòu)猖凛，正是在復(fù)雜的業(yè)務(wù)需求中反復(fù)提煉和總結(jié)歸納而來赂蠢，解決了真正的業(yè)務(wù)問題，不是空談辨泳。
軟件架構(gòu)除了清理歷史舊架構(gòu)的缺陷虱岂，是我們業(yè)務(wù)開發(fā)的基石之外。還能夠賦能業(yè)務(wù)菠红，為業(yè)務(wù)帶來價值第岖。在建立軟件架構(gòu)的基礎(chǔ)上，還圍繞著軟件架構(gòu)建立起微信支付的跨平臺自動化數(shù)據(jù)上報機(jī)制试溯，防重復(fù)支付蔑滓，安全橫切等帶來巨大業(yè)務(wù)收益的能力。有機(jī)會的話遇绞，后面也會進(jìn)一步編寫相關(guān)文章和大家交流探討烫饼。
架構(gòu)是一個不斷演進(jìn)的過程，隨著新的支付業(yè)務(wù)基于跨平臺軟件架構(gòu)的不斷編寫试读， 我也會對這個架構(gòu)進(jìn)行持續(xù)的更新迭代杠纵。讓這個軟件架構(gòu)更貼合微信支付，更加健壯和完整钩骇。
