Android App整體架構(gòu)設(shè)計(jì)中培偉業(yè)是國(guó)內(nèi)一流的IT培訓(xùn)機(jī)構(gòu)，每年針對(duì)各種IT技術(shù)在各地開展了相關(guān)培訓(xùn)，Android App架構(gòu)設(shè)計(jì)就是中培的培訓(xùn)內(nèi)容之一。對(duì)于Android App整體架構(gòu)設(shè)計(jì)，中培偉業(yè)的專家組專家們有以下的看法。
1.架構(gòu)設(shè)計(jì)的目的何在
　　對(duì)程序進(jìn)行架構(gòu)設(shè)計(jì)的原因，歸根到底是為了提高生產(chǎn)力。通過設(shè)計(jì)使程序模塊化，做到模塊內(nèi)部的高聚合和模塊之間的低耦合。這樣做的好處是使得程序在開發(fā)的過程中，開發(fā)人員只需要專注于一點(diǎn)，提高程序開發(fā)的效率，并且更容易進(jìn)行后續(xù)的測(cè)試以及定位問題。但設(shè)計(jì)不能違背目的，對(duì)于不同量級(jí)的工程，具體架構(gòu)的實(shí)現(xiàn)方式必然是不同的，切忌犯為了設(shè)計(jì)而設(shè)計(jì)，為了架構(gòu)而架構(gòu)的毛病。舉個(gè)簡(jiǎn)單的例子， 一個(gè)Android App如果只有3個(gè)Java文件，那只需要做點(diǎn)模塊和層次的劃分就可以，引入框架或者架構(gòu)反而提高了工作量，降低了生產(chǎn)力。當(dāng)前開發(fā)的App最終代碼量應(yīng)該在10W行以上，本地需要進(jìn)行復(fù)雜操作，同時(shí)也需要考慮到與其余的Android開發(fā)者以及后臺(tái)開發(fā)人員之間的同步配合，那就需要在架構(gòu)上進(jìn)行一些思考。
2.基于MVP的架構(gòu)設(shè)計(jì)思路
　　在App開發(fā)過程中，經(jīng)常出現(xiàn)的問題就是某一部分的代碼量過大，雖然做了模塊劃分和接口隔離，但也很難完全避免。從實(shí)踐中看到，這更多的出現(xiàn)在UI部分，也就是Activity里。有的專家曾見過2000+行以上基本不帶注釋的Activity，這很容易讓人眼暈。Activity內(nèi)容過多的原因其實(shí)很好解釋，因?yàn)锳ctivity本身需要擔(dān)負(fù)與用戶之間的操作交互，再加上現(xiàn)在大部分的Activity還對(duì)整個(gè)App起到控制器的作用，這又帶入了大量的邏輯代碼，造成Activity的臃腫。MVP框架思路，就是為了解決這一問題而引進(jìn)的。
2.1 什么是MVP?
　　MVP是一種使用廣泛的基礎(chǔ)架構(gòu)模式，使用基于事件驅(qū)動(dòng)的應(yīng)用框架。MVP從更早的MVC框架演變過來的一種框架，與MVC有一定的相似性。MVP框架由3部分組成：View負(fù)責(zé)顯示，Presenter負(fù)責(zé)邏輯處理，Model提供數(shù)據(jù)。MVP與MVC之間最主要的區(qū)別在控制層上，在MVP框架中，View與Model并不直接交互，所有的交互放在Presenter中；而在MVC里，View與Model會(huì)直接產(chǎn)生一定的交互。MVP的Presenter是框架的控制者，承擔(dān)了大量的邏輯操作，而MVC的Controller更多時(shí)候承擔(dān)一種轉(zhuǎn)發(fā)的作用。因此在App中引入MVP的原因，是為了將此前在Activty中包含的大量邏輯操作放到控制層中，避免Activity的臃腫。MVP的變種有很多，其中使用最廣泛的是Passive View模式，即被動(dòng)視圖。在這種模式下，整個(gè)框架內(nèi)部模塊之間的邏輯操作均由Presenter控制，View僅僅是整個(gè)操作的匯報(bào)者和結(jié)果接收者，Model根據(jù)Presenter的單向調(diào)用返回?cái)?shù)據(jù)(圖片來自網(wǎng)絡(luò))。并且MVP模式使得View與Model的耦合性更低，降低了Presenter對(duì)View的依賴，實(shí)現(xiàn)了關(guān)注點(diǎn)分離的初衷，方便開發(fā)人員的編碼和測(cè)試工作。
　　具體到Android App中，我一般將App根據(jù)程序的結(jié)構(gòu)進(jìn)行縱向劃分，對(duì)應(yīng)MVP分別為模型層，UI層和邏輯層。UI層一般包括Activity，F(xiàn)ragment，Adapter等直接和UI相關(guān)的類，UI層的Activity在啟動(dòng)之后實(shí)例化相應(yīng)的Presenter，App的控制權(quán)后移，由UI轉(zhuǎn)移到Presenter，兩者之間的通信通過BroadCast、Handler或者接口完成，只傳遞事件和結(jié)果。舉個(gè)簡(jiǎn)單的例子，UI層通知邏輯層（Presenter）用戶點(diǎn)擊了一個(gè)Button，邏輯層（Presenter）自己決定應(yīng)該用什么行為進(jìn)行響應(yīng)，該找哪個(gè)模型（Model）去做這件事，最后邏輯層（Presenter）將完成的結(jié)果更新到UI層。
2.2 MVP架構(gòu)存在的問題
　　轉(zhuǎn)移邏輯操作之后可能部分較為復(fù)雜的Activity內(nèi)代碼量還是不少，于是在分層的基礎(chǔ)上再加入模板方法（Template Method）。具體做法是在Activity內(nèi)部分層。其中最頂層為BaseActivity，不做具體顯示，而是提供一些基礎(chǔ)樣式，Dialog，ActionBar在內(nèi)的內(nèi)容，展現(xiàn)給用戶的Activity繼承BaseActivity，重寫B(tài)aseActivity預(yù)留的方法。如有必要再進(jìn)行二次繼承，App中Activity之間的繼承次數(shù)最多不超過3次。
模型層（Model）中的整體代碼量是最大的，一般由大量的Package組成，針對(duì)這部分需要做的就是在程序設(shè)計(jì)的過程中，做好模塊的劃分，進(jìn)行接口隔離，在內(nèi)部進(jìn)行分層。
　　強(qiáng)化Presenter的作用，將所有邏輯操作都放在Presenter內(nèi)也容易造成Presenter內(nèi)的代碼量過大，對(duì)于這點(diǎn)，我的方法是在UI層和Presenter之間設(shè)置中介者M(jìn)ediator，將例如數(shù)據(jù)校驗(yàn)、組裝在內(nèi)的輕量級(jí)邏輯操作放在Mediator中；在Presenter和Model之間使用代理Proxy；通過上述兩者分擔(dān)一部分Presenter的邏輯操作，但整體框架的控制權(quán)還是在Presenter手中。Mediator和Proxy不是必須的，只在Presenter負(fù)擔(dān)過大時(shí)才建議使用。最終的架構(gòu)如下圖所示：
　　接上文：Android App整體架構(gòu)設(shè)計(jì)的思考(一) ，本文主要介紹AOP以及一些快速開發(fā)框架。
3.基于AOP的框架設(shè)計(jì)
　　AOP(Aspect-Oriented Programming, 面向切面編程)，誕生于上個(gè)世紀(jì)90年代，是對(duì)OOP(Object-Oriented Programming, 面向?qū)ο缶幊?的補(bǔ)充和完善。OOP引入封裝、繼承和多態(tài)性等概念來建立一種對(duì)象層次結(jié)構(gòu)，用以模擬公共行為的一個(gè)集合。當(dāng)我們需要為分散的對(duì)象引入公共行為的時(shí)候，OOP則顯得無能為力。也就是說，OOP允許你定義從上到下的關(guān)系，但并不適合定義從左到右的關(guān)系。例如日志功能。日志代碼往往水平地散布在所有對(duì)象層次中，而與它所散布到的對(duì)象的核心功能毫無關(guān)系。對(duì)于其他類型的代碼，如安全性、異常處理和透明的持續(xù)性也是如此。這種散布在各處的無關(guān)的代碼被稱為橫切（Cross-Cutting）代碼，在OOP設(shè)計(jì)中，它導(dǎo)致了大量代碼的重復(fù)，而不利于各個(gè)模塊的重用。而AOP技術(shù)則恰恰相反，它利用一種稱為“橫切”的技術(shù)，剖解開封裝的對(duì)象內(nèi)部，并將那些影響了多個(gè)類的公共行為封裝到一個(gè)可重用模塊，并將其名為“Aspect”，即方面。所謂“方面”，簡(jiǎn)單地說，就是將那些與業(yè)務(wù)無關(guān)，卻為業(yè)務(wù)模塊所共同調(diào)用的邏輯或責(zé)任封裝起來，便于減少系統(tǒng)的重復(fù)代碼，降低模塊間的耦合度，并有利于未來的可操作性和可維護(hù)性。
3.1 AOP在Android中的使用
　　AOP把軟件系統(tǒng)分為兩個(gè)部分：核心關(guān)注點(diǎn)和橫切關(guān)注點(diǎn)。業(yè)務(wù)處理的主要流程是核心關(guān)注點(diǎn)，與之關(guān)系不大的部分是橫切關(guān)注點(diǎn)。橫切關(guān)注點(diǎn)的一個(gè)特點(diǎn)是，他們經(jīng)常發(fā)生在核心關(guān)注點(diǎn)的多處，而各處都基本相似。AOP的作用在于分離系統(tǒng)中的各種關(guān)注點(diǎn)，將核心關(guān)注點(diǎn)和橫切關(guān)注點(diǎn)分離開來。在Android App中，哪些是我們需要的橫切關(guān)注點(diǎn)？個(gè)人認(rèn)為主要包括以下幾個(gè)方面：Http, SharedPreferences, Json, Xml, File, Device, System, Log, 格式轉(zhuǎn)換等。Android App的需求差別很大，不同的需求橫切關(guān)注點(diǎn)必然是不一樣的。一般的App工程中應(yīng)該有一個(gè)Util Package來存放相關(guān)的切面操作，在項(xiàng)目多了之后可以將其中使用較多的Util封裝為一個(gè)Jar包供工程調(diào)用。
4.總結(jié)
　　在使用MVP和AOP對(duì)App進(jìn)行縱向和橫向的切割之后，能夠使得App整體的結(jié)構(gòu)更清晰合理，避免局部的代碼臃腫，方便開發(fā)、測(cè)試以及后續(xù)的維護(hù)。目前很多尚停留在實(shí)踐和思想，今年上半年會(huì)抽時(shí)間寫一個(gè)基于MVP、AOP和IOC的Android框架。
5.快速開發(fā)框架
　　目前網(wǎng)絡(luò)上也有一些針對(duì)Android的快速開發(fā)框架，下面介紹3個(gè)主要的快速開發(fā)框架。針對(duì)這些快速開發(fā)框架，個(gè)人認(rèn)為可以參考，但并不推薦使用，因?yàn)锳pp整體依賴一個(gè)個(gè)人維護(hù)的框架風(fēng)險(xiǎn)實(shí)在太大，框架存在一些學(xué)習(xí)成本，本身也不一定完全符合App的需求，使用后的收益并沒有想象中大。
5.1 Afinal
　　Afinal是一個(gè)Android的IOC，ORM框架，內(nèi)置了四大模塊功能：FinalAcitivity, FinalBitmap, FinalDb, FinalHttp。通過FinalActivity，可以通過注解的方式進(jìn)行綁定UI和事件。通過FinalBitmap，可以方便的加載Bitmap圖片，而無需考慮OOM等問題。通過FinalDB模塊，通過一行代碼就可以對(duì)Android的SQlite數(shù)據(jù)庫(kù)進(jìn)行增刪改查。通過FinalHttp模塊，可以以Ajax形式請(qǐng)求Http數(shù)據(jù)。
　　GitHub項(xiàng)目地址：Afinal
5.2 xUtils
　　xUtils目前主要包括4大模塊：DbUtils, ViewUtils, HttpUtils, BitmapUtils。包含了很多實(shí)用的Android工具；支持大文件上傳，更全面的Http請(qǐng)求協(xié)議支持，擁有更加靈活的ORM，更多的事件注解支持且不受混淆影響；最低兼容Android 2.2 (Api Level 8)。
5.3 ThinkAndroid
　　ThinkAndroid是一個(gè)免費(fèi)的開源的、簡(jiǎn)易的、遵循Apache2開源協(xié)議發(fā)布的Android開發(fā)框架，其開發(fā)宗旨是簡(jiǎn)單、快速的進(jìn)行 Android應(yīng)用程序的開發(fā)，包含Android MVC、簡(jiǎn)易SQlite ORM、IOC模塊、封裝Android HttpClitent的Http模塊, 具有快速構(gòu)建文件緩存功能，無需考慮緩存文件的格式，都可以非常輕松的實(shí)現(xiàn)緩存，它還基于文件緩存模塊實(shí)現(xiàn)了圖片緩存功能， 在Android中加載的圖片的時(shí)候，對(duì)OOM的問題，和對(duì)加載圖片錯(cuò)位的問題都輕易解決。他還包括了一個(gè)手機(jī)開發(fā)中經(jīng)常應(yīng)用的實(shí)用工具類， 如日志管理，配置文件管理，Android下載器模塊，網(wǎng)絡(luò)切換檢測(cè)等等工具。