這是一個(gè)用mvp架構(gòu)寫的demo，實(shí)現(xiàn)了閃屏頁的廣告展示匕积，版本更新彈窗盈罐、以及首頁的Tab和帶下拉刷新與上拉加載更多的列表頁面榜跌，有需要的都可以進(jìn)來倉庫參考。

周一上線了一版盅粪，這些天在討論下一波需求钓葫。正好前陣子有一位朋友問我關(guān)于mvp架構(gòu)的問題，所以想寫一篇博客來講講mvp票顾。 之前剛接觸mvp的時(shí)候础浮，看了很多個(gè)版本，正所謂一百個(gè)人中就有一百個(gè)想法奠骄，但總感覺好像都不是我想要的豆同。可能是我沒找到寫得好的吧含鳞。

看過很多mvp版本后影锈，基于對它的理解，寫了自己覺得比較接近它的定義的mvp模式〔醣粒現(xiàn)在整理出一個(gè)demo發(fā)出來供大家參考精居。來看看效果圖吧：

ps: 這是閃屏頁的廣告，進(jìn)入閃屏頁會(huì)有1.75秒鐘的加載時(shí)間潜必，若數(shù)據(jù)在1.75秒內(nèi)返回并且有廣告靴姿，則顯示廣告及倒計(jì)時(shí)，否則直接進(jìn)入首頁磁滚。

ps: 這就是首頁的版本更新彈窗與列表顯示佛吓，帶下拉刷新和加載更多。? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

其實(shí)mvp就是把傳統(tǒng)的mvc分成三個(gè)模塊垂攘，model數(shù)據(jù)模型層维雇、view視圖層 和 presenter邏輯處理層：? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?model：作用是獲取數(shù)據(jù)功能，用于網(wǎng)絡(luò)接口的請求與模型解析晒他。? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?view ：主要是與用戶交互的也頁面吱型，平時(shí)我們所展示的activity及fragment頁面，就是管理UI展示的陨仅。? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?presenter：主要負(fù)責(zé)view層與model層之間的數(shù)據(jù)傳遞津滞，從view層發(fā)出的數(shù)據(jù)需求起，到model層請求后的數(shù)據(jù)返回灼伤，它就是一個(gè)中間件触徐。但它不單單只是一個(gè)中間件，它還要處理view層展示的一些邏輯狐赡，而view頁面只需要處理與UI相關(guān)就可以了撞鹉。? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

mvp這樣分的好處就是：? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1 模型與視圖完全分離，降低耦合度，完全符合高類聚低耦合的思想鸟雏。? ? ? ? ? ? ? ? ? ? ? ? ? ? 2 代碼更簡潔享郊，可閱讀性高，利于他人維護(hù)和拓展孝鹊，降低成本炊琉。

萬事無絕對，有利也有弊惶室，它的缺點(diǎn)就是：? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1 同時(shí)你要寫很多個(gè)類温自，因?yàn)榛旧厦總€(gè)頁面就是有自己的model、view皇钞、presenter三個(gè)模塊類組成悼泌。當(dāng)然了，你也可以不這么寫夹界，你要是覺得類太多太麻煩馆里，那你都寫在一個(gè)類里也可以，你開心就好可柿。但我就擔(dān)心多年后的你再看到你當(dāng)初寫的代碼鸠踪，估計(jì)連你自己都不認(rèn)識(shí)了，所以這就無形中填增了維護(hù)的成本复斥。

???2 還有的就是因?yàn)樯婕暗絭iew層與presenter層的交互营密，要注意實(shí)例的持有，如果的App比較復(fù)雜目锭，頁面比較多或者層級(jí)比較深的评汰，一不小心就內(nèi)存泄漏了，因?yàn)槿绻鹥resenter層有延時(shí)的操作痢虹，尤其是handler和定時(shí)器等被去，一直持有view層的實(shí)例，那么本來要回收的頁面不能被回收奖唯，堆積多了惨缆，那就造成內(nèi)存泄漏了。? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

剛開始我是在presenter的基類里使用弱引用去接收view層的實(shí)例的丰捷，但后來跑小米測試的時(shí)候坯墨，過不去，連軟引用都過不去瓢阴，所以就使用接口回調(diào)來做數(shù)據(jù)的傳遞畅蹂，在view頁面回收的時(shí)候再將它們斷開。

好了荣恐，關(guān)于實(shí)現(xiàn)細(xì)節(jié)我這里就不多說，一切都在代碼里，大家打開項(xiàng)目地址就能看到demo叠穆。

項(xiàng)目地址：https://github.com/weioule/MVPDemo