androidmvp框架
⑴ Android MVP 開發模式有哪些優缺點
MVP概念：
MVP(Model-View-Presenter) 是總所周知MVC模式的一個演變，主要目的都是劃分模塊職責，降低模塊耦合，易測試,提高代碼復用。
層級責任
Model:負責數據的檢索,持久化等操作。
View: 負責UI的繪制和用戶的交互。
Presenter: 作為Model和View的中間協調部分,負責兩者之間的業務邏輯處理。
MVC模式的區別
MVC模式允許View層和Model層直接通訊。
當某個View的功能很復雜的時候,View和Model的耦合度可能會很高。
MVP模式就沒有這個問題,View會抽象出來一系列操作UI的介面。
Presenter拿到的都是其他兩個層級的介面來做業務邏輯的處理，這樣不僅可以使View和Model之間的耦合度降低,還可以更易得進行單元測試。
MVP的優缺點
優點:降低耦合，層級職責更明顯，易於單元測試。
缺點:造成類數量爆炸，代碼復雜度和學習成本高，在某些場景下presenter的復用會產生介面冗餘。
⑵ Android MVP架構中的Presentation層應該怎麼設計
對於MVP（Model View Presenter），大多數人都能說出一二：「MVC的演化版本」，「讓Model和View完全解耦」等等。本篇博文僅是為了做下記錄，提出一些自己的看法，和幫助大家如何針對一個Activity頁面去編寫針對MVP風格的代碼。
對於MVP，我的內心有一個問題：
為何這個模式出來後，就能被廣大的Android的程序員接受呢？
問了些程序員，他們對於MVP的普遍的認識是：「代碼很清晰，不過增加了很多類」。我在第一次看到MVP的時候，看了一個demo，看完以後覺得非常nice（但是回過頭來，自己想個例子寫，就頭疼寫不出來，當然這在後文會說）。nice的原因還是因為，這個模式的確讓代碼的清晰度有了很大的提升。
那麼，提升一般都是對比出來的，回顧下，沒有應用MVP的代碼結構。很多人說明顯是MVC么：
View：對應於布局文件
Model：業務邏輯和實體模型
Controllor：對應於Activity
看起來的確像那麼回事，但是細細的想想這個View對應於布局文件，其實能做的事情特別少，實際上關於該布局文件中的數據綁定的操作，事件處理的代碼都在Activity中，造成了Activity既像View又像Controller（當然了Data-Binder的出現，可能會讓View更像View吧）。這可能也就是為何，在該文中有一句這樣的話：
Most of the modern Android applications just use View-Model architecture，everything is connected with Activity.
而當將架構改為MVP以後，Presenter的出現，將Actvity視為View層，Presenter負責完成View層與Model層的交互。現在是這樣的：
View 對應於Activity，負責View的繪制以及與用戶交互
Model 依然是業務邏輯和實體模型
Presenter 負責完成View於Model間的交互
ok，先簡單了解下，文中會有例子到時候可以直觀的感受下。
⑶ Android 中 MVC、MVP 和 MVVM 對比
MVC、MVP和MVVM是常見的三種架構設計模式，當前MVP和MVVM的使用相對比較廣泛，當然MVC也並沒有過時之說。
MVC (Model-View-Controller, 模型-視圖-控制器)，標準的MVC是這個樣子的：
簡述：
缺點：
MVP (Model-View-Presenter) 是MVC的演化版本，幾個主要部分如下：
簡述：
解釋：
優點：
缺點：
MVVM 是 Model-View-ViewModel 的簡寫。和 MVP 模式相比，MVVM 模式用 ViewModel 替換了 Presenter ，其他層基本上與 MVP 模式一致，ViewModel 可以理解成 是 View 的數據模型和 Presenter 的合體。MVVM 就是將其中的 View 的狀態和行為抽象化，讓我們將視圖 UI 和業務邏輯分開。
簡述：
缺點:
參考：
⑷ 如何實現自己的Android MVP框架
前言
MVP作為一種MVC的演化版本在Android開發中受到了越來越多的關注，但在項目開發中選擇一種這樣的軟體設計模式需保持慎重心態，一旦確定使用MVP作為你App的開發模式那麼你就最好堅持做下去，如果在使用MVP模式開發過程中發現問題而且坑越來越大，這時你想用MVC等來重新設計的話基本上就等於推倒重來了。要知道在Android上MVP在現在為止並沒有統一的標准或者框架，不像SSH這三個成熟穩重強而有力的三劍客支持推動著java EE的開發，所以在運用MVP時一定要做好自己的理解，並且盡量預知自己App各模塊的需求（客戶說改改改，我們就改改改 :-( ）以便提前做好充分的設計工作。當然MVP既然能出現那麼必然有它的優點的，不然誰會理會這個冒出來的東西，下面就對Android中MVP做一些闡述。
MVP簡介
相信大家對MVC都是比較熟悉了：M-Model-模型、V-View-視圖、C-Controller-控制器，MVP作為MVC的演化版本，也是作為用戶界面（用戶層）的實現模式，那麼類似的MVP所對應的意義：M-Model-模型、V-View-視圖、P-Presenter-表示器。從MVC和MVP兩者結合來看，Controlller/Presenter在MVC/MVP中都起著邏輯控制處理的角色，起著控制各業務流程的作用。而MVP與MVC最不同的一點是M與V是不直接關聯的也是就Model與View不存在直接關系，這兩者之間間隔著的是Presenter層，其負責調控View與Model之間的間接交互，MVP的結構圖如下所示，對於這個圖理解即可而不必限於其中的條條框框，畢竟在不同的場景下多少會有些出入的。在Android中很重要的一點就是對UI的操作基本上需要非同步進行也就是在MainThread中才能操作UI，所以對View與Model的切斷分離是合理的。此外Presenter與View、Model的交互使用介面定義交互操作可以進一步達到松耦合也可以通過介面更加方便地進行單元測試。
項目效果預覽
包圖中明顯的三層：Model包、Presenter包、UI包，其中，三者都實現各自的結構，Model為WeatherModel、Presenter為WeatherPresenter、View為Weather，那麼具體實現類就是impl包里的了，View層的即為Activity。此外的app和util包無關緊要可以不看。可以看到採用MVP設計後項目明顯多了很多東西，這也是不可避免的，使用原始方法可以使項目開起來簡單些但是以後還有維護呢、測試呢、加功能呢、。。。
entity里的實體屬性基本上對應json里的這些屬性了，代碼不貼了
View裡面的介面：
public interface WeatherView {
void showLoading();
void hideLoading();
void showError();
void setWeatherInfo(Weather weather);
}
WeatherPresenter的介面：
public interface WeatherPresenter {
/**
* 獲取天氣的邏輯
*/
void getWeather(String cityNO);
}
WeatherModel介面：
public interface WeatherModel {
void loadWeather(String cityNO, OnWeatherListener listener);
}
prestener裡面還有個OnWeatherListener，其在Presenter層實現，給Model層回調，更改View層的狀態，確保Model層不直接操作View層。如果沒有這一介面在WeatherPresenterImpl實現的話，WeatherPresenterImpl只有View和Model的引用那麼Model怎麼把結果告訴View呢？當然這只是一種解決方案，在實際項目中可以使用Dagger、EventBus、Otto等第三方框架結合進來達到更加松耦合的設計。
public interface OnWeatherListener {
/**
* 成功時回調
*
* @param weather
*/
void onSuccess(Weather weather);
/**
* 失敗時回調，簡單處理，沒做什麼
*/
void onError();
}
所以demo的代碼流程：Activity做了一些UI初始化的東西並需要實例化對應WeatherPresenter的引用和實現WeatherView的介面，監聽界面動作，Go按鈕按下後即接收到查詢天氣的事件，在onClick里接收到即通過WeatherPresenter的引用把它交給WeatherPresenter處理。WeatherPresenter接收到了查詢天氣的邏輯就知道要查詢天氣了，然後把查詢天氣的具體業務實現交給WeatherModel去實現同時把WeatherListener即WeatherPresenter自己傳給WeatherModel。WeatherModel進行查詢天氣業務後即把結果通過WeatherListener回調通知WeatherPresenter，WeatherPresenter再把結果返回給View層的Activity，最後Activity顯示結果。就這樣，拍磚之處請拍。
End
採用哪種軟體設計模式都是為了達到如下目的，找到合適的加以運用就是最好的：
易於維護
易於測試
松耦合度
復用性高
健壯穩定
------------------------------------------------------------------------------------
以上內容均參考互聯網，希望以上知識對您有所幫助，
⑸ Android真的推薦用MVI模式MVI和MVVM有什麼區別
android自己卷自己，自己造一個MVI架構模式嗎？
MVI架構模式是國內android開發者最近一兩年造出來的嗎？
看了很多MVI的資料，發現都提到cycle.js框架。android的mvi架構就是啟發於cycle.js框架。
我們再看看Cycle.js框架是什麼時候開始的，又是什麼時候開始使用MVI模式的。
Cycle.js框架 第一個預發版本 ：
https://github.com/cyclejs/cyclejs/releases?page=6
再結合官方文檔來看，Cycle.js框架就是為了MVI架構模式而生的。
雖然不知道，Cycle.js框架是不是首個MVI模式框架。
但是從很多資料可以推測，MVI架構模式就是Cycle.js框架推廣開來的。
而且早在2014年就已經在前端開發中用得飛起了。
想想2014年，咱們在幹嘛？android在用什麼架構模式。
正所謂，天下武功出少林啊。
我們android的很多技術，在前端早就用「爛了」。
我們知道MVP和MVVM的爹都是MVC。MVI的爹也是MVC。
MVC的Controller是命令是編程組件，不能直接實現響應式編程思想。
響應式編程範式（Reactive programming）：
安卓官方的compose框架、微信小程序、Flutter、React、鴻蒙UI的開發框架，都是使用響應式開發框架。
這里就不拓展開來講了，上面提到的任何一個開發框架，你只要會一個基本就能理解響應式編程範式。
如果一個都不會也沒關系，現在不理解響應式編程也沒關系，等你學會MVI就理解了，這種只有實際使用過才能深刻理解。
學不會也沒關系，不要焦慮（尤其那些工作不久的小夥伴，學不會屬於正常現象~）
MVI，咱第一遍學不會，就等2年，再學一遍~
2年後也沒學會，那就再等2年~ 一定要有耐心~
如果還是學不會，那也沒關系，因為MVI早晚也會過時~ 等過時了就不用學了~
哈哈哈~ 別笑，正經Android可不會開玩笑的。
就像rxjava，當年有多少人死活學不會，android開發現在誰還學Rxjava？哈哈哈~
用一張圖來總結這次升級的核心思想：
新版架構指南在舊版的基礎上，做了如下調整和建議：
1. 將LiveData組件改成了StateFlow
對協程的使用更友好。並且更能體現面向數據流開發的思想。
實際上，依然使用LiveData也沒毛病。
2. ViewModel傳遞給View的數據限制為View的UIState
ViewModel從Model層獲取數據後，轉換為UIState數據，通過StateFlow流向View層。
UIState的數據面向界面組件而定義的，是能直接控制View組件如何顯示的數據。
所以我們也可以稱UIState為界面的狀態或者View的狀態。
如下：
3. 單數據流還是多數據流的選擇
官方指南並沒有強制我們使用單流。
同一個界面應該使用單個StateFlow還是多個StateFlow，需要我們自己判斷。
我們應該根據UIStates數據們之間關聯程度來決定多流還是單流。
單流優缺點都十分明顯：
優點： 數據集中管控，會提高代碼的可讀性和修改的便利性。
缺點： 當數據非常多且復雜時，會影響效率。因為我們沒有diff功能，View層不能只更新有變化的數據，只會根據UIState刷新當前界面。
https://developer.android.com/jetpack/guide/ui-layer#additional-considerations
我們再看下官方新版架構圖：
當然不僅僅MVVM可以改造成響應式開發範式，MVP也是可以的。
不信你看 這篇blog ：
https://www.raywenderlich.com/817602-mvi-architecture-for-android-tutorial-getting-started
1. 理解MVC架構模式的思想【MVC是其他架構模式之爹，他的思想是MVP、MVVM、MVI的基礎，學會它是關鍵步驟~】。
3. 學習kotlin的StateFlow組件，的使用：Sequence->Flow->StateFlow。
4. 學習ViewModel組件的使用（雖然不用ViewModel也能實現MVI架構，但是ViewModel還是值得學習）。
5. 理解DRY（Don't Repeat Yourself）原則。
6. 理解MVVM（因為官方的MVI模式是基於MVVM的基礎改造的~）。
7. 學習官方架構指南。
8. 實戰。
在這里就分享一份由大佬親自收錄整理的 學習PDF+架構視頻+面試文檔+源碼筆記 ， 高級架構技術進階腦圖、Android開發面試專題資料，高級進階架構資料
這些都是我現在閑暇時還會反復翻閱的精品資料。裡面對近幾年的大廠面試高頻知識點都有詳細的講解。相信可以有效地幫助大家掌握知識、理解原理，幫助大家在未來取得一份不錯的答卷。
當然，你也可以拿去查漏補缺，提升自身的競爭力。
真心希望可以幫助到大家，Android路漫漫，共勉！
如果你有需要的話，只需 私信我【進階】即可獲取