原文：Architectural Guidelines to follow for MVP pattern in Android
默認(rèn)情況下，Android沒有強制使用任何架構(gòu)模式。盡管這使得框架在開發(fā)應(yīng)用程序時更加強大，但同樣的情況也會使您的代碼在更復(fù)雜的應(yīng)用程序場景中更加脆弱。
這是因為在一段時間內(nèi)，應(yīng)用程序開發(fā)涉及更復(fù)雜的生命周期和特性管理，這可能會在不以適當(dāng)?shù)姆绞教幚頃r造成應(yīng)用程序的混亂。這就是為什么開發(fā)人員依賴于不同的架構(gòu)模式，比如MVC、MVP和MVVM，用于Android的應(yīng)用開發(fā)。
就我開發(fā)應(yīng)用程序的經(jīng)驗而言，我建議使用MVP架構(gòu)模式來開發(fā)Android應(yīng)用程序。有了這篇文章，我打算幫助我的開發(fā)人員在開發(fā)帶有MVP架構(gòu)的android應(yīng)用程序時遵循一些指導(dǎo)原則。在討論指導(dǎo)方針之前，讓我們了解一下Android的MVP架構(gòu)模式到底是什么，以及每個人在他們的項目中應(yīng)該如何使用它。
MVP架構(gòu)模式——回顧
MVP架構(gòu)設(shè)計模式是相當(dāng)著名的Android開發(fā)者設(shè)計模式。它允許您通過引入一個稱為“演示者”的中介來將業(yè)務(wù)邏輯（模型）與視圖邏輯（活動/片段）分離。
正如其名稱所暗示的，模型-視圖-演示者被劃分為三個不同的層，其獨立的層定義如下：
Model?:如上所述的模型，模型是存儲業(yè)務(wù)邏輯和應(yīng)用程序數(shù)據(jù)的地方。在Android中，Model的角色通常由數(shù)據(jù)訪問層，如數(shù)據(jù)庫API或REST API來扮演。不僅僅是模型負(fù)責(zé)存儲應(yīng)用程序數(shù)據(jù)，它還包括負(fù)責(zé)生成、公開和獲取數(shù)據(jù)的組件。一般來說，所有這些功能都是在后臺運行的，因為它們可以阻塞UI線程。視圖視圖基本上是一個被動的接口和UI，它負(fù)責(zé)將用戶的操作路由到演示者。
VIEW:在Android中，View可以是你的活動、片段或回收器視圖適配器。一般來說，除了應(yīng)用程序的pojo和實體之外，view對你的模型是不可見的。為了使用更簡單的術(shù)語，View不會直接與Model通信。然而，他們與Presenter交流。
Presenter:Presenter是視圖和模型之間的中介或中介，它負(fù)責(zé)所有必須處理應(yīng)用程序中表示邏輯的事情的責(zé)任。一般來說，演示者負(fù)責(zé)查詢您的Model，在響應(yīng)用戶的交互時更新View。它監(jiān)視Model和對話，以便當(dāng)特定View需要更新時，它們可以處理，何時不需要更新。
為什么在Android中使用MVP架構(gòu)模式？
MVP是為數(shù)不多的幾個遵循bob叔叔的清潔架構(gòu)指南的架構(gòu)模式之一。以下是一些讓MVP成為Android的優(yōu)秀架構(gòu)模式的原因
1.使應(yīng)用程序中的調(diào)試更輕松
MVP強制執(zhí)行三層不同的抽象層，這使得調(diào)試應(yīng)用程序變得更加容易。而且，由于業(yè)務(wù)邏輯與視圖完全解耦，所以在開發(fā)應(yīng)用程序時執(zhí)行單元測試更容易。
2.更好分離問題
mvp將你的業(yè)務(wù)邏輯和持久性邏輯從你的活動和片段類中分離出來，從而更好地執(zhí)行好的問題分離。
3.代碼的復(fù)用性
在MVP中，代碼可以更好地復(fù)用，因為你可以有多個presenter來控制你的view。這一點更重要，因為你絕對不希望依靠一個presenter來控制你的不同view。
在Android中有效實現(xiàn)MVP架構(gòu)模式的指導(dǎo)方針
1.讓你的view盡可能簡單
如果你問任何一個新手Android開發(fā)者，他們會告訴你為什么測試Android對測試人員來說更痛苦。在Android中，開發(fā)應(yīng)用程序的常見模式是在單個Activity/Fragment類中編寫數(shù)千行代碼。然而，當(dāng)您的應(yīng)用程序發(fā)展并變得更加復(fù)雜時，同樣的實現(xiàn)往往會變得有問題。為了解決這個問題，你應(yīng)該讓你的View盡可能的簡單。你的view越簡單，測試你的Android用戶界面就越好。
在MVP中，你可以使用Passive View模式實現(xiàn)同樣的功能。通過實現(xiàn)這個模式，您將通過引入一個通過與View對話來響應(yīng)用戶行為的演示者，將View的行為減少到幾乎最小的級別。
例如，讓我們考慮你需要在你的應(yīng)用中實現(xiàn)一個登錄界面。用戶將會填寫他們的注冊電子郵件和用戶名來登錄。在實現(xiàn)相同的過程中，您不需要在View中編寫身份驗證邏輯。相反，您將把它寫在Presenter程序中，當(dāng)用戶成功登錄時（比如型材屏幕），它將更新您的View。在這種情況下，您的View的作用是只接收電子郵件和密碼的輸入，并將其傳遞給Presenter，后者將更新View。
2.在Model中管理遠(yuǎn)程和本地數(shù)據(jù)源
您可以通過在Model中管理遠(yuǎn)程和本地數(shù)據(jù)源來提高應(yīng)用程序的速度。
例如，讓我們假設(shè)您需要開發(fā)一個離線的應(yīng)用程序，它甚至在數(shù)據(jù)連接關(guān)閉時也會運行，實現(xiàn)相同的一個解決方案是通過獲取數(shù)據(jù)和存儲緩存，這樣當(dāng)用戶在線時就可以查詢它。
您可以通過創(chuàng)建三個不同的Model類來實現(xiàn)這一點，特別是以遠(yuǎn)程數(shù)據(jù)源、本地數(shù)據(jù)源和數(shù)據(jù)存儲庫的形式。
你的數(shù)據(jù)存儲庫類將包含與Presenter對話的邏輯。
本地數(shù)據(jù)存儲類可以處理緩存的數(shù)據(jù)和本地存儲，而遠(yuǎn)程數(shù)據(jù)源類則處理所有遠(yuǎn)程API調(diào)用和響應(yīng)。
3.使用像Dagger2和RxJava這樣的庫來最小化代碼冗余
我建議使用像Dagger2這樣的依賴注入庫，這將使您的Model和Presenter程序獨立于您的View的生命周期。
使用Dagger可以通過在它們之間注入依賴關(guān)系來簡化組件的行為。
此外，您應(yīng)該使用像RxJava這樣的庫，它將簡化您的代碼庫，同時處理繁重的繁重工作，例如多個用戶交互（如單擊、滑動等）和用于網(wǎng)絡(luò)的背景數(shù)據(jù)。
4.使用適當(dāng)?shù)拿s定來分離職責(zé)
為您在代碼庫中使用的方法使用適當(dāng)?shù)拿s定。一般來說，您有兩種不同的方法，例如您的Presenter中的動作和用戶事件。動作是包含View將被更新的邏輯的方法。
例如：load（）或loadmore（）將告訴演示者在用戶向下滾動應(yīng)用程序時加載另一個頁面。
也就是說，View將知道何時更新自己（比如通過與演示者交談），當(dāng)用戶滾動到頁面的末尾時，用戶事件表示由用戶觸發(fā)的動作。
例如：只有當(dāng)用戶鍵入正確數(shù)量的字符，顯示相關(guān)的搜索時，才可以調(diào)用querychanged（）方法。
簡單地說，應(yīng)該使用適當(dāng)?shù)拿s定，它適合于需要觸發(fā)的動作，這意味著應(yīng)該運行什么邏輯，以及什么時候應(yīng)該運行它。
5.讓你的Presenter獨立于一個框架來提高可測試性
在Android中使用MVP的主要想法是在你的項目中執(zhí)行適當(dāng)?shù)目蓽y試性。為了實現(xiàn)相同的（改進(jìn)的可測試性），您應(yīng)該使您的演講者獨立于任何Android類。主要的想法是讓Presenter被剝奪任何平臺的依賴，這樣您就可以使用Junit測試演示者了。
您應(yīng)該避免使用來自共享資源的上下文對象，使其更獨立于平臺。Ivan sk瑞克寫了一篇很好的文章，解釋了如何讓你的Presenter獨立于android國家。
總結(jié)
Android的MVP架構(gòu)模式保持了代碼的簡單性和可重用性，這反過來又促進(jìn)了更高的可測試性。
通過堅持MVP架構(gòu)的以上幾點，你可以有效地實現(xiàn)它，并利用它的優(yōu)勢為Android開發(fā)更好的移動應(yīng)用。
