拓荒微信1.0 for Android的測(cè)試版本于2011年1月發(fā)布。這是微信Android客戶端的第一個(gè)版本，軟件架構(gòu)采用早期標(biāo)準(zhǔn)的Android系統(tǒng)應(yīng)用設(shè)計(jì)。

【圖1】

第一個(gè)版本是兩個(gè)人用了一個(gè)多月的時(shí)間開(kāi)發(fā)出來(lái)的，其中一個(gè)還是剛剛畢業(yè)沒(méi)多久的實(shí)習(xí)生。這個(gè)時(shí)期團(tuán)隊(duì)一窮二白，資源有限、經(jīng)驗(yàn)不夠，主導(dǎo)思想是，復(fù)雜的事情盡量交出去做，保持最精簡(jiǎn)的客戶端代碼。得益于Android應(yīng)用開(kāi)發(fā)簡(jiǎn)單快速，從結(jié)構(gòu)上看，這個(gè)時(shí)候其實(shí)還沒(méi)有到需要特別設(shè)計(jì)的階段，是最原始、簡(jiǎn)單的Android應(yīng)用。

當(dāng)然，再簡(jiǎn)單的軟件也要考慮基本的設(shè)計(jì)思路。分層設(shè)計(jì)思想從這最早的版本開(kāi)始引入一直到今天。回顧當(dāng)時(shí)的設(shè)計(jì)，更像是MVP結(jié)合事件通知機(jī)制。從最上面由Activity組件組成的UI層（VIEW），往下到由NetScene組成的表現(xiàn)層（Presenter），再往下Network負(fù)責(zé)網(wǎng)絡(luò)長(zhǎng)短連接與數(shù)據(jù)庫(kù)的通信與Storage組成的存儲(chǔ)層。NetScene是一個(gè)網(wǎng)絡(luò)或者本地任務(wù)的基本單元，包括操作網(wǎng)絡(luò)做數(shù)據(jù)收發(fā)、協(xié)議編解碼，操作數(shù)據(jù)庫(kù)做各種聯(lián)系人、消息模塊的讀寫(xiě)。典型的例子如發(fā)送一條消息NetSceneSendMsg、做一次收信同步操作NetSceneSync。1.0版本的微信整個(gè)UI的activity可能不超過(guò)五個(gè)。

這個(gè)階段，不需要做什么“減法”，我們的安裝包也只有354k。

成長(zhǎng)微信的快速增長(zhǎng)，從2.0版本開(kāi)始第一次爆發(fā)。從語(yǔ)音版，到附近的人、漂流瓶，再到搖一搖。這個(gè)階段的我們，似乎將全部的時(shí)間和精力都放在新功能拓展上。新的Activity、新的NetScene加上新的Storage，在看似成熟的框架里，一個(gè)功能就這樣完成了。簡(jiǎn)單、快速、暴力。隨之而來(lái)的，是一些之前完全沒(méi)有想到會(huì)可能出現(xiàn)的問(wèn)題，讓最開(kāi)始接觸Android開(kāi)發(fā)的我們措手不及。

早期版本因?yàn)榻?jīng)驗(yàn)的問(wèn)題，產(chǎn)品上很多功能不去想也不敢去想，版本開(kāi)發(fā)的時(shí)間跨度也比較長(zhǎng)。隨著開(kāi)發(fā)經(jīng)驗(yàn)的積累和對(duì)產(chǎn)品方向的理解，3.0之后的每一個(gè)小版本都處在一到兩周的高速迭代過(guò)程中。

追求更好的用戶體驗(yàn)，更多豐富的功能是產(chǎn)品經(jīng)理們永遠(yuǎn)不會(huì)放棄的事情，尤其是在新功能為微信的新增用戶帶來(lái)了一次次爆發(fā)式的增長(zhǎng)之后，更是無(wú)法控制。功能的試錯(cuò)頻率大大加速，機(jī)型覆蓋量上升后的兼容性問(wèn)題也逐漸暴露。代碼量、內(nèi)存占用、安裝包體積迅速膨脹。而同樣處于發(fā)展中的Android系統(tǒng)，也給我們埋下了很多坑，需要開(kāi)發(fā)自己來(lái)實(shí)現(xiàn)、修復(fù)和優(yōu)化。放在今天webview組件不再是什么問(wèn)題，但在2.3之前的系統(tǒng)里面都會(huì)存在嚴(yán)重的內(nèi)存泄露。內(nèi)存問(wèn)題為微信客戶端架構(gòu)的第一次進(jìn)化埋下了伏筆。

變革在微信1.0時(shí)代的時(shí)候，我們的關(guān)注點(diǎn)更偏向功能，隨著用戶增長(zhǎng)，性能和穩(wěn)定性問(wèn)題逐漸浮上水面。2.0版本后，用戶反饋中微信消息推送不及時(shí)的比例在上升，作為一款目標(biāo)替代短信的即時(shí)通訊應(yīng)用，無(wú)法及時(shí)收取別人發(fā)來(lái)的消息，這一點(diǎn)是非常致命的。

Android 1.5、1.6、2.1在當(dāng)時(shí)是主要的版本，那個(gè)時(shí)候是沒(méi)有今天的GCM的，甚至連C2DM也是2.2系統(tǒng)之后才會(huì)有的。而谷歌服務(wù)在國(guó)內(nèi)被屏蔽，在相當(dāng)長(zhǎng)一段時(shí)間內(nèi)，無(wú)論是C2DM還是GCM都無(wú)法正常進(jìn)行推送。沒(méi)有像APNS一樣穩(wěn)定的推送通道可供Android平臺(tái)的應(yīng)用使用，怎么辦？自己實(shí)現(xiàn)。

國(guó)內(nèi)網(wǎng)絡(luò)的特殊性，使得我們?cè)賹?shí)現(xiàn)微信推送機(jī)制時(shí)，需要維持準(zhǔn)確的心跳周期。如果一段時(shí)間沒(méi)有活動(dòng)，運(yùn)營(yíng)商便會(huì)將長(zhǎng)連接斷開(kāi)以回收資源，這時(shí)服務(wù)器發(fā)消息給客戶端就接收不到了。進(jìn)一步研究發(fā)現(xiàn)，運(yùn)營(yíng)商網(wǎng)絡(luò)的時(shí)間限制各個(gè)地區(qū)不同，有的地區(qū)有兩分鐘，有的地區(qū)有半個(gè)小時(shí)，這種情況是不可接受的。我們的解決方案是縮短心跳間隔，在網(wǎng)絡(luò)運(yùn)營(yíng)商把客戶端到接入點(diǎn)之間的連接斷開(kāi)之前，我再發(fā)送一次心跳，主動(dòng)維持住這個(gè)長(zhǎng)連接的活性。這個(gè)我們稱之為長(zhǎng)連接的?；?。關(guān)于長(zhǎng)連接的?；畈呗裕⑿乓沧鲞^(guò)多次優(yōu)化，這里另文介紹，不再贅述。

還記得前面說(shuō)微信的膨脹嗎？代碼、內(nèi)存、apk大小都在膨脹，這其中，內(nèi)存對(duì)消息收發(fā)的影響很關(guān)鍵。Android運(yùn)行時(shí)的擇優(yōu)置換機(jī)制，會(huì)選取占用資源最多的程序結(jié)束掉，除了微信自己功能膨脹導(dǎo)致內(nèi)存占用加大之外，前面說(shuō)的不省心的webview，還會(huì)給我們?cè)趦?nèi)存問(wèn)題上挖坑。而結(jié)果就是在用戶手機(jī)運(yùn)行APP比較多的時(shí)候，微信會(huì)被系統(tǒng)殺掉回收資源，消息收取不及時(shí)的問(wèn)題就出來(lái)了。

如何解決？方法其實(shí)不少，微信選擇的，是輕重分離的思路。通過(guò)在微信3.5版本時(shí)候做的架構(gòu)重構(gòu)，實(shí)現(xiàn)了不受功能增長(zhǎng)、系統(tǒng)缺陷影響的穩(wěn)定推送方案。

【圖2】

對(duì)比v1.x版本的微信客戶端架構(gòu)圖，我們將右下角Network的部分用輕重進(jìn)程分離的思想，獨(dú)立到一個(gè)單獨(dú)的進(jìn)程（:push）中，而上面兩個(gè)層級(jí)依然跑在微信的主進(jìn)程（:worker）中。而對(duì)于有內(nèi)存泄露問(wèn)題的webview或者其他不頻繁使用的功能，再把其分離到獨(dú)立的工具進(jìn)程（:tools）中。通過(guò)分離進(jìn)程，微信第一次重構(gòu)解決了系統(tǒng)因?yàn)槲⑿刨Y源消耗，主動(dòng)干掉微信服務(wù)的困境。分離后的push進(jìn)程內(nèi)存占用以及被系統(tǒng)kill回收的幾率大幅降低，而對(duì)于worker和tools進(jìn)程，我們不再要求其一定存在，只在用戶收到消息，或者進(jìn)入h5相關(guān)功能界面時(shí)存在即可。這個(gè)版本的架構(gòu)變更基本達(dá)成了我們?cè)O(shè)定的目標(biāo)，無(wú)論是電量還是平均待機(jī)內(nèi)存消耗上都大幅度下降，從內(nèi)存上來(lái)看下降了70%，電量的話也比競(jìng)品和我們前一個(gè)版本有好轉(zhuǎn)。

當(dāng)然任何事物都有兩面性。這一次架構(gòu)的改變存在的問(wèn)題逐漸在我們后面的開(kāi)發(fā)當(dāng)中暴露出來(lái)。比如進(jìn)程每一次都要重新加載，里面所有的Cache、圖片、界面全部要重新去執(zhí)行一遍同樣的代碼，每一次加載內(nèi)存都需要重新消耗時(shí)間。而啟動(dòng)速度變慢，則是最明顯，用戶最能感知的問(wèn)題。“地球出現(xiàn)頻率高了”是我們?cè)谶@一時(shí)期經(jīng)常聽(tīng)到的聲音。而系統(tǒng)資源的消耗實(shí)際上比原來(lái)單進(jìn)程的時(shí)候會(huì)更多，每一個(gè)進(jìn)程都需要額外多占用一份虛擬機(jī)部分的內(nèi)存。

這些缺點(diǎn)在3.5版本時(shí)代是可以接受的。從監(jiān)測(cè)結(jié)果上看，啟動(dòng)速度變慢將微信的啟動(dòng)速度延長(zhǎng)到了秒級(jí)，從原來(lái)的300-500毫秒到現(xiàn)在800-1000毫秒的級(jí)別。主要的圖片緩存失效，則通過(guò)異步加載、解碼、展示解決。拉長(zhǎng)來(lái)看，微信的主進(jìn)程資源會(huì)被自動(dòng)回收，平均內(nèi)存占用相比之前還是下降的。即便在今天來(lái)回顧，依然可以看到，輕重進(jìn)程拆分的思路是正確的選擇。即便系統(tǒng)層面各種各樣的bug逐漸減少，但應(yīng)用的迭代使得功能一定不會(huì)減少。為了保證圖片、資源類(lèi)在速度上的體驗(yàn)，內(nèi)存的消耗也只會(huì)更大，是空間換時(shí)間的思路。而輕重分離，保證了核心服務(wù)在設(shè)備資源發(fā)生競(jìng)爭(zhēng)時(shí)最大概率存活的同時(shí)，不造成對(duì)設(shè)備過(guò)多的資源占用。典型的場(chǎng)景就是用戶開(kāi)啟游戲、視頻錄制通話等大型應(yīng)用，作為常駐應(yīng)用，不應(yīng)該搶占額外的有限資源，需要做到“該放手的時(shí)候就放手”。

進(jìn)化很快，微信的架構(gòu)演進(jìn)進(jìn)入了第三個(gè)階段（v3.x）。微信4.5版本的開(kāi)發(fā)過(guò)程中，出現(xiàn)了無(wú)法安裝在一部分Android 2.3以下系統(tǒng)的機(jī)器上，當(dāng)時(shí)2.3的市占率還在50%以上。試想一下，市場(chǎng)上一半用戶的手機(jī)不能安裝使用微信，這對(duì)我們是一個(gè)致命打擊。放在今天看，2.3早已被淘汰，但在當(dāng)時(shí)，我們不可能停下來(lái)等待，無(wú)論從開(kāi)發(fā)和產(chǎn)品來(lái)說(shuō)都是不可接受的。技術(shù)分析的直接原因就是，微信的發(fā)展速度太快，觸發(fā)到Android虛擬機(jī)機(jī)制的設(shè)計(jì)缺陷。

兩個(gè)問(wèn)題，一是單dex 65535方法數(shù)限制，二是線性內(nèi)存分配器（LinearAlloc）限制。今天的Android開(kāi)發(fā)者看到這兩個(gè)限制都不會(huì)陌生。前者是因?yàn)锳ndroid的早期設(shè)計(jì)中，對(duì)dex文件中方法id用16位整型標(biāo)記，單個(gè)dex文件中的方法數(shù)無(wú)法超過(guò)65535，eclipse環(huán)境中生成不了未做過(guò)proguard的debug apk。后者則是dalvik虛擬機(jī)用來(lái)加載類(lèi)的堆內(nèi)存大小被硬編碼了，2.3以下是5M，2.3以上是8M，微信無(wú)法安裝的原因就是因?yàn)檫@個(gè)堆內(nèi)存被耗盡導(dǎo)致dexopt失敗。

今天來(lái)看，Google已經(jīng)給出了一些可靠的解決方案，輔以更加先進(jìn)的gradle + Android Studio，開(kāi)發(fā)者們可能根本不會(huì)再遇到這兩個(gè)經(jīng)典問(wèn)題，。官方的MultiDex分dex機(jī)制解決了方法數(shù)限制的問(wèn)題，其中main dex最小化原則，結(jié)合dalvik LinearAlloc heap size調(diào)整（修改到了16M），使得dexopt的失敗幾率大幅下降。而art的出現(xiàn)徹底不再存在LinearAlloc這樣的限制?；剡^(guò)來(lái)再看，那個(gè)時(shí)代里微信是如何通過(guò)軟件架構(gòu)調(diào)整解決這些問(wèn)題的。

微信在高速發(fā)展過(guò)程當(dāng)中，到5.0的時(shí)候已經(jīng)有很多功能，而其中一些功能，隨著用戶群體、產(chǎn)品設(shè)計(jì)等因素變化，用戶使用的頻率在改變。之前試錯(cuò)的一些功能，也大量存留在微信版本中。這些不常使用的功能不應(yīng)該始終占用程序資源，從架構(gòu)上進(jìn)行縱向分離，保證主要場(chǎng)景的體驗(yàn)，是這一時(shí)期的主要設(shè)計(jì)思路。

【圖3】

要做的第一步就是解耦。微信這類(lèi)社交型應(yīng)用，在用戶數(shù)據(jù)、關(guān)系、消息等結(jié)構(gòu)上存在著各種各樣復(fù)雜的依賴，這些依賴相比工具型的軟件來(lái)說(shuō)，調(diào)用頻率更高，性能要求也更高。想做到完美的拆分不是一件容易的事，但是不完美的拆分卻是可以達(dá)成的。輕重分離的思想再一次被應(yīng)用，這一次是在代碼模塊的使用和組織上。保證主app功能的快速和穩(wěn)定，將附屬的新功能分離在獨(dú)立的插件工程（p_XX）中，每個(gè)插件有獨(dú)立的UI界面邏輯和資源、存儲(chǔ)及網(wǎng)絡(luò)協(xié)議編解碼處理邏輯，通過(guò)共用統(tǒng)一的基礎(chǔ)庫(kù)接口訪問(wèn)網(wǎng)絡(luò)服務(wù)。

將微信功能解耦為插件，一個(gè)插件內(nèi)僅向下依賴。插件最后編譯出來(lái)會(huì)是一個(gè)jar包，其內(nèi)包括的實(shí)際內(nèi)容是對(duì)應(yīng)的dex。這里需要注意的是，插件并不需要有獨(dú)立的進(jìn)程空間，而是根據(jù)該插件實(shí)際的場(chǎng)景決定其運(yùn)行的實(shí)際進(jìn)程，絕大多數(shù)情況下，插件是和主app功能共享多進(jìn)程載體的。

v3.x架構(gòu)的改造工作量對(duì)當(dāng)時(shí)的我們來(lái)說(shuō)很大，從最開(kāi)始4.3版本發(fā)現(xiàn)dex limit和LinearAlloc limit到5.0版本成型做第一次的驗(yàn)證，我們花了8個(gè)月時(shí)間，解耦出來(lái)的工程項(xiàng)目有60個(gè)以上。4.5版本將附近的人分離出去是作為一次試驗(yàn)，為5.0這一大版本填完了坑。5.0版本是微信歷史上非常重要的一環(huán)，從這個(gè)版本開(kāi)始引入了游戲、支付和更加完善的公眾賬號(hào)體系。

這種設(shè)計(jì)思路不是微信首創(chuàng)，現(xiàn)在回顧也并不復(fù)雜。如果你的產(chǎn)品歷史功能不多，迭代不是很快，可以全部人停下來(lái)1到2個(gè)月集中一次重構(gòu)搞定。但對(duì)于微信來(lái)說(shuō)，但這一版的架構(gòu)變更，更像是在給天上飛著的飛機(jī)換發(fā)動(dòng)機(jī)，由一支10來(lái)個(gè)人組成的團(tuán)隊(duì)完成?；ヂ?lián)網(wǎng)的快速、敏捷給處在“創(chuàng)業(yè)”階段的我們新的挑戰(zhàn)。如何做到呢？要保證不給處于高度需求壓力下的開(kāi)發(fā)人員增加架構(gòu)變動(dòng)的額外負(fù)擔(dān)，首先要做的就是不要讓他們重復(fù)修改代碼，無(wú)縫遷移到新的架構(gòu)。

一、創(chuàng)建必要的工具和規(guī)范。微信在4.3發(fā)現(xiàn)問(wèn)題之前，一直堅(jiān)持著非常好的開(kāi)發(fā)效率優(yōu)化思想，代碼自動(dòng)生成起到了很大的幫助。團(tuán)隊(duì)內(nèi)部使用的自研的代碼生成工具autogen，通過(guò)簡(jiǎn)單的xml定義，即可生成所需要的存儲(chǔ)、協(xié)議編解碼、事件機(jī)制代碼。這使得我們具備了比較輕松解耦的前提。
二、新的架構(gòu)要求開(kāi)發(fā)者在做新功能時(shí)，使用獨(dú)立插件子工程，好的工程模板可以事半功倍。早期傳承下來(lái)的分層設(shè)計(jì)，也使得開(kāi)發(fā)人員在前后兩種開(kāi)發(fā)模式下的學(xué)習(xí)成本降到最低。對(duì)應(yīng)的編譯和開(kāi)發(fā)調(diào)試工具。
三、對(duì)于歷史實(shí)現(xiàn)的功能特性，盡量通過(guò)反射等一些技巧，來(lái)保證不需要大規(guī)模重寫(xiě)代碼，“先抗住，再優(yōu)化”。不要一開(kāi)始就追求完美，先活下來(lái)。直到5.1、5.2版本，我們才基本上全部完成這一次程序架構(gòu)調(diào)整。
四、人。架構(gòu)調(diào)整是必須要做的事，但是作為發(fā)起者，也不能只從理論角度去強(qiáng)硬推動(dòng)。減少開(kāi)發(fā)者的工作量，而不是增加，站在開(kāi)發(fā)者的角度想問(wèn)題，往往會(huì)得到非常積極的響應(yīng)。

不同的客戶端架構(gòu)時(shí)期，背后的團(tuán)隊(duì)和開(kāi)發(fā)模式也會(huì)有所不同。對(duì)比三個(gè)版本的客戶端架構(gòu)，v1.x和v2.x的時(shí)候比較適合小型團(tuán)隊(duì)、沒(méi)有特別復(fù)雜或者反復(fù)需求的客戶端進(jìn)行快速開(kāi)發(fā)。單trunk主線開(kāi)發(fā)即可滿足。每次發(fā)布后，拉出來(lái)一個(gè)對(duì)應(yīng)的release branch，如果發(fā)現(xiàn)有bug或者小優(yōu)化需要修改，直接在這個(gè)release branch上修改、測(cè)試、發(fā)布上線。這一時(shí)期release branch通常保持在兩個(gè)以內(nèi)，當(dāng)前版本和前一版本。當(dāng)前版本是為了線上問(wèn)題的快速發(fā)布，而前版本則是為了修復(fù)一些廠商渠道預(yù)裝的問(wèn)題。

【圖4】

v3.x就比較適合中到大型團(tuán)隊(duì)，解耦之后，可以支持多個(gè)團(tuán)隊(duì)的并行開(kāi)發(fā)，也可以滿足多個(gè)版本的同時(shí)開(kāi)發(fā)和發(fā)布。微信的產(chǎn)品經(jīng)理和客戶端開(kāi)發(fā)人員的比例大概是1.5+，也就是說(shuō)產(chǎn)品經(jīng)理會(huì)比開(kāi)發(fā)人員多50%以上。開(kāi)發(fā)人員會(huì)面對(duì)產(chǎn)品各式各樣的需求需要實(shí)現(xiàn)，很多需求處于原型或者是設(shè)計(jì)階段，而有些即便開(kāi)發(fā)完成，也需要和老大體驗(yàn)修改。這種不穩(wěn)定狀態(tài)的需求，往往是今天說(shuō)最終確定，但2個(gè)小時(shí)后就可能要修改，甚至臨上線前都可能說(shuō)這個(gè)功能被砍掉，不要發(fā)布了。不穩(wěn)定的需求會(huì)帶來(lái)不穩(wěn)定的代碼實(shí)現(xiàn)，質(zhì)量也沒(méi)法控制。通過(guò)多迭代多版本多分支并行開(kāi)發(fā)，只有所有人體驗(yàn)過(guò)最終確認(rèn)沒(méi)問(wèn)題可以上線，才會(huì)合入發(fā)布版本上線。

這個(gè)過(guò)程像什么？像開(kāi)源項(xiàng)目的開(kāi)發(fā)。

開(kāi)放進(jìn)入到2015年后，微信在軟件架構(gòu)上逐漸趨于平穩(wěn)。在v3.x原有插件加載基礎(chǔ)上，研究了更多行業(yè)內(nèi)Android應(yīng)用的技術(shù)架構(gòu)。結(jié)合官方MultiDex的實(shí)現(xiàn)，增加動(dòng)態(tài)熱補(bǔ)丁功能，通過(guò)終端的運(yùn)營(yíng)系統(tǒng)，實(shí)現(xiàn)了微信客戶端補(bǔ)丁版本更新48小時(shí)90%+覆蓋率。編譯系統(tǒng)也從buck+修改為微信自研的builder構(gòu)建，支持LinearAlloc和methods/fields count的實(shí)時(shí)計(jì)算，以及融合了MultiDex與微信插件模式的dex自動(dòng)分包。在v2.x架構(gòu)輕重分離的多進(jìn)程思路基礎(chǔ)上，進(jìn)一步優(yōu)化實(shí)現(xiàn)了push的在收信條件下的“lightpush”運(yùn)行模式。在僅消耗push進(jìn)程低內(nèi)存的條件下，實(shí)時(shí)收取新消息通知，避免對(duì)進(jìn)行中的游戲進(jìn)行資源搶占的同時(shí)，又可以及時(shí)收取消息。

【圖5】

更重要的是，我們開(kāi)始將目光轉(zhuǎn)移到開(kāi)源的開(kāi)發(fā)模式上。v3.x的并行開(kāi)發(fā)模式，在svn下已不再適應(yīng)。2015年上半年開(kāi)始微信Android客戶端團(tuán)隊(duì)開(kāi)始轉(zhuǎn)向git，充分發(fā)揮git在多團(tuán)隊(duì)并行開(kāi)發(fā)下的優(yōu)勢(shì)。內(nèi)部也放棄了沿用許久的ant + eclipse，全面轉(zhuǎn)向gradle + Android Studio的分布式構(gòu)建思想。通過(guò)內(nèi)部開(kāi)源，微信內(nèi)的公共組件已經(jīng)可以通過(guò)maven在不同的開(kāi)發(fā)團(tuán)隊(duì)中共享并隨時(shí)使用。

最新評(píng)論