本文原文由微信客戶端高級工程師方秋枋原創(chuàng)發(fā)表于WeMobileDev公眾號，收錄時有修訂和加工，感謝作者的無私分享。
1、引言
作為一個重要業(yè)務(wù)，微信支付在客戶端上面臨著各種問題。
其中最核心問題就是分平臺實現(xiàn)導(dǎo)致的問題：
1）iOS 和安卓實現(xiàn)不一致：容易出 Bug、通過溝通保證不了質(zhì)量；
2）擴展性差且無法快速響應(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++ 的跨平臺框架，并對核心支付流程進行了重構(gòu)。微信支付跨平臺從 iOS 7.0.4 版本起， 安卓從 7.0.7 版本起全面覆蓋。
重構(gòu)后的軟件架構(gòu)原理如下圖所示：
本文分享了微信團隊基于 C++ 的移動端跨平臺技術(shù)在重構(gòu)整個微信支付功能的過程中，對于移動端軟件架構(gòu)設(shè)計方面的思考和實踐總結(jié)。
術(shù)語約定：本文中的名詞 CGI 可以理解為一個網(wǎng)絡(luò)請求，類似HTTP請求。
擴展閱讀：本文引用的所有圖片均來自《基于C++構(gòu)建微信客戶端跨平臺開發(fā)框架(PPT) [附件下載]》，如有需要可前往下載PPT原稿。
（本文同步發(fā)布于：http://www.52im.net/thread-2958-1-1.html）
2、關(guān)于作者
方秋枋：畢業(yè)于華中科技大學(xué)，現(xiàn)為微信客戶端高級工程師。目前主要負責(zé)微信支付的跨平臺開發(fā)框架與相關(guān)業(yè)務(wù)開發(fā)。
是開源項目 SwiftNotificationCenter ，SwiftTimer ，SwiftCssParser 的作者。業(yè)余時間也喜歡混跡在 SwiftGG 翻譯組，老司機 iOS 周報給大家翻譯文章，摘錄周報。喜歡 Simple and Stupid 的代碼。熱愛科技、開源。
方秋枋的Github：https://github.com/100mango
方秋枋的微博：https://weibo.com/100mango?is_hot=1
方秋枋的知乎：https://www.zhihu.com/people/fang-qiu-fang
3、先感受一下本次重構(gòu)的線上效果指標
以 iOS 上線情況為例。
3.1 Crash 率
上線前后 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)怎么樣有效進行質(zhì)量保障，并且提升生產(chǎn)力呢？這是這篇文章的主要內(nèi)容。
對基于 C++ 如何從零到一構(gòu)建跨平臺框架感興趣的同學(xué)，可以看看我在2019 QCon 廣州站的演講 《基于 C++ 構(gòu)建微信客戶端跨平臺開發(fā)框架》PPT原稿。
4、什么是軟件架構(gòu)
什么是軟件架構(gòu)？正如 Ivar Jacobson （UML 之父）說過的一樣，找五個人來回答這個問題，五個人可能都有各自不同的答案。
Ivar Jacobson博士：
現(xiàn)代軟件開發(fā)之父Ivar Jacobson博士被認為是深刻影響或改變了整個軟件工業(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è)界譽為UML之父。Ivar Jacobson 的用例驅(qū)動方法對整個OOAD行業(yè)影響深遠，他因此而成為業(yè)界的一面“旗幟”。
架構(gòu)定義可以有很多種說法，從代碼規(guī)范到發(fā)布流程都可以是架構(gòu)的一部分。
針對微信支付的業(yè)務(wù)特點，這里對架構(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)力。
5、從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)簡單套用一下就好？
5.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) 模式忽略了一個非常重要的一點，那就是業(yè)務(wù)流程，界面的轉(zhuǎn)場究竟由誰負責(zé)。也即 ViewController 與 ViewController 之間的關(guān)系由誰維護，業(yè)務(wù)流程的邏輯寫在哪里。如果還按照傳統(tǒng)的 MVC 模式，那么 ViewController 自己負責(zé)和不同的 ViewController 通訊。那么 ViewController 得不到復(fù)用，更致命的是業(yè)務(wù)流程的代碼非常不清晰，業(yè)務(wù)流程的代碼都被分散到各個 Controller 中， 而一個 Controller 又可能耦合了多個業(yè)務(wù)的代碼。
舉個例子：一個普通的轉(zhuǎn)賬流程，可能會涉及風(fēng)控攔截，實名驗證， 收銀臺， 綁卡，支付成功頁等等。如果是基于 MVC 這種架構(gòu)的話，很快代碼會變得難以維護。
因此：為了適應(yīng)微信支付流程多，界面跳轉(zhuǎn)復(fù)雜的特點。架構(gòu)抽象的第一步就是將業(yè)務(wù)流程抽象為一個獨立的角色 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ù)特點。
5.2 加入路由機制
既然流程得到了抽象，這個時候需要針對業(yè)務(wù)流程做更深的思考。在開發(fā)支付業(yè)務(wù)流程時，開發(fā)者不可繞過的問題有下面這些。
流程之間，頁面之間的流傳：
比如我們要給一個朋友轉(zhuǎn)賬，輸入金額，確認支付,觸發(fā) Cgi 后。下一個流程是多變的。有可能用戶需要去實名，有可能用戶要進入一個安全攔截的 WebView，或者是正常拉起收銀臺。
注意：本文中的名詞 CGI 可以理解為一個網(wǎng)絡(luò)請求，類似HTTP請求。
那么以往在 iOS, 安卓分開實現(xiàn)時，都沒有一個統(tǒng)一的處理機制。要么就是通過網(wǎng)絡(luò)回包的某個字段來判斷，要么就是本地維護一些狀態(tài)來決定下一步走什么流程等等。非常繁瑣，易錯。
特殊流程的處理：
支付業(yè)務(wù)流程還有個特殊的地方，那就是在正常流程的中間，往往很多時候要需要插入一些特殊流程。比如有些地方要跳轉(zhuǎn) Webview, 有些地方要跳轉(zhuǎn)小程序，有些地方要彈窗告知用戶風(fēng)險，或者終止當(dāng)前流程，等等。我們經(jīng)常需要在業(yè)務(wù)代碼里面不斷重復(fù)增加這樣的處理。
這些問題，引導(dǎo)我想到，微信支付需要一個路由機制。
首先了解一下路由機制：
路由機制的核心思想，就是通過向路由傳遞數(shù)據(jù)，然后路由解析數(shù)據(jù)，并響應(yīng)。
結(jié)合微信支付和網(wǎng)絡(luò)密切相關(guān)的特點。創(chuàng)新地將支付領(lǐng)域模型作為傳遞的數(shù)據(jù)。
那么怎么建立這個支付領(lǐng)域模型的呢？
建模，就是建立映射。領(lǐng)域知識 + 建模方法 = 領(lǐng)域建模。那么這里的領(lǐng)域知識，就是對支付業(yè)務(wù)流程的理解。建模方法，我采用了 UML 建模。最終會落地為 Proto 協(xié)議供客戶端和后臺一起使用。
首先：微信支付業(yè)務(wù)特點就是和網(wǎng)絡(luò)密切相關(guān)，流程和頁面往往是由 Cgi 串聯(lián)起來。因此建立模型時，最外層便是網(wǎng)絡(luò)回包。對于路由機制，這里我們只關(guān)心路由數(shù)據(jù)模型。
路由數(shù)據(jù)模型由路由類型，還有各個路由類型所需要的信息組合成。
路由類型清晰的定義了要觸發(fā)的行為。究竟是要開啟一個 UseCase，還是要打開一個界面，或者 網(wǎng)頁，小程序，彈窗等等。
然后：就是這些行為所需要的數(shù)據(jù)。比如打開小程序所需要的參數(shù)，彈窗所需要的參數(shù)等。
建立支付領(lǐng)域模型后，我們路由的解析就變得非常清晰了。路由解析之后，會根據(jù)路由類型，觸發(fā)不同的動作。
比如流程，界面流轉(zhuǎn)，會交給 UseCase 處理。
而特殊流程，比如打開小程序，打開 webview, 彈窗這些行為會統(tǒng)一進行處理。
我們在第一步把業(yè)務(wù)流程抽象為 UseCase。第二步則加入了路由機制。
加入路由機制后，支付跨平臺的軟件架構(gòu)演進為這個樣子：
加入路由機制后，對比微信的iOS、安卓原來的舊架構(gòu)：
1）統(tǒng)一了流程，頁面的流轉(zhuǎn)。清晰，易維護；
2）統(tǒng)一了特殊流程的處理，減少重復(fù)工作；
3）在加入路由機制的時候，結(jié)合微信支付和網(wǎng)絡(luò)密切相關(guān)的特點進行了支付領(lǐng)域建模。支付后臺協(xié)議重構(gòu) 2.0 的核心思想也是圍繞著這個路由機制展開。
再來看一下，加入路由機制后，對生產(chǎn)力的提升。以支付流程打開 WebView,、小程序為例，減少將近 83% 的代碼。更重要的是，這里的特殊流程，是在路由機制里面統(tǒng)一處理的，沒有耦合到業(yè)務(wù)代碼中，并且是可復(fù)用的。
5.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 只能通過修修補補，增加場景值，增加些標記位來解決。可能某一天就會又出現(xiàn)新的坑。
具體的問題流程是：
a. 進入錢包頁面后，發(fā)起了一個 Cgi；
b. 然后進入收付款頁面也發(fā)起同一個 Cgi；
c. 如果收付款發(fā)起的回包先到；
d. 然后錢包首頁的回包再到。
2）CGI 生命周期問題：
如上圖所示，不時會有用戶反饋一下，怎么沒有做什么操作，突然就會彈出網(wǎng)絡(luò)報錯。
原因就是 Cgi 的生命周期有問題，在業(yè)務(wù)結(jié)束后，Cgi 的回包仍然得到了處理。
在我們的解決方案里，將在構(gòu)架的如下兩個方面進行優(yōu)化和處理。
1）將 Cgi 抽象為獨立對象：
在架構(gòu)設(shè)計上來說，舊架構(gòu)是通過單例模式實現(xiàn)的集約型 API，而我們新的架構(gòu)則是通過命令模式實現(xiàn)的離散型 API。
也就是將 Cgi 封裝為獨立對象。我們把 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 進行發(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ù)流程，加入了路由機制：
在上述第c步管理網(wǎng)絡(luò)請求后，我們的軟件架構(gòu)演進為這樣子：
5.4 規(guī)范數(shù)據(jù)傳遞
iOS 和安卓的舊架構(gòu)都存在信息傳遞不當(dāng)和數(shù)據(jù)污染問題。這個問題最嚴重。iOS 和 安卓都出過不少 bug。
首先我們來看看最近現(xiàn)網(wǎng)出現(xiàn)過的問題：
之前 iOS 出現(xiàn)，不少內(nèi)部同事，外部的用戶都在反饋：進行零錢頁后，會無故彈空白框。而支付又和金錢有關(guān)，引起用戶的恐慌（見下面的演示視頻所示）。
▲ 視頻原地址：點此進入
大致的原因，如下圖所示：
具體原因就是:
1）進入支付首頁時，后臺返回了數(shù)據(jù)，然后被寫入到一個公共的 Model；
2）然后進入錢包頁，再進入零錢頁。這個公共 model 一路被傳遞過去；
3）然后零錢頁讀取了公共 Model 的數(shù)據(jù)，但是代碼無法處理，導(dǎo)致出現(xiàn)了這個讓用戶恐慌的問題。
除此之外，之前還有有很多發(fā)生在安卓，iOS ，像錢包頁零錢展示錯誤。付款的時候。銀行卡失效等等問題。
這些問題五花八門，看起來發(fā)生的地方，場景都不一樣。每次遇到這類問題的時候，就只能去修修補補。
但是深究下去，會發(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ù)流程，加入了路由機制，統(tǒng)一管理網(wǎng)絡(luò)請求：
那么規(guī)范數(shù)據(jù)傳遞后，我們軟件架構(gòu)就演進為這樣子：
規(guī)范數(shù)據(jù)傳遞后，對比舊架構(gòu):
1）從架構(gòu)上根本解決了困擾微信支付已久的數(shù)據(jù)污染的問題；
2）數(shù)據(jù)的流動變?yōu)閱蜗颍瑪?shù)據(jù)流動變得可追溯。
6、本文小結(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ù)上報機制，防重復(fù)支付，安全橫切等帶來巨大業(yè)務(wù)收益的能力。有機會的話，后面也會進一步編寫相關(guān)文章和大家交流探討。
架構(gòu)是一個不斷演進的過程，隨著新的支付業(yè)務(wù)基于跨平臺軟件架構(gòu)的不斷編寫， 我也會對這個架構(gòu)進行持續(xù)的更新迭代。讓這個軟件架構(gòu)更貼合微信支付，更加健壯和完整。
擴展閱讀：本文引用的所有圖片均來自《基于C++構(gòu)建微信客戶端跨平臺開發(fā)框架(PPT) [附件下載]》，如有需要可前往下載PPT原稿。
附錄：更多QQ、微信團隊原創(chuàng)技術(shù)文章匯總
《微信朋友圈千億訪問量背后的技術(shù)挑戰(zhàn)和實踐總結(jié)》
《騰訊技術(shù)分享：騰訊是如何大幅降低帶寬和網(wǎng)絡(luò)流量的(圖片壓縮篇)》
《騰訊技術(shù)分享：騰訊是如何大幅降低帶寬和網(wǎng)絡(luò)流量的(音視頻技術(shù)篇)》
《微信團隊分享：微信移動端的全文檢索多音字問題解決方案》
《騰訊技術(shù)分享：Android版手機QQ的緩存監(jiān)控與優(yōu)化實踐》
《微信團隊分享：iOS版微信的高性能通用key-value組件技術(shù)實踐》
《微信團隊分享：iOS版微信是如何防止特殊字符導(dǎo)致的炸群、APP崩潰的？》
《騰訊技術(shù)分享：Android手Q的線程死鎖監(jiān)控系統(tǒng)技術(shù)實踐》
《微信團隊原創(chuàng)分享：iOS版微信的內(nèi)存監(jiān)控系統(tǒng)技術(shù)實踐》
《讓互聯(lián)網(wǎng)更快：新一代QUIC協(xié)議在騰訊的技術(shù)實踐分享》
《iOS后臺喚醒實戰(zhàn)：微信收款到賬語音提醒技術(shù)總結(jié)》
《騰訊技術(shù)分享：社交網(wǎng)絡(luò)圖片的帶寬壓縮技術(shù)演進之路》
《微信團隊分享：視頻圖像的超分辨率技術(shù)原理和應(yīng)用場景》
《微信團隊分享：微信每日億次實時音視頻聊天背后的技術(shù)解密》
《QQ音樂團隊分享：Android中的圖片壓縮技術(shù)詳解（上篇）》
《QQ音樂團隊分享：Android中的圖片壓縮技術(shù)詳解（下篇）》
《騰訊團隊分享：手機QQ中的人臉識別酷炫動畫效果實現(xiàn)詳解》
《騰訊團隊分享 ：一次手Q聊天界面中圖片顯示bug的追蹤過程分享》
《微信團隊分享：微信Android版小視頻編碼填過的那些坑》
《微信手機端的本地數(shù)據(jù)全文檢索優(yōu)化之路》
《企業(yè)微信客戶端中組織架構(gòu)數(shù)據(jù)的同步更新方案優(yōu)化實戰(zhàn)》
《微信團隊披露：微信界面卡死超級bug“15。。。。”的來龍去脈》
《QQ 18年：解密8億月活的QQ后臺服務(wù)接口隔離技術(shù)》
《月活8.89億的超級IM微信是如何進行Android端兼容測試的》
《以手機QQ為例探討移動端IM中的“輕應(yīng)用”》
《一篇文章get微信開源移動端數(shù)據(jù)庫組件WCDB的一切！》
《微信客戶端團隊負責(zé)人技術(shù)訪談：如何著手客戶端性能監(jiān)控和優(yōu)化》
《微信后臺基于時間序的海量數(shù)據(jù)冷熱分級架構(gòu)設(shè)計實踐》
《微信團隊原創(chuàng)分享：Android版微信的臃腫之困與模塊化實踐之路》
《微信后臺團隊：微信后臺異步消息隊列的優(yōu)化升級實踐分享》
《微信團隊原創(chuàng)分享：微信客戶端SQLite數(shù)據(jù)庫損壞修復(fù)實踐》
《騰訊原創(chuàng)分享(一)：如何大幅提升移動網(wǎng)絡(luò)下手機QQ的圖片傳輸速度和成功率》
《騰訊原創(chuàng)分享(二)：如何大幅壓縮移動網(wǎng)絡(luò)下APP的流量消耗（下篇）》
《騰訊原創(chuàng)分享(三)：如何大幅壓縮移動網(wǎng)絡(luò)下APP的流量消耗（上篇）》
《微信Mars：微信內(nèi)部正在使用的網(wǎng)絡(luò)層封裝庫，即將開源》
《如約而至：微信自用的移動端IM網(wǎng)絡(luò)層跨平臺組件庫Mars已正式開源》
《開源libco庫：單機千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]》
《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》
《微信團隊原創(chuàng)分享：Android版微信后臺保活實戰(zhàn)分享(進程保活篇)》
《微信團隊原創(chuàng)分享：Android版微信后臺保活實戰(zhàn)分享(網(wǎng)絡(luò)保活篇)》
《Android版微信從300KB到30MB的技術(shù)演進(PPT講稿) [附件下載]》
《微信團隊原創(chuàng)分享：Android版微信從300KB到30MB的技術(shù)演進》
《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(演講全文)》
《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(PPT講稿) [附件下載]》
《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡》》
《微信海量用戶背后的后臺系統(tǒng)存儲架構(gòu)(視頻+PPT) [附件下載]》
《微信異步化改造實踐：8億月活、單機千萬連接背后的后臺解決方案》
《微信朋友圈海量技術(shù)之道PPT [附件下載]》
《微信對網(wǎng)絡(luò)影響的技術(shù)試驗及分析（論文全文）》
《一份微信后臺技術(shù)架構(gòu)的總結(jié)性筆記》
《架構(gòu)之道：3個程序員成就微信朋友圈日均10億發(fā)布量[有視頻]》
《快速裂變：見證微信強大后臺架構(gòu)從0到1的演進歷程（一）》
《快速裂變：見證微信強大后臺架構(gòu)從0到1的演進歷程（二）》
《微信團隊原創(chuàng)分享：Android內(nèi)存泄漏監(jiān)控和優(yōu)化技巧總結(jié)》
《全面總結(jié)iOS版微信升級iOS9遇到的各種“坑”》
《微信團隊原創(chuàng)資源混淆工具：讓你的APK立減1M》
《微信團隊原創(chuàng)Android資源混淆工具：AndResGuard [有源碼]》
《Android版微信安裝包“減肥”實戰(zhàn)記錄》
《iOS版微信安裝包“減肥”實戰(zhàn)記錄》
《移動端IM實踐：iOS版微信界面卡頓監(jiān)測方案》
《微信“紅包照片”背后的技術(shù)難題》
《移動端IM實踐：iOS版微信小視頻功能技術(shù)方案實錄》
《移動端IM實踐：Android版微信如何大幅提升交互性能（一）》
《移動端IM實踐：Android版微信如何大幅提升交互性能（二）》
《移動端IM實踐：實現(xiàn)Android版微信的智能心跳機制》
《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》
《移動端IM實踐：谷歌消息推送服務(wù)(GCM)研究（來自微信）》
《移動端IM實踐：iOS版微信的多設(shè)備字體適配方案探討》
《信鴿團隊原創(chuàng)：一起走過 iOS10 上消息推送(APNS)的坑》
《騰訊信鴿技術(shù)分享：百億級實時消息推送的實戰(zhàn)經(jīng)驗》
《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實踐（上篇）》
《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實踐（下篇）》
《騰訊TEG團隊原創(chuàng)：基于MySQL的分布式數(shù)據(jù)庫TDSQL十年鍛造經(jīng)驗分享》
《微信多媒體團隊訪談：音視頻開發(fā)的學(xué)習(xí)、微信的音視頻技術(shù)和挑戰(zhàn)等》
《了解iOS消息推送一文就夠：史上最全iOS Push技術(shù)詳解》
《騰訊技術(shù)分享：微信小程序音視頻技術(shù)背后的故事》
《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計的方方面面》
《微信多媒體團隊梁俊斌訪談：聊一聊我所了解的音視頻技術(shù)》
《騰訊音視頻實驗室：使用AI黑科技實現(xiàn)超低碼率的高清實時視頻聊天》
《騰訊技術(shù)分享：微信小程序音視頻與WebRTC互通的技術(shù)思路和實踐》
《手把手教你讀取Android版微信和手Q的聊天記錄(僅作技術(shù)研究學(xué)習(xí))》
《微信技術(shù)分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《微信技術(shù)分享：微信的海量IM聊天消息序列號生成實踐（容災(zāi)方案篇）》
《騰訊技術(shù)分享：GIF動圖技術(shù)詳解及手機QQ動態(tài)表情壓縮技術(shù)實踐》
《微信團隊分享：Kotlin漸被認可，Android版微信的技術(shù)嘗鮮之旅》
《社交軟件紅包技術(shù)解密(一)：全面解密QQ紅包技術(shù)方案——架構(gòu)、技術(shù)實現(xiàn)等》
《社交軟件紅包技術(shù)解密(二)：解密微信搖一搖紅包從0到1的技術(shù)演進》
《社交軟件紅包技術(shù)解密(三)：微信搖一搖紅包雨背后的技術(shù)細節(jié)》
《社交軟件紅包技術(shù)解密(四)：微信紅包系統(tǒng)是如何應(yīng)對高并發(fā)的》
《社交軟件紅包技術(shù)解密(五)：微信紅包系統(tǒng)是如何實現(xiàn)高可用性的》
《社交軟件紅包技術(shù)解密(六)：微信紅包系統(tǒng)的存儲層架構(gòu)演進實踐》
《社交軟件紅包技術(shù)解密(九)：談?wù)勈諵紅包的功能邏輯、容災(zāi)、運維、架構(gòu)等》
《QQ設(shè)計團隊分享：新版 QQ 8.0 語音消息改版背后的功能設(shè)計思路》
《微信團隊分享：極致優(yōu)化，iOS版微信編譯速度3倍提升的實踐總結(jié)》
《IM“掃一掃”功能很好做？看看微信“掃一掃識物”的完整技術(shù)實現(xiàn)》
《微信團隊分享：微信支付代碼重構(gòu)帶來的移動端軟件架構(gòu)上的思考》
>> 更多同類文章 ……
（本文同步發(fā)布于：http://www.52im.net/thread-2958-1-1.html）