安居客 Android 項目架構演進

來源:AndroidDeveloper2018-06-13 22:04:08

閱讀本文大概需要 6.66 分鐘。

導讀:

這篇文章是我的一位好友,現擔任安居客 Android Team Leader 的張磊所寫,記錄了安居客 Android 端這幾年來的架構遷移與變化,非常值得看,也很有借鑒意義,所以這里推薦給大家,并已獲獨家授權發布,感興趣的可以在文末關注作者的 GitHub 與知乎專欄。


入職安居客三年從工程師到 Team Leader,見證了 Android 團隊一路走來的發展歷程。因此有心將這些記錄下來與大家分享,也算是對自己三年來一部分工作的總結。希望對大家有所幫助,更希望能得到大家寶貴的建議。


1
三網合并



三年前入職時安居客在業務上剛完成了三網合并(新房、二手房、好租和商業地產多個平臺多個網站合成現在的 anjuke.com,這在公司的歷史上稱之為三網合并),因此移動端也將原先的新房、二手房、好租和商業地產多個 App 合并成為了現在的安居客 App。所謂的合并也差不多就是將多個項目的代碼拷貝到了一起組成了新的 Anjuke Project。下面這張圖能更加直觀的呈現當時的狀況:



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


而后隨著項目的迭代,我們不斷引入了 Retrofit、UniversalImageLoader、OkHttp、ButterKnife 等一系列成熟的開源庫,同時我們也開發了自己的 UI 組件庫 UIComponent、基礎工具庫 CommonUtils、基于第三方地圖封裝的 MapSDK、即時聊天模塊 ChatLibrary 等等。這之后安居客項目架構大致演變成了由基礎組件層、業務組件層和業務層組成的三層架構。如下圖:



其中業務層是一種非標準的 MVC 架構,Activity 和 Fragment 承擔了 View 和 Controller 的職責:



前面這種分層的架構本身是沒太大問題的,即使到了現在我們的業務項目也已然是基于這種分層的架構來構建的,只不過在不斷的迭代中我們做了些許調整(分層架構后面在介紹組件化和模塊化的時候會詳細介紹)。但是隨著業務的不斷迭代,我們慢慢發現業務層這種非標準的 MVC 架構帶來了種種影響團隊開發效率的問題:


  • Activity 和 Fragment 越來越多的同時承擔了 Controller 和 View 的職責,導致他們變得及其臃腫且難以維護;

  • 由于 Controller 和 View 的揉合,導致單元測試起來很困難;

  • 回調嵌套太多,面對負責業務時的代碼邏輯不清晰,難以理解且不利于后期維護;

  • 各層次模塊之間職責不清晰等等


鑒于三網合并時期我還未加入安居客,所以對這一塊的理解難免有偏差,如果有安居客的老同事發現文章中的描述有不對的地方還望批評指正。


2
由 RxJava 驅動的 MVP 架構


一種技術架構無法滿足所有的業務項目,更不可能有一種架構方案能夠一勞永逸。正如上一節中提到的隨著業務的不斷迭代,現有架構的缺陷逐漸浮出水面,項目架構必需不斷升級迭代才能更好地服務于業務。


2.1 MVP 的設計與實現


在研究了 Google 推出的基于 MVP 架構的 Demo 后,我們發現 MVP 架構能解決現在所面臨過的很多問題,于是我們學習并引入到了我們的項目中來,并針對性的做了部分調整。下圖呈現的是安居客 MVP 方案:



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



基于此架構我在 GitHub 上開源了一個項目 MinimalistWeather (https://github.com/BaronZ88/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 的文章」(https://zhuanlan.zhihu.com/p/20687178))。我們也將網絡庫升級到了 Retrofit2 + OkHttp3,它們和 RxJava 之間能更好的配合。


2.2 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 這類開源庫來管理生命周期。


3
組件化與模塊化


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


3.1 組件化


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


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


  • 避免重復造輪子,節省開發維護成本;

  • 降低項目復雜性,提升開發效率;

  • 多個團隊公用同一個組件,在一定層度上確保了技術方案的統一性。


現在的安居客有是三個業務團隊:安居客用戶 App、經紀人 App、集客家 App。為了避免各個業務團隊重復造輪子,團隊中也需要有一定的技術沉淀,因此組件化是必須的。從本篇的第一節大家就能看到組件化的影子,只不過在這之前我們做的并不好。現在我們需要提供更多的、職能單一、性能更優的組件供業務團隊使用。根據業務相關性,我們將這些組件分為:基礎組件和業務組件。后面在介紹模塊化的時候會有進一步的描述。


3.2 模塊化


自從 Oasis Feng 在去年的 MDCC 2016 上分享了模塊化的經驗后,模塊化在 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,并再出一篇文章詳細介紹模塊化的設計實現細節。


參考資料:


  • http://www.csdn.net/article/2015-12-16/2826499-android-app-architecture

  • http://www.trinea.cn/android/didi-internationalization-android-evolution/

  • https://www.tianmaying.com/tutorial/AndroidMVC

  • https://www.diycode.cc/topics/362

  • https://github.com/MDCC2016/Android-Session-Slides/blob/master/02-From.Containerization.To.Modularity.pdf



如果你喜歡作者的文章,就關注下作者的知乎專欄或者在 GitHub 上添個 Star 吧!


知乎專欄: https://zhuanlan.zhihu.com/baron

GitHub: https://github.com/BaronZ88


猜你喜歡

整租

1500元/月 37.00㎡

整租

1800元/月 55.00㎡

整租

600元/月 95.00㎡

整租

3500元/月 130.00㎡

Copyright ?2018 威海高區地產網  版權所有
湖北30选5今天开奖号码