androidmvp缺點

⑴ Android MVP與MVC的區別和理解

MVP架構：
View不直接與Model交互，而是通過與Presenter交互來與Model間接交互。
Presenter與View的交互是通過介面來進行的。
通常View與Presenter是一對一的，但復雜的View可能綁定多個Presenter來處理邏輯。
MVC架構：
View可以與Model直接交互。
Controller是基於行為的，並且可以被多個View共享。
可以負責決定顯示哪個View。

⑵ mvp android會導致內存泄漏嗎

MVP模式是MVC模式在Android上的一種變體，要介紹MVP就得先介紹MVC。在MVC模式中，Activity應該是屬於View這一層。而實質上，它既承擔了View，同時也包含一些Controller的東西在裡面。這對於開發與維護來說不太友好，耦合度大高了。把Activity的View和Controller抽離出來就變成了View和Presenter，這就是MVP模式。 在Android項目中，Activity和Fragment占據了大部分的開發工作。如果有一種設計模式（或者說代碼結構）專門是為優化Activity和Fragment的代碼而產生的，你說這種模式重要不？這就是MVP設計模式。 按照MVC的分層，Activity和Fragment（後面只說Activity）應該屬於View層，用於展示UI界面，以及接收用戶的輸入，此外還要承擔一些生命周期的工作。Activity是在Android開發中充當非常重要的角色，特別是TA的生命周期的功能，所以開發的時候我們經常把一些業務邏輯直接寫在Activity裡面，這非常直觀方便，代價就是Activity會越來越臃腫，超過1000行代碼是常有的事，

⑶ Android MVP解釋！，

優點：view由Activity承擔，Presenter做業務，結構清晰（模式么就是講究一個套路，結構清晰後來者維護也是受益的）。之前開發都是全寫一個類-Activity裡面，業務復雜的情況下看著頭疼。看一些公司招android還講究mvc，™Activity到底算v還是c，還是兩者都是？缺點：每個view有個presenter，類多了。不說presenter重用，實際工作中我是沒法抽象使得presenter重用（技術渣）。有時候業務簡單就直接一個Activity搞定了。

⑷ Android MVP模式中，一個Activity對應多個Presenter時該怎樣抽象

MVP概念：MVP(Model-View-Presenter) 是總所周知MVC模式的一個演變，主要目的都是劃分模塊職責，降低模塊耦合，易測試,提高代碼復用。層級責任Model:負責數據的檢索,持久化等操作。
View: 負責UI的繪制和用戶的交互。
Presenter: 作為Model和View的中間協調部分,負責兩者之間的業務邏輯處理。</ol>MVC模式的區別MVC模式允許View層和Model層直接通訊。
當某個View的功能很復雜的時候,View和Model的耦合度可能會很高。
MVP模式就沒有這個問題,View會抽象出來一系列操作UI的介面。
Presenter拿到的都是其他兩個層級的介面來做業務邏輯的處理，這樣不僅可以使View和Model之間的耦合度降低,還可以更易得進行單元測試。</ol>MVP的優缺點優點:降低耦合，層級職責更明顯，易於單元測試。
缺點:造成類數量爆炸，代碼復雜度和學習成本高，在某些場景下presenter的復用會產生介面冗餘。

⑸ 安卓mvc和mvp的區別

對於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吧）。這可能也就是為何，在該文中有一句這樣的話：

詳細

⑹ 如何看待android mvp 設計模式的優缺點

MVP設計模式是為了方便ASP.

⑺ 我是覺得mvp不適合android，增加那麼多介面，雖然能解耦，但實際情況是改動一點需求就要涉及好

我今天在研究MVVM你要不要一起啊。你說的是

復雜的業務同時會導致presenter層太大，代碼臃腫的問題。

MVVM為MVP升級版哇，有空研究一下子。網頁鏈接

⑻ mvp模式中將activity當成p有什麼壞處

缺點：每個view有個presenter ，類多了。不說presenter重用，實際工作中我是沒法抽象使得presenter重用（技術渣）。有時候業務簡單就直接一個Activity搞定了。

⑼ android mvvm和mvp哪個好

沒有那個好那個不好一說，大項目需要用到框架做以後的維護升級，小項目沒必要去強套什麼框架，反而會變得麻煩。

⑽ Android 目前是 mvc，mvp，mvvm 哪種模式比較好

mvc的界面和邏輯關聯緊密，數據直接從資料庫讀取。mvvm的界面與viewmode是松耦合，界面數據從viewmodel中獲取。如果你寫代碼的時候在界面的cs文件里有很多業務邏輯代碼，那麼你使用的就不是mvvm，而是mvc