寫在前面

講道理，這次是真的筆者很久都沒有更新 blog 了，主要最近維護的框架問題也是層出不窮，而且對技術交流群的解答也讓我身心疲憊，所以在這里跟關注我的人說聲抱歉，沒有定期給你們帶來福利，那么這里就給大家帶來一個重磅福利：愛吖妹紙 —— Retrofit & RxJava & MVP & Butterknife 的完整 App.

講到最近讓我身心疲憊的問題解答，無疑是讓我在開源的路上越走越遠，雖然我不是技術大牛，卻依然被一些很簡單的問題輪番轟炸，其實筆者的內心真的是拒絕的。不得不說，寫給技術群內的你和群主，為什么你提問，而總沒人回你！寫的挺好。

概述

廢話也不多說，對于 MVP（Model View Presenter），我相信大多數人都能說出一些的，“ MVC 的演化版本”，“讓Model和View完全解耦”等等，但用過 MVP 的人一定會覺得，在 Android 中，代碼很清晰，不過多了很多類。對于大多數人而言，在看 MVP 的 Demo 的時候，一眼便是慢慢的 nice，然而讓自己來寫個例子，卻很頭疼寫不出來。但的確 MVC 模式寫起來更加像是順水推舟。只需要把自己的業務邏輯一股腦的放進 Activity 就成功完事兒。

不得不說，之前我們項目中的確也是用的 MVC 在編寫的。很簡單的會發現隨便一個 Activity 代碼都是幾百上千行，甚至還有一萬行以上的。看起來的確那么一回事兒，但是細想這個 View 對于布局文件，其實能做的事情特別少，實際上關于該布局文件中的數據綁定的操作，事件處理的操作都在 Activity 中，造成了 Activity 既想 View 又像 Controller，鄙棄代碼上的不美觀來說，對于后面的閱讀代碼真的是吃力。

不信？你瞧瞧。

也許業務邏輯比較簡單的功能用 MVC 沒什么，但是想沒想過，如果你產品后面改需求怎么辦？是的，你接受產品需求的強奸，但還是只有忍辱偷生。在日漸復雜的業務邏輯上，你的 Activity 和 Fragment 代碼越來越多，最終導致代碼爆炸，難以維護。

網上瀏覽一圈，發現講 MVP 的文章比比皆是，可見 MVP 的歡迎度，但大多數文章都只是講理論，稍微好點的會附帶一個簡單的登錄的 Demo。然而，一個簡單的 demo 很難讓初次接觸 MVP 模式的人掌握它的使用。所以 愛吖妹紙應運而生。

愛吖妹紙的優勢？

愛吖妹紙是運用 MVP，Retrofit，RxJava 等主流框架整合的干貨 App，項目資源來源于代碼家的干貨集中營。代碼量不多，但基本涉及了各個方面，界面采用 design 風格，所以也是學習 design 的良藥。你還在等什么，猛戳鏈接吧！https://github.com/nanchen2251/AiYaGirl

什么是 MVP

當然不能跑題，前面對 MVP 做了簡單的概述，下面還是用一個簡單的圖表示一下。

如上圖所示，在項目中 View 和 Model 并不直接交互，而是使用 Presenter 作為 View 和 Model 之間的橋梁。其中 Presenter 中同時持有 View 層以及 Model 層的 Interface 的引用，而 View 層持有 Presenter 層 Interface 的引用，當 View 層某個頁面需要展示某些數據的時候，首先會調用Presenter 層的某個接口，然后 Presenter 層會調用 Model 層請求數據，當 Model 層數據加載成功之后會調用 Presenter 層的回調方法通知 Presenter 層數據加載完畢，最后 Presenter 層再調用 View 層的接口將加載后的數據展示給用戶。這就是 MVP 模式的核心過程。

這樣分層的好處就是大大減少了 Model 與 View 層之間的耦合度。一方面可以使得 View 層和 Model 層單獨開發與測試，互不依賴。另一方面Model層可以封裝復用，可以極大的減少代碼量。當然，MVP 還有其他的一些優點，這里不再贅述。

看看項目截圖？

還是給大家看看項目截圖，以免大家心慌。

六、寫在最后

筆者也是希望繼續在開源路上越走越遠，還請大家支持，點擊評論 666！別忘了關注我的 github，隨手點贊。

做不完的開源，寫不完的矯情。歡迎掃描下方二維碼或者公眾號搜索「nanchen」關注我的微信公眾號，目前多運營 Android ，盡自己所能為你提升。如果你喜歡，為我點贊分享吧~

nanchen

總結

以上是生活随笔為你收集整理的【知识必备】浅淡MVP在Android项目中的实战演习，让代码结构更简单~的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。