微信支付在各个操做系统，各个应用下的挑战仍是蛮大的，这也得益于腾讯架构师的专业。程序员
做为一个重要业务，微信支付在客户端上面临着各类问题，其中最核心问题就是分平台实现致使的问题。小程序
容易出 Bug缓存
经过沟通保证不了质量安全
需求变动迭代周期长微信
数据上报不全面网络
缺乏业务及设计知识沉淀闭包
协议管理松散架构
缺乏统一的自动化测试app
-
好比下图就是以前安卓和 iOS 没有统一前的收银台
为了解决分平台实现这个核心问题，并解决以往的技术债务。咱们创建起了一整套基于 C++ 的跨平台框架，并对核心支付流程进行了重构。框架
微信支付跨平台从 iOS 7.0.4 版本起， 安卓从 7.0.7 版本起全面覆盖。
线上效果指标
以 iOS 上线状况为例：
②效能提高
7.0.4 版本需求一：收银台改版。
7.0.4 版本需求二：简化版本收银台。
什么是软件架构
什么是软件架构？正如 Ivar Jacobson （UML 之父）说过的同样，找五我的来回答这个问题，五我的可能都有各自不一样的答案。
架构定义能够有不少种说法，从代码规范到发布流程均可以是架构的一部分。
针对微信支付的业务特色，这里对架构的定义是：架构是系统的组成部件及其之间的相互关系（通信方式）。
这更符合咱们程序员平常编写业务代码时对架构的理解。也就是通俗意义上讲的 MVC，MVVM 等。
为何须要软件架构
早在 1986 年的时候，人月神话的做者在讨论软件的复杂性时，谈到：软件的本质复杂性存在于复杂的业务需求中。
而管理复杂性，最根本的手段就是职责分离。为了实现职责分离，代码重用，架构慢慢地复现出来。架构的本质是管理复杂性。
没有架构，咱们全部的代码都耦合在一块儿，人类的心智模型不擅长处理这种复杂性，架构的设立，和图书馆的图书分类，公司的组织划分等，本质都是同样的。是为了管理复杂性，以取得更高的生产力。
从 0 到 1 构建支付跨平台软件架构
在移动客户端领域，业界基于 C++ 来编写业务代码，并无成熟的架构。即便使用 C++ 编写业务逻辑，但都不涉及 UI，不涉及界面的跳转流程。
既然业界没有一个成熟的架构可借鉴，那么是否是直接把业界通用的架构简单套用一下就好？
抽象业务流程
如今业界通用的有 MVC，MVP，MVVM 。这些你们都熟悉的软件架构。可是这些软件架构都存在一个问题： 那就是没有处理好业务流程， 界面转场。
微信支付的流程多。而流程就是由一个个的界面（ViewController，Activity）和相关的业务逻辑组合而成。
上面的 MV(X)模式忽略了一个很是重要的一点，那就是业务流程，界面的转场究竟由谁负责。
也即 ViewController 与 ViewController 之间的关系由谁维护，业务流程的逻辑写在哪里。
若是还按照传统的 MVC 模式，那么 ViewController 本身负责和不一样的 ViewController 通信。
那么 ViewController 得不到复用，更致命的是业务流程的代码很是不清晰，业务流程的代码都被分散到各个 Controller 中， 而一个 Controller 又可能耦合了多个业务的代码。
举个例子：一个普通的转帐流程，可能会涉及风控拦截，实名验证， 收银台， 绑卡，支付成功页等等。
所以，为了适应微信支付流程多，界面跳转复杂的特色。架构抽象的第一步就是将业务流程抽象为一个独立的角色 UseCase。
和刚才基于 MVC 混乱的架构相比：
业务流程的代码可以聚合到 UseCase 中，而不是分散到原来 iOS，安卓的各个 ViewController，Activity 中。
业务流程和界面获得了复用。
契合微信支付多流程，界面跳转复杂的业务特色。
加入路由机制
既然流程获得了抽象，这个时候须要针对业务流程作更深的思考。在开发支付业务流程时，开发者不可绕过的问题有：
①流程之间，页面之间的流传
②特殊流程的处理
路由机制的核心思想，就是经过向路由传递数据，而后路由解析数据，并响应。
那么怎么创建这个支付领域模型的呢？建模，就是创建映射。领域知识+建模方法=领域建模。那么这里的领域知识，就是对支付业务流程的理解。
首先，微信支付业务特色就是和网络密切相关，流程和页面每每是由 CGI 串联起来。
所以创建模型时，最外层即是网络回包。对于路由机制，这里咱们只关心路由数据模型。
路由数据模型由路由类型，还有各个路由类型所须要的信息组合成。路由类型清晰的定义了要触发的行为。
到底是要开启一个 UseCase，仍是要打开一个界面，或者 网页，小程序，弹窗等等。
创建支付领域模型后，咱们路由的解析就变得很是清晰了。路由解析以后，会根据路由类型，触发不一样的动做。
好比流程，界面流转，会交给 UseCase 处理。而特殊流程，好比打开小程序，打开 WebView，弹窗这些行为会统一进行处理。
加入路由机制后，对比 iOS，安卓原来的旧架构：
统一了流程，页面的流转。清晰，易维护。
统一了特殊流程的处理，减小重复工做。
-
在加入路由机制的时候，结合微信支付和网络密切相关的特色进行了支付领域建模。支付后台协议重构 2.0 的核心思想也是围绕着这个路由机制展开。
再来看一下，加入路由机制后，对生产力的提高。以支付流程打开 WebView, 小程序为例，减小将近 83% 的代码。
更重要的是，这里的特殊流程，是在路由机制里面统一处理的，没有耦合到业务代码中，而且是可复用的。
管理网络请求
原来支付的请求，都是经过一个单例网络中心去发起请求，而后收到回包后，经过抛通知，或者调用闭包的方式回调给业务侧。
会存在这样的问题：
举个以前遇到的问题：
②CGI 生命周期问题
不时会有用户反馈一下，怎么没有作什么操做，忽然就会弹出网络报错。缘由就是 CGI 的生命周期有问题，在业务结束后，CGI 的回包仍然获得了处理。
解决方案以下：
①将 CGI 抽象为独立对象
在架构设计上来讲，旧架构是经过单例模式实现的集约型 API，而咱们新的架构则是经过命令模式实现的离散型 API。
所以，在跨平台软件架构中，咱们统一由业务流程 UseCase 进行发起。而且生命周期是一对一的，一个 CGI 只会有一个 UseCase 处理， UseCase 销毁后，CGI也随之销毁。
对比旧架构：
杜绝了一对多通讯形成的 Bug。
生命周期和业务逻辑绑定，不会出现业务结束，CGI 回来后再触发动做。
高内聚，低耦合。将 CGI 相关的数据，能力集中处理，业务侧无需感知。
-
提供统一的缓存，加密能力。
在第三步管理网络请求后，咱们的软件架构演进为这样子：
规范数据传递
iOS 和安卓的旧架构都存在信息传递不当和数据污染问题。这个问题最严重。iOS 和 安卓都出过很多 Bug。
具体缘由就是：
进入支付首页时，后台返回了数据，而后被写入到一个公共的 Model。
而后进入钱包页，再进入零钱页。这个公共 Model 一路被传递过去。
而后零钱页读取了公共 Model 的数据，可是代码没法处理，致使出现了这个让用户恐慌的问题。
除此以外，以前还有有不少发生在安卓，iOS ，像钱包页零钱展现错误。付款的时候银行卡失效等等问题。
这些问题五花八门，看起来发生的地方，场景都不同。每次遇到这类问题的时候，就只能去修修补补。
支付旧的架构采用了黑板模式，虽然方便了数据读写。可是带来的问题和收益彻底不成正比：
存在公共读写的数据类型。安卓传递的数据类型是一个字典，而 iOS 则是一个 Model 对象。全部的界面，业务逻辑都共用一个数据。
-
无序的数据流动。 数据的流动是不可追溯的，数据的修改能够发生在任意使用公共数据的地方。
那么支付跨平台软件架构，为了杜绝这样的问题我是这么作的:
去掉公共读写的数据类型。
传递值类型（Value Type）的数据, 后面流程修改数据时，不影响前面的流程。
单向传递数据，只依赖注入必要数据。
若是数据修改须要通知前序流程，使用代理模式通信。
规范数据传递后，对比旧架构：
从架构上根本解决了困扰微信支付已久的数据污染的问题。
数据的流动变为单向，数据流动变得可追溯。
总结
软件的本质复杂性存在于复杂的业务需求中。而软件架构的本质就是管理复杂性，所以真正的好的架构，正是在复杂的业务需求中反复提炼和总结概括而来，解决了真正的业务问题，不是空谈。
软件架构除了清理历史旧架构的缺陷，是咱们业务开发的基石以外。还可以赋能业务，为业务带来价值。
在创建软件架构的基础上，还围绕着软件架构创建起微信支付的跨平台自动化数据上报机制，防重复支付，安全横切等带来巨大业务收益的能力。有机会的话，后面也会进一步编写相关文章和你们交流探讨。
架构是一个不断演进的过程，随着新的支付业务基于跨平台软件架构的不断编写， 我也会对这个架构进行持续的更新迭代。让这个软件架构更贴合微信支付，更加健壮和完整。
做者：方秋枋
编辑：陶家龙
出处：《基于 C++ 构建微信客户端跨平台开发框架》
若是文章对您有帮助，请您分享、点赞、在看，一波三连支持一下做者，很是感谢！
本文分享自微信公众号 - Java学习指南（gh_85b94beaede2）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。