安居客Android項目架構演進

時間  2019-12-09 標籤 安居 客 android 項目 架構 演進

這裏寫圖片描述

本文已受權微信公衆號 AndroidDeveloper 獨家發佈。java

入職安居客三年從工程師到 Team Leader，見證了 Android 團隊一路走來的發展歷程。所以有心將這些記錄下來與你們分享，也算是對本身三年來一部分工做的總結。但願對你們有所幫助，更但願能獲得你們寶貴的建議。android

三網合併

三年前入職時安居客在業務上剛完成了三網合併（新房、二手房、好租和商業地產多個平臺多個網站合成如今的 anjuke.com，這在公司的歷史上稱之爲三網合併）,所以移動端也將原先的新房、二手房、好租和商業地產多個 App 合併成爲了如今的安居客 App。所謂的合併也差很少就是將多個項目的代碼拷貝到了一塊兒組成了新的 Anjuke Project。下面這張圖能更加直觀的呈現當時的情況：git

圖片名稱

這一時期代碼結構混亂、層次不清，各業務技術方案不統一，冗餘代碼充斥項目的各個角落；甚至連基本的包結構也是胡亂不堪，項目架構更是無從談起。你們只不過是不停地往上堆砌代碼添加新功能罷了。因而我進入公司的第一件事就是向 Leader 申請梳理了整個項目的結構。github

然後隨着項目的迭代，咱們不斷引入了 Retrofit、UniversalImageLoader、OKHttp、ButterKnife 等一系列成熟的開源庫，同時咱們也開發了本身的 UI 組件庫 UIComponent、基礎工具庫 CommonUtils、基於第三方地圖封裝的 MapSDK、即時聊天模塊 ChatLibrary 等等。這以後安居客項目架構大體演變成了由基礎組件層、業務組件層和業務層組成的三層架構。以下圖：web

圖片名稱

其中業務層是一種非標準的 MVC 架構，Activity 和 Fragment 承擔了 View 和 Controller 的職責：數據庫

圖片名稱

前面這種分層的架構自己是沒太大問題的，即便到了如今咱們的業務項目也已然是基於這種分層的架構來構建的，只不過在不斷的迭代中咱們作了些許調整（分層架構後面在介紹組件化和模塊化的時候會詳細介紹）。可是隨着業務的不斷迭代,咱們慢慢發現業務層這種非標準的MVC架構帶來了種種影響團隊開發效率的問題：bash

  • Activity 和 Fragment 愈來愈多的同時承擔了 Controller 和 View 的職責，致使他們變得及其臃腫且難以維護；
  • 因爲 Controller 和 View 的揉合，致使單元測試起來很困難；
  • 回調嵌套太多，面對負責業務時的代碼邏輯不清晰，難以理解且不利於後期維護；
  • 各層次模塊之間職責不清晰等等

鑑於三網合併時期我還未加入安居客，因此對這一塊的理解不免有誤差，若是有安居客的老同事發現文章中的描述有不對的地方還望批評指正。微信

由 RxJava 驅動的 MVP 架構

一種技術架構沒法知足全部的業務項目，更不可能有一種架構方案可以一勞永逸。正如上一節中提到的隨着業務的不斷迭代，現有架構的缺陷逐漸浮出水面，項目架構必需不斷升級迭代才能更好地服務於業務。網絡

MVP 的設計與實現

在研究了 Google 推出的基於 MVP 架構的 Demo 後，咱們發現 MVP 架構能解決如今所面臨過的不少問題，因而咱們學習並引入到了咱們的項目中來，並針對性的作了部分調整。下圖呈現的是安居客 MVP 方案：
這裏寫圖片描述架構

之前面提到的三層架構的方案來看是這樣的：

圖片名稱

基於此架構我在 GitHub 上開源了一個項目MinimalistWeather，有興趣的小夥伴能夠去 Clone 下來看看，若是以爲對你有幫助就給個 Star 吧。 :)

  • View Layer: 只負責 UI 的繪製呈現，包含 Fragment 和一些自定義的 UI 組件，View 層須要實現 ViewInterface 接口。Activity 在項目中再也不負責 View 的職責，僅僅是一個全局的控制者，負責建立 View 和 Presenter 的實例；
  • Model Layer: 負責檢索、存儲、操做數據，包括來自網絡、數據庫、磁盤文件和SharedPreferences的數據；
  • Presenter Layer: 做爲 View Layer 和 Module Layer 的之間的紐帶，它從 Model 層中獲取數據，而後調用 View 的接口去控制 View；
  • Contract: 咱們參照 Google 的 Demo 加入契約類 Contract 來統一管理 View 和 Presenter 的接口，使得某一功能模塊的接口能更加直觀的呈現出來，這樣作是有利於後期維護的。

另外這套MVP架構還爲咱們帶來了一個額外的好處：咱們有了足夠明確的開發規範和標準。細緻到了每個類應該放到哪一個包下，哪一個類具體應該負責什麼職責等等。這對於咱們的 Code Review、接手他人的功能模塊等都提供了極大的便利。前面提到的 MinimalistWeather 就是爲了定規範定標準而開發的。

這一時期咱們還在項目中引入了 RxJava，很好的解決了前面提到的嵌套回調的問題，同時可以幫助咱們簡化複雜業務場景下的代碼邏輯（固然 RxJava 的好處遠遠不止這麼一點，對 RxJava 不瞭解的同窗能夠去翻翻我以前一系列關於 RxJava 的文章）。咱們也將網絡庫升級到了 Retrofit2 + OKHttp3，它們和 RxJava 之間能更好的配合。

MVP 帶來的新問題及解決方案

是否是升級到了 MVP 架構就高枕無憂了呢？很明顯不是這樣！MVP 架構也會帶來如下新的問題：

  • 因爲大量的業務邏輯處理轉移到了 Presenter 層，在一些複雜的業務場景中 Presenter 一樣會變得臃腫難懂。細心的同窗可能注意到了前面的架構圖中的 Model 層有個 Data Repository 模塊，Data Repository 在這裏有兩個做用：一是能夠將本來由 Presenter 處理的部分邏輯轉移到這裏來處理，包括數據的校驗、部分單純只與數據相關的邏輯等等，向 Presenter 屏蔽數據處理細節，好比做爲 Presenter 就沒必要關心 Model 層傳遞過來的數據究竟是來至網絡仍是來至數據庫仍是來至本地文件等等；二是咱們引入了 RxJava，可是隻有網絡層中的 Retrofit 能返回 Observable 對象，其餘模塊都是返回的仍是一些非 Observable 的 Java 對象，爲了能在整個 Presenter 層中都體驗 RxJava 帶來的美妙之處，所以能夠經過 Data Repository 作一層轉換；
  • 如今的 MVP 架構中最重的部分就是 Model Layer 了，這一點從前面的架構圖中就能體現。所以這就要求咱們在 Model 層的設計過程當中職責劃分要足夠清晰，分包更明確，耦合度更低。至於分包你們能夠參考 MinimalistWeather 的方案：db 包爲數據庫模塊、http 包爲網絡模塊、preference 包是對 SharedPreferences 的一些封裝、repository 包就是前面提到的 Data Repository 模塊；
  • 同時還有一點須要注意，不少人在使用 RxJava 的過程當中每每忘記了對生命週期的管理，這很容易形成內存泄露。MinimalistWeather 中採用了 CompositeSubscription 來管理，你也可使用 RxLifecycle 這類開源庫來管理生命週期。

組件化與模塊化

去年下半年咱們 Android 團隊內部成立了技術小組，基礎組件的開發是技術小組很重要的一部分工做，因此組件化是咱們正在作的事；模塊化更多的是現有的方案受到來自業務上的挑戰以及受到了 Oasis Feng 在 MDCC 上的分享和整個大環境的啓發，如今正處於設計規劃和 Demo 開發的階段。

組件化

組件化不是個新概念，通俗的講組件化就是基於可重用的目的，將一個大的軟件系統拆分紅一個個獨立組件。

組件化的帶來的好處不言而喻：

  • 避免重複造輪子，節省開發維護成本；
  • 下降項目複雜性，提高開發效率；
  • 多個團隊公用同一個組件，在必定層度上確保了技術方案的統一性。

如今的安居客有是三個業務團隊：安居客用戶 App、經紀人 App、集客家 App。爲了不各個業務團隊重複造輪子，團隊中也須要有必定的技術沉澱，所以組件化是必須的。從本篇的第一節你們就能看到組件化的影子，只不過在這以前咱們作的並很差。如今咱們須要提供更多的、職能單1、性能更優的組件供業務團隊使用。根據業務相關性，咱們將這些組件分爲：基礎組件和業務組件。後面在介紹模塊化的時候會有進一步的描述。

模塊化

自從 Oasis Feng 在去年的 MDCC2016 上分享了模塊化的經驗後，模塊化在 Android 社區愈來愈多的被提起。咱們天然也不落俗的去作了一些研究和探索。安居客如今面臨不少問題：例如全量編譯時間太長（我這臺13款的 MacBook Pro 上打一次包得花十多分鐘）；例如新房、二手房、租房等等模塊間耦合嚴重，不利於多團隊並行開發測試；另外在17年初公司從新將租房 App 撿起推廣，單獨讓人來開發維護一個三年前的項目並不划算，因此咱們但願能直接從如今的安居客用戶端中拆分出租房模塊做爲一個單獨的 App 發佈上線。這樣看來模塊化彷佛是一個不錯的選擇。

因此咱們作模塊化的目的大體是這樣的：

  • 業務模塊間解耦
  • 單個業務模塊單獨編譯打包，加快編譯速度
  • 多團隊間並行開發、測試
  • 解決好租App須要單獨維護的問題，下降研發成本

15年 Trinea 還在安居客的時候開發了一套插件化框架，但受限於當時的團隊規模而且插件化對整個項目的改造太大，所以在安居客團隊中插件化並未實施下來。而模塊化實際上是個很好的過渡方案，將項目按照模塊拆分後各業務模塊間解耦的問題不存在了，後續若有必要，再進行插件化改造只不過是水到渠成的事。

來看看安居客用戶 App 的模塊化設計圖：
這裏寫圖片描述

整個項目分爲三層，從下往上分別是：

  • Basic Component Layer: 基礎組件層，顧名思義就是一些基礎組件，包含了各類開源庫以及和業務無關的各類自研工具庫；
  • Business Component Layer: 業務組件層，這一層的全部組件都是業務相關的，例如上圖中的支付組件 AnjukePay、數據模擬組件 DataSimulator 等等；
  • Business Module Layer: 業務 Module 層，在 Android Studio 中每塊業務對應一個單獨的 Module。例如安居客用戶 App 咱們就能夠拆分紅新房 Module、二手房 Module、IM Module 等等，每一個單獨的 Business Module 都必須準遵照前面提到的 MVP 架構。

同時針對模塊化咱們也須要定義一些本身的遊戲規則:

  • 對於 Business Module Layer，各業務模塊之間的通信跳轉採用路由框架 Router 來實現（可能會採用成熟的開源庫，也可能會選擇重複造輪子）;
  • 對於 Business Component Layer，單一業務組件只能對應某一項具體的業務，對於有個性化需求的對外部提供接口讓調用方定製;
  • 合理控制各組件和各業務模塊的拆分粒度，過小的公有模塊不足以構成單獨組件或者模塊的，咱們先放到相似於 CommonBusiness 的組件中，在後期不斷的重構迭代中視狀況進行進一步的拆分（這一點的靈感來源於 Trinea 的文章）;
  • 上層的公有的業務或者功能模塊能夠逐步下放到下層，合理把握好度就好；
  • 各 Layer 間嚴禁反向依賴，橫向依賴關係由各業務 Leader 和技術小組商討決定。

對於模塊化項目，每一個單獨的 Business Module 均可以單獨編譯成 APK。在開發階段須要單獨打包編譯，項目發佈的時候又須要它做爲項目的一個 Module 來總體編譯打包。簡單的說就是開發時是 Application，發佈時是 Library。所以須要你在 Business Module 的 Gradle 配置文件中加入以下代碼：

if(isBuildModule.toBoolean()){
    apply plugin: 'com.android.application'
}else{
    apply plugin: 'com.android.library'
}

若是咱們須要把租房模塊打包成一個單獨的租房 App，像下面這樣就好：
這裏寫圖片描述

咱們能夠把 Basic Component Layer 和 Business Component Layer 放在一塊兒看作是 Anjuke SDK，新的業務或者項目只須要依賴 Anjuke SDK 就好（這一點一樣是受到了 Trinea 文章的啓發）。甚至咱們能夠作得更極致一些，開發一套本身的組件管理平臺，業務方能夠根據本身的需求選擇本身須要的組件，定製業務專屬的 Anjuke SDK。業務端和 Anjuke SDK 的關係以下圖所示：
這裏寫圖片描述

最後看看安居客模塊化的總體設計圖：
這裏寫圖片描述

模塊化拆分對於安居客這種比較大型的商業項目而言，因爲歷史比較久遠不少代碼都運行五六年了；各個業務相互交叉耦合嚴重，因此實施起來仍是有很大難度的。過程當中不免會有預料不到的坑，這就須要咱們對各個業務有較深的理解同時也要足夠的耐心和細緻。雖然辛苦，可是一旦完成模塊化拆分對整個團隊及公司業務上的幫助是很大的。

以上是個人簡單總結以及對模塊化的一些思考，不足之處還望你們批評指正。後面模塊化的 Demo 完善後我會把它放到 GitHub，並再出一篇文章詳細介紹模塊化的設計實現細節。

參考資料：

若是你喜歡個人文章，就關注下個人知乎專欄或者在 GitHub 上添個 Star 吧！

联系我们 沪ICP备2021010478号-7