本文由微信開發團隊工程師“virwu”分享。
1、引言
近期，微信小游戲支持了視頻號一鍵開播，將微信升級到最新版本，打開騰訊系小游戲（如跳一跳、歡樂斗地主等），在右上角菜單就可以看到發起直播的按鈕一鍵成為游戲主播了（如下圖所示）。
然而微信小游戲出于性能和安全等一系列考慮，運行在一個獨立的進程中，在該環境中不會初始化視頻號直播相關的模塊。這就意味著小游戲的音視頻數據必須跨進程傳輸到主進程進行推流，給我們實現小游戲直播帶來了一系列挑戰。
（本文同步發布于：http://www.52im.net/thread-3594-1-1.html）
2、系列文章
本文是系列文章中的第5篇：
《直播系統聊天技術(一)：百萬在線的美拍直播彈幕系統的實時推送技術實踐之路》
《直播系統聊天技術(二)：阿里電商IM消息平臺，在群聊、直播場景下的技術實踐》
《直播系統聊天技術(三)：微信直播聊天室單房間1500萬在線的消息架構演進之路》
《直播系統聊天技術(四)：百度直播的海量用戶實時消息系統架構演進實踐》
《直播系統聊天技術(五)：微信小游戲直播在Android端的跨進程渲染推流實踐》（* 本文）
3、視頻采集推流
3.1 錄屏采集？
小游戲直播本質上就是把主播手機屏幕上的內容展示給觀眾，自然而然地我們可以想到采用系統的錄屏接口MediaProjection進行視頻數據的采集。
這種方案有這些優點：
- 1）系統接口，實現簡單，兼容性和穩定性有一定保證；
- 2）后期可以擴展成通用的錄屏直播；
- 3）對游戲性能影響較小，經測試對幀率影響在10%以內；
- 4）可以直接在主進程進行數據處理及推流，不用處理小游戲跨進程的問題。
但是最終這個方案被否決了，主要出于以下考慮：
- 1）需要展示系統授權彈窗；
- 2）需要謹慎處理切出小游戲后暫停畫面推流的情況，否則可能錄制到主播的其他界面，有隱私風險；
- 3）最關鍵的一點：產品設計上需要在小游戲上展示一個評論掛件（如下圖），便于主播查看直播評論以及進行互動，錄屏直播會讓觀眾也看到這個組件，影響觀看體驗的同時會暴露一些只有主播才能看到的數據。
轉念一想，既然小游戲的渲染完全是由我們控制的，為了更好的直播體驗，能否將小游戲渲染的內容跨進程傳輸到主進程來進行推流呢？
3.2 小游戲渲染架構
為了更好地描述我們采用的方案，這里先簡單介紹一下小游戲的渲染架構：
可以看到圖中左半邊表示在前臺的小游戲進程，其中MagicBrush為小游戲渲染引擎，它接收來自于小游戲代碼的渲染指令調用，將畫面渲染到在屏的SurfaceView提供的Surface上。整個過程主進程在后臺不參與。
3.3 小游戲錄屏時的情況
小游戲之前支持過游戲內容的錄制，和直播原理上類似，都需要獲取當前小游戲的畫面內容。
錄屏啟用時小游戲會切換到如下的模式進行渲染：
可以看到，MagicBrush的輸出目標不再是在屏的SurfaceView，而是Renderer產生的一個SurfaceTexture。
這里先介紹一下Renderer的作用：
Renderer是一個獨立的渲染模塊，表示一個獨立的GL環境，它可以創建SurfaceTexture作為輸入，收到SurfaceTexture的onFrameAvailable回調后通過updateTexImage方法將圖像數據轉換為類型是GL_TEXTURE_EXTERNAL_OES的紋理參與后續的渲染過程，并可以將渲染結果輸出到另一個Surface上。
下面逐步對圖中過程進行解釋：
1）MagicBrush接收來自小游戲代碼的渲染指令調用，將小游戲內容渲染到第一個Renderer所創建的SurfaceTexture上；
2）隨后這個Renderer做了兩件事情：
- 2.1）將得到的小游戲畫面紋理再次渲染到了在屏的Surface上；
- 2.2）提供紋理ID給到第二個Renderer（這里兩個Renderer通過共享GLContext來實現共享紋理）。
3）第二個Renderer將第一個Renderer提供的紋理渲染到mp4編碼器提供的輸入SurfaceTexture上，最終編碼器編碼產生mp4錄屏文件。
3.4 改造錄屏方案？
可以看到，錄屏方案中通過一個Renderer負責將游戲內容上屏，另一個Renderer將同樣的紋理渲染到編碼器上的方式實現了錄制游戲內容，直播其實類似，是不是只要將編碼器替換為直播的推流模塊就可以了呢？
確實如此，但還缺少關鍵的一環：推流模塊運行在主進程，我們需要實現跨進程傳輸圖像數據！如何跨進程呢？
說到跨進程：可能我們腦海里蹦出的第一反應就是Binder、Socket、共享內存等等傳統的IPC通信方法。但仔細一想，系統提供的SurfaceView是非常特殊的一個View組件，它不經過傳統的View樹來參與繪制，而是直接經由系統的SurfaceFlinger來合成到屏幕上，而SurfaceFlinger運行在系統進程上，我們繪制在SurfaceView所提供的Surface上的內容必然是可以跨進程進行傳輸的，而Surface跨進程的方法很簡單——它本身就實現了Parcelable接口，這意味著我們可以用Binder直接跨進程傳輸Surface對象。
于是我們有了下面這個初步方案：
可以看到：第3步不再是渲染到mp4編碼器上，而是渲染到主進程跨進程傳輸過來的Surface上，主進程的這個Surface是通過一個Renderer創建的SurfaceTexture包裝而來的，現在小游戲進程作為生產者向這個Surface渲染畫面。當一幀渲染完畢后，主進程的SurfaceTexture就會收到onFrameAvailable回調通知圖像數據已經準備完畢，隨之通過updateTexImage獲取到對應的紋理數據，這里由于直播推流模塊只支持GL_TEXTURE_2D類型的紋理，這里主進程Renderer會將GL_TEXTURE_EXTERNAL_OES轉換為GL_TEXTURE_2D紋理后給到直播推流編碼器，完成推流過程。
經過一番改造：上述方案成功地實現了將小游戲渲染在屏幕上的同時傳遞給主進程進行推流，但這真的是最優的方案嗎？
思考一番，發現上述方案中的Renderer過多了，小游戲進程中存在兩個，一個用于渲染上屏，一個用于渲染到跨進程而來的Surface上，主進程中還存在一個用于轉換紋理以及調用推流模塊。如果要同時支持錄屏，還需要在小游戲進程再起一個Renderer用于渲染到mp4編碼器，過多的Renderer意味著過多的額外渲染開銷，會影響小游戲運行性能。
3.5 跨進程渲染方案
縱觀整個流程，其實只有主進程的Renderer是必要的，小游戲所使用的額外Render無非就是想同時滿足渲染上屏和跨進程傳輸，讓我們大開腦洞——既然Surface本身就不受進程的約束，那我們干脆把小游戲進程的在屏Surface傳遞到主進程進行渲染上屏吧！
最終我們大刀闊斧地砍掉了小游戲進程的兩個冗余Renderer，MagicBrush直接渲染到了跨進程傳遞而來的Surface上，而主進程的Renderer在負責紋理類型轉換的同時也負責將紋理渲染到跨進程傳遞而來的小游戲進程的在屏Surface上，實現畫面的渲染上屏。
最終所需要的Renderer數量從原來的3個減少到了必要的1個，在架構更加清晰的同時提升了性能。
后續需要同時支持錄屏時，只要稍作改動，將mp4編碼器的輸入SurfaceTexture也跨進程傳遞到主進程，再新增一個Renderer渲染紋理到它上面就行了（如下圖所示）。
3.6 兼容性與性能
到這里，不禁有點擔心，跨進程傳輸和渲染Surface的這套方案的兼容性會不會有問題呢？
實際上，雖然并不常見，但是官方文檔里面是有說明可以跨進程進行繪制的：
SurfaceView combines a surface and a view. SurfaceView's view components are composited by SurfaceFlinger (and not the app), enabling rendering from a separate thread/process and isolation from app UI rendering.
并且Chrome以及Android O以后的系統WebView都有使用跨進程渲染的方案。
在我們的兼容性測試中，覆蓋了Android 5.1及以后的各個主流系統版本和機型，除了Android 5.x機型上出現了跨進程渲染黑屏的問題外，其余均可以正常渲染上屏和推流。
性能方面：我們使用了WebGL水族館的Demo進行了性能測試，可以看到對于平均幀率的影響在15%左右，主進程的CPU因為渲染和推流有所升高，奇怪的是小游戲進程的CPU開銷卻出現了一些下降，這里下降的原因暫時還沒有確認，懷疑與上屏操作移到主進程相關，也不排除是統計方法的影響。
3.7 小結一下
為了實現不錄制主播端的評論掛件，我們從小游戲渲染流程入手，借助于Surface跨進程渲染和傳輸圖像的能力，把小游戲渲染上屏的過程移到了主進程，并同時生成紋理進行推流，在兼容性和性能上達到了要求。
4、音頻采集推流
4.1 方案選擇
在音頻采集方案中，我們注意到在Android 10及以上系統提供了AudioPlaybackCapture方案允許我們在一定的限制內對系統音頻進行采集。當時預研的一些結論如下。
捕獲方 - 進行捕獲的條件：
- 1）Android 10(api 29)及以上；
- 2）獲取了RECORD_AUDIO權限；
- 3）通過MediaProjectionManager.createScreenCaptureIntent()進行MediaProjection權限的申請（和MediaProjection錄屏共用）；
- 4）通過AudioPlaybackCaptureConfiguration.addMatchingUsage()/AudioPlaybackCaptureConfiguration.excludeUsage() 添加/排除要捕獲的MEDIA類型；
- 5）通過 AudioPlaybackCaptureConfiguration.addMatchingUid() /AudioPlaybackCaptureConfiguration.excludeUid()添加/排除可以捕獲的應用的UID。
被捕獲方 - 可以被捕獲的條件：
- 1）Player的AudioAttributes設置的Usage為USAGE_UNKNOWN,USAGE_GAME或USAGE_MEDIA（目前絕大部分用的都是默認值，可以被捕獲）；
- 2）應用的CapturePolicy被設置為AudioAttributes#ALLOW_CAPTURE_BY_ALL，有三種辦法可以設置（以最嚴格的為準，目前微信內沒有配置，默認為可以捕獲）；
- 3）通過manifest.xml設置android:allowAudioPlaybackCapture="true"，其中，TargetApi為29及以上的應用默認為true，否則為false；
- 4）api 29及以上可以通過setAllowedCapturePolicy方法運行時設置；
- 5）api 29及以上可以通過AudioAttributes針對每一個Player單獨設置。
總的來說：Android 10及以上可以使用AudioPlaybackCapture方案進行音頻捕獲，但考慮到Android 10這個系統版本限制過高，最終我們選擇了自己來采集并混合小游戲內播放的所有音頻。
4.2 跨進程音頻數據傳輸
現在，老問題又擺在了我們眼前：小游戲混合后的音頻數據在小游戲進程，而我們需要把數據傳輸到主進程進行推流。
與一般的IPC跨進程通信用于方法調用不同：在這個場景下，我們需要頻繁地（40毫秒一次）傳輸較大的數據塊（16毫秒內的數據量在8k左右）。
同時：由于直播的特性，這個跨進程傳輸過程的延遲需要盡可能地低，否則就會出現音畫不同步的情況。
為了達到上述目標：我們對Binder、LocalSocket、MMKV、SharedMemory、Pipe這幾種IPC方案進行了測試。在搭建的測試環境中，我們在小游戲進程模擬真實的音頻傳輸的過程，每隔16毫秒發送一次序列化后的數據對象，數據對象大小分為3k/4M/10M三擋，在發送前儲存時間戳在對象中；在主進程中接收到數據并完成反序列化為數據對象的時刻作為結束時間，計算傳輸延遲。
最終得到了如下結果：
注：其中XIPCInvoker(Binder)和MMKV在傳輸較大數據量時耗時過長，不在結果中展示。
對于各個方案的分析如下（卡頓率表示延遲>2倍平均延遲且>10毫秒的數據占總數的比例）：
可以看到：LocalSocket方案在各個情況下的傳輸延遲表現都極為優異。差異的原因主要是因為裸二進制數據在跨進程傳輸到主進程后，仍需要進行一次數據拷貝操作來反序列化為數據對象，而使用LocalSocket時可以借助于ObjectStream和Serializeable來實現流式的拷貝，相比與其他方案的一次性接收數據后再拷貝節約了大量的時間（當然其他方案也可以設計成分塊流式傳輸同時拷貝，但實現起來有一定成本，不如ObjectStream穩定易用）。
我們也對LocalSocket進行了兼容性與性能測試，未出現不能傳輸或斷開連接的情況，僅在三星S6上平均延遲超過了10毫秒，其余機型延遲均在1毫秒左右，可以滿足我們的預期。
4.3 LocalSocket的安全性
常用的Binder的跨進程安全性有系統實現的鑒權機制來保證，LocalSocket作為Unix domain socket的封裝，我們必須考慮它的安全性問題。
論文《The Misuse of Android Unix Domain Sockets and Security Implications》較為詳細地分析了Android中使用LocalSocket所帶來的安全風險。
PS：論文原文附件下載（請從此鏈接的4.3節處下載：http://www.52im.net/thread-3594-1-1.html）
總結論文所述：由于LocalSocket本身缺乏鑒權機制，任意一個應用都可以進行連接，從而截取到數據或是向接收端傳遞非法數據引發異常。
針對這個特點，我們可以做的防御方法有兩種：
- 1）隨機化LocalSocket的命名，例如使用當前直播的小游戲的AppId和用戶uin等信息計算md5作為LocalSocket的名字，使得攻擊者無法通過固定或窮舉名字的方法嘗試建立連接；
- 2）引入鑒權機制，在連接成功后發送特定的隨機信息來驗證對方的真實性，然后才啟動真正的數據傳輸。
4.4 小結一下
為了兼容Android 10以下的機型也能直播，我們選擇自己處理小游戲音頻的采集，并通過對比評測，選用了LocalSocket作為跨進程音頻數據傳輸的方案，在延遲上滿足了直播的需求。
同時，通過一些對抗措施，可以有效規避LocalSocket的安全風險。
5、多進程帶來的問題
回頭來看，雖然整個方案看起來比較通順，但是在實現的過程中還是由于多進程的原因踩過不少坑，下面就分享其中兩個比較主要的。
5.1 glFinish造成渲染推流幀率嚴重下降
在剛實現跨進程渲染推流的方案后，我們進行了一輪性能與兼容性測試，在測試中發現，部分中低端機型上幀率下降非常嚴重（如下圖所示）。
復現后查看小游戲進程渲染的幀率（即小游戲進程繪制到跨進程而來的Surface上的幀率）發現可以達到不開直播時的幀率。
而我們所用的測試軟件PerfDog所記錄的是在屏Surface的繪制幀率，這就說明性能下降不是直播開銷過高引起的小游戲代碼執行效率下降，而是主進程上屏Renderer效率太低。
于是我們對主進程直播時運行效率進行了Profile，發現耗時函數為glFinish。
并且有兩次調用：
- 1）第一次調用是Renderer將外部紋理轉2D紋理時，耗時會達到100多毫秒；
- 2）第二次調用是騰訊云直播SDK內部，耗時10毫秒以內。
如果將第一次調用去掉，直播SDK內部的這次則會耗時100多毫秒。
為了弄清為什么這個GL指令耗時這么久，我們先看看它的描述：
glFinish does not return until the effects of all previously called GL commands are complete.
描述很簡單：它會阻塞直到之前調用的所有GL指令全部完成。
這么看來是之前的GL指令太多了？但是GL指令隊列是以線程為維度隔離的，在主進程的Renderer線程中，glFinish前只會執行紋理類型轉換的非常少量的GL指令，和騰訊云的同學了解到推流接口也不會在本線程執行很多GL指令，如此少量的GL指令怎么會使glFinish阻塞這么久呢？等等，大量GL指令？小游戲進程此時不就正在執行大量GL指令嗎，難道是小游戲進程的大量GL指令導致了主進程的glFinsih耗時過長？
這樣的猜測不無道理：雖然GL指令隊列是按線程隔離的，但處理指令的GPU只有一個，一個進程的GL指令過多導致另一個進程在需要glFinish時阻塞過久。Google了一圈沒找到有相關的描述，需要自己驗證這個猜測。
重新觀察一遍上面的測試數據：發現直播前能達到60幀的情況下，直播后也能達到60幀左右，這是不是就說明在小游戲的GPU負載較低時glFinish的耗時也會下降呢？
在性能下降嚴重的機型上：控制其他變量不變嘗試運行低負載的小游戲，發現glFinsih的耗時成功下降到了10毫秒左右，這就印證了上面的猜測——確實是小游戲進程正在執行的大量GL指令阻塞了主進程glFinish的執行。
該如何解決呢？小游戲進程的高負載無法改變，那能讓小游戲在一幀渲染完成以后停住等主進程的glFinish完成后再渲染下一幀嗎？
這里經過了各種嘗試：OpenGL的glFence同步機制無法跨進程使用；由于GL指令是異步執行的，通過跨進程通信加鎖鎖住小游戲的GL線程并不能保證主進程執行glFinish時小游戲進程的指令已經執行完，而能保證這點只有通過給小游戲進程加上glFinish，但這會使得雙緩沖機制失效，導致小游戲渲染幀率的大幅下降。
既然glFinish所帶來的阻塞無法避免，那我們回到問題的開始：為什么需要glFinish？由于雙緩沖機制的存在，一般來說并不需要glFinish來等待之前的繪制完成，否則雙緩沖就失去了意義。兩次glFinish中，第一次紋理處理的調用可以直接去掉，第二次騰訊云SDK的調用經過溝通，發現是為了解決一個歷史問題引入的，可以嘗試去掉。在騰訊云同學的幫助下，去掉glFinish后，渲染的幀率終于和小游戲輸出的幀率一致，經過兼容性和性能測試，沒有發現去掉glFinish帶來的問題。
這個問題最終的解法很簡單：但分析問題原因的過程實際上做了非常多的實驗，同一個應用中一個高GPU負載的進程會影響到另一個進程的glFinish耗時的這種場景確實也非常少見，能參考的資料不多。這個過程也讓我深刻體會到了glFinish使得雙緩沖機制失效所帶來的性能影響是巨大的，在使用OpenGL進行渲染繪制時對于glFinish的使用應當非常謹慎。
5.2 后臺進程優先級問題
在測試過程中：我們發現無論以多少的幀率向直播SDK發送畫面，觀眾端看到的畫面幀率始終只有16幀左右，排除后臺原因后，發現是編碼器編碼的幀率不足導致的。經騰訊云同學測試同進程內編碼的幀率是可以達到設定的30幀的，那么說明還是多進程帶來的問題，這里編碼是一個非常重的操作，需要消耗比較多的CPU資源，所以我們首先懷疑的就是后臺進程優先級的問題。
為了確認問題：
- 1）我們找來了已經root的手機，通過chrt命令提高編碼線程的優先級，觀眾端幀率立馬上到了25幀；
- 2）另一方面，經測試如果在小游戲進程上顯示一個主進程的浮窗（使主進程具有前臺優先級），幀率可以上到30幀。
綜上：可以確認幀率下降就是由于后臺進程（以及其擁有的線程）的優先級過低導致的。
提高線程優先級的做法在微信里比較常見，例如：小程序的JS線程以及小游戲的渲染線程都會在運行時通過android.os.Process.setThreadPriority方法設置線程的優先級。騰訊云SDK的同學很快提供了接口供我們設置線程優先級，但當我們真正運行起來時，卻發現編碼的幀率僅從16幀提高到了18幀左右，是哪里出問題了呢？
前面提到：我們通過chrt命令設置線程優先級是有效的，但android.os.Process.setThreadPriority這個方法設置的線程優先級對應的是renice這個命令設置的nice值。仔細閱讀chrt的manual后，發現之前測試時的理解有誤，之前直接用chrt -p [pid] [priority]的命令設置優先級，卻沒有設置調度策略這個參數，導致該線程的調度策略從Linux默認的SCHED_OTHER改為了命令缺省設置的SCHED_RR，而SCHED_RR是一種“實時策略”，導致線程的調度優先級變得非常高。
實際上：通過renice（也就是android.os.Process.setThreadPriority）設置的線程優先級，對于后臺進程所擁有線程來說沒有太大的幫助。
其實早有人解釋過這一點：
To address this, Android also uses Linux cgroups in a simple way to create more strict foreground vs. background scheduling. The foreground/default cgroup allows thread scheduling as normal. The background cgroup however applies a limit of only some small percent of the total CPU time being available to all threads in that cgroup. Thus if that percentage is 5% and you have 10 background threads all wanting to run and one foreground thread, the 10 background threads together can only take at most 5% of the available CPU cycles from the foreground. (Of course if no foreground thread wants to run, the background threads can use all of the available CPU cycles.)
關于線程優先級的設置，感興趣的同學可以看看另一位大佬的文章：《Android的離奇陷阱 — 設置線程優先級導致的微信卡頓慘案》。
最終：為了提高編碼幀率并防止后臺主進程被殺，我們最終還是決定直播時在主進程創建一個前臺Service。
6、總結與展望
多進程是一把雙刃劍，在給我們帶來隔離性和性能優勢的同時也帶來了跨進程通信這一難題，所幸借助系統Surface的能力和多種多樣的跨進程方案可以較好地解決小游戲直播中所遇到的問題。
當然：解決跨進程問題最好的方案是避免跨進程，我們也考慮了將視頻號直播的推流模塊運行在小游戲進程的方案，但出于改造成本的考慮而沒有選擇這一方案。
同時：這次對于SurfaceView跨進程渲染的實踐也對其他業務有一定參考價值——對于一些內存壓力較大或是安全風險較高，又需要進行SurfaceView渲染繪制的場景，可以把邏輯放到獨立的進程，再通過跨進程渲染的方式繪制到主進程的View上，在獲得獨立進程優勢的同時又避免了進程間跳轉所帶來的體驗的割裂。
附錄1：有關直播技術的文章匯總
《移動端實時音視頻直播技術詳解（一）：開篇》
《移動端實時音視頻直播技術詳解（二）：采集》
《移動端實時音視頻直播技術詳解（三）：處理》
《移動端實時音視頻直播技術詳解（四）：編碼和封裝》
《移動端實時音視頻直播技術詳解（五）：推流和傳輸》
《移動端實時音視頻直播技術詳解（六）：延遲優化》
《理論聯系實際：實現一個簡單地基于html]5的實時視頻直播》
《實時視頻直播客戶端技術盤點：Native、html]5、WebRTC、微信小程序》
《Android直播入門實踐：動手搭建一套簡單的直播系統》
《淘寶直播技術干貨：高清、低延時的實時視頻直播技術解密》
《技術干貨：實時視頻直播首屏耗時400ms內的優化實踐》
《新浪微博技術分享：微博實時直播答題的百萬高并發架構實踐》
《實時音頻的混音在視頻直播中的技術原理和實踐總結》
《七牛云技術分享：使用QUIC協議實現實時視頻直播0卡頓！》
《近期大熱的實時直播答題系統的實現思路與技術難點分享》
《P2P技術如何將實時視頻直播帶寬降低75%？》
《網易云信實時視頻直播在TCP數據傳輸層的一些優化思路》
《首次披露：快手是如何做到百萬觀眾同場看直播仍能秒開且不卡頓的？》
《淺談實時音視頻直播中直接影響用戶體驗的幾項關鍵技術指標》
《技術揭秘：支持百萬級粉絲互動的Facebook實時視頻直播》
《移動端實時視頻直播技術實踐：如何做到實時秒開、流暢不卡》
《實現延遲低于500毫秒的1080P實時音視頻直播的實踐分享》
《淺談開發實時視頻直播平臺的技術要點》
《直播系統聊天技術(一)：百萬在線的美拍直播彈幕系統的實時推送技術實踐之路》
《直播系統聊天技術(二)阿里電商IM消息平臺，在群聊、直播場景下的技術實踐》
《直播系統聊天技術(三)：微信直播聊天室單房間1500萬在線的消息架構演進之路》
《直播系統聊天技術(四)：百度直播的海量用戶實時消息系統架構演進實踐》
《直播系統聊天技術(五)：微信小游戲直播在Android端的跨進程渲染推流實踐》
《海量實時消息的視頻直播系統架構演進之路(視頻+PPT)[附件下載]》
《YY直播在移動弱網環境下的深度優化實踐分享(視頻+PPT)[附件下載]》
《從0到1：萬人在線的實時音視頻直播技術實踐分享(視頻+PPT) [附件下載]》
《在線音視頻直播室服務端架構最佳實踐(視頻+PPT) [附件下載]》
>> 更多同類文章 ……
附錄2：微信團隊分享的技術文章匯總
《微信朋友圈千億訪問量背后的技術挑戰和實踐總結》
《微信團隊分享：微信移動端的全文檢索多音字問題解決方案》
《微信團隊分享：iOS版微信的高性能通用key-value組件技術實踐》
《微信團隊分享：iOS版微信是如何防止特殊字符導致的炸群、APP崩潰的？》
《微信團隊原創分享：iOS版微信的內存監控系統技術實踐》
《iOS后臺喚醒實戰：微信收款到賬語音提醒技術總結》
《微信團隊分享：視頻圖像的超分辨率技術原理和應用場景》
《微信團隊分享：微信每日億次實時音視頻聊天背后的技術解密》
《微信團隊分享：微信Android版小視頻編碼填過的那些坑》
《微信手機端的本地數據全文檢索優化之路》
《企業微信客戶端中組織架構數據的同步更新方案優化實戰》
《微信團隊披露：微信界面卡死超級bug“15。。。。”的來龍去脈》
《月活8.89億的超級IM微信是如何進行Android端兼容測試的》
《一篇文章get微信開源移動端數據庫組件WCDB的一切！》
《微信客戶端團隊負責人技術訪談：如何著手客戶端性能監控和優化》
《微信后臺基于時間序的海量數據冷熱分級架構設計實踐》
《微信團隊原創分享：Android版微信的臃腫之困與模塊化實踐之路》
《微信后臺團隊：微信后臺異步消息隊列的優化升級實踐分享》
《微信團隊原創分享：微信客戶端SQLite數據庫損壞修復實踐》
《微信Mars：微信內部正在使用的網絡層封裝庫，即將開源》
《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《開源libco庫：單機千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]》
《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》
《微信團隊原創分享：Android版微信后臺保活實戰分享(進程保活篇)》
《微信團隊原創分享：Android版微信后臺保活實戰分享(網絡保活篇)》
《Android版微信從300KB到30MB的技術演進(PPT講稿) [附件下載]》
《微信團隊原創分享：Android版微信從300KB到30MB的技術演進》
《微信技術總監談架構：微信之道——大道至簡(演講全文)》
《微信技術總監談架構：微信之道——大道至簡(PPT講稿) [附件下載]》
《如何解讀《微信技術總監談架構：微信之道——大道至簡》》
《微信海量用戶背后的后臺系統存儲架構(視頻+PPT) [附件下載]》
《微信異步化改造實踐：8億月活、單機千萬連接背后的后臺解決方案》
《微信朋友圈海量技術之道PPT [附件下載]》
《微信對網絡影響的技術試驗及分析（論文全文）》
《一份微信后臺技術架構的總結性筆記》
《架構之道：3個程序員成就微信朋友圈日均10億發布量[有視頻]》
《快速裂變：見證微信強大后臺架構從0到1的演進歷程（一）》
《快速裂變：見證微信強大后臺架構從0到1的演進歷程（二）》
《微信團隊原創分享：Android內存泄漏監控和優化技巧總結》
《全面總結iOS版微信升級iOS9遇到的各種“坑”》
《微信團隊原創資源混淆工具：讓你的APK立減1M》
《微信團隊原創Android資源混淆工具：AndResGuard [有源碼]》
《Android版微信安裝包“減肥”實戰記錄》
《iOS版微信安裝包“減肥”實戰記錄》
《移動端IM實踐：iOS版微信界面卡頓監測方案》
《微信“紅包照片”背后的技術難題》
《移動端IM實踐：iOS版微信小視頻功能技術方案實錄》
《移動端IM實踐：Android版微信如何大幅提升交互性能（一）》
《移動端IM實踐：Android版微信如何大幅提升交互性能（二）》
《移動端IM實踐：實現Android版微信的智能心跳機制》
《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》
《移動端IM實踐：谷歌消息推送服務(GCM)研究（來自微信）》
《移動端IM實踐：iOS版微信的多設備字體適配方案探討》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（上篇）》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（下篇）》
《微信多媒體團隊訪談：音視頻開發的學習、微信的音視頻技術和挑戰等》
《騰訊技術分享：微信小程序音視頻技術背后的故事》
《騰訊資深架構師干貨總結：一文讀懂大型分布式系統設計的方方面面》
《微信多媒體團隊梁俊斌訪談：聊一聊我所了解的音視頻技術》
《騰訊音視頻實驗室：使用AI黑科技實現超低碼率的高清實時視頻聊天》
《騰訊技術分享：微信小程序音視頻與WebRTC互通的技術思路和實踐》
《手把手教你讀取Android版微信和手Q的聊天記錄(僅作技術研究學習)》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（容災方案篇）》
《騰訊技術分享：GIF動圖技術詳解及手機QQ動態表情壓縮技術實踐》
《微信團隊分享：Kotlin漸被認可，Android版微信的技術嘗鮮之旅》
《社交軟件紅包技術解密(二)：解密微信搖一搖紅包從0到1的技術演進》
《社交軟件紅包技術解密(三)：微信搖一搖紅包雨背后的技術細節》
《社交軟件紅包技術解密(四)：微信紅包系統是如何應對高并發的》
《社交軟件紅包技術解密(五)：微信紅包系統是如何實現高可用性的》
《社交軟件紅包技術解密(六)：微信紅包系統的存儲層架構演進實踐》
《社交軟件紅包技術解密(十一)：解密微信紅包隨機算法(含代碼實現)》
《微信團隊分享：極致優化，iOS版微信編譯速度3倍提升的實踐總結》
《IM“掃一掃”功能很好做？看看微信“掃一掃識物”的完整技術實現》
《微信團隊分享：微信支付代碼重構帶來的移動端軟件架構上的思考》
《IM開發寶典：史上最全，微信各種功能參數和邏輯規則資料匯總》
《微信團隊分享：微信直播聊天室單房間1500萬在線的消息架構演進之路》
>> 更多同類文章 ……
（本文同步發布于：http://www.52im.net/thread-3594-1-1.html）