根據實際項目淺談Android項目中的搭建簡單的框架

轉載:https://silencedut.github.io/2016/12/05/%E6%A0%B9%E6%8D%AE%E5%AE%9E%E9%99%85%E9%A1%B9%E7%9B%AE%E6%B5%85%E8%B0%88Android%E9%A1%B9%E7%9B%AE%E4%B8%AD%E7%9A%84%E6%A1%86%E6%9E%B6%E6%90%AD%E5%BB%BA/

此構架待優化,不要參考!!!

重構中…

這是知天氣實踐中的架構搭建方式,建議先下載應用【應用寶,或騰訊bugly分發平臺】體驗下,以免浪費你的時間O(∩_∩)O~~。

項目的構架搭建過程包括MVP的使用,MVP使用中P層的組織,Model層的管理,以及劃分P層和Model層的理解。除了項目的框架部分,結構分包方式也很重要,一個好的分包方式能讓項目更加清晰,開發過程也會更有效率。除此之外,再加上一些第三方開源框架就能很好的搭建出一個Android應用了。

MVP的使用(縱向)

關於MVP的介紹和優點分析的文章很多,可以自行google。主要分析項目中的應用。

MVC

MVC全名是Model View Controller,如圖,是模型(model)-視圖(view)-控制器(controller)的縮寫

MVC是一種軟件設計典範,用一種業務邏輯、數據、界面顯示分離的方法組織代碼,在改進和個性化定製界面及用戶交互的同時,不需要重新編寫業務邏輯。MVC是一種很被廣泛使用的框架,但在Android開發中,Activity並不是一個標準的MVC模式中的Controller,它的首要職責是加載應用的佈局和初始化用戶界面,並接受並處理來自用戶的操作請求,進而作出響應。隨着界面及其邏輯的複雜度不斷提升,Activity類的職責不斷增加,以致變得龐大臃腫。

MVP

MVP從更早的MVC框架演變過來,與MVC有一定的相似性:Controller/Presenter負責邏輯的處理,Model提供數據,View負責顯示。可以看做MVP就是將MVC中Controller更加細分開來,減少Controller的體積,這很好理解,如果一個類過於龐大,不妨在將其細分,除此之外將View和Model的通信隔絕,都通過Presenter來傳遞。

這裏箭頭的指向值得是依賴關係,Model不應該依賴上層的邏輯,所以應該是單向的。

MVP在Android中的體現

  • View:負責繪製UI元素、與用戶進行交互(在Android中體現爲Activity,frament等等)
  • Model:負責存儲、檢索、操縱數據(有時也實現一個Model interface用來降低耦合)
  • Presenter:作爲View與Model交互的中間紐帶,處理與用戶交互的負責邏輯。
  • *View interface:需要View實現的接口,View通過View interface與Presenter進行交

使用

上面的框架只是一些理論式的知識,具體的應用中還需要更加詳細的設計,如:

  • Presenter具體是什麼,該怎麼和View層交互
  • Model層和Presenter怎麼劃分,怎麼管理
  • 對應到Android項目中的生命週期是怎樣的
  • 不同層之間的通信方式
  • 使用中應該注意什麼

Presenter其實就是一些普通的類,只是負責將View層(Activity等)中的只和當前View的業務邏輯放在這一層來避免隨着業務的增多導致View層過大,如很多應用的主界面,然後通過接口來和View交互。生命週期也應該和View保持一致。並要注意避免由於持有View的引用而導致View結束時內存泄露的產生。

Presenter層和Model的劃分問題,經常見到的說法是Model層應用於封裝與應用程序的業務邏輯相關的數據以及對數據的處理方法,如數據的存儲與獲取等。這種說法沒什麼問題,但是和Presenter在一起使用的時候容易讓人迷惑,Presenter也是處理邏輯,Model也是處理邏輯,那應該怎麼區別呢,我的理解是看這些邏輯能否被共用,如果能被多個View或Presenter共用,那這部分邏輯應該放到model層,否則應該在Presenter。Model由於共用的原因,所以其生命週期應該和應用的生命週期保持一致,而寫需要一個管理類ModelManager來統一管理。

對於View層與Presenter層,通過接口的方式進行通信,所以View與Presenter是強依賴關係,是共同存在。而Presenter層與Model層則是通過事件總線庫如EventBus,我是用的Router,主要是用起來更方便。這樣Presenter層與Model層關係是弱依賴,因爲它們的生命週期不同,而且一個Model肯需要對多個Presenter服務。

下面是總結出來的框架圖:

結合上面的圖在總結一下,Presenter應該是單一職責的,只用於處理一個View的邏輯,而一個View可以有多個Presenter,以避免如果View中邏輯過多而導致單個Presenter過於龐大臃腫。而Model層應該被共用,以體現其複用性。

在實際的使用中應該注意的是:

1.不要死板的按照這個框架,不是任何View都需要一個Presenter,有些View可能只是個很簡單的頁面,再去寫個Presenter就真的爲了框架而框架了,這時候框架對你的開發起到的反而是阻礙作用。

2.注意Presenter持有View導致的內存泄露問題,因爲二者是強依賴關係,所以在View相應的生命週期對Presenter進行綁定和解綁,也可以通過若引用來持有View對象,但我覺的這是可以自己來避免的,用若引用來處理的方式是一種不好的思想。

MVP搭建的縱向的框架,橫向的分割依據AOP面向切面的思想,主要是提取出共用方法作爲一個單獨的Util,這些Util會在App整體中穿插使用。很多人的App都會引入自己封裝的Jar包,封裝了包括文件、JSON、SharedPreference等在內的常用操作,自己寫的用起來順手,也大幅度降低了重複作業。

項目劃分方式

框架搭好後,還需要好的分包方式來管理,我偏向於先根據模塊劃分,然後在不同的模塊裏在再按邏輯劃分。這樣可以很好的使項目模塊化,而且開發的時候更方便。

不要畏懼構架,也不要過度設計,具體過度設計的度,可能就需要經驗了,但不實踐,永遠也不會有這個經驗。

知天氣已開源。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章