Android MVP方面的知識，我想大家都不陌生了，這裡我就做些總結與歸納；我會寫一個系列的Android
MVP的文章推送給大家，不敢保證你們都能完全的會使用，但是我敢保證的是你肯定能對MVP會有一個新的認識；廢話不多說下面進入正題。
引言
作為一個Android 的移動開發者我相信很多人都應該瞭解Android MVP框架；我相信很多人都想知道那麼MVP框架為什麼要學習？學習了有什麼用？我們作為程序猿相信每個人都離不開這些高性能、高效率的開發工具了，居然我們對工具的使用是如此，那我們對自己敲的代碼又何嘗不是如此呢？
Android的MVC架構我想我們很多人都是瞭解、清楚的，那麼使用過MVC的老鐵更加清楚的知道MVC的弊端的：臃腫、擴展性差、耦合性高等等缺點，人類的特點就是進化，從猿人到現在繁華的世界。因此，Android MVP框架就應運而生了，它有著諸多的優點：
1.解決了Acticity的臃腫問題
2.擴展行更強
3.耦合性低
…
作為程序猿的我們怎麼不去學這個高效的MVP框架呢？那就跟著我的腳步，你會驚訝Android MVP的學習就是那麼簡單
場景
我先來描述一個場景：
1、新聞列表展示
3、新聞列表要可以排序，可能會有n個條件
4、新聞列表的item點擊跳轉到詳情頁面
5、新聞列表可編輯，也許包括CURD，同時要同步服務器
6、新聞item長按可以刪除，收藏等功能
我相信這個場景是很常見的，我們試想一下這個需求不是一次就直接全部給出來的，是依次由產品經理提出來的；
展示新聞界面
產品經理通過市場那邊發現需要可以排序
又提出需求點擊item查看詳情
最後又提出item長按支持刪除、收藏、取消收藏等
。。。
還有很多很多的需求增加。哈哈，看到這裡的程序猿包括我在內（老子真想給他一刀），就不能一次說完麼？但是現實中我們遇到的情況就是這樣的，需求不斷的增加。
通常做法
1.展示新聞界面：
在activity中添加一個列表，然後列表來展示新聞，所有的代碼就寫在Activity中；網絡請求，列表刷新都放在activity中來執行。從只有這麼一個簡單的需求來說這樣寫是最簡單的。
2.增加需求：下拉刷新，上拉加載更多
大多數人可能還是會按照上面的方法，將刷新和加載更多都放在activity中
這樣做依然沒有任何的問題。
3.增加需求：支持時間、內容、關鍵詞排序
由於在創建項目的時候沒有想過接下來會增加這麼多需求，那麼可能接下來的措施是依然往activity中添加排序需求代碼。
。。。
後面依次增加需求，這樣我們的activity中的代碼之後就會非常難讀、臃腫。我們試想一下要是你把這樣的代碼交接給同事，看到這樣的代碼同事估計不知道如何下手，估計你的同事有想打你的衝動。我們換個思考，假如是你事隔多天之後，測試的同事給你說，某某地方有bug需要你去處理一下，估計你自己看到自己的代碼你想死的心情就有了。
哈哈，拿菜刀幹。。。
MVC的出現
然後就有人說了，這樣寫代碼不行，我們應該引入一種設計模式或者是框架之類的東西，既然上面的代碼臃腫，難讀，那我們就引入MVC框架來設計吧。
如果你要想更佳深刻的理解MVP，並在實際開發中靈活的應用，那麼就要先了解它的低配版MVC，他倆只是一步之遙，先了解MVC再學習MVP，MVP的優勢才能凸顯出來，這樣連貫性的學習才會加深對MVP的理解。
下面一章節我會著重介紹MVC的設計，有人就會問了，你不是說你要講MVP的嗎？怎麼去講MVC了，放心我肯定會著重講解MVP的，但是在講MVP之前我們要介紹下MVC。
只有經過MVC的這種模式你才能更加清楚的認識到MVP框架的優勢。
歡迎點評，指出不足和缺點，大家共同學習進步
