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

蓋樓的故事（虛構）

有一塊地，兩個區(qū)域，開發(fā)商分別讓兩個包工頭負責開發(fā)。

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

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

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

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

包工頭B的巔峰秘籍

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

接到項目，沒有立即開發(fā)，開會整理需求；

按需求、職能劃分模塊，并由對應的人員負責；

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

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

分層的準則：

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

先來解釋一下第一條，以往我們開發(fā)App都是先從界面開始，然后最終到業(yè)務邏輯。現(xiàn)在要反過來，接到需求，要先明確實體是什么

（舉個例子，比如登錄功能，它所描述的實體就是用戶User），然后它有哪些行為（比如登陸，登出userCase）。最后再到具體功能實現(xiàn)。

內層不了解外層，還是拿登錄來說，在內層只需要知道用戶有登錄以及登出的行為就可以了，至于它是如何進行這些行為，內層就不需要知道了，但是反過來外層要實現(xiàn)內層的行為就要知道內層有哪些行為于是便產生了依賴關系。內層能獨立存在，而外層必須依賴內層。

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

4個管理者

• domain：定義抽象實體，核心業(yè)務邏輯，以及數(shù)據(jù)輸出接口。此層為純java代碼，建議直接創(chuàng)建java module。
• data：數(shù)據(jù)管理，分為本地的存儲（sqlLite，sharedpreferences），以及服務端Api。
• device：與Android底層相關，如通知，藍牙，傳感器等等。
• app：我們最熟悉的層級，內部可以根據(jù)各自的喜好選擇MVP，以及MVVM模式來實現(xiàn)UI界面。

App開發(fā)的流程

• domain層中定義抽象實體，設定其對應的行為。
• data層中，給予數(shù)據(jù)支持
• device層，按需開發(fā)

app層，這里以MVP為例，首先在presenter中實現(xiàn)domain層定義的所有行為，data層和device層協(xié)助。最后實現(xiàn)UI界面，完成功能。

最新評論