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

一、三網合并

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

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

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

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

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

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

二、由Rxjava驅動的MVP架構

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

2.1 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之間能更好的配合。

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

三、組件化與模塊化

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

3.1 組件化

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

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

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

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

3.2 模塊化

自從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，單一業務組件只能對應某一項具體的業務，對于有個性化需求的對外部提供接口讓調用方定制;合理控制各組件和各業務模塊的拆分粒度，太小的公有模塊不足以構成單獨組件或者模塊的，我們先放到類似于CommonBusuness的組件中，在后期不斷的重構迭代中視情況進行進一步的拆分（這一點的靈感來源于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?locationNum=7&fps=1http://www.trinea.cn/android/didi-internationalization-android-evolution/https://www.tianmaying.com/tutorial/AndroidMVChttps://www.diycode.cc/topics/362https://github.com/MDCC2016/Android-session-Slides/blob/master/02-From.Containerization.To.Modularity.pdf