通俗易懂的Android應用架構思想

算算日子，工作剛好三年了。這篇開始，鄙人就要向著各種以前想起來就頭大的方向努力前進了。作為在Android應用層搬磚多年的民工，首篇我想談談自己對架構思想的一些看法。如有不妥，還請拍磚。

蓋樓的故事（虛構）

有一塊地，兩個區域，開發商分別讓兩個包工頭負責開發。

包工頭A辦事幹淨利落，甩開膀子就開工了。為了省錢僱了一個全能的工人，他既要去採購蓋房的材料，又要用這些材料蓋房子。起初底層屋子結構簡單，還能應付得來，到了後面複雜的設計需求時，忙的不可開交，經常精疲力盡，阻斷了蓋房子的程式，使得老闆很是不開心，偶爾讓他改個屋子結構，他要把整層樓都推到才能實現，嚴重影響了工期。畫的圖紙都是一次性的，不能重用，耗時又耗錢，開發商整天吹鬍子瞪眼的跟在屁股後面催。

包工頭B拿到開發商方案後，先召集小弟開了個會，確定了所有樓層的樣式，並把它們拆分成獨立的模組。按照模組劃分給了各個負責人，有制定樓層樣式的，有專門負責資源提供的，有負責運送資源的，有按照預定方案實施的等等。花了大半個月將所有任務都分配完畢，開始施工。雖然人僱傭的有點多，前面的時間也耽誤了大半個月，但是一開工很快就趕上了隔壁樓。emmm，開發商喜笑顏開，點點頭，這個錢花的划算，完事後以後就用包工頭B了。

不久後，兩塊地都完工了。這時質檢開始了，令人頭疼的A區域，有個小毛病就要拆掉一大片地方去改造，有的地方改好了卻又影響了其它地方，而反觀B區域，專人負責只要改有問題的地方就好了。

後來，包工頭A遊走在各個小開發商，工資又低又累，而包工頭B已經走上了人生巔峰。（哈哈，終結）

包工頭B的巔峰祕籍

我們再來回顧一下包工頭B的蓋樓經過。

1. 接到專案，沒有立即開發，開會整理需求；

2. 按需求、職能劃分模組，並由對應的人員負責；

3. 各功能模組的負責人扁平化管理，沒有相互掣肘；

同樣的，我們App的開發也是一樣的道理，不能像包工頭A一樣把所有的任務都交給Activity去做。我們要像包工頭B一樣分層去建立App。大家可以瞭解一下clean Architecture，這裡將App應用分為三層，內-中-外，然後由4個管理者分別去管理他們。

分層的準則：

由外到內抽象
內層不瞭解層，外層依賴內層
分工明確，相互獨立

先來解釋一下第一條，以往我們開發App都是先從介面開始，然後最終到業務邏輯。現在要反過來，接到需求，要先明確實體是什麼

（舉個例子，比如登入功能，它所描述的實體就是使用者User），然後它有哪些行為（比如登陸，登出userCase）。最後再到具體功能實現。

內層不瞭解外層，還是拿登入來說，在內層只需要知道使用者有登入以及登出的行為就可以了，至於它是如何進行這些行為，內層就不需要知道了，但是反過來外層要實現內層的行為就要知道內層有哪些行為於是便產生了依賴關係。內層能獨立存在，而外層必須依賴內層。

分工明確，相互獨立，講的是各模組功能獨立存在，就比如登入，和註冊功能是相互獨立的，各司其職，不能越俎代庖。

4個管理者

domain：定義抽象實體，核心業務邏輯，以及資料輸出介面。此層為純java程式碼，建議直接建立java module。
data：資料管理，分為本地的儲存（sqlLite，sharedpreferences），以及服務端Api。
device：與Android底層相關，如通知，藍芽，感測器等等。

app：我們最熟悉的層級，內部可以根據各自的喜好選擇MVP，以及MVVM模式來實現UI介面。

App開發的流程

domain層中定義抽象實體，設定其對應的行為。
data層中，給予資料支援
device層，按需開發

app層，這裡以MVP為例，首先在presenter中實現domain層定義的所有行為，data層和device層協助。最後實現UI介面，完成功能。

原文釋出時間為：2018-06-22

本文作者：bear~

本文來自雲棲社群合作伙伴“安卓巴士Android開發者門戶”，瞭解相關資訊可以關注“安卓巴士Android開發者門戶”。