本文原文由微信客户端高级工程师方秋枋原创发表于WeMobileDev公众号，收录时有修订和加工，感谢作者的无私分享。
1、引言
作为一个重要业务，微信支付在客户d | { = @ Z端上面临% q 0 ? = h着各种问题。
其中最核心问题就是分平台实现导致的问题：
1）iOS 和j / M安卓实现不一致：容易出 Bug、通过沟通保证不了质量；
2）扩展性差且无9 K ^ J F y q法快速响应业务需求：需求变更迭代: 7 i 0周期长、数据上报不全面；
3）质量保障体系不完善：缺少业务及设计知识沉淀、协议管理松散、缺少统一的自w J D v 8动化测试；
4）用户体验不一致：比如下图就是之前安卓和 iOS 没有统一前的收银台。
▲ 微信安卓片和iOS版，没有统一用户体验前的收银台功能
为了解决分平台实现这个核心问题，并解决以K r X ) H 2 J往的技术债务。我们建立起了一整套基于 C++ 的跨平台框架，并对核心支付流程进行了重构。微信支付跨平台从 iOS 7.0.4 版本起， 安卓从 7.0.7 版本起全面覆盖。
重构后的软件架构原理如下图所示：
本文分享了微信团队基于 C++ 的移动端跨平台技术在重构整个微信支付功能的过程中，对于移动端软件架构设计方面的思考和实践总结。
术语约定：本文中的名词 CGI 可以理解为一个网络请求，类似HTTP请求。
扩展阅读：本文引用的所有图片均来自《基于C+h C w q # z+构建微信客户端跨平台开发框架(PPT) [附件下载]》，如有需要可前往下载PPT原稿。
（本文同步发布于：http://www.52im.net/thread-2958-1-1.html）
2、关于作者
方秋枋：毕业于华中科技大学，现为微信客户端高级工程师。目前主要负责微信支付的跨平台开发框架与相关业务开发。
是开源项目 SwiftNotificationCenter ，SwiftTimer ，SwiftCssParser 的作者。业余d + S { 6 L 7时间也喜欢l b O E U混迹在 SwiftGG 翻译组，老司机 iOS 周报给大家翻译文l B 4 + 7 D L章，摘录周报。喜欢 Simple and Stupid 的代码。热爱科技、开源。
方秋枋的Github：http8 j | v * ? { ^s://github.com/100mango
方秋枋的微博：https://weibo.& 5 L %com/100mango?is_hot=1
方秋枋的知乎：ht q M ! X https://www.zhihu.com/people/fang-qiu-fang
3、先感受一下本次重构的线上效果指标
以 iOS 上线情况为例。
3.1 Crash 率
上线前后 Cra[ 3 ; V i 8 ush 率保持7 k K L e平稳，没u w S ! l d q r P有影响微信稳n 8 / z - # W定性，跨平台支付无必现 Crash，做到了用户无感知切换。
举个例子，大家可以用微信发一笔红包，拉起的收银台和支付流程就是由基于C++编写的跨平台代码所驱动的。
3.1 A E 8 _ G M ) U2 效能提升
以核心支付流程代码为例，跨平台需要 3512 行，iOS 原生H ( l _ + M需要 6328 行。减少了近 4w y ; : Z m5% 的代码。
以新需求开发为例：
1）7.0.4 版本需求一：收银台改版；
2）7.0.4 版本需9 Y G ) J求二：简化版本收银台。
重构后的软件架构对开发效率的提升对比：
跨平台实现：iOS + 安卓 共计b J s 6 k H X d 3 人日，在封板时间前完成；
原生t F 8 K 5 J I实现：iOSj i & s R i ?， 安卓封板时间后一周才基本完成；
跨平台实现：iOS + 安卓共计 5 人日，在封板时间前完成j ( X；
原生r u D f实现：iOS， 安卓封板时间后一周才基本完成。
那么支付跨平台软件架构怎么样有效进行质W z t y ~ U m量保障，并且提升生产力呢？这是这篇文K m g v q T i 4 2章的主要内容。
对基于 C+K V L Z J ) u s Z+ 如何( I S从零到一构建跨平台框架感兴趣的同学，可以看看我在2019 QCon 广州站的演讲 《基于 C++ 构建微信客户端跨平台开发框架》PPT原稿。
4、什么是软件架构
什么是软件架构？正* W T 5 U 5 W j如 Ivar Jacobson （UMP s ( n TL 之父）b : z r ] M R t说过的一样，找五个人来回答这个问题，五个人可y 2 N L能都有各自t k Z c I } D B不同的答案。
Ivar Jacobson博士：
现代软件开发之父Ivar Jacobson博士被认为是深刻影响或改变了整个软件工业开发模q v O Q ]式的几位世界级大师之一。他是模块和模块架构、用例、现代业务工程、Rational统一过程等业界主流方法、技术的创始c S | 5人。Iz b V }var Jacobson博士与Grady Booch和James Rumbaugh一道共同创建了UML建模语言，被业界誉为UML之父y ; s。Ivar Jacobson 的用例. ^ M ` U 1驱动方8 s R法对整个OOAD行业影响深远，他因此而成为业界的一面“旗帜”。
架构定义可以有很多种说法w I : S，从代码规范到发布流程都可以是架构的一部分。
针F - M [ q | +对微信支付的+ 1 i ] y =业务特点，这里对架构的定义是：架构是I ) H . 7系统的组成部件及其之间的相互关系（通讯方式）。这更符合我们程序员日常编写业务代码u 4 K _ # 7 * 1 o时对架构的理解。e Z Y P % F - o E也就是通] = h b d e o俗意义上讲的 MVC，MVVM 等。
5、u K z = [ 4 J N D为什么需要软件架构
早在 1986 年的时候，《人月神话》的作者在讨论软件的复杂性时，谈到：软件的本质复杂C y I 6性存在于复杂的业务需N : 3 | h求中。
▲ 软件工程不朽的经典《人月神话》书籍(中文版)封面
而管理复] s $ B g杂性，最根本的手段就是职责分离。为了实现职责分离，代码重用，架构慢慢地复现出来。架构的本质是管理复杂性。
没有架构，我们所有的代码都耦合在一起，m 5 @人类的心智模型不擅长处理这种复杂性，% s / d i E J g架构的设立，和图书馆的图书分类，公司的组织划分等，本质都是一样的。是为了管理复杂性，以取得更高的生产力。
5、从0到1：构建微信支付跨平台软件架构
在移动客户端领域，业界基于 C++ 来编G w B 8写业务代码，并没有成熟的架构。即使使用 C++ 编写业务逻辑，但都不涉及 UI，不涉及界面的跳转流程。
既然业界没有一个成熟的架构可借鉴，那么是不是直接把业界通用的架构简单套用一下就好？
5.1 抽象业务流程
现在业界通 - : Z B o d用的有 MVC , MVP,_ 2 w r MVVF = M 6M 。这些大家都熟悉的软件架构。但是这些软件架构都存在一个问题： 那就是= B ] n没有处理好业务流程， 界面转场。
微信支D S q W | 2 7 +付的流程多。而流程就是由一个个的界面（ViewController，Activity）和相关的业务逻辑组合而成。
上面的 MV(X) 模式忽略了一个非常重要的一点，那就是业务流程，界面的转场究竟由谁负责。也即 ViewController 与 ViewController 之间的关系由谁维护，业务流程的逻辑写在哪里。如果还按照传统的 MVC 模式，那么 ViewController 自己负M _ @ W x y @责和不同的 ViewController 通讯。那么 ViewCoI = 2 m n : ; Tntroller 得不到复用，更致命的是业务流程的代码非常不清晰，业务流程的代码都被分散到各个 Contra o K 5 f roller 中& & E x B = {， 而一个 Controller 又可能耦合y ( : ` R {了多个业务 O m ) o + L的代码。3 b + r | T g U
举个例子：一个普通的转账流程r r c 7 / { 4 x，可能会涉及风控拦截，实名验证， 收银台， 绑卡，支付成功页b n r 1 V等等。如果是基于 MVC 这种架构的话，很快代码会变得难以维护。
因此：为了适应微信支付流程多，界面F d q ! B { j 4跳转复杂的特点。架构抽象的第一步就是将业务流程抽象为一个独立的角色 UseCase。同时[ u e, 把界面抽象为 UIPage。 一个大的业务流程可以分解为一个个小的业务流程。
和刚才基于 MVC 混乱的架构相比：
1）业务流程的代码能够聚合到 UseCase 中，而不是分散到原G $ k V } ) )来 iOS, 安卓的各个 ViewController，Activity 中；
2）业务流程和界面得到了复用；
3）契合微信支付多流程，界面跳转k o 2 ^ 7 复杂的业务特点。
5.2 加入路由机制
既然流程得到了抽象，这个时候需要针对业务流程做更深的思考。在U / y , P F X开发支付业务流程时，开发者不可绕过的问题有下面这些。
流程之间，页面之间1 _ h q P F $ 7的流传：
比如我们要给一个朋友转账，输入金额v , e 5 I P w |，确认支付,触发 Cgi 后。下一个流程是多变的。有可能% 3 E ; o C $ x用户需要去实名，有可能用户要进入一个安全拦截的 WebView，或者是正常拉起收银台。
注意：本文中的名词 CGI 可以理B 5 i & e o @解为一个网络请求，类似HTTL 6 1 ` + 6 TP请求。
那么以往在 iOS, 安卓分开实现时，都没有一个统一的处理机制。要么就是通过网络回包的某个字段来判断，要么就是本地维护一些状态来决定下一步走) @ v l . 3 k | u什么流程等等。非常繁琐，易错。
特殊流程的E q g = S S Z 3 2处理：
支Z M * e付业务流程还有个特殊的地方，那就是在正常流程的中间，往往很多时候要需要插入一些特殊流程。比如有些地方要跳转 Webview, 有些地方要- 9 ^ h 5 D A 9 (跳转小程序，有些地方要弹窗告知用户风险，或者终止当前流程，等等。我们经常需要在业务代码里面不断重复增加这样的处理。
这些问题，引导我想到，微信支付需要一个路由机制。z | m P 3 f
首先了解一下路由机制：
路由机制# ^ @ c {的核心思想，就是通过向路由传递数据，然后路由解析数据，并响应。
结合微信支付和网络密切相关的特点。创新地将支付领域模型作为传递的数据。
那么怎么建立这个支付领域模型的呢？
建模，就是建立映射。领域知识 + 建模方法 = 领域建模。那么这里的领域知识，就是对支付业务流程的理解。建模方法，我采用了 UML 建模。最终会落地为 Proto 协议供客户端和后台一起使用。
首先：微信支付业务特点就是和网络密切s 4 =相关，流程和页面往往是由 Cgi 串联起来。因此建立模型时，最外层便 L 9 . * k t a是网络回5 ~ L }包。对于路由机制，这里我们只关心路由数据模型。
路由数W * l I v据模型由路由类型，还有各个路由类型所需要的信息组合成。
路由类型清晰的定义) O E : , # |了要触发的行为。究竟是要开启一个 UseCase，还是要打开一个界面，或者 网页，小程序，弹窗等等。
然后：就是这M . R X i (些行为所需要的数据。比如打& H 6 C M 8 W开小程序所需要的参数，弹窗所需要的参数等。
建立支付领域模型后C u z : J b v，我们路由的解析就变得非常清晰了。路由解析之后，会根据路由类型，触发不同的动作y 1 I M x -。
比如流程，界面流转，会交给 UseCase 处理。
而特殊流程，比如; P _ f (打开小程序，打开$ 0 g , N webview, 弹窗这些行为会统一进行处理。
我们在第一步把业务流程抽象为 UseCase。d c $ N t $第二步则加入了路由机制[ } % W +。
加入路由机制后，支付跨平台的软件架构演进为这个样子：
加入路由机制后，对比微信的iOS、安卓原来v x Z 3 ] 0 A d的旧架构：
1）统一了流程，页面的流转。清晰，易维M n Q F _ N护；
2）统一了特殊流程9 $ L w J x 9 M的处理，减少重复工作；
3）在加入路a : j由机制的时候，结合微信支付和网络密切相关的特点进行了支付领域建模。支付后台协议重构 2.0 的核心思想也是围绕着这个路由机制展开。
再来看一下，加入路由机制后，对生w ) O @ 1产力的提升。以支付流程打开 WebView,、小程序为例，减少将近 83% 的代码。更重要的是，这里的特殊流程，是在路由机制里面统一处理的，没有耦合到业务代码中，并且是可复用的。
5.3 管理网络请求
首先看看原来 iOS 处理支付网络8 { : U T 0 X请求的缺陷：
原来支付的请求，都是通过一个d 6 /单例网络中心去发起请求，然后收到回包后，通过抛通知，或者调用闭包的方式回调给业c m V ~ W务侧。
会存在这样两个问题。
1）CGI 一对多通讯问题：
举个之前遇到的问题：
如上图所示，钱包发^ _ : w Z V z起的 Cgi 的回包会覆盖收付款页面的数据。之前在 iOS 只能通过修修补补，增加场景值，& R [ D P增加些标记位来解决。可能某一F [ X q 5 9天就会又出现新的坑。
具体的问题流程是：
a. 进入钱包页面后，发起了一个 Cgi；
b. 然后进入收付款页面也发起同一个 Cgi@ Z x；
c. 如果收付款发起的回包先到；
d. 然后钱包首页的回包再到。
2）CGI 生命周期问题：T ) ) 9
如上图所示，不时会有用户反馈一下，怎么没有m w V 6 ~ ] .做什么操作，突然就会弹出网络报错。
原因就是 Cgi 的生命周期有问题，在业务结束后，Cgi 的回包仍然得到了处理。
在我们的解C - V Q L ] L } (决方案里，将在构架的如下两个方面进行优化和处理。
1）将 Cgi 抽象为独立对象：
在架构设计上来说，旧架构是通过单例模式实现的集约型 API，而我们新的架构则是M 7 t k z # j通过命令模式实现的L D X q离散型 API。
也就是将 Cgi 封装为独立对象。我们把 Cgi 相关属性和能力内聚起来。开发业务时，只需简单继承 BaseCgi| x V，设置一下参数即可。
2）划分职责，明i h p = 1 H 2确生命周期：
关于 Cgi 由谁发# j & W起，之前安卓和 iOS 都没有一个统一的做法。有些人会放到 Activity，ViewController，和 UI 代码耦合S o l m W 2 I 8 ,起来。
因此，在跨平台软件架构中，我们j % Z ? b & e { ]统一由业务流程 UseCase 进行发起。并且生命周期是一对一的，e E = x , & c一个 Cgi 只会有一个 UseCase 处理， UseCase 销毁后，Cgi 也随之销毁。
对比旧架构：
a. 杜绝了一对多通信造成的 Bug；
b. 生命周期和业务逻辑绑定，不会出现业务结束，Cgi 回来后再触发动作；
c. 高内聚，低耦合。将 Cgi 相关的数据，能力集中处理，业务侧无需感知；
d. 提& K Q ] 1 + V I a供统一的缓存，加密能力。
在上述第a步和第b步，我们抽象了业务流程，加入了路由机制：
在上述第c步管理网络请求后，我们的软件架构演进为这样子：
5.4U m h C 规范数据传递
iOS 和安卓的旧架构都存在信息传递不当和数据污染问题。这个问题最严重。iOS 和 安卓都u ] $ } ,出过不少 bug。
首先我们来看看最近现网出现过的问题：
之前 iOS 出现，不i Y少内部同O ! i m _ v 8 l事，外部的用户都在反馈：进行零钱页后，会 K 1 + [ q i c 无故弹空白框。而支付又和金钱有关，引起用户的恐慌（见下面 R u - T m W %的演示视频所示）。
▲ 视频原地址：点此进入
大致: ] L ` , g o S的原因，如下图所示：
具体原因就是:
1）进入支付首页时，后台返回了数据，然后被写入L v [到一个公共的 Model；
2）然后进入钱包页，再进入零钱页。这个公共 model 一路被传递过去；
3）然后零钱页读取了公8 ? } /共 Model 的数据，但是代码无法处理，导致出现了这个让用户恐慌的问题。
除F : P l此之外，之前还有有很多发生在安卓，iOS ，像钱包页零钱展Q w R 5示错误。_ u ) 5 P e &付款的时候。银行卡失效等等问题。
这些问题五花八门，看起来发生的地方，场景都不一样。每次遇到这类问题的时候，就只能去修修补补。
但是深究下去，会发现真正的原因，是软件架构上存在的问题：
支付旧的B g } X @架构采用了黑板模式，虽然方便了数据读写，但是带来的问题和收益完全不成正比。
具体存在以下问题：
1）8 X t n (存在公共读_ _ U $ l F j ) 0写的数据类型：安卓传递的数据类型是一个字典，而 iOS 则是. V ~ : v =一个 Model 对象。所有的界面6 / -，业务逻辑都共用一个数据；
2）无序的数据流动：数据的流动是不可追溯的，数据的修改可以发生在任意使用公共X T ( ; &数据的地方。
那么支付跨平台软件架构，为了杜绝这样的问题，我是这么做的Z y %:
具体的思路是：
1）去掉公共读写的数据类型；
2）传递值类型（Value Type）的I $ K ` 2 Y N数据, 后面流程修改数据时，不影响前面的流程；
3）单向传递数据，只依赖注入必要数据；
4）如果数据修改需要通知前序流程，使用代理模式通讯。
上述的前面三步，我们抽象了业务流程，加入了路由机制，统一管理网络请求：
那么规范数据传递7 ; x T / ) L后，我们软件架构就演进为这样子：
规范数据传递后，对比旧架构:
1）从架构上根本解决了困扰微信支付已久的数据污染的问题；
2）数据的流动变为单向，数据流动变得可追溯。
6、本文小I o n Q m 8 [ 9 结
软件的本质复杂性存在于复杂的业务需求中。而软件架o ? = ? y 1 )构的本质就$ _ f 5是管理复杂性，因此真正的好的架构，正是在复杂的业务需求中反复提炼和总结归纳而来，解决了真正的业务问题，不是空谈。
软件架构除了清理历史旧架构的缺陷，是我们业务开发的基石之外。还能够赋能业务，为业务带来价值。在建立软件架构的基% B +础上，还G & J 1 p ;围绕着软件架构建立起微信支付的跨平台自动化数D . B x _ # - Z据上报机制，防重复支付，安全横切* K D L 1 q 1等带来巨大业务收益的能力。有机会! E V $ e . D % =的话，后面也会进一步编写相关文章和大家交流探讨。
架构是一个不断演进的过程，随着新的支付业务基于跨平台软件架构的不断编写， 我也会对这个架构进行持续的更新迭代。让这个软件架构更贴合微信支付，更加健壮和完整。
扩展阅读3 B + ] Y：本文引用的所有图片均来自《基于C++构建微信客户端跨平台开发框架(PPT) [附件下载]》，如有需要可前往下载PPT原c @ #稿。
附录：更多QQ、微信团队原创技术文章汇总
《微信朋友圈千亿访问量背后的技术挑战和实践总结》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》F 7 1 $ c z e ( g
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(音视频技术篇q c 9 @ f 4 R 4 B)》
《微信团队分享：微信移动端的全文检索多音字问题解决方案》
《腾讯技术分c a 3享：Android版手机QQ的缓存监控与优化实践》
《微信团队分享：iOS版微信的高性能通用key-value组件技术实践》
《微信团队= F q分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？》8 Z [ % D 7 . 4 x
《腾讯技术分享：Android手Q的线程死锁监控系统技G 5 R ) { D J : *术实践》
《微信团队原创分享：iOS版微信的内存监控系统技术实践》
《让互联网更快：新一代QUIC协议在腾讯的技术实践分享》
《iOS后台唤醒实战：微信收款到账语音提醒技术总结》
《腾讯技术分享：社交网络图片的带宽压缩技术演进之路》$ 7 I m
《微信团队分享：视频图像的超分辨率技术原理和应用场景》
《微信团队分享：微信每日亿次实时音视频聊天背后的技术解密》
《QQ音乐团队分享：Android中的图片压缩技术详解（上篇）》
《QQ音乐团队分享：Android中的图片压缩技术详解（下篇）》
《腾讯团队分享：手机QQ中的人脸识别酷炫动画效果实现详解》
《腾讯团队分享 ：一次手Q聊天界面中图片显示bug的追踪过程分享》
《微信8 m G团队分享：微信Android版小视频编码填过的那些坑》
《微信手机端的本地数据全文检索优化之路》
《企业微信客户端5 k O I中组织架构数据的同步更新方案优化实战》
《微信团队披露：微信界/ 1 P S [ Z i t ;面卡死超级bug“15。。。。”的来~ ) / 1 _龙去= U m x Z ! + X Y脉》
《QQ 18年：解密8亿月活的QQ后台服务接口隔离技术》
《月活8.89亿的超级IM微j % | e D 1 g S信是如何进行Android端兼容测试的》
《以手9 4 L D 8 b ; y 机QQ为例探讨移g J /动端IM中的“轻应用”》W / 0 R T 5
《一篇文章get微g t [ | } - a信开源移动端数据库组件WCDB的一切！》
《微信客户端团队负责人技术访谈：如何着手客户端性能监控和优化》
《微信后台基于时间序的海量数据冷热分级Q f c l Y f : (架构设计实践》
《_ c p微信团队原创分享：Androiq e 9 i z _ + d版微信的臃肿之困与模块化实践之e } { C路》
《微信后台团队：微信后台异步消息队列的优化升级x ! ~ G e 实践分享》
《微信团队原创分享：微信客户端_ H v vSQLite数据库损坏修复实践》
《腾讯原创分享3 ` a - + r `(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成B z 3功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APPL ( T w `的流量消耗（下篇）》
《腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《微信O P 1 d 9 1 D -Mars：微信内部正在使用的网络层封装库，即将开源》
《如约而至：微信自用的Y i H 9 t移动端IM网络层跨平台组件库Mars已正式开源》
《开源libc3 H P V v q Yo库: k J S @ S L：单机千万连接、支撑微信8亿用户的后台框2 x m架基石 [源码下载]》
《微信新一d 7 = V v f代通信安全解决方案：基于TLS1.3的MMTLS详解》
《微信团队原创分享：Android版微2 & b ` u信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保7 ] .活实战分享(网络K J r K h b x J保活篇)》
《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》
《微信团队原创分享：Android版微信从300KB到30MB的技术演进》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《微信技: y h术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万连接背后的后台解决方案7 9 p ] J》
《微信V + S g + t e &朋友圈海量技术之道PPT [附件下载]》
《微信对网络影响的技术试验及分析（论文全文）》
《一份微信后台技术架构的总结性笔记》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《快速裂变：见证微信强大后台架构从0到1的演进历程（二）》
《微信团队原创分享：Android内存泄漏监控和优化技巧总结》
《全面总结iOS版微信升级iOS9; / U遇到的各种“坑”》
《微信团队原创资源混淆工具：让你的APK立减1M》
《微信团队原创Android资源混淆工具：AndRese N cGuard [有源码]》
《Android版微信安装包“减肥A % ~ X Q * & E ;”实战记录》
《iOS版微信安装包“减肥”实战记录[ q . V L》
《移动端IM实践：iOS版微信界面卡顿监测方案》
《微信“红包照片”背后的技术难? 8 7 F A % | a G题》
《移动端IM实践：iOS版微* ; Q m n ) M信小视频功能技术方案实录》
《移动端IM实践：R Q ZAndroid版微信如何大幅提升k H p i W 6 e 7交互性能（一）》
《移动端IM实践：Android版b / 0 b { X { 3 w微信如何大幅& ^ Z R J提升交互性能（二）》
《o ` $ x O 4 3 e ^移动端P 4 F U G & D eIM实践：# X -实现Android版微信的智能心跳机制》
《移动端IM实w B J V M g f践：Whap % 9 } h QtsApp、Line、微信的心跳策略分析N o e》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《移动端IM实践：iOS版微信的多设备字体适配方案探讨》
《信鸽团V ; [ r I n n队原创：一起走过 iOS10 上消息推送(APNS)的坑》
《腾讯信鸽技术分享：百亿级实时消息推送的实战经验》
《Ir b u ! J [ i vPv6技术详解：基本概念2 s S ! k O x 、应用现状、技术实践（上篇）》
《IPv6o ^ /技术详解：基本概念、应用现状、技术实践（下篇）》
《腾讯TEG团队原创：基于MySQL的分布式数据库TDSQL十年锻造经验分享》
《微信多媒体团队访谈：音视频开发的学习、微信的音视频技术和挑战等》
《了解iOS消息推送一文就够：史上最全iOS Push技术详解》
《腾讯技术分享：微信小程序音视频技术背后的故事》
《腾讯资深架构师干货总结：一文读懂大+ @ 2型分布f 7 H c式系统设计的方方面面》
《微信多媒体团队c % S U M @ J T梁俊斌访谈：聊一聊我v x q N 4 f 0所了解的音视频技术》
《腾讯音视频实验室：使用AI黑科技实现超低码率的高清实时视频聊天》
《腾讯技术分享：微信小程序音视频与WebRTC互通的技术思路和实践》
《手把手教你读取Android版微信和手Q的聊天记录(仅作技术研究学习)》
《微信技术分享：微信的海量IM聊天消息序列号生3 6 / 2成实践（算法原理篇）》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《腾讯技术分享：GIF动图技术详解及手机QQ动态表情压缩技术实践》
《微信团队分享：Kotlin渐被认可，And@ @ M r 5 ;roid版微信的技术u 4 m d F n尝鲜之旅》
《社交软件红包技术解密(一)：全面解密QQ红包技* ? & C f I $ 7 V术方案——K G F O 4 a h b :架构、技术实现等》
《社交软件红包技术解密(二)：解密微信摇一摇红b A o = P , R ~ W包从0到f @ ] R J [1的技术演进》
《社交软件红包技术解密(三)：微[ ? L .信摇一摇红包雨背后的技术细节》8 j 8 # } L $ f
《社交软件Q = i 7 红包技术解密(四)：微信红包系统是如何应对高并发的》
《社交软件红包技术解密(五)：微信红包系统是, o | N如何实现高可用性的》
《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》
《社3 8 e c B交软件红包技术解密(九)：谈谈手Q红包的功能6 * t @ ? x . j ;逻辑、容灾、运维、架构等》
《QQ设计团队分享：新版 QQ 8.0 语音消息改版背后x h z @ i ;的功能设计思路》
《微信团队分享：极致优化，iOS版微信编译速度3倍提升的实践总结》
《IM“扫一扫”功能很好做？看看微信“扫一扫识物”的完整技术实现》
《R e Z % D W # n t微信团队分享：微信支付代码重构带来的移动端软件架构上的思考》
>&gA N Lt; 更多同类文章 ……
（本文同步3 9 u发布于：http://www.52im.net/thread-2958-1-1.html）