大型IM工程重構實踐：企業微信Android端的重構之路

Posted on 2024-03-28 11:21 Jack Jiang 閱讀(123) 評論(0) 編輯收藏

本文由騰訊技術yeconglu分享，原題“企業微信大型Android系統重構之路”，下文進行了排版和內容優化等。

1、引言

企業微信本地部署版（下文簡稱為本地版）是從2017年起，脫胎于企業微信的一款產品。本地版的后臺服務能獨立部署在政府或者大型企業的本地服務器上。在一個已經迭代了7年的大型Android端工程中，企業微信本地版不可避免地會暴露出一些遺留系統的特點。

本文將探討我們在大型IM工程實踐中采用的一些行之有效的重構方法和實例，以及如何讓一個大型軟件系統持續保持活力。

技術交流：

- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

（本文已同步發布于：http://www.52im.net/thread-4633-1-1.html）

2、企業微信技術合集

《企業微信的IM架構設計揭秘：消息模型、萬人群、已讀回執、消息撤回等》

《企業微信針對百萬級組織架構的客戶端性能優化實踐》

《揭秘企業微信是如何支持超大規模IM組織架構的——技術解讀四維關系鏈》

《企業微信客戶端中組織架構數據的同步更新方案優化實戰》

《大型IM工程重構實踐：企業微信Android端的代碼重構之路》（* 本文）

3、遺留系統的特點

Martin Fowler 曾經說過這樣一句話：

Let’s face it, all we are doing is writing tomorrow’s legacy software today.

你現在所寫的每一行代碼，都是未來的遺留系統。

很多人以為存在時間很長的就是遺留系統，但這其實是個誤區。時間長短并不能作為衡量遺留系統的標準。

判斷遺留系統的幾個維度是：

1）代碼；
2）架構；
3）測試；
4）DevOps；
5）技術和工具。

遺留系統的真正特點其實是：

1）代碼質量差；
2）架構混亂；
3）沒有測試；
4）純手工的 DevOps（或運維）；
5）老舊的技術和工具。

看看下面這 6 個問題是否在你的項目中也曾經遇到過：

如果你的產品也有類似的一些問題，符合的“癥狀”越多，你的產品就越趨近于一個遺留系統。當遺留系統這個泥球越滾越大時，我們對它投入的改造成本就會越來越高。

遺留系統就像一輛老破舊的小汽車，不知道啥時候會出問題，維修成本也越來越高，想快也快不起來。

4、什么是重構

重構（名詞）：對軟件內部結構的一種調整，目的是在不改變軟件可觀察行為的前提下，提高其可理解性，降低其修改成本。

具體來說：

1）小型重構：是指對單個類內部的重構優化。通常包括對方法名稱、方法參數數量、方法大小等內容的修改。

2）中型重構：是對多個類間的重構優化，通常的一些修改包括提取接口、超類、委托等調整。

3）大型重構：是對整個系統的架構進行重構優化，比如組件化、應用中臺架構升級等，通常在做大型重構時也會伴隨中小型的代碼重構。

以組件化為例：通過提取公用的基礎組件和業務組件，來提高代碼的可復用性，同時讓業務能獨立演進，就是一種大型重構。重構的目的是在不改變軟件可觀察行為的前提下，重點提高其可理解性，降低其修改成本。

因此計算重構收益的方式很簡單，從商業的角度來看，收益 = 軟件價值 - (研發 + 維護成本)。

如果我們只注重業務上的價值而忽略了軟件的研發維護成本，那么長此以往就會來到拐點 1。當研發維護成本超出業務價值，收益就開始負增長了。很多企業往往也是到這個拐點才意識到重構的重要性。

通常來說：重構需要一段時間的投入，來慢慢降低研發維護成本，有的需要幾個月，有的甚至超過一年。但如果能堅持下來，就會來到拐點 3，此時收益開始正向增長。

5、遺留系統重構策略1：絞殺者模式

5.1定義

這個模式是指我們在替換一個軟件系統時，在舊系統旁邊搭建一個新系統，讓它緩慢增長，與舊系統同時存在，逐步地“絞殺”舊系統。這個“逐步”的意思，其實就是增量演進。“同時存在”指的是并行運行。

它有三個優勢：

1）第一：不會遺漏原有需求；
2）第二：可以穩定地提供價值，頻繁地交付版本，更好地監控其改造進展；
3）第三：避免“閉門造車”。

劣勢主要來自迭代的風險和成本，絞殺的時間跨度會很大，存在一定風險，而且還會產生一定的迭代成本。

5.2案例：啟動任務重構

5.2.1）問題：

最開始時，我們的啟動任務邏輯全部都寫在 Application的 onCreate中。隨著啟動邏輯越來越復雜，這部分代碼越來越難以維護，而且很難監控每個版本中由于啟動任務邏輯的變化，而帶來的啟動速度變化。

下圖所示是一部分重構前的啟動任務邏輯，各種業務的啟動任務都寫在 initMainProcess()中。

5.2.2）方案：

重構后我們引入了啟動任務管理框架，不同業務的啟動任務劃分到不同的Task中，按照順序裝載到對應的進程。

每個Task實現一個相對比較內聚的功能：

但是由于啟動任務邏輯的復雜性，我們沒有一次性把所有啟動邏輯都重構成Task的形式，而是新邏輯使用Task的形式，舊邏輯逐步遷移。這種新舊寫法共存的情況維持了相當長的一段時間，直到所有啟動邏輯都最終遷移到了新的啟動框架中，后續 Application的 onCreate中也不允許再增加新的啟動邏輯。

5.2.3）效果：

重構后，啟動Task的功能職責單一化，達到了高內聚、低耦合的目標。而且對于新增的啟動任務，以及每個任務的速度劣化，都更方便監控了。

6、遺留系統重構策略2：修繕者模式

6.1定義

絞殺植物模式適合用于新的系統和服務，替換舊的系統或舊系統中的一個模塊。在舊系統內部，也可以使用類似的思想來替換一個模塊，只不過這個模塊仍然位于舊系統中，而不是外部。我們把這種方式叫做修繕者模式。

修繕者模式是對于現有系統新增一層進行封裝，然后在保證新層對外提供功能不變的情況下，對系統內部進行改造。

6.2案例：云服務重構——中間分發層重構

6.2.1）問題：

本地版客戶端除了能連接到本地版的服務器，還能連接到Saas的云端服務器，實現這部分能力的模塊稱為云服務模塊。

為了在同一個UI頁面，同時支持使用本地版服務和云服務，我們基于這兩個底層服務構建了一個中間分發層。中間分發層能夠根據不同的情況，適當地將請求分發給本地版服務或者云服務。

Android開發中使用maven依賴其他模塊時，有implementation和api兩種方式。

它們的區別是：

1）implementation關鍵字用于將依賴的庫隱藏在當前模塊內，只能在當前模塊中訪問，不會傳遞給其他依賴該模塊的模塊；
2）api關鍵字用于將依賴的庫的公共接口暴露給其他模塊，可以在其他依賴該模塊的模塊中直接訪問。

但是由于分發層的隔離不夠嚴格，使用了api依賴云服務模塊，導致業務層也可以繞過分發層，直接調用本地版服務或者云服務。業務層開發需要根據具體情況，考慮應該在什么情況調用哪個服務，增加了維護成本和出錯的概率。

6.2.2）方案：

我們針對分層不夠清晰的問題，重構了一套嚴格編譯隔離的云服務底層：業務層調用者必須通過中間分發層調用本地版服務或者云服務，無法繞過中間層。

具體的做法是改成使用maven的implementation依賴方式，使得云服務底層的maven依賴不會傳遞給業務模塊，保證只有中間層能夠調用云服務底層，而業務層只能依賴中間層。

重構的過程是可以小步進行的：先把一個業務模塊對云服務底層的依賴改成只依賴中間層，然后編譯，接著逐個處理編譯錯誤。處理完一個業務模塊就可以提測這個模塊。

6.2.3）效果：

在保證新的中間層對外提供功能不變的情況下，我們漸進式地對中間層進行了重構，逐個模塊地把非預期中的跨層依賴都剝離掉。

整個過程修改的Java文件數量超過800+，從此業務層只能通過中間層調用本地版通用底層或者Saas通用底層，跨層調用都會直接報編譯錯誤。

7、遺留系統重構策略3：拆遷者模式

7.1定義

基于原有的業務，新寫一套系統，然后一次性將舊系統的數據和功能，遷移到新系統上。

7.2案例：生命周期重構

7.2.1）問題：

我們本地版原來已經有一套頁面生命周期的監控模塊，后來又引入了一套Saas的頁面生命周期監控模塊。

兩個模塊的功能大部分重復又不完全相同，維護的成本很大，比如開發做一個功能可能得同時修改兩個模塊的代碼，而且兩個模塊的修改都是類似的。

7.2.2）方案和效果：

雖然這個模塊的改動影響很大，但是為了徹底解決遺留代碼帶來的問題，我們在一次迭代中合并了兩個模塊的代碼，一次性切到新的唯一一個生命周期監控模塊中。

8、架構級重構實踐1：組件化

8.1概述

在本節中，我會介紹兩個架構重構的案例：組件化和云服務ProtoBuf定義統一。

一般來說，挑戰可以歸納成兩大類：

1）首先：是普遍性挑戰，比如組件化重構，我將會展示我們是如何深入理解業務需求，找到量身定制的組件化重構方案。
2）其次：是特有的業務挑戰。以本地版為例，我們面臨的是歷史遺留問題，比如本地版和Saas兩種沖突的PB定義共存的情況。

這種獨特的挑戰要求我們不僅要有技術上的廣度，還需要深度和創造性地思考。接下來，我將分享我們如何安全小步地實施架構重構，同時保持系統持續迭代。

8.2意義

單體架構是常見的架構模式之一。

通常所有開發人員基于單個模塊進行開發，所有業務功能都集成在一起打包發布。單體架構非常適合團隊規模小、業務復雜度低的產品，在項目起始階段能快速迭代進行驗證。

隨著業務的持續演進，代碼不斷地膨脹和腐壞，所以代碼內部的耦合度很高。在這樣的基礎上修改代碼，非常容易牽一發而動全身：修改一個 Bug，又引起另外一個 Bug；開發一個功能，又引起另外一個功能的異常。

8.3重構過程

8.3.1）方案：

這里先簡單講述一下企業微信組件化的技術方案，但是不會涉及太多細節。

組件間的通信方案使用接口，即每個模塊各自提供一批對外的api接口，其它模塊只能訪問到這些api，如下圖所示。

工程結構上使用Module這種官方的形式進行工程結構拆分，各組件之間能只能訪問到對方的api，通過只依賴api而不依賴本體的形式來實現的代碼隔離。

組件化方案確定后，解耦遺留代碼的過程是漫長而瑣碎的。這里我更想著重敘述下本地版是如何推進組件化項目的進度，以及提高組件化實施的效率的。

8.3.2）進度管理：

一個完整的組件化重構步驟如下圖所示：

劃分出不同功能模塊的分界線后，我們把不同模塊的解耦任務分給對應負責的開發。

然后我們做了一個網站自動監控每個模塊的解耦進度：

統計每日的解耦類和api數量：

我們通過這種方式持續推進這個維持了一年多的組件化大型重構項目，讓每個模塊的解耦進度和組件化程度都可以一目了然。

8.3.3）自動化重構腳本：

組件化的過程中，最常見的操作就是把更為內聚的一些類移動到同一個組件內，以及為隔離的組件提供對外的API接口。為了提高組件化的效率，我們開發了許多解耦代碼的腳本，用于抽取組件API、移動類、移動資源，大大提高了全組開發實施組件化的效率。

自動化重構腳本分析和移動基礎庫ui_foundation的執行示例：

8.4優化后效果

抽取基礎庫40+，類1700+：

抽取業務模塊30+，抽取接口數2200+：

9、架構級重構實踐2：統一云服務ProtoBuf定義

9.1問題：兩套相似又不相同的ProtoBuf定義共存

由于本地版的歷史需求和Saas既有相同也有不同的地方，所以造成了兩者的ProtoBuf有大量相同重合的地方，但是少量字段又并不是完全一樣的。而且在開始沒有開發規范的情況下，產生了沖突的數據字段，也就是在同一個Message結構體的相同位置的字段，在本地版和Saas中的類型或者含義是不一樣的。

雖然后面我們已經意識到這個問題，對本地版需求新增加的ProtoBuf字段索引都增加了1000，以此避免沖突，但是歷史已經放出去的版本也無法再修改。如果沒有一個兼容舊版本的方案，那沖突的字段只能一直保留著。

在本地版的業務層中，本地版的ProtoBuf和Saas的ProtoBuf一起編譯，由于不能存在包名和類名都一樣的類，所以本地版的ProtoBuf包名都從wework修改成了weworklocal。因此業務開發需要關注當前使用的是哪套ProtoBuf，而選擇引入不同的包名，大大增加了代碼的理解成本和開發成本。

9.2方案：統一ProtoBuf定義

9.2.1）沖突類型：

為了實現兩套通用底層的PB統一，最大的問題是如何兼容兩份PB的沖突字段。

本地版PB和SaasPB的字段沖突類型，主要有4種：

1）類型相同，但名字不同，實際業務含義不同；
2）類型不同，名字不同；
3）本地版獨有字段；
4）enum值沖突。

9.2.2）分層設計：

為了解決PB字段沖突的問題，我們增加了一個沖突轉換層：

如上圖所示：

1）上層UI統一使用Saas的PB結構；
2）在本地版通用底層和UI之間，增加一層轉換層，負責把沖突的PB字段重新賦值；
3）本地版的底層繼續使用原有的本地版PB。

9.2.3）自動化重構腳本:

針對重復性工作，我們使用腳本對比Proto，找出沖突字段并進行自動化處理，提高效率。

流程如下：

自動化重構腳本方案收益如下：

1）無需手動對齊Proto文件 Proto文件數量470+，以處理一個文件15分鐘計算，可節省工作量約5人日；
2）自動生成轉換代碼沖突字段110+，每個沖突需實現3個轉換函數，總計可以少寫6000+行代碼；
3）出現新沖突時，可以重復生成新的轉換代碼。

9.3優化后效果

1）對組件化的收益：可以消除約50%云服務需求導致的接口差異；

2）減少了開發的理解和維護成本：后續維護的開發都不需要過多關注當前是需要使用本地版還是Saas的協議。

10、代碼重構實踐1：過大類重構

將大型的單體遺留系統重構為組件化架構后，我們有了更加低耦合、高內聚的組件。但是回到組件內部，代碼質量對開發也非常重要。

我相信你在過去的代碼里一定會遇到一種典型的代碼壞味道，那就是“過大類”。在產品迭代的過程中，由于缺少規范和守護，單個類很容易急劇膨脹，有的甚至達到幾萬行的規模。

過大的類會導致發散式的修改問題，只要需求有變化，這個類就得做相應修改。

隨著業務需求和代碼規模的不斷膨脹，我們針對過大類的重構策略就是分而治之。通過分層將不同維度的變化控制在獨立的邊界中，使之能夠獨立的演化，從而減少修改代碼時彼此之間產生的影響。

11、代碼重構實踐2：會話列表重構

11.1業務分析和代碼分析

對于遺留系統來說，比較常見的問題就是需求的上下文中容易存在斷層，所以第一步就是盡可能地了解、分析原有的業務需求。

只有更清楚地挖掘原有的需求設計，才不會因為理解上的差異出現錯誤的代碼調整。接下來我們以會話列表頁面為例，講述我們重構過大類的過程。

下圖是我們對會話列表涉及的業務功能進行的梳理：

下圖是會話列表頁面的示意圖：

11.2架構設計

分析完之后，接下來就是進行架構設計了。這一步讓我們在開始動手重構前，想清楚重構后的代碼將會是什么樣子，以終為始才能讓我們的目標更加清晰，讓過程更加可度量。

現在主流APP框架都是用一套MVP或者MVVM框架來解耦。企微還是傳統的MVC方案，由于歷史原因修改成MVP或者MVVM都會有非常大的成本。

于是我們創建了一個新的MVCs的框架。MVCs的主要理念是將View和Model的交互，變成一個可插拔的抽象的邏輯。所以一個Controller描述的是一組View與一組Model的關系，從理念上，它應與業務無關。MVCs架構在面對企微這種復雜度的場景下，已經可以較好得支撐實際面臨的業務需求。

11.3小步安全重構

建立一個IController，抽象出和 Activity/Fragment相同的生命周期，然后在Activity/Fragment相同的生命周期執行。同時一個IController可以包含多個IController，先執行本身的邏輯，然后再執行子IController邏輯，同時提供懶加載方案LazyController ,當達到一定條件的時候才會加載，保證性能和效率。