算算日子，工作剛好三年了。這篇開始，鄙人就要向著各種以前想起來就頭大的方向努力前進了。作為在Android應用層搬磚多年的民工，首篇我想談談自己對架構思想的一些看法。如有不妥，還請拍磚。
蓋樓的故事（虛構）
有一塊地，兩個區域，開發商分別讓兩個包工頭負責開發。
包工頭A辦事干凈利落，甩開膀子就開工了。為了省錢雇了一個全能的工人，他既要去采購蓋房的材料，又要用這些材料蓋房子。起初底層屋子結構簡單，還能應付得來，到了后面復雜的設計需求時，忙的不可開交，經常精疲力盡，阻斷了蓋房子的進程，使得老板很是不開心，偶爾讓他改個屋子結構，他要把整層樓都推到才能實現，嚴重影響了工期。畫的圖紙都是一次性的，不能重用，耗時又耗錢，開發商整天吹胡子瞪眼的跟在屁股后面催。
包工頭B拿到開發商方案后，先召集小弟開了個會，確定了所有樓層的樣式，并把它們拆分成獨立的模塊。按照模塊劃分給了各個負責人，有制定樓層樣式的，有專門負責資源提供的，有負責運送資源的，有按照預定方案實施的等等。花了大半個月將所有任務都分配完畢，開始施工。雖然人雇傭的有點多，前面的時間也耽誤了大半個月，但是一開工很快就趕上了隔壁樓。emmm，開發商喜笑顏開，點點頭，這個錢花的劃算，完事后以后就用包工頭B了。
不久后，兩塊地都完工了。這時質檢開始了，令人頭疼的A區域，有個小毛病就要拆掉一大片地方去改造，有的地方改好了卻又影響了其它地方，而反觀B區域，專人負責只要改有問題的地方就好了。
后來，包工頭A游走在各個小開發商，工資又低又累，而包工頭B已經走上了人生巔峰。（哈哈，終結）
包工頭B的巔峰秘籍
我們再來回顧一下包工頭B的蓋樓經過。
接到項目，沒有立即開發，開會整理需求；
按需求、職能劃分模塊，并由對應的人員負責；
各功能模塊的負責人扁平化管理，沒有相互掣肘；
同樣的，我們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界面，完成功能。
原文鏈接：http://www.apkbus.com/blog-302849-78058.html
