來一張爸爸的照片，鎮樓。
很多人不願意寫關於Android中MVP的文章，為啥呢，費時間，大家更喜歡用視頻的方式，文章寫起來太浪費時間了，所以咯，目前也只有我這樣的離職人員有時間寫了。話說回來，我們在工作中，你不可能對著一個視頻教你寫代碼吧！小組長或者CTO在背後diss你，你不怕？所以來一下文章，邊看邊寫，真香。還有人說這百度一大堆MVP的文章，為啥要看你的。這裡，我希望你看完文章你就知道為什麼，我現在寫的才是你實際可以直接用的，百度很多都是知識教你認識，也有人寫類似的文章，但我們每個人的都有些不一樣，你可以集思廣益，自己優化。先說下今天寫哪些內容，首先，我們還是簡單的比較下MVC，MVVM，MVP，然後我們就開始擼代碼，最後我們就講一下MVP優化。
MVC有兩個很明顯的問題：
1.m層和v層直接打交道，導致這兩層耦合度高
2.因為所有邏輯都寫在c層，導致c層特別臃腫
我相信很多Android的開發工程師都還在用MVC模式，我自己的同學，包括前同事等，目前都在用，問他們為啥，回答都是簡單，項目週期緊，沒時間，MVP接口多，寫起來麻煩，所以直接懟代碼。（如果是做服務端的人肯定奇怪為啥Android居然可以用MVC寫的下去），實際上MVP眾多的缺點都是可以用代碼解決的。
MVP:
p層代替了了c層，v層和m層的交互被p層隔斷，從理論上去除了v和m層的耦合。
但是造成p層比原來的c層更加臃腫，為了緩解這種臃腫，MVVM出現了
MVVM：
簡單的來說MVVM其實就是MVP中把P層削弱為VM層，部分簡單的邏輯職責分給了View層。但是有一個很大的問題，也是至今這個模式比MVP模式用的少太多的原因，那就是佔用內存，比方說，如果你用MVP開發的app只是佔用1G的內存的話，那MVVM差不多就要佔用2.5G。至於為什麼，那一講又是一內容，本來今天講的就會很多。所以有興趣的同學自己去學習。
好了，現在我們來擼項目，用項目說話，更直觀，我們首先來百度一大堆的那個教程先寫一遍，然後我們來優化。
先來看看大部分人寫法看下圖：
一個簡單的recycler加載數據
然後我們看下跑出來效果：
跑出來的效果
然後我們用內存分析工具，我們拍一張內存照片，然後在GC一下，我們看看會發生什麼：
內存快照GC前
如果看不懂這個圖的，可以自己去學習一下。看出了什麼沒有，
GC後
兩張圖對比，本來GC完這個activity會回收的，然而現實並沒有。現在我們來改代碼，改成MVP的模式，百度上已經基礎的教我們怎麼寫了，我們直接寫，我以下截圖都是類跟接口，然後上截圖。（接口跟類起名比較隨意，只是例子，實際中都有規範）
首先創建ivew接口
這個就是View層，只要是做回調把數據回調給activity
創建model層接口
model層接口，很多人直接寫void loadDate(ListModelBean listModelBean)；這個是不對的，因為我們的數據大多數是從服務器來的，所以只要加載速度過長那就會直接卡在這裡，所以我們創建內部接口進行回調
創建model類
model類，所有的數據邏輯都是在這個地方處理，繼承ITaskModel接口把數據傳遞進去，此時我們完成了M層和V層，現在就差P層，這個時候我們可以一個形象的比喻，P是身體，M層跟V層是左右手。是不是很像。下面我們來創建P層
創建的P層
P 層第一我們肯定先寫出兩個接口（左右手）ITaskview，ITaskModel，然後構造函數，然後初始化，有沒有發現我們的初始化跟百度的很多不一樣，這裡有人問為什麼要用泛型，這裡好處很多啊！大家可以自己體會下，我就不講好處，思考使我們必須具備的能力。現在直接在P層執行UI邏輯，並且通過view層回調給activity
Activity
activity裡面代碼是不是少很多，像加載數據之類的跟activity全部給了model。這是基本的MVP，大家執行下效果。現在我們並不是大功告成，大家想想，如果數據不能及時回收怎麼辦？內存洩漏怎麼辦？還有我們的MVP會創建那麼多接口，看著就麻煩怎麼辦？這個是可以通過代碼解決的，這也是研究一點跟只會基礎掌握的區別。下面我們開始優化代碼，我們目光轉移到P層，然後我們把數據弱引用來解決內存洩漏問題。看下圖：
修改後的p層
看到改了什麼沒有，我們註銷ITaskview，然後用弱引用的方式，這樣內存在不足的時候GC就回收。運行效果看看，我們主要看內存，這個我想大家會在控制檯看變化。當然我們這個還沒做完，而且也不是最好的辦法，這個時候我們咋辦呢？很簡單，綁定跟解綁，有沒有很熟悉。繼續P層：
再次修改過的P層
我們把構造函數里面做的事情放在綁定和解綁裡面。
activity裡面修改
調用綁定和解綁，這樣只要銷燬activity，GC就會回收。現在我們MVP算是完成了，但是我們P層會特別多，我們怎麼優化？所以我們我們就需要各種創建基類。下面我們來操作：
創建present基類
把綁定解綁直接放在基類裡面
修改的Taskpersent
繼承基類，並去掉公共方法。
創建BaseActivity來進行P層的綁定跟解綁
修改後的activity
繼承BaseActivity然後去除那些綁定解綁之類的公共方法。現在我們基本上完善了MVP的優化，大家可以有一個小測試，那就是我們直接修改xml裡面的View（RecyclerView或者listView）更換成GridView,看看是不是有一個小驚喜。現在我們優化了activity的內存洩露。講了這麼多，真的特別累人，不過現在還有問題，我們如何優化model層呢？model是比較麻煩的，先看看實際開發中我們遇到的基本是這幾個問題：
- 無法對所有Model統一管理。
- 每個Model對外提供的獲取數據方法不一樣，上層請求數據沒有規範。
- 代碼冗餘高，網絡數據請求除URL和參數外其他大概都一樣的。
- 對已存在的Model管理困難，不能直觀的統計已存在的Model。
model層我們優化就一句話，單獨封裝，集中管理或者我們弄一個事件總線RXBus（推薦）來調度。是不是一說就很簡單了？一看時間又花了三小時了，整理這篇文章已經超過四個小時了，下次再說如何優化model層。最後心疼一下程序員，唉~分享使我快樂，MVP我只是在這個地方提供這麼一個思路，優化的路還很長，裡面細節問題，歡迎自己思考，現在寫到這樣吧！贈人玫瑰，手有餘香。哈哈！一個愛程序的加班狗。
閱讀更多 我有一隻小蟑螂 的文章
