全國服務熱線0313-2562332 在線咨詢 留言/需求提交

實戰解析Android架構設計原則

【摘要】好的軟件設計必須能夠幫助開發者發展和擴充解決方案,保持代碼清晰健壯,并且可擴展,易于維護,而不必每件事都重寫代碼。面對軟件存在的問題,必須遵守SOLID原則,不要過度工程化,盡可能降低框架中模塊的依賴性。

嘿!經過一段時間收集了大量反饋意見后,我認為應該來說說這個話題了。我會在這里給出我認為構建現代移動應用(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時。還可以避免“回調的坑”——            它使我們代碼可讀性差,且難以跟進。

  • 數據轉換/組成:在不影響客戶端情況下,我們能夠整合多個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 —— 它是Java的標準模塊。

  • 數據層:將測試組合換成了Robolectric 3 + JUnit + Mockito。這一層的測試曾經存在于單獨的Android模塊。由于當時(當前示例程序的第一個版本)沒有內置單元測試的支持,也沒有建立像 robolectric那樣的框架,該框架比較復雜,需要一群黑客的幫忙才能讓其正常工作。


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

包的組織

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

我們能夠辨別出將應用程序封裝進入包(package)的2個路徑:


  • 按層分包:每一個包(package)中包含的項通常不是彼此密切相關的。這樣包的內聚性低、模塊化程度低,包之間偶合度高。因此,編輯某個特性要編輯來自不同包的文件。另外,單次操作幾乎不可能刪除掉某個功能特性。

  • 按特性分包:用包來體現特性集。把所有相關某一特性(且僅特性相關)的項放入一個包中。這樣包的內聚性高,模塊化程度高,包之間偶合度低。緊密相關的項放在一起。它們沒有分散到整個應用程序中。


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


  • 模塊化程度更高

  • 代碼導航更容易

  • 功能特性的作用域范圍最小化了


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

           
           

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

還需要做的事:組織構建邏輯

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

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


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


               
           

           

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


  • 創建依賴關系圖


           

 

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

結語

到目前為止講了那么多,一句話,要記住沒有靈丹妙藥。但好的軟件架構會幫助代碼保持清晰和健壯,還可以保持代碼的可擴展性,易于維護。

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


  • 遵守SOLID原則

  • 不要過度思考(不過度工程化)

  • 務實

  • 盡可能降低(Android)框架中模塊的依賴性


源代碼


  1. Clean architecture github repository – master branch

  2. Clean architecture github repository – releases


延伸閱讀


  1. Architecting Android..the clean way

  2. Tasting Dagger 2 on Android

  3. The Mayans Lost Guide to RxJava on Android

  4. It is about philosophy: Culture of a good programmer


參考資料


  1. RxJava wiki by Netflix

  2. Framework bound by Uncle Bob

  3. Gradle user guide

  4. Package by feature, not layer

(譯者/張揮戈  友情審校/白云鵬)


聲明: 文章為張家口易誠網絡科技有限公司原創文章,轉載請注明出處,謝謝合作!

文章閱讀推薦

文章排行

2019年以太坊走势分析 白小姐管家婆2018开奖结果 3d开机号开奖 广东时时赚钱吗 2019篮球世界杯赛程表 北京赛车开奖记录 幸运飞艇时间差漏洞 王中王277手机论坛 爱购彩最新版 大快乐时时 成都麻将血战到底 足球比分网即时比分一一 北京pkapp下载 三中三的算法 彩票欢乐生肖041 开心三张官方版 黑龙江十一选五开奖结果