本文原文由微信客戶端高級(jí)工程師方秋枋原創(chuàng)發(fā)表于WeMobileDev公眾號(hào)，收錄時(shí)有修訂和加工，感謝作者的無私分享。

1、引言

作為一個(gè)重要業(yè)務(wù)，微信支付在客戶端上面臨著各種問題。

其中最核心問題就是分平臺(tái)實(shí)現(xiàn)導(dǎo)致的問題：

1）iOS 和安卓實(shí)現(xiàn)不一致：容易出 Bug、通過溝通保證不了質(zhì)量；

2）擴(kuò)展性差且無法快速響應(yīng)業(yè)務(wù)需求：需求變更迭代周期長、數(shù)據(jù)上報(bào)不全面；

3）質(zhì)量保障體系不完善：缺少業(yè)務(wù)及設(shè)計(jì)知識(shí)沉淀、協(xié)議管理松散、缺少統(tǒng)一的自動(dòng)化測(cè)試；

4）用戶體驗(yàn)不一致：比如下圖就是之前安卓和 iOS 沒有統(tǒng)一前的收銀臺(tái)。

 

▲ 微信安卓片和iOS版，沒有統(tǒng)一用戶體驗(yàn)前的收銀臺(tái)功能

為了解決分平臺(tái)實(shí)現(xiàn)這個(gè)核心問題，并解決以往的技術(shù)債務(wù)。我們建立起了一整套基于 C++ 的跨平臺(tái)框架，并對(duì)核心支付流程進(jìn)行了重構(gòu)。微信支付跨平臺(tái)從 iOS 7.0.4 版本起， 安卓從 7.0.7 版本起全面覆蓋。

重構(gòu)后的軟件架構(gòu)原理如下圖所示： 

本文分享了微信團(tuán)隊(duì)基于 C++ 的移動(dòng)端跨平臺(tái)技術(shù)在重構(gòu)整個(gè)微信支付功能的過程中，對(duì)于移動(dòng)端軟件架構(gòu)設(shè)計(jì)方面的思考和實(shí)踐總結(jié)。

術(shù)語約定：本文中的名詞 CGI 可以理解為一個(gè)網(wǎng)絡(luò)請(qǐng)求，類似HTTP請(qǐng)求。

擴(kuò)展閱讀：本文引用的所有圖片均來自《基于C++構(gòu)建微信客戶端跨平臺(tái)開發(fā)框架(PPT) [附件下載]》，如有需要可前往下載PPT原稿。

（本文同步發(fā)布于：http://www.52im.net/thread-2958-1-1.html）

2、關(guān)于作者

方秋枋：畢業(yè)于華中科技大學(xué)，現(xiàn)為微信客戶端高級(jí)工程師。目前主要負(fù)責(zé)微信支付的跨平臺(tái)開發(fā)框架與相關(guān)業(yè)務(wù)開發(fā)。

是開源項(xiàng)目 SwiftNotificationCenter ，SwiftTimer ，SwiftCssParser 的作者。業(yè)余時(shí)間也喜歡混跡在 SwiftGG 翻譯組，老司機(jī) iOS 周報(bào)給大家翻譯文章，摘錄周報(bào)。喜歡 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)的線上效果指標(biāo)

以 iOS 上線情況為例。

3.1 Crash 率

上線前后 Crash 率保持平穩(wěn)，沒有影響微信穩(wěn)定性，跨平臺(tái)支付無必現(xiàn) Crash，做到了用戶無感知切換。

舉個(gè)例子，大家可以用微信發(fā)一筆紅包，拉起的收銀臺(tái)和支付流程就是由基于C++編寫的跨平臺(tái)代碼所驅(qū)動(dòng)的。

3.2 效能提升 

以核心支付流程代碼為例，跨平臺(tái)需要 3512 行，iOS 原生需要 6328 行。減少了近 45% 的代碼。

以新需求開發(fā)為例：

1）7.0.4 版本需求一：收銀臺(tái)改版；

2）7.0.4 版本需求二：簡化版本收銀臺(tái)。

重構(gòu)后的軟件架構(gòu)對(duì)開發(fā)效率的提升對(duì)比：

跨平臺(tái)實(shí)現(xiàn)：iOS + 安卓 共計(jì) 3 人日，在封板時(shí)間前完成；

原生實(shí)現(xiàn)：iOS， 安卓封板時(shí)間后一周才基本完成；

跨平臺(tái)實(shí)現(xiàn)：iOS + 安卓共計(jì) 5 人日，在封板時(shí)間前完成；

原生實(shí)現(xiàn)：iOS， 安卓封板時(shí)間后一周才基本完成。

那么支付跨平臺(tái)軟件架構(gòu)怎么樣有效進(jìn)行質(zhì)量保障，并且提升生產(chǎn)力呢？這是這篇文章的主要內(nèi)容。

對(duì)基于 C++ 如何從零到一構(gòu)建跨平臺(tái)框架感興趣的同學(xué)，可以看看我在2019 QCon 廣州站的演講 《基于 C++ 構(gòu)建微信客戶端跨平臺(tái)開發(fā)框架》PPT原稿。

4、什么是軟件架構(gòu)

什么是軟件架構(gòu)？正如 Ivar Jacobson （UML 之父）說過的一樣，找五個(gè)人來回答這個(gè)問題，五個(gè)人可能都有各自不同的答案。

Ivar Jacobson博士：

現(xiàn)代軟件開發(fā)之父Ivar Jacobson博士被認(rèn)為是深刻影響或改變了整個(gè)軟件工業(yè)開發(fā)模式的幾位世界級(jí)大師之一。他是模塊和模塊架構(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ū)動(dòng)方法對(duì)整個(gè)OOAD行業(yè)影響深遠(yuǎn)，他因此而成為業(yè)界的一面“旗幟”。

架構(gòu)定義可以有很多種說法，從代碼規(guī)范到發(fā)布流程都可以是架構(gòu)的一部分。

針對(duì)微信支付的業(yè)務(wù)特點(diǎn)，這里對(duì)架構(gòu)的定義是：架構(gòu)是系統(tǒng)的組成部件及其之間的相互關(guān)系（通訊方式）。這更符合我們程序員日常編寫業(yè)務(wù)代碼時(shí)對(duì)架構(gòu)的理解。也就是通俗意義上講的 MVC，MVVM 等。

5、為什么需要軟件架構(gòu)

早在 1986 年的時(shí)候，《人月神話》的作者在討論軟件的復(fù)雜性時(shí)，談到：軟件的本質(zhì)復(fù)雜性存在于復(fù)雜的業(yè)務(wù)需求中。

▲ 軟件工程不朽的經(jīng)典《人月神話》書籍(中文版)封面

而管理復(fù)雜性，最根本的手段就是職責(zé)分離。為了實(shí)現(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)建微信支付跨平臺(tái)軟件架構(gòu)

在移動(dòng)客戶端領(lǐng)域，業(yè)界基于 C++ 來編寫業(yè)務(wù)代碼，并沒有成熟的架構(gòu)。即使使用 C++ 編寫業(yè)務(wù)邏輯，但都不涉及 UI，不涉及界面的跳轉(zhuǎn)流程。

既然業(yè)界沒有一個(gè)成熟的架構(gòu)可借鑒，那么是不是直接把業(yè)界通用的架構(gòu)簡單套用一下就好？

5.1 抽象業(yè)務(wù)流程

現(xiàn)在業(yè)界通用的有 MVC , MVP, MVVM 。這些大家都熟悉的軟件架構(gòu)。但是這些軟件架構(gòu)都存在一個(gè)問題： 那就是沒有處理好業(yè)務(wù)流程， 界面轉(zhuǎn)場。

微信支付的流程多。而流程就是由一個(gè)個(gè)的界面（ViewController，Activity）和相關(guān)的業(yè)務(wù)邏輯組合而成。

上面的 MV(X) 模式忽略了一個(gè)非常重要的一點(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ù)流程的代碼都被分散到各個(gè) Controller 中， 而一個(gè) Controller 又可能耦合了多個(gè)業(yè)務(wù)的代碼。

舉個(gè)例子：一個(gè)普通的轉(zhuǎn)賬流程，可能會(huì)涉及風(fēng)控?cái)r截，實(shí)名驗(yàn)證， 收銀臺(tái)， 綁卡，支付成功頁等等。如果是基于 MVC 這種架構(gòu)的話，很快代碼會(huì)變得難以維護(hù)。

 

因此：為了適應(yīng)微信支付流程多，界面跳轉(zhuǎn)復(fù)雜的特點(diǎn)。架構(gòu)抽象的第一步就是將業(yè)務(wù)流程抽象為一個(gè)獨(dú)立的角色 UseCase。同時(shí), 把界面抽象為 UIPage。 一個(gè)大的業(yè)務(wù)流程可以分解為一個(gè)個(gè)小的業(yè)務(wù)流程。

 

和剛才基于 MVC 混亂的架構(gòu)相比：

1）業(yè)務(wù)流程的代碼能夠聚合到 UseCase 中，而不是分散到原來 iOS, 安卓的各個(gè) ViewController，Activity 中；

2）業(yè)務(wù)流程和界面得到了復(fù)用；

3）契合微信支付多流程，界面跳轉(zhuǎn)復(fù)雜的業(yè)務(wù)特點(diǎn)。

5.2 加入路由機(jī)制

既然流程得到了抽象，這個(gè)時(shí)候需要針對(duì)業(yè)務(wù)流程做更深的思考。在開發(fā)支付業(yè)務(wù)流程時(shí)，開發(fā)者不可繞過的問題有下面這些。

流程之間，頁面之間的流傳：

 

比如我們要給一個(gè)朋友轉(zhuǎn)賬，輸入金額，確認(rèn)支付,觸發(fā) Cgi 后。下一個(gè)流程是多變的。有可能用戶需要去實(shí)名，有可能用戶要進(jìn)入一個(gè)安全攔截的 WebView，或者是正常拉起收銀臺(tái)。

注意：本文中的名詞 CGI 可以理解為一個(gè)網(wǎng)絡(luò)請(qǐng)求，類似HTTP請(qǐng)求。

那么以往在 iOS, 安卓分開實(shí)現(xiàn)時(shí)，都沒有一個(gè)統(tǒng)一的處理機(jī)制。要么就是通過網(wǎng)絡(luò)回包的某個(gè)字段來判斷，要么就是本地維護(hù)一些狀態(tài)來決定下一步走什么流程等等。非常繁瑣，易錯(cuò)。

特殊流程的處理：

 

支付業(yè)務(wù)流程還有個(gè)特殊的地方，那就是在正常流程的中間，往往很多時(shí)候要需要插入一些特殊流程。比如有些地方要跳轉(zhuǎn) Webview, 有些地方要跳轉(zhuǎn)小程序，有些地方要彈窗告知用戶風(fēng)險(xiǎn)，或者終止當(dāng)前流程，等等。我們經(jīng)常需要在業(yè)務(wù)代碼里面不斷重復(fù)增加這樣的處理。

這些問題，引導(dǎo)我想到，微信支付需要一個(gè)路由機(jī)制。

首先了解一下路由機(jī)制： 

路由機(jī)制的核心思想，就是通過向路由傳遞數(shù)據(jù)，然后路由解析數(shù)據(jù)，并響應(yīng)。

結(jié)合微信支付和網(wǎng)絡(luò)密切相關(guān)的特點(diǎn)。創(chuàng)新地將支付領(lǐng)域模型作為傳遞的數(shù)據(jù)。

 

那么怎么建立這個(gè)支付領(lǐng)域模型的呢？

建模，就是建立映射。領(lǐng)域知識(shí) + 建模方法 = 領(lǐng)域建模。那么這里的領(lǐng)域知識(shí)，就是對(duì)支付業(yè)務(wù)流程的理解。建模方法，我采用了 UML 建模。最終會(huì)落地為 Proto 協(xié)議供客戶端和后臺(tái)一起使用。

 

首先：微信支付業(yè)務(wù)特點(diǎn)就是和網(wǎng)絡(luò)密切相關(guān)，流程和頁面往往是由 Cgi 串聯(lián)起來。因此建立模型時(shí)，最外層便是網(wǎng)絡(luò)回包。對(duì)于路由機(jī)制，這里我們只關(guān)心路由數(shù)據(jù)模型。

路由數(shù)據(jù)模型由路由類型，還有各個(gè)路由類型所需要的信息組合成。

路由類型清晰的定義了要觸發(fā)的行為。究竟是要開啟一個(gè) UseCase，還是要打開一個(gè)界面，或者 網(wǎng)頁，小程序，彈窗等等。

然后：就是這些行為所需要的數(shù)據(jù)。比如打開小程序所需要的參數(shù)，彈窗所需要的參數(shù)等。

 

建立支付領(lǐng)域模型后，我們路由的解析就變得非常清晰了。路由解析之后，會(huì)根據(jù)路由類型，觸發(fā)不同的動(dòng)作。

比如流程，界面流轉(zhuǎn)，會(huì)交給 UseCase 處理。

而特殊流程，比如打開小程序，打開 webview, 彈窗這些行為會(huì)統(tǒng)一進(jìn)行處理。

我們?cè)诘谝徊桨褬I(yè)務(wù)流程抽象為 UseCase。第二步則加入了路由機(jī)制。

加入路由機(jī)制后，支付跨平臺(tái)的軟件架構(gòu)演進(jìn)為這個(gè)樣子： 

加入路由機(jī)制后，對(duì)比微信的iOS、安卓原來的舊架構(gòu)：

1）統(tǒng)一了流程，頁面的流轉(zhuǎn)。清晰，易維護(hù)；

2）統(tǒng)一了特殊流程的處理，減少重復(fù)工作；

3）在加入路由機(jī)制的時(shí)候，結(jié)合微信支付和網(wǎng)絡(luò)密切相關(guān)的特點(diǎn)進(jìn)行了支付領(lǐng)域建模。支付后臺(tái)協(xié)議重構(gòu) 2.0 的核心思想也是圍繞著這個(gè)路由機(jī)制展開。

 

再來看一下，加入路由機(jī)制后，對(duì)生產(chǎn)力的提升。以支付流程打開 WebView,、小程序?yàn)槔?，減少將近 83% 的代碼。更重要的是，這里的特殊流程，是在路由機(jī)制里面統(tǒng)一處理的，沒有耦合到業(yè)務(wù)代碼中，并且是可復(fù)用的。

5.3 管理網(wǎng)絡(luò)請(qǐng)求

首先看看原來 iOS 處理支付網(wǎng)絡(luò)請(qǐng)求的缺陷： 

原來支付的請(qǐng)求，都是通過一個(gè)單例網(wǎng)絡(luò)中心去發(fā)起請(qǐng)求，然后收到回包后，通過拋通知，或者調(diào)用閉包的方式回調(diào)給業(yè)務(wù)側(cè)。

會(huì)存在這樣兩個(gè)問題。

1）CGI 一對(duì)多通訊問題：

舉個(gè)之前遇到的問題：

如上圖所示，錢包發(fā)起的 Cgi 的回包會(huì)覆蓋收付款頁面的數(shù)據(jù)。之前在 iOS 只能通過修修補(bǔ)補(bǔ)，增加場景值，增加些標(biāo)記位來解決。可能某一天就會(huì)又出現(xiàn)新的坑。

具體的問題流程是：

a. 進(jìn)入錢包頁面后，發(fā)起了一個(gè) Cgi；

b. 然后進(jìn)入收付款頁面也發(fā)起同一個(gè) Cgi；

c. 如果收付款發(fā)起的回包先到；

d. 然后錢包首頁的回包再到。

2）CGI 生命周期問題：

 

如上圖所示，不時(shí)會(huì)有用戶反饋一下，怎么沒有做什么操作，突然就會(huì)彈出網(wǎng)絡(luò)報(bào)錯(cuò)。

原因就是 Cgi 的生命周期有問題，在業(yè)務(wù)結(jié)束后，Cgi 的回包仍然得到了處理。

在我們的解決方案里，將在構(gòu)架的如下兩個(gè)方面進(jìn)行優(yōu)化和處理。

1）將 Cgi 抽象為獨(dú)立對(duì)象：

在架構(gòu)設(shè)計(jì)上來說，舊架構(gòu)是通過單例模式實(shí)現(xiàn)的集約型 API，而我們新的架構(gòu)則是通過命令模式實(shí)現(xiàn)的離散型 API。

也就是將 Cgi 封裝為獨(dú)立對(duì)象。我們把 Cgi 相關(guān)屬性和能力內(nèi)聚起來。開發(fā)業(yè)務(wù)時(shí)，只需簡單繼承 BaseCgi，設(shè)置一下參數(shù)即可。

 

 

2）劃分職責(zé)，明確生命周期：

關(guān)于 Cgi 由誰發(fā)起，之前安卓和 iOS 都沒有一個(gè)統(tǒng)一的做法。有些人會(huì)放到 Activity，ViewController，和 UI 代碼耦合起來。

因此，在跨平臺(tái)軟件架構(gòu)中，我們統(tǒng)一由業(yè)務(wù)流程 UseCase 進(jìn)行發(fā)起。并且生命周期是一對(duì)一的，一個(gè) Cgi 只會(huì)有一個(gè) UseCase 處理， UseCase 銷毀后，Cgi 也隨之銷毀。

 

對(duì)比舊架構(gòu)：

a. 杜絕了一對(duì)多通信造成的 Bug；

b. 生命周期和業(yè)務(wù)邏輯綁定，不會(huì)出現(xiàn)業(yè)務(wù)結(jié)束，Cgi 回來后再觸發(fā)動(dòng)作；

c. 高內(nèi)聚，低耦合。將 Cgi 相關(guān)的數(shù)據(jù)，能力集中處理，業(yè)務(wù)側(cè)無需感知；

d. 提供統(tǒng)一的緩存，加密能力。

 

在上述第a步和第b步，我們抽象了業(yè)務(wù)流程，加入了路由機(jī)制： 

在上述第c步管理網(wǎng)絡(luò)請(qǐng)求后，我們的軟件架構(gòu)演進(jìn)為這樣子： 

5.4 規(guī)范數(shù)據(jù)傳遞

iOS 和安卓的舊架構(gòu)都存在信息傳遞不當(dāng)和數(shù)據(jù)污染問題。這個(gè)問題最嚴(yán)重。iOS 和 安卓都出過不少 bug。

首先我們來看看最近現(xiàn)網(wǎng)出現(xiàn)過的問題：

之前 iOS 出現(xiàn)，不少內(nèi)部同事，外部的用戶都在反饋：進(jìn)行零錢頁后，會(huì)無故彈空白框。而支付又和金錢有關(guān)，引起用戶的恐慌（見下面的演示視頻所示）。

 

▲ 視頻原地址：點(diǎn)此進(jìn)入

大致的原因，如下圖所示： 

具體原因就是:

1）進(jìn)入支付首頁時(shí)，后臺(tái)返回了數(shù)據(jù)，然后被寫入到一個(gè)公共的 Model；

2）然后進(jìn)入錢包頁，再進(jìn)入零錢頁。這個(gè)公共 model 一路被傳遞過去；

3）然后零錢頁讀取了公共 Model 的數(shù)據(jù)，但是代碼無法處理，導(dǎo)致出現(xiàn)了這個(gè)讓用戶恐慌的問題。

除此之外，之前還有有很多發(fā)生在安卓，iOS ，像錢包頁零錢展示錯(cuò)誤。付款的時(shí)候。銀行卡失效等等問題。

這些問題五花八門，看起來發(fā)生的地方，場景都不一樣。每次遇到這類問題的時(shí)候，就只能去修修補(bǔ)補(bǔ)。

但是深究下去，會(huì)發(fā)現(xiàn)真正的原因，是軟件架構(gòu)上存在的問題：

支付舊的架構(gòu)采用了黑板模式，雖然方便了數(shù)據(jù)讀寫，但是帶來的問題和收益完全不成正比。

具體存在以下問題：

1）存在公共讀寫的數(shù)據(jù)類型：安卓傳遞的數(shù)據(jù)類型是一個(gè)字典，而 iOS 則是一個(gè) Model 對(duì)象。所有的界面，業(yè)務(wù)邏輯都共用一個(gè)數(shù)據(jù)；

2）無序的數(shù)據(jù)流動(dòng)：數(shù)據(jù)的流動(dòng)是不可追溯的，數(shù)據(jù)的修改可以發(fā)生在任意使用公共數(shù)據(jù)的地方。

那么支付跨平臺(tái)軟件架構(gòu)，為了杜絕這樣的問題，我是這么做的: 

具體的思路是：

1）去掉公共讀寫的數(shù)據(jù)類型；

2）傳遞值類型（Value Type）的數(shù)據(jù), 后面流程修改數(shù)據(jù)時(shí)，不影響前面的流程；

3）單向傳遞數(shù)據(jù)，只依賴注入必要數(shù)據(jù)；

4）如果數(shù)據(jù)修改需要通知前序流程，使用代理模式通訊。

上述的前面三步，我們抽象了業(yè)務(wù)流程，加入了路由機(jī)制，統(tǒng)一管理網(wǎng)絡(luò)請(qǐng)求：

那么規(guī)范數(shù)據(jù)傳遞后，我們軟件架構(gòu)就演進(jìn)為這樣子： 

規(guī)范數(shù)據(jù)傳遞后，對(duì)比舊架構(gòu):

1）從架構(gòu)上根本解決了困擾微信支付已久的數(shù)據(jù)污染的問題；

2）數(shù)據(jù)的流動(dòng)變?yōu)閱蜗?，?shù)據(jù)流動(dòng)變得可追溯。

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ù)帶來價(jià)值。在建立軟件架構(gòu)的基礎(chǔ)上，還圍繞著軟件架構(gòu)建立起微信支付的跨平臺(tái)自動(dòng)化數(shù)據(jù)上報(bào)機(jī)制，防重復(fù)支付，安全橫切等帶來巨大業(yè)務(wù)收益的能力。有機(jī)會(huì)的話，后面也會(huì)進(jìn)一步編寫相關(guān)文章和大家交流探討。

架構(gòu)是一個(gè)不斷演進(jìn)的過程，隨著新的支付業(yè)務(wù)基于跨平臺(tái)軟件架構(gòu)的不斷編寫， 我也會(huì)對(duì)這個(gè)架構(gòu)進(jìn)行持續(xù)的更新迭代。讓這個(gè)軟件架構(gòu)更貼合微信支付，更加健壯和完整。

擴(kuò)展閱讀：本文引用的所有圖片均來自《基于C++構(gòu)建微信客戶端跨平臺(tái)開發(fā)框架(PPT) [附件下載]》，如有需要可前往下載PPT原稿。

 

附錄：更多QQ、微信團(tuán)隊(duì)原創(chuàng)技術(shù)文章匯總

《微信朋友圈千億訪問量背后的技術(shù)挑戰(zhàn)和實(shí)踐總結(jié)》

《騰訊技術(shù)分享：騰訊是如何大幅降低帶寬和網(wǎng)絡(luò)流量的(圖片壓縮篇)》

《騰訊技術(shù)分享：騰訊是如何大幅降低帶寬和網(wǎng)絡(luò)流量的(音視頻技術(shù)篇)》

《微信團(tuán)隊(duì)分享：微信移動(dòng)端的全文檢索多音字問題解決方案》

《騰訊技術(shù)分享：Android版手機(jī)QQ的緩存監(jiān)控與優(yōu)化實(shí)踐》

《微信團(tuán)隊(duì)分享：iOS版微信的高性能通用key-value組件技術(shù)實(shí)踐》

《微信團(tuán)隊(duì)分享：iOS版微信是如何防止特殊字符導(dǎo)致的炸群、APP崩潰的？》

《騰訊技術(shù)分享：Android手Q的線程死鎖監(jiān)控系統(tǒng)技術(shù)實(shí)踐》

《微信團(tuán)隊(duì)原創(chuàng)分享：iOS版微信的內(nèi)存監(jiān)控系統(tǒng)技術(shù)實(shí)踐》

《讓互聯(lián)網(wǎng)更快：新一代QUIC協(xié)議在騰訊的技術(shù)實(shí)踐分享》

《iOS后臺(tái)喚醒實(shí)戰(zhàn)：微信收款到賬語音提醒技術(shù)總結(jié)》

《騰訊技術(shù)分享：社交網(wǎng)絡(luò)圖片的帶寬壓縮技術(shù)演進(jìn)之路》

《微信團(tuán)隊(duì)分享：視頻圖像的超分辨率技術(shù)原理和應(yīng)用場景》

《微信團(tuán)隊(duì)分享：微信每日億次實(shí)時(shí)音視頻聊天背后的技術(shù)解密》

《QQ音樂團(tuán)隊(duì)分享：Android中的圖片壓縮技術(shù)詳解（上篇）》

《QQ音樂團(tuán)隊(duì)分享：Android中的圖片壓縮技術(shù)詳解（下篇）》

《騰訊團(tuán)隊(duì)分享：手機(jī)QQ中的人臉識(shí)別酷炫動(dòng)畫效果實(shí)現(xiàn)詳解》

《騰訊團(tuán)隊(duì)分享 ：一次手Q聊天界面中圖片顯示bug的追蹤過程分享》

《微信團(tuán)隊(duì)分享：微信Android版小視頻編碼填過的那些坑》 

《微信手機(jī)端的本地?cái)?shù)據(jù)全文檢索優(yōu)化之路》 

《企業(yè)微信客戶端中組織架構(gòu)數(shù)據(jù)的同步更新方案優(yōu)化實(shí)戰(zhàn)》

《微信團(tuán)隊(duì)披露：微信界面卡死超級(jí)bug“15。。。。”的來龍去脈》

《QQ 18年：解密8億月活的QQ后臺(tái)服務(wù)接口隔離技術(shù)》

《月活8.89億的超級(jí)IM微信是如何進(jìn)行Android端兼容測(cè)試的》

《以手機(jī)QQ為例探討移動(dòng)端IM中的“輕應(yīng)用”》

《一篇文章get微信開源移動(dòng)端數(shù)據(jù)庫組件WCDB的一切！》

《微信客戶端團(tuán)隊(duì)負(fù)責(zé)人技術(shù)訪談：如何著手客戶端性能監(jiān)控和優(yōu)化》

《微信后臺(tái)基于時(shí)間序的海量數(shù)據(jù)冷熱分級(jí)架構(gòu)設(shè)計(jì)實(shí)踐》

《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信的臃腫之困與模塊化實(shí)踐之路》

《微信后臺(tái)團(tuán)隊(duì)：微信后臺(tái)異步消息隊(duì)列的優(yōu)化升級(jí)實(shí)踐分享》

《微信團(tuán)隊(duì)原創(chuàng)分享：微信客戶端SQLite數(shù)據(jù)庫損壞修復(fù)實(shí)踐》 

《騰訊原創(chuàng)分享(一)：如何大幅提升移動(dòng)網(wǎng)絡(luò)下手機(jī)QQ的圖片傳輸速度和成功率》 

《騰訊原創(chuàng)分享(二)：如何大幅壓縮移動(dòng)網(wǎng)絡(luò)下APP的流量消耗（下篇）》 

《騰訊原創(chuàng)分享(三)：如何大幅壓縮移動(dòng)網(wǎng)絡(luò)下APP的流量消耗（上篇）》 

《微信Mars：微信內(nèi)部正在使用的網(wǎng)絡(luò)層封裝庫，即將開源》 

《如約而至：微信自用的移動(dòng)端IM網(wǎng)絡(luò)層跨平臺(tái)組件庫Mars已正式開源》 

《開源libco庫：單機(jī)千萬連接、支撐微信8億用戶的后臺(tái)框架基石 [源碼下載]》 

《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》 

《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺(tái)保活實(shí)戰(zhàn)分享(進(jìn)程保活篇)》 

《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺(tái)?；顚?shí)戰(zhàn)分享(網(wǎng)絡(luò)?；钇?》 

《Android版微信從300KB到30MB的技術(shù)演進(jìn)(PPT講稿) [附件下載]》 

《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信從300KB到30MB的技術(shù)演進(jìn)》 

《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(演講全文)》

《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(PPT講稿) [附件下載]》 

《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡》》

《微信海量用戶背后的后臺(tái)系統(tǒng)存儲(chǔ)架構(gòu)(視頻+PPT) [附件下載]》

《微信異步化改造實(shí)踐：8億月活、單機(jī)千萬連接背后的后臺(tái)解決方案》 

《微信朋友圈海量技術(shù)之道PPT [附件下載]》 

《微信對(duì)網(wǎng)絡(luò)影響的技術(shù)試驗(yàn)及分析（論文全文）》 

《一份微信后臺(tái)技術(shù)架構(gòu)的總結(jié)性筆記》 

《架構(gòu)之道：3個(gè)程序員成就微信朋友圈日均10億發(fā)布量[有視頻]》 

《快速裂變：見證微信強(qiáng)大后臺(tái)架構(gòu)從0到1的演進(jìn)歷程（一）》

《快速裂變：見證微信強(qiáng)大后臺(tái)架構(gòu)從0到1的演進(jìn)歷程（二）》 

《微信團(tuán)隊(duì)原創(chuàng)分享：Android內(nèi)存泄漏監(jiān)控和優(yōu)化技巧總結(jié)》 

《全面總結(jié)iOS版微信升級(jí)iOS9遇到的各種“坑”》 

《微信團(tuán)隊(duì)原創(chuàng)資源混淆工具：讓你的APK立減1M》 

《微信團(tuán)隊(duì)原創(chuàng)Android資源混淆工具：AndResGuard [有源碼]》 

《Android版微信安裝包“減肥”實(shí)戰(zhàn)記錄》 

《iOS版微信安裝包“減肥”實(shí)戰(zhàn)記錄》 

《移動(dòng)端IM實(shí)踐：iOS版微信界面卡頓監(jiān)測(cè)方案》 

《微信“紅包照片”背后的技術(shù)難題》 

《移動(dòng)端IM實(shí)踐：iOS版微信小視頻功能技術(shù)方案實(shí)錄》 

《移動(dòng)端IM實(shí)踐：Android版微信如何大幅提升交互性能（一）》

《移動(dòng)端IM實(shí)踐：Android版微信如何大幅提升交互性能（二）》

《移動(dòng)端IM實(shí)踐：實(shí)現(xiàn)Android版微信的智能心跳機(jī)制》 

《移動(dòng)端IM實(shí)踐：WhatsApp、Line、微信的心跳策略分析》 

《移動(dòng)端IM實(shí)踐：谷歌消息推送服務(wù)(GCM)研究（來自微信）》

《移動(dòng)端IM實(shí)踐：iOS版微信的多設(shè)備字體適配方案探討》 

《信鴿團(tuán)隊(duì)原創(chuàng)：一起走過 iOS10 上消息推送(APNS)的坑》

《騰訊信鴿技術(shù)分享：百億級(jí)實(shí)時(shí)消息推送的實(shí)戰(zhàn)經(jīng)驗(yàn)》

《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（上篇）》

《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（下篇）》

《騰訊TEG團(tuán)隊(duì)原創(chuàng)：基于MySQL的分布式數(shù)據(jù)庫TDSQL十年鍛造經(jīng)驗(yàn)分享》

《微信多媒體團(tuán)隊(duì)訪談：音視頻開發(fā)的學(xué)習(xí)、微信的音視頻技術(shù)和挑戰(zhàn)等》

《了解iOS消息推送一文就夠：史上最全iOS Push技術(shù)詳解》

《騰訊技術(shù)分享：微信小程序音視頻技術(shù)背后的故事》

《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計(jì)的方方面面》

《微信多媒體團(tuán)隊(duì)梁俊斌訪談：聊一聊我所了解的音視頻技術(shù)》

《騰訊音視頻實(shí)驗(yàn)室：使用AI黑科技實(shí)現(xiàn)超低碼率的高清實(shí)時(shí)視頻聊天》

《騰訊技術(shù)分享：微信小程序音視頻與WebRTC互通的技術(shù)思路和實(shí)踐》

《手把手教你讀取Android版微信和手Q的聊天記錄(僅作技術(shù)研究學(xué)習(xí))》

《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（算法原理篇）》

《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（容災(zāi)方案篇）》

《騰訊技術(shù)分享：GIF動(dòng)圖技術(shù)詳解及手機(jī)QQ動(dòng)態(tài)表情壓縮技術(shù)實(shí)踐》

《微信團(tuán)隊(duì)分享：Kotlin漸被認(rèn)可，Android版微信的技術(shù)嘗鮮之旅》

《社交軟件紅包技術(shù)解密(一)：全面解密QQ紅包技術(shù)方案——架構(gòu)、技術(shù)實(shí)現(xiàn)等》

《社交軟件紅包技術(shù)解密(二)：解密微信搖一搖紅包從0到1的技術(shù)演進(jìn)》

《社交軟件紅包技術(shù)解密(三)：微信搖一搖紅包雨背后的技術(shù)細(xì)節(jié)》

《社交軟件紅包技術(shù)解密(四)：微信紅包系統(tǒng)是如何應(yīng)對(duì)高并發(fā)的》

《社交軟件紅包技術(shù)解密(五)：微信紅包系統(tǒng)是如何實(shí)現(xiàn)高可用性的》

《社交軟件紅包技術(shù)解密(六)：微信紅包系統(tǒng)的存儲(chǔ)層架構(gòu)演進(jìn)實(shí)踐》

《社交軟件紅包技術(shù)解密(九)：談?wù)勈諵紅包的功能邏輯、容災(zāi)、運(yùn)維、架構(gòu)等》

《QQ設(shè)計(jì)團(tuán)隊(duì)分享：新版 QQ 8.0 語音消息改版背后的功能設(shè)計(jì)思路》

《微信團(tuán)隊(duì)分享：極致優(yōu)化，iOS版微信編譯速度3倍提升的實(shí)踐總結(jié)》

《IM“掃一掃”功能很好做？看看微信“掃一掃識(shí)物”的完整技術(shù)實(shí)現(xiàn)》

《微信團(tuán)隊(duì)分享：微信支付代碼重構(gòu)帶來的移動(dòng)端軟件架構(gòu)上的思考》

>> 更多同類文章 ……

（本文同步發(fā)布于：http://www.52im.net/thread-2958-1-1.html）