[轉]Android App總體架構設計的思考

 

1. 架構設計的目的

        對程序進行架構設計的緣由，歸根究竟是爲了提升生產力。經過設計使程序模塊化，作到模塊內部的高聚合和模塊之間的低耦合。這樣作的好處是使得程序在開發的過程當中，開發人員只須要專一於一點，提升程序開發的效率，而且更容易進行後續的測試以及定位問題。但設計不能違背目的，對於不一樣量級的工程，具體架構的實現方式必然是不一樣的，切忌犯爲了設計而設計，爲了架構而架構的毛病。舉個簡單的例子，一個Android App若是隻有3個Java文件，那隻須要作點模塊和層次的劃分就能夠，引入框架或者架構反而提升了工做量，下降了生產力。但我當前開發的App最終代碼量應該在10W行以上，本地須要進行復雜操做，同時也須要考慮到與其他的Android開發者以及後臺開發人員之間的同步配合，那就須要在架構上進行一些思考。

2. 基於MVP的架構設計思路

        在App開發過程當中，常常出現的問題就是某一部分的代碼量過大，雖然作了模塊劃分和接口隔離，但也很難徹底避免。從實踐中看到，這更多的出如今UI部分，也就是Activity裏。我曾見過2000+行以上基本不帶註釋的Activity，那時個人第一反應就是想吐。Activity內容過多的緣由其實很好解釋，由於Activity自己須要擔負與用戶之間的操做交互，再加上如今大部分的Activity還對整個App起到控制器的做用，這又帶入了大量的邏輯代碼，形成Activity的臃腫。爲了解決這個問題，咱們引入了MVP框架思路。

2.1 什麼是MVP?

        MVP是一種使用普遍的基礎架構模式，使用基於事件驅動的應用框架。MVP從更早的MVC框架演變過來的一種框架，與MVC有必定的類似性。MVP框架由3部分組成：View負責顯示，Presenter負責邏輯處理，Model提供數據。MVP與MVC之間最主要的區別在控制層上，在MVP框架中，View與Model並不直接交互，全部的交互放在Presenter中；而在MVC裏，View與Model會直接產生必定的交互。MVP的Presenter是框架的控制者，承擔了大量的邏輯操做，而MVC的Controller更多時候承擔一種轉發的做用。所以在App中引入MVP的緣由，是爲了將此前在Activty中包含的大量邏輯操做放到控制層中，避免Activity的臃腫。MVP的變種有不少，其中使用最普遍的是Passive View模式，即被動視圖。在這種模式下，整個框架內部模塊之間的邏輯操做均由Presenter控制，View僅僅是整個操做的彙報者和結果接收者，Model根據Presenter的單向調用返回數據(圖片來自網絡)。而且MVP模式使得View與Model的耦合性更低，下降了Presenter對View的依賴，實現了關注點分離的初衷，方便開發人員的編碼和測試工做。

                                        

        具體到Android App中，我通常將App根據程序的結構進行縱向劃分，對應MVP分別爲模型層，UI層和邏輯層。UI層通常包括Activity，Fragment，Adapter等直接和UI相關的類，UI層的Activity在啓動以後實例化相應的Presenter，App的控制權後移，由UI轉移到Presenter，二者之間的通訊經過BroadCast、Handler或者接口完成，只傳遞事件和結果。舉個簡單的例子，UI層通知邏輯層（Presenter）用戶點擊了一個Button，邏輯層（Presenter）本身決定應該用什麼行爲進行響應，該找哪一個模型（Model）去作這件事，最後邏輯層（Presenter）將完成的結果更新到UI層。

2.2 MVP架構存在的問題

        轉移邏輯操做以後可能部分較爲複雜的Activity內代碼量仍是很多，因而在分層的基礎上再加入模板方法（Template Method）。具體作法是在Activity內部分層。其中最頂層爲BaseActivity，不作具體顯示，而是提供一些基礎樣式，Dialog，ActionBar在內的內容，展示給用戶的Activity繼承BaseActivity，重寫BaseActivity預留的方法。若有必要再進行二次繼承，App中Activity之間的繼承次數最多不超過3次。

        模型層（Model）中的總體代碼量是最大的，通常由大量的Package組成，針對這部分須要作的就是在程序設計的過程當中，作好模塊的劃分，進行接口隔離，在內部進行分層。

        強化Presenter的做用，將全部邏輯操做都放在Presenter內也容易形成Presenter內的代碼量過大，對於這點，個人方法是在UI層和Presenter之間設置中介者Mediator，將例如數據校驗、組裝在內的輕量級邏輯操做放在Mediator中；在Presenter和Model之間使用代理Proxy；經過上述二者分擔一部分Presenter的邏輯操做，但總體框架的控制權仍是在Presenter手中。Mediator和Proxy不是必須的，只在Presenter負擔過大時才建議使用。最終的架構以下圖所示：

                                               

知乎上個人回答連接：從零開始開發一款Android app，前期須要哪些規劃工做避免代碼臃腫混亂？

 

接上文：Android App總體架構設計的思考(一) ，本文主要介紹AOP以及一些快速開發框架。

3 基於AOP的框架設計

        AOP(Aspect-Oriented Programming, 面向切面編程)，誕生於上個世紀90年代，是對OOP(Object-Oriented Programming, 面向對象編程)的補充和完善。OOP引入封裝、繼承和多態性等概念來創建一種對象層次結構，用以模擬公共行爲的一個集合。當咱們須要爲分散的對象引入公共行爲的時候，OOP則顯得無能爲力。也就是說，OOP容許你定義從上到下的關係，但並不適合定義從左到右的關係。例如日誌功能。日誌代碼每每水平地散佈在全部對象層次中，而與它所散佈到的對象的核心功能毫無關係。對於其餘類型的代碼，如安全性、異常處理和透明的持續性也是如此。這種散佈在各處的無關的代碼被稱爲橫切（Cross-Cutting）代碼，在OOP設計中，它致使了大量代碼的重複，而不利於各個模塊的重用。而AOP技術則偏偏相反，它利用一種稱爲「橫切」的技術，剖解開封裝的對象內部，並將那些影響了多個類的公共行爲封裝到一個可重用模塊，並將其名爲「Aspect」，即方面。所謂「方面」，簡單地說，就是將那些與業務無關，卻爲業務模塊所共同調用的邏輯或責任封裝起來，便於減小系統的重複代碼，下降模塊間的耦合度，並有利於將來的可操做性和可維護性。

                                                                  

3.1 AOP在Android中的使用

        AOP把軟件系統分爲兩個部分：核心關注點和橫切關注點。業務處理的主要流程是核心關注點，與之關係不大的部分是橫切關注點。橫切關注點的一個特色是，他們常常發生在覈心關注點的多處，而各處都基本類似。AOP的做用在於分離系統中的各類關注點，將核心關注點和橫切關注點分離開來。在Android App中，哪些是咱們須要的橫切關注點？我的認爲主要包括如下幾個方面：Http, SharedPreferences, Json, Xml, File, Device, System, Log, 格式轉換等。Android App的需求差異很大，不一樣的需求橫切關注點必然是不同的。通常的App工程中應該有一個Util Package來存放相關的切面操做，在項目多了以後能夠將其中使用較多的Util封裝爲一個Jar包供工程調用。

4 總結

        在使用MVP和AOP對App進行縱向和橫向的切割以後，可以使得App總體的結構更清晰合理，避免局部的代碼臃腫，方便開發、測試以及後續的維護。目前不少尚停留在實踐和思想，今年上半年會抽時間寫一個基於MVP、AOP和IOC的Android框架。

 

5 快速開發框架

        目前網絡上也有一些針對Android的快速開發框架，下面介紹3個主要的快速開發框架。針對這些快速開發框架，我的認爲能夠參考，但並不推薦使用，由於App總體依賴一個我的維護的框架風險實在太大，框架存在一些學習成本，自己也不必定徹底符合App的需求，使用後的收益並無想象中大。

5.1 Afinal

        Afinal是一個Android的IOC，ORM框架，內置了四大模塊功能：FinalAcitivity, FinalBitmap, FinalDb, FinalHttp。經過FinalActivity，能夠經過註解的方式進行綁定UI和事件。經過FinalBitmap，能夠方便的加載Bitmap圖片，而無需考慮OOM等問題。經過FinalDB模塊，經過一行代碼就能夠對Android的SQlite數據庫進行增刪改查。經過FinalHttp模塊，能夠以Ajax形式請求Http數據。

GitHub項目地址：Afinal

5.2 xUtils

        xUtils目前主要包括4大模塊：DbUtils, ViewUtils, HttpUtils, BitmapUtils。包含了不少實用的Android工具；支持大文件上傳，更全面的Http請求協議支持，擁有更加靈活的ORM，更多的事件註解支持且不受混淆影響；最低兼容Android 2.2 (Api Level 8)。

GitHub項目地址：xUtils

5.3 ThinkAndroid

        ThinkAndroid是一個免費的開源的、簡易的、遵循Apache2開源協議發佈的Android開發框架，其開發宗旨是簡單、快速的進行 Android應用程序的開發，包含Android MVC、簡易SQlite ORM、IOC模塊、封裝Android HttpClitent的Http模塊, 具備快速構建文件緩存功能，無需考慮緩存文件的格式，均可以很是輕鬆的實現緩存，它還基於文件緩存模塊實現了圖片緩存功能， 在Android中加載的圖片的時候，對OOM的問題，和對加載圖片錯位的問題都輕易解決。他還包括了一個手機開發中常常應用的實用工具類， 如日誌管理，配置文件管理，Android下載器模塊，網絡切換檢測等等工具。

GitHub項目地址：ThinkAndroid

參考目錄： AOP技術基礎

                   從三層架構到MVC, MVP

                   MVC, MVP以及Model2

                   GOF等。