記得第一次接觸MVP開發是上大學的時候,當時看了數十篇關於MVP的文章,這裏不得不吐槽一下國內技術帖子的質量真是參次不齊啊。看完以後一直懵懵懂懂的,總覺有幾處關鍵的地方沒搞清可是文章中卻一帶而過了,好比:html
抱着這些問題,我本身摸索着構建出了一套個性化風格MVP架構,使用過程當中也優化了幾回,現在一年多過去了再看這套架構也就算是個能用吧,因此決定新的架構優化。小程序
本文講述了MVP的核心概念和如何從最初的乞丐版MVP架構一步步升級到平民版MVP架構,時尚版MVP架構,以及即將開始更新的旗艦版MVP架構,爲了保證思路清晰,文中包含大量代碼與文字,跟着文中的例子即可寫出一個完整的MVP架構。安全
其實咱們平常開發中的Activity,Fragment和XML界面就至關因而一個 MVC 的架構模式,Activity中不只要處理各類 UI 操做還要請求數據以及解析。網絡
這種開發方式的缺點就是業務量大的時候一個Activity 文件分分鐘飆到上千行代碼,想要改一處業務邏輯光是去找就要費半天勁,並且有點地方邏輯處理是同樣的無奈是不一樣的 Activity 就沒辦法很好的寫成通用方法。架構
那 MVP 爲啥好用呢?app
MVP 模式將Activity 中的業務邏輯所有分離出來,讓Activity 只作 UI 邏輯的處理,全部跟Android API無關的業務邏輯由 Presenter 層來完成。異步
將業務處理分離出來後最明顯的好處就是管理方便,可是缺點就是增長了代碼量。ide
在MVP 架構中跟MVC相似的是一樣也分爲三層。post
Activity 和Fragment 視爲View層,負責處理 UI。優化
Presenter 爲業務處理層,既能調用UI邏輯,又能請求數據,該層爲純Java類,不涉及任何Android API。
Model 層中包含着具體的數據請求,數據源。
三層之間調用順序爲view->presenter->model,爲了調用安全着想不可反向調用!不可跨級調用!
那Model 層如何反饋給Presenter 層的呢?Presenter 又是如何操控View 層呢?看圖!
上圖中說明了低層的不會直接給上一層作反饋,而是經過 View 、 Callback 爲上級作出了反饋,這樣就解決了請求數據與更新界面的異步操做。上圖中 View 和 Callback 都是以接口的形式存在的,其中 View 是經典 MVP 架構中定義的,Callback 是我本身加的。
View 中定義了 Activity 的具體操做,主要是些將請求到的數據在界面中更新之類的。
Callback 中定義了請求數據時反饋的各類狀態:成功、失敗、異常等。
下面咱們用 MVP 模式構造一個簡易模擬請求網絡的小程序。效果圖以下:
下面是Demo中的Java文件目錄:
Callback 接口是Model層給Presenter層反饋請求信息的傳遞載體,因此須要在Callback中定義數據請求的各類反饋狀態:
Model 類中定了具體的網絡請求操做。爲模擬真實的網絡請求,利用postDelayed
方法模擬耗時操做,經過判斷請求參數反饋不一樣的請求狀態:
View接口是Activity與Presenter層的中間層,它的做用是根據具體業務的須要,爲Presenter提供調用Activity中具體UI邏輯操做的方法。
Presenter類是具體的邏輯業務處理類,該類爲純Java類,不包含任何Android API,負責請求數據,並對數據請求的反饋進行處理。
Presenter類的構造方法中有一個View接口的參數,是爲了可以經過View接口通知Activity進行更新界面等操做。
在Activity代碼中須要強調的是若是想要調用Presenter就要先實現Presenter須要的對應的View接口。
至此,已經完整的實現了一個簡易的MVP架構。
注意!以上代碼中還存在很大的問題,不能用到實際開發中,下面會討論目前存在的問題以及如何優化。
由於上節中乞丐版MVP Demo的代碼只實現了一個Activity的請求操做,容易出現一個概念的混淆:
每一個Activity都須要有與它對應的一套MVP(Model,View,Presenter)嗎?
答案確定是否認的!
首先不須要數據請求的Activity固然就一樣不須要MVP輔助。與其餘Activity中存在相同邏輯的Activity,就不須要重複生成對應的MVP。可是這個存在相同邏輯的定義,不一樣的場景有不一樣的說法:
場景1中Activity A和Activity C都只有一個「買東西」的邏輯,屬於典型的邏輯相同,因此Activity C就能夠直接用Activity A寫好的MVP無需再作任何處理。
場景2和場景3的邏輯相似,都屬於一個業務邏輯中包含另一個能夠單獨存在的業務邏輯,這種狀況採用繼承的方法便可
場景4中Activity C想要同時調用獨立服務於Activity A 和 Activity B的業務邏輯,只須要將兩個業務邏輯對應的Presenter分別實例化並調用業務方法便可:
經過上面一攬子場景的分析,得出的第一個結論就是MVP的結構太過於繁重,因此爲了不多寫重複代碼和往後須要進行無心義的修改,在開發前必定要設計好邏輯調用圖,這樣才能事半功倍。
對於上面經典的經過業務邏輯繼承實現包含重複邏輯的方法,其實也能夠在一個Presenter中寫好完整的邏輯方法,對於不一樣的Activity須要哪一個業務邏輯方法就調用哪一個,這樣豈不就簡單多了。可是從架構設計角度看這種作法是不嚴謹的,可能存在漏洞,因此爲保持軟件架構的健壯仍是不要偷懶的好。
以前說過乞丐版MVP架構模式中還存在不少問題不能應用到實際的開發中,大概存在的問題有:
針對這些問題咱們須要進一步優化,單車變摩托,升級爲能夠在實際開發中使用的平民版MVP架構。
平民版MVP架構 優化代碼可參考 ————>>>>
博文出處:http://www.jcodecraeer.com/a/anzhuokaifa/2017/1020/8625.html?1508484926