最實用的Android架構設計原則是什么

最實用的Android架構設計原則是什么，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

開始之前，假設你已經閱讀過我之前撰寫的文章“ Architecting Android…The clean way ?”。如果還沒有閱讀過，為了更好地理解這篇文章，應借此機會讀一讀：

架構演變

演變意味著一個循序漸進的過程，由某些狀態改變到另一種不同的狀態，且新狀態通常更好或更復雜。

照這么一說，軟件是隨著時間發展和改變的，是架構上的發展和改變。實際上，好的軟件設計必須能夠幫助我們發展和擴充解決方案，保持其健壯性，而不 必每件事都重寫代碼（雖然在某些情況下重寫的方法更好，但是那是另一篇文章的話題，所以相信我，讓我們聚焦在前面所討論的話題上）。

在這篇文章中，我將講解我認為是必需的和重要的要點，為了保持基本代碼條理清晰，要記住下面這張圖片，我們開始吧！

響應式方法：RxJava

因為已經 有很多這方面的文章 ，還有這方面 做得很好、令人景仰的人 ，所以我不打算在這里討論RxJava的好處（ 我假設您已經對它有所體驗了 ）。但是，我將指出在Android應用程序開發方面的有趣之處，以及如何幫助我形成***個清晰的架構的方法。

首先，我選擇了一種響應式的模式通過轉換usecase（在這個清晰的架構命名規則中，其被稱為interactor）返回Observables<T>，表示所有底層都遵循這一鏈條，也返回Observables<T> 。

正如你所看到的，所有用例繼承這個抽象類，并實現抽象方法buildUseCaseObservable()。該方法將建立一個Observables<T>，它承擔了繁重的工作，還要返回所需的數據。

需要強調是，在execute()方法中，要確保Observables<T> 是在獨立線程執行，因此，要盡可能減輕阻止android主線程的程度。其結果就是會通過android主線程調度程序將主線程壓入線程隊列的尾部（push back）。

到目前為止，我們的Observables<T>啟動并且運行了。但是，正如你所知，必須要觀察它所發出的數據序列。要做到這一點， 我改進了presenters（MVP模式表現層的一部分），把它變成了觀察者（Subscribers），它通過用例對發出的項目做出“react”， 以便更新用戶界面。

觀察者是這樣的：

每個觀察者都是每個presenter的內部類，并實現了一個Defaultsubscriber<T>接口，創建了基本的默認錯誤處理。

將所有的片段放在一起后，通過下面的圖，你可以獲得完整的概念：

讓我們列舉一些擺脫基于RxJava方法的好處：

在觀察者（Subscribers）與被觀察者（Observables）之間去耦合：更加易于維護和測試。

簡化異步任務：如果要求多個異步執行時，如果需要一個以上異步執行的級別，Java的thread和future的操作和同步比較復雜，因此 通過使用調度程序，我們可以很方便地（不需要額外工作）在后臺與主線程之間跳轉，特別是當我們需要更新UI時。還可以避免“回調的坑”&mdash;&mdash; 它使我們代碼可讀性差，且難以跟進。
數據轉換/組成：在不影響客戶端情況下，我們能夠整合多個Observables<T>，使解決方案更靈活。
錯誤處理：在任何Observables<T>內發生錯誤時，就向消費者發出信號。

從我的角度看有一點不足，甚至要為此需要付出代價，那些還不熟悉概念的開發人員還是要遵循學習曲線。但你從中得到了極有價值的東西。為了成功而reactive起來吧！
依賴注入：Dagger 2

關于依賴注入， 因為我已經寫了一篇完整的文章 ，我不想說太多。強烈建議你閱讀它，這樣我們就可以接著說下面的內容了。

值得一提的是，通過實現一個像Dagger 2那樣的依賴注入框架我們能夠獲得：

組件重用，因為依賴的對象可以在外部注入和配置。
當注入對象作為協作者（collaborators）時，由于對象的實例存在于在一個隔離和解耦地方，這樣在我們的代碼庫中，就不需要做很多的改變，就可以改變任何對象的實現。
依賴可以注入到一個組件：這些將這些模擬實現的依賴對象注入成為可能，這使得測試更容易。

Lambda表達式：Retrolambda

沒有人會抱怨在代碼中使用Java 8的lambada表達式，甚至在簡化并擺脫了很多樣板代碼以后，使用得更多，如你看到這段代碼：

然而，我百感交集，為什么呢？我們曾在 @SoundCloud 討論 Retrolambada ，主要是是否使用它，結果是：

1. 贊成的理由：

Lambda表達式和方法引用
“try-with-resources”語句
使用karma做開發

2. 反對的理由：

Java 8 API的意外使用
十分令人反感的第三方庫
要與Android一起使用的第三方插件Gradle

***，我們認定它不能為我們解決任何問題：你的代碼看起來很好且具有可讀性，但這不是我們與之共存的東西，由于現在所有功能***大的IDE都包含代碼折疊式選項，這就涵蓋這一需求了，至少是一個可接受的方式。

說實話，盡管我可能會在業余時間的項目中使用它，但在這里使用它的主要原因是嘗試和體驗Android中Lambda表達式。是否使用它由你自己決定。在這里我只是展示我的視野。當然，對于這樣一個了不起的工作，這個 庫 的作者值得我的稱贊。
測試方法

在測試方面，與示例的***個版本相關的部分變化不大：

表現層：用Espresso 2和Android Instrumentation測試框架測試UI。
領域層：JUnit + Mockito &mdash;&mdash; 它是Java的標準模塊。
數據層：將測試組合換成了Robolectric 3 + JUnit + Mockito。這一層的測試曾經存在于單獨的Android模塊。由于當時（當前示例程序的***個版本）沒有內置單元測試的支持，也沒有建立像 robolectric那樣的框架，該框架比較復雜，需要一群黑客的幫忙才能讓其正常工作。

幸運的是，這都是過去的一部分，而現在所有都是即刻可用，這樣我可以把它們重新放到數據模塊內，專門為其默認的測試路徑：src/test/java。
包的組織

我認為一個好的架構關鍵因素之一是代碼/包的組織：程序員瀏覽源代碼遇到的***件事情就是包結構。一切從它流出，一切依賴于它。

我們能夠辨別出將應用程序封裝進入包（package）的2個路徑：

按層分包：每一個包（package）中包含的項通常不是彼此密切相關的。這樣包的內聚性低、模塊化程度低，包之間偶合度高。因此，編輯某個特性要編輯來自不同包的文件。另外，單次操作幾乎不可能刪除掉某個功能特性。
按特性分包：用包來體現特性集。把所有相關某一特性（且僅特性相關）的項放入一個包中。這樣包的內聚性高，模塊化程度高，包之間偶合度低。緊密相關的項放在一起。它們沒有分散到整個應用程序中。

我的建議是去掉按特性分包，會帶來的好處有以下主要幾點：

模塊化程度更高
代碼導航更容易
功能特性的作用域范圍最小化了

如果與功能特性團隊一起工作（就像我們在@SoundCloud的所作所為），也會是非常有趣的事情。代碼的所有權會更容易組織，也更容易被模塊化。在許多開發人員共用一個代碼庫的成長型組織當中，這是一種成功。

如你所見，我的方法看起來就像按層分包：這里我可能會犯錯（例如，在“users”下組織一切），但在這種情況下我會原諒自己，因為這是個以學習為目的的例子，而且我想顯示的是清晰架構方法的主要概念。領會其意，切勿盲目模仿:-)。
還需要做的事：組織構建邏輯

我們都知道，房子是從地基上建立起來的。軟件開發也是這樣，我想說的是，從我的角度來看，構建系統（及其組織）是軟件架構的重要部分。

在Android平臺上，我們采用Gradle，它事實上是一種與平臺無關的構建系統，功能非常強大。這里的想法是通過一些提示和技巧，讓你組織構建應用程序時能夠得到簡化。

在單獨的gradle構建文件中按功能對內容進行分組

因此，你可以用“apply from: &lsquo;buildsystem/ci.gradle&rsquo;”插入到任何Gradle建立的文件中進行配置。不要把所有都放置在一個build.gradle文件中，否則就是去創建一個怪物，這是教訓。

創建依賴關系圖

如果想在項目的不同模塊間重用相同的組件版本，這很好；否則就要在不同的模塊間使用不同的版本的組件依賴。另外一點，你是在同一個地方控制依賴關系，像組件版本發生沖突這樣的事情一眼就能看出來。
結語

我想指出一些事情。面對軟件存在的問題，要報以本應當解決的態度：

遵守SOLID原則
不要過度思考（不過度工程化）
務實
盡可能降低（Android）框架中模塊的依賴性

看完上述內容，你們掌握最實用的Android架構設計原則是什么的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！