目錄
引言
隨著這幾年移動網際網路的快速發展，移動網際網路技術也得到了推動，輔助架構設計型的框架和思想層出不窮，從井噴的2015年到現在，開發者們越來越離不開這些高效能、高效率的工具，而製造這些工具的公司或個人，也被推到神壇，受猿們的膜拜。與此同時，Google在今年的io大會上釋出了自己的官方框架Architecture Components【譯】，可以說是相當的應景了。時不我待，瞭解架構的知識，並且靈活的應用是我們程式設計師未來必不可少的技能，這系列文章是介紹MVP架構的，希望能對閱讀此文的朋友們帶來些收穫。
1、如何實現一個MVP框架的基本原則，以及MVP的使用場景，是我想寫這篇文章的初衷，同時也是對我自己學習的知識做一個總體的融合。
2、為了避免一上來生硬的開場，我先以一個簡單的開發例子作為引子，以初學者的角度去看待問題，同時也能兼顧到初學者，到後面我們會一步步提示。所以你也可以選擇直接跳轉到。。。。
3、因為講架構，多是場景描述，所以程式碼量比較少，習慣於通過程式碼理解的同學，我儘量多些並反覆描述。
場景
假設實現一個商品的列表展示功能，我們首先需要一個使用者介面，包含一些控制元件來供使用者操作，比如列表展示。我們大多數情況下使用一個Fragment作為控制元件的載體，在Fragment中直接呼叫網路請求的工具並等待回撥方法被執行後去重新整理UI去展示資料，所以對於這個需求的程式碼量並不是很多。現在需求增加了，要加入下拉重新整理和上拉載入更多，一般是監聽這兩個事件，在相應的回撥中處理資料，沒幾行程式碼，依舊寫在Fragment中，而需求又一次增加了，要加入排序，緊接著我們處理排序邏輯，程式碼依舊寫在Fragment中，接著又增加需求了，加入詳情頁的跳轉，可能跳轉前要處理些業務邏輯，接著又要增加需求了，列表檢視可以從宮格式轉變為瀑布式，需要改變控制元件的樣式，……接著新需求又來了，可編輯的列表項，可以刪除和修改列表項，同時資料要同步到伺服器，需求又來了，編輯列表項需要動畫功能……直到這個時候我們回頭再看看我們的Fragment，這個時候我們可能無法容忍Fragment裡混亂複雜的邏輯了。
從功能性需求的角度來說，功能完整、軟體正常執行，這是沒有問題的，但回過頭來我看了一下程式碼覺的並不是那麼“沒問題”，在不使用架構的情況下，我們無感知的將邏輯程式碼業務以及檢視程式碼都堆積到了Activity當中，這樣的角色可以說是相當的臃腫的，同時非常不利於未來的擴充套件，於是非功能性的需求需要滿足：Activity優化與擴充套件性。
我們再梳理一下這個場景的需求列表：
1、列表展示
2、列表支援下拉重新整理，上拉載入更多
3、列表要可以排序，可能會有n個條件
4、列表的item點選跳轉到詳情頁面
5、列表展示需要多樣化，瀑布流變宮格
6、列表可編輯，也許包括CURD，同時要同步伺服器
7、編輯列表時，加上動畫效果
下一章節，我們首先使用加入架構的方式來處理上面的需求，其中會介紹Model的定義，Controller的職責，以及它們如何通過控制反轉來進行解耦，如果你對MVC有了足夠的瞭解，可以直接跳轉到MVP的章節。