爲何會選擇clean+mvp架構

在瞭解代碼架構以前，先普及一下軟件開發週期，由於有着軟件不是一層不變的，它也有着週期的循環，因此做爲開發者而言，代碼架構的搭建，應該考慮後續的擴展性，易測性等。 常見的軟件週期： 瀑布模型、快速原型、迭代開發、螺旋模型 瀑布模型 瀑布模型如今看來是比較老舊的方式了，一條龍下來的模型，是典型的預見性的方法，嚴格遵循預先計劃的需求分析、設計、編碼、集成、測試、維護的步驟順序進行。

瀑布模型強調文檔的做用，並要求每一個階段都要仔細驗證。可是，這種模型的線性過程太理想化，已再也不適合現代的軟件開發模式，幾乎被業界拋棄，其主要問題在於： （1） 各個階段的劃分徹底固定，階段之間產生大量的文檔，極大地增長了工做量； （2） 因爲開發模型是線性的，用戶只有等到整個過程的末期才能見到開發成果，從而增長了開發的風險； （3） 早期的錯誤可能要等到開發後期的測試階段才能發現，進而帶來嚴重的後果。

快速原型： 快速原型模型的第一步是建造一個快速原型，實現客戶或將來的用戶與系統的交互，用戶或客戶對原型進行評價，進一步細化待開發軟件的需求。經過逐步調整原型使其知足客戶的要求，開發人員能夠肯定客戶的真正需求是什麼；第二步則在第一步的基礎上開發客戶滿意的軟件產品。 快速原型的關鍵在於儘量快速地建造出軟件原型，一旦肯定了客戶的真正需求，所建造的原型將被丟棄。所以，原型系統的內部結構並不重要，重要的是必須迅速創建原型，隨之迅速修改原型，以反映客戶的需求。 螺旋模型 螺旋模型由風險驅動，強調可選方案和約束條件從而支持軟件的重用，有助於將軟件質量做爲特殊目標融入產品開發之中。可是，螺旋模型也有必定的限制條件，具體以下：

（1） 螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，並作出相關反應是不容易的，所以，這種模型每每適應於內部的大規模軟件開發。 （2） 若是執行風險分析將大大影響項目的利潤，那麼進行風險分析毫無心義，所以，[螺旋模型]只適合於大規模軟件項目。 （3） 軟件開發人員應該擅長尋找可能的風險，準確地分析風險，不然將會帶來更大的風險 一個階段首先是肯定該階段的目標，完成這些目標的選擇方案及其約束條件，而後從風險角度分析方案的開發策略，努力排除各類潛在的風險，有時須要經過建造原型來完成。若是某些風險不能排除，該方案當即終止，不然啓動下一個開發步驟。最後，評價該階段的結果，並設計下一個階段。

迭代開發 每次只設計和實現這個產品的一部分, 逐步逐步完成的方法叫迭代開發, 每次設計和實現一個階段叫作一個迭代，第一個增量每每是實現基本需求的核心產品。核心產品交付用戶使用後，通過評價造成下一個增量的開發計劃，它包括對核心產品的修改和一些新功能的發佈。這個過程在每一個增量發佈後不斷重複，直到產生最終的完善產品。 迭代開發模型也存在如下缺陷： （1） 因爲各個構件是逐漸併入已有的軟件體系結構中的，因此加入構件必須不破壞已構造好的系統部分，這須要軟件具有開放式的體系結構。 （2） 在開發過程當中，需求的變化是不可避免的增量模型的靈活性可使其適應這種變化的能力大大優於瀑布模型和快速原型模型，但也很容易退化爲邊作邊改模型，從而使軟件過程的控制失去總體性

各自特色： 瀑布模型 文檔驅動 系統可能不知足客戶的需求 快速原型模型 關注知足客戶需求 可能致使系統設計差、效率低，難於維護 迭代模型 開發早期反饋及時，易於維護 。可是須要開放式體系結構，易擴展。可能會致使效率低下 螺旋模型風險驅動 風險分析人員須要有經驗且通過充分訓練

咱們在作app開發的時候，如今大部分的狀況都是敏捷性的迭代開發，團隊較小溝通效率高，相對靈活，週期也短，從而下降風險，這就要求咱們對於框架的選型須要合理，不能爲了完成迭代任務而加代碼，致使後期的須要一次次的重構。那怎樣的架構相對來講比較合理性，如今介紹一種叫clean乾淨架構的代碼特色：

上圖來自https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html 介紹意思是大致的源碼依賴項只能向內指向，內環裏的全部項不能瞭解外環所發生的東西，而後clean架構的目的是： 框架獨立，不依賴其餘庫包，以避免受到約束 可測試。能夠在沒有UI，數據庫，Web服務器或任何其餘外部元素的狀況下測試業務規則。 UI獨立。UI能夠輕鬆更改，而無需更改系統的其他部分。例如，可使用控制檯UI替換Web UI，而無需更改業務規則。 數據源獨立，業​​務規則未綁定到數據庫。 外部代理模塊獨立，即框架內部不瞭解外部的狀況

如下內容是來自該做者的翻譯文檔： zhuanlan.zhihu.com/p/20001838 如下是更好地理解和熟悉本方法的一些相關詞彙：

• Entities：是指一款應用的業務對象
• Use cases：是指結合數據流和實體中的用例，也稱爲Interactor
• Interface Adapters： 這一組適配器，是負責以最合理的格式轉換用例（use cases）和實體（entities）之間的數據，表現層（Presenters ）和控制層（Controllers ），就屬於這一塊的。
• Frameworks and Drivers: 這裏是全部具體的實現了：好比：UI，工具類，基礎框架，等等。

Android應用架構 這一對象遵循關注分離原則，也就是經過業務規則讓內環操做對外環事物一無所知，這樣一來，在測試時它們就不會依賴任何的外部元素了。  要達到這個目的，個人建議就是把一個項目分紅三個層次，每一個層次擁有本身的目的而且各自獨立於堆放運做。  值得一提的是，每一層次使用其自有的數據模型以達到獨立性的目的（你們能夠看到，在代碼中須要一個數據映射器來完成數據轉換。若是你不想把你的模型和整個應用交叉使用，這是你要付出的代價）。

如下是圖解，你們感覺下：

表現層 (Presentation Layer) 表現層在此，表現的是與視圖和動畫相關的邏輯。這裏僅用了一個Model View Presenter（下文簡稱MVP），可是你們也能夠用MVC或MVVM等模式。這裏我再也不贅述細節，可是須要強調的是，這裏的fragment和activity都是View,其內部除了UI邏輯之外沒有其餘邏輯，這也是全部渲染的東西發生的地方。 本層次的Presenter由多個interactor（用例）組成，Presenter在 android UI 線程之外的新線程裏工做，並經過回調將要渲染到View上的數據傳遞回來。

** 領域層 (Domain Layer)** 這裏的業務規則是指全部在本層發生的邏輯。對於Android項目來講，你們還能夠看到全部的interactor（用例）實施。這一層是純粹的java模塊，沒有任何的Android依賴性。當涉及到業務對象時，全部的外部組件都使用接口。

數據層 (Data Layer) 應用所需的全部數據都來自這一層中的UserRepository實現（接口在領域層）。這一實現採用了Repository Pattern，主要策略是經過一個工廠根據必定的條件選取不一樣的數據來源。  好比，經過ID獲取一個用戶時，若是這個用戶在緩存中已經存在，則硬盤緩存數據源會被選中，不然會經過向雲端發起請求獲取數據，而後存儲到硬盤緩存。  這一切背後的原理是因爲原始數據對於客戶端是透明的，客戶端並不關心數據是來源於內存、硬盤仍是雲端，它須要關心的是數據能夠正確地獲取到。

最後附上另一個博客地址，也寫的挺好 www.jianshu.com/p/66e749e19… 好了，總結一下：無論項目採起什麼形式的架構，都是一種代碼的規範的基本原則前提下，尋找一種對於業務實現的最優解，如java中代碼設計原則主要有單一職責、開閉原則、里氏替換原則、依賴倒置原則、接口隔離原則、迪米特法則。目的也是提升程序的可維護性，擴展性，實現高內聚，低耦合結果。 好比說，最開始先後端是一個系統的時候就已經強調ui分離了，如今前端可經過npm獨立搭建前端項目了，在在這個前端項目自己也不只僅是ui了，也包含了前端的業務，同時也應該用上訴的代碼設計原則，對代碼進行調整而達到可維護，解耦的可測性的效果。

app的項目調整也是如此，考慮到不一樣基礎功能的複用，也依然能夠用組件化的形式搭建項目，相似後臺系統的組件化，微服務的發展。到必定程度app也能夠用插件化進行擴展。因此怎麼說呢，最重要的仍是代碼設計的規範吧。 附上本身的clean+mvp的「番茄工做」項目地址https://github.com/liangzs/tomatoTodo