基于Android系統(tǒng)的移動(dòng)應(yīng)用整體架構(gòu)分析與設(shè)計(jì)

于炳虎

摘要：近兩年，隨著智能手機(jī)的普及和移動(dòng)互聯(lián)網(wǎng)的興起，帶動(dòng)了移動(dòng)應(yīng)用市場(chǎng)的快速發(fā)展，移動(dòng)APP逐漸成為互聯(lián)網(wǎng)用戶新入口，重要性越來(lái)越突出，用戶對(duì)APP產(chǎn)品的功能性和非功能性的要求也越來(lái)越高。然而，隨著大批APP應(yīng)用的涌入市場(chǎng)，問(wèn)題卻逐漸凸顯，眾多APP架構(gòu)的先天不足直接影響了產(chǎn)品的功能性和穩(wěn)定性，逐漸成為APP長(zhǎng)期發(fā)展的瓶頸。本文從APP整體架構(gòu)角度，將分析與設(shè)計(jì)相結(jié)合，闡述如何進(jìn)行移動(dòng)應(yīng)用的整體構(gòu)建，為后續(xù)廣大移動(dòng)應(yīng)用領(lǐng)域的APP開(kāi)發(fā)者奠定架構(gòu)基礎(chǔ)，提供參考價(jià)值。

關(guān)鍵詞：APP應(yīng)用；整體架構(gòu)；架構(gòu)設(shè)計(jì)

中圖分類號(hào)：TP311.52 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1007-9416（2017）01-0133-03

1 引言

移動(dòng)互聯(lián)網(wǎng)技術(shù)的不斷創(chuàng)新，帶動(dòng)了移動(dòng)互聯(lián)網(wǎng)市場(chǎng)的快速蓬勃發(fā)展。凱度中國(guó)觀察最近發(fā)布了2016年前三季度移動(dòng)操作系統(tǒng)占有率報(bào)告，該報(bào)告顯示，全球Android手機(jī)的市場(chǎng)份額上升至87.5%，用戶的海量增長(zhǎng)，致使APP應(yīng)用市場(chǎng)“一片繁榮”，新的App更是層出不窮，今年1月份的數(shù)據(jù)顯示，以Android系統(tǒng)為主的Google Play應(yīng)用商店，APP數(shù)量超過(guò)140萬(wàn)，我們的日常生活已然被移動(dòng)APP淹沒(méi)了，越來(lái)越多的APP改變了人們以往的生活方式和消費(fèi)方式。

APP應(yīng)用軟件數(shù)量已經(jīng)多到不可計(jì)數(shù)，并且每天還有數(shù)以萬(wàn)計(jì)的APP軟件不斷上新到應(yīng)用市場(chǎng)，但是很多APP產(chǎn)品較為注重眼前利益，只注重前期用戶的快速積累和圈錢，而APP在設(shè)計(jì)開(kāi)發(fā)之初，沒(méi)有重視產(chǎn)品的功能架構(gòu)與后期的更新維護(hù)，導(dǎo)致產(chǎn)品在功能、性能和穩(wěn)定性等方面存在很大的問(wèn)題和隱患，用戶在使用的過(guò)程中體驗(yàn)較差，用戶粘性較低，用戶逐漸流失。為此，本文提出一套基于Android系統(tǒng)的APP開(kāi)發(fā)整體架構(gòu)方案，旨在提高App產(chǎn)品的整體質(zhì)量和用戶體驗(yàn)，為后續(xù)廣大移動(dòng)應(yīng)用領(lǐng)域的APP開(kāi)發(fā)者奠定架構(gòu)基礎(chǔ)。

2 UI架構(gòu)設(shè)計(jì)模式分析

移動(dòng)產(chǎn)品的用戶體驗(yàn)和交互體驗(yàn)可以說(shuō)是這個(gè)產(chǎn)品的靈魂，UI作為與用戶最為直接的交互層，直接影響著用戶的使用體驗(yàn)，而這里的UI架構(gòu)包含的不僅僅只是展示層，還有業(yè)務(wù)層和數(shù)據(jù)層，這是一個(gè)完整的UI架構(gòu)體系。Android應(yīng)用開(kāi)發(fā)的UI架構(gòu)設(shè)計(jì)模式歷經(jīng)了MVC、MVP到MVVM的演進(jìn)，前期的架構(gòu)設(shè)計(jì)承載著整個(gè)軟件的設(shè)計(jì)思想和關(guān)鍵決策，架構(gòu)模式是面向開(kāi)發(fā)者的，它在一定程度上存在性能的損耗，但在開(kāi)發(fā)過(guò)程中具有更好的代碼可閱讀性、可測(cè)試性和可維護(hù)性。

2.1 MVC

MVC全名是Model View Controller，是模型（Model）、視圖（View）、控制器（Controller）的縮寫(xiě)，是軟件架構(gòu)中最常見(jiàn)的一種框架，并且是經(jīng)典的框架模式之一，它在多個(gè)開(kāi)發(fā)領(lǐng)域中都有廣泛的應(yīng)用，尤其在Java EE領(lǐng)域。MVC簡(jiǎn)單來(lái)說(shuō)就是通過(guò)Controller的控制去操作Model層的數(shù)據(jù)，并且返回給View層展示，MVC架構(gòu)設(shè)計(jì)見(jiàn)圖1所示。

MVC模式的最大優(yōu)勢(shì)是將視圖的展示與數(shù)據(jù)處理和業(yè)務(wù)邏輯相分離，視圖層只需關(guān)注UI的展示。在Android應(yīng)用開(kāi)發(fā)中，業(yè)務(wù)邏輯和數(shù)據(jù)處理等擔(dān)任了Model角色，XML布局文件等擔(dān)任了View角色，Activity和Fragment擔(dān)任了Controller角色。控制器的角色可以看作一個(gè)中間橋梁的作用，通過(guò)接口通信來(lái)協(xié)同 View（視圖）和Model（模型）工作，起到了兩者之間的通信作用?？刂破鬟€起到了一定解耦的作用，將View視圖和Model模型分離，但是在Activity中依然有很多關(guān)于視圖UI的顯示代碼，可見(jiàn)View視圖和Activity控制器并不是完全分離的，也就是說(shuō)一部分View視圖和Controller控制器Activity是綁定在一個(gè)類中的。

MVC在Web開(kāi)發(fā)中使用極為廣泛，但使用在Android中，問(wèn)題還是較多的，xml布局文件作為視圖層，控制能力較弱，如果動(dòng)態(tài)的去改變界面，只能把代碼寫(xiě)在Activity中，這就造成了Activity既是Controller層，又是View層的這樣一個(gè)窘境。MVC還有一個(gè)重要的缺陷，圖1可以看到，View層和Model層是相互可知的，這意味著兩層之間存在耦合，雖然控制器起到了一定的解耦作用，但也只是在一定程度上，耦合對(duì)于一個(gè)大型程序來(lái)說(shuō)是非常致命的，因?yàn)檫@表示開(kāi)發(fā)，測(cè)試，維護(hù)都需要花大量的精力。

2.2 MVP

MVP是模型（Model）、視圖（View）、主持人（Presenter）的縮寫(xiě)，分別代表項(xiàng)目中3個(gè)不同的模塊。MVP作為MVC的演化，更適用在移動(dòng)應(yīng)用的開(kāi)發(fā)中，解決了MVC存在的缺點(diǎn)，對(duì)于Android來(lái)說(shuō)，MVP的Model層相對(duì)于MVC是一樣的，而Activity和Fragment不再是Controller層，而是純粹的View層，所有關(guān)于用戶事件的轉(zhuǎn)發(fā)全部交由Presenter層處理。

圖2是MVP的設(shè)計(jì)模式圖，從圖中可以看出，與MVC最明顯的差別就是View層和Model層是不連通的，做到了完全的解耦，當(dāng)View層某個(gè)界面需要展示某些數(shù)據(jù)的時(shí)候，首先會(huì)調(diào)用Presenter層的接口，然后Presenter層會(huì)調(diào)用Model層請(qǐng)求數(shù)據(jù)，當(dāng)Model層數(shù)據(jù)加載成功之后會(huì)調(diào)用Presenter層的回調(diào)方法通知Presenter層數(shù)據(jù)加載完畢，最后Presenter層再調(diào)用View層的接口將加載后的數(shù)據(jù)展示給用戶。這就是MVP模式的整個(gè)核心過(guò)程。

在整個(gè)過(guò)程中，Presenter層充當(dāng)了橋梁的作用，View層和Model層完全沒(méi)有聯(lián)系。在層與層的通信交互中，主要是通過(guò)接口和回調(diào)機(jī)制實(shí)現(xiàn)的。這樣分層的好處就是大大減少了Model與View層之間的耦合度。一方面可以使得View層和Model層單獨(dú)開(kāi)發(fā)與測(cè)試，互不依賴。另一方面Model層可以封裝復(fù)用，可以極大的減少代碼量。不僅如此，還可以編寫(xiě)測(cè)試用的View，模擬用戶的各種操作，從而實(shí)現(xiàn)對(duì)Presenter的測(cè)試。在MVC模式中測(cè)試和維護(hù)較難解決的問(wèn)題，在MVP中都解決了。

2.3 MVVM

Android應(yīng)用中的MVVM是在2015年Google的IO大會(huì)上推出的。提到MVVM，大多數(shù)開(kāi)發(fā)者都會(huì)想Data Binding，Data Binding是Google官方推出的一個(gè)基于MVVM設(shè)計(jì)模式實(shí)現(xiàn)的框架，MVVM可以實(shí)現(xiàn)視圖和邏輯代碼的超級(jí)解耦，按照Google的說(shuō)法，使用了MVVM的開(kāi)發(fā)模式，還可以提高布局文件的解析速度。從圖3中可以看到，MVVM和MVP的結(jié)構(gòu)上區(qū)別不大，Presenter層換成了ViewModel層，View層和ViewModel層是相互綁定的關(guān)系，這意味著當(dāng)更新ViewModel層的數(shù)據(jù)的時(shí)候，View層的UI會(huì)相應(yīng)的變動(dòng)。

在MVVM設(shè)計(jì)模式中，通過(guò)ViewModel和View的映射，完成了View和Model的雙向綁定。View的事件直接傳遞到ViewModel，ViewModel去對(duì)Model進(jìn)行操作并接受更新。進(jìn)而反饋到View上。相比于MVP去掉了Presenter，但View層略顯過(guò)重，同時(shí)View的復(fù)用成為了一個(gè)新的問(wèn)題。

2.4 分析比較

經(jīng)過(guò)上面的分析，可見(jiàn)MVC已不太適用Android等移動(dòng)應(yīng)用的開(kāi)發(fā)設(shè)計(jì)中了，相比來(lái)說(shuō)MVP和MVVM是更適合在移動(dòng)應(yīng)用的開(kāi)發(fā)中使用，MVP和MVVM這兩個(gè)MVC的升級(jí)延續(xù)孰優(yōu)孰劣，并沒(méi)有結(jié)論，還是要根據(jù)具體的項(xiàng)目、具體產(chǎn)品來(lái)分析。

3 整體架構(gòu)的設(shè)計(jì)與實(shí)現(xiàn)

優(yōu)秀的APP架構(gòu)應(yīng)該具有清晰的層次劃分，功能模塊劃分和業(yè)務(wù)邏輯劃分，同一層模塊間充分解耦，模塊內(nèi)部高內(nèi)聚，各分層設(shè)計(jì)符合面向?qū)ο笤O(shè)計(jì)六大原則，提高程序的封裝性、復(fù)用性、可維護(hù)性，最后應(yīng)該在功能，性能，穩(wěn)定性等方面達(dá)到綜合最優(yōu)?；诖耍珹PP架構(gòu)可分為四層，如圖4所示，最頂層是應(yīng)用層，是面向用戶的第一層，然后是應(yīng)用組件層，提供了封裝組件服務(wù)，再下是基礎(chǔ)組件層，為APP提供基礎(chǔ)功能組件，最下面是系統(tǒng)層，直接面向系統(tǒng)底層開(kāi)發(fā)。

3.1 應(yīng)用層

應(yīng)用層專注于業(yè)務(wù)領(lǐng)域的實(shí)現(xiàn)，與需求的業(yè)務(wù)功能關(guān)聯(lián)，直接面向用戶，是用戶對(duì)產(chǎn)品感知的第一層，應(yīng)用層包含以下細(xì)分的三層，如圖5所示。

（1）視圖層，與用戶直接交互的界面，是用戶和系統(tǒng)之間交流的橋梁，它一方面為用戶提供了交互的工具，另一方面也為顯示和數(shù)據(jù)處理實(shí)現(xiàn)了一定的邏輯，協(xié)調(diào)用戶和系統(tǒng)的操作。（2）業(yè)務(wù)層，包含了APP需要的所有功能上的算法和邏輯處理，并與數(shù)據(jù)層和視圖層交互。抽象的說(shuō)，業(yè)務(wù)層是處理與業(yè)務(wù)相關(guān)的部分，包含一系列的執(zhí)行與數(shù)據(jù)的操作。（3）數(shù)據(jù)層，提供訪問(wèn)數(shù)據(jù)的功能，在分層設(shè)計(jì)中，所有讀取數(shù)據(jù)或?qū)懭霐?shù)據(jù)的工作都屬于這一層的任務(wù)，不做過(guò)多的數(shù)據(jù)邏輯處理，操作的是非原始數(shù)據(jù)。

3.2 應(yīng)用組件層

應(yīng)用組件層為上層封裝業(yè)務(wù)功能，以服務(wù)的表現(xiàn)形式提供，不涉及UI和平臺(tái)的特性，應(yīng)用組件層的服務(wù)是獨(dú)立的，可移植的，不依賴特定的開(kāi)發(fā)和使用環(huán)境，如圖6所示，主要包括有社交分享、推送服務(wù)、掃碼組件、鍵盤組件、手勢(shì)密碼等。

3.3 基礎(chǔ)組件層

基礎(chǔ)組件是相對(duì)于業(yè)務(wù)功能來(lái)說(shuō)的，它是對(duì)復(fù)用率比較高的代碼的一種抽離，它提供APP的公有特性，實(shí)現(xiàn)依賴特定的平臺(tái)環(huán)境，這一層也是用戶對(duì)產(chǎn)品的一種感知，這種感知表現(xiàn)在穩(wěn)定性、性能等方面，直接關(guān)系到產(chǎn)品的用戶體驗(yàn)。如圖7所示主要包括有數(shù)據(jù)庫(kù)操作、網(wǎng)絡(luò)通信處理、日志記錄、圖片緩存、數(shù)據(jù)解析（JSON/XML）、加解密等。

3.4 系統(tǒng)層

系統(tǒng)層主要是基于底層的一些系統(tǒng)模塊，如圖8所示，主要包括進(jìn)程通信、線程管理、內(nèi)存管理、消息處理等，在Android APP的開(kāi)發(fā)中，進(jìn)程和內(nèi)存的管理是較難處理的，Android采取了一種有別于Linux的進(jìn)程管理策略，在進(jìn)程活動(dòng)停止后并不立刻結(jié)束該進(jìn)程，Android把這些進(jìn)程都保留在內(nèi)存中，直到系統(tǒng)需要更多內(nèi)存為止。這些保留在內(nèi)存中的進(jìn)程通常情況下不會(huì)影響整體系統(tǒng)的運(yùn)行速度，并且當(dāng)用戶再次激活這些進(jìn)程時(shí)，提升了進(jìn)程的啟動(dòng)速度，Android其實(shí)已經(jīng)為開(kāi)發(fā)者做好了很多事情，系統(tǒng)層的開(kāi)發(fā)應(yīng)多參考源碼標(biāo)準(zhǔn)。

4 關(guān)鍵技術(shù)實(shí)現(xiàn)

4.1 應(yīng)用層

應(yīng)用層作為與用戶交互的第一層，直接影響著用戶的交互體驗(yàn)，因此采用成熟的設(shè)計(jì)框架更為穩(wěn)妥，本文分析了Android中常用的UI設(shè)計(jì)架構(gòu)模式，MVC的設(shè)計(jì)思想是從Model出發(fā)，而沒(méi)有考慮到View端的復(fù)雜性，這樣導(dǎo)致的問(wèn)題是Model難以符合復(fù)雜多變的View端變化。相對(duì)這點(diǎn)，MVP和MVVM就要好得多。它們都獨(dú)立出了Presenter 和ViewModel來(lái)對(duì)應(yīng)每個(gè)View。MVP模式是一個(gè)真正意義上的隔離View的細(xì)節(jié)和復(fù)雜性的模式，在MVP模式中的V代表的是一個(gè)接口，一個(gè)將UI界面提煉而抽象出來(lái)的接口。接口意味著任何實(shí)現(xiàn)了該接口的界面，都能夠復(fù)用已有的Presenter和Model代碼。在MVVM模式中，一個(gè)ViewModel和一個(gè)View匹配，它沒(méi)有MVP中的IView接口，而是完全的和View綁定，所有View中的修改變化，都會(huì)自動(dòng)更新到ViewModel中，同時(shí)ViewModel的任何變化也會(huì)自動(dòng)同步到View上顯示。MVP與MVVM兩者沒(méi)有嚴(yán)格的好壞之分，在具體選擇實(shí)現(xiàn)時(shí)，還是要要具體分析APP的需求復(fù)雜度和具體的業(yè)務(wù)場(chǎng)景。

4.2 應(yīng)用組件層

應(yīng)用組件層為上層封裝業(yè)務(wù)功能，以服務(wù)的表現(xiàn)形式提供，社交分享、推送服務(wù)等，它們的實(shí)現(xiàn)最簡(jiǎn)單的方式就是使用第三方平臺(tái)，具體的整合，第三方平臺(tái)都已經(jīng)提供了很完善的API接口文檔。同時(shí)補(bǔ)充一點(diǎn)，事件總線也分布在此層，在Android系統(tǒng)中，事件總線簡(jiǎn)化了Activity、Fragment、Service等組件之間的交互，很大程度上降低了它們之間的耦合，使得我們的代碼更加簡(jiǎn)潔，耦合性更低，提升我們的代碼質(zhì)量。

4.3 基礎(chǔ)組件層

基礎(chǔ)組件層提供APP的公有特性，數(shù)據(jù)庫(kù)操作是應(yīng)盡量使用ORM框架，ORM是一種程序設(shè)計(jì)技術(shù)，用于實(shí)現(xiàn)面向?qū)ο缶幊陶Z(yǔ)言里不同類型系統(tǒng)的數(shù)據(jù)之間的轉(zhuǎn)換?，F(xiàn)在較為成熟的是ORMLite與GreenDao。網(wǎng)絡(luò)、圖片、JSON等的處理，依靠成熟的框架是較為明智的選擇。日志記錄是一個(gè)基礎(chǔ)且極為重要的組件，可幫助開(kāi)發(fā)人員代碼調(diào)試，快速錯(cuò)誤定位，Android系統(tǒng)中提供了Log類來(lái)記錄日志，使用起來(lái)方便簡(jiǎn)單，也可以使用功能更為強(qiáng)大的開(kāi)源日志記錄庫(kù)Logger，具體的選擇依賴于開(kāi)發(fā)者的使用習(xí)慣。

4.4 系統(tǒng)層

系統(tǒng)層的開(kāi)發(fā)更偏向于Linux環(huán)境開(kāi)發(fā)，Android系統(tǒng)是以Linux內(nèi)核為基礎(chǔ)，所以對(duì)于進(jìn)程的管理自然離不開(kāi)Linux本身提供的機(jī)制。在Android系統(tǒng)中，進(jìn)程可以大致分為系統(tǒng)進(jìn)程和應(yīng)用進(jìn)程兩大類，開(kāi)發(fā)者更多關(guān)注的是應(yīng)用進(jìn)程，Android應(yīng)用程序是通過(guò)消息來(lái)驅(qū)動(dòng)的，系統(tǒng)為每一個(gè)應(yīng)用程序維護(hù)一個(gè)消息隊(duì)列，應(yīng)用程序的主線程不斷地從這個(gè)消息隊(duì)列中獲取消息，然后對(duì)這些消息進(jìn)行處理，這樣就實(shí)現(xiàn)了通過(guò)消息來(lái)驅(qū)動(dòng)應(yīng)用程序的執(zhí)行。系統(tǒng)層的開(kāi)發(fā)實(shí)現(xiàn)，Android提供了較為豐富的實(shí)現(xiàn)方式，包括上層Java的封裝實(shí)現(xiàn)，和下層C/C++的底層實(shí)現(xiàn)。本文不再詳細(xì)介紹。

5 結(jié)語(yǔ)

本文通過(guò)一系列的分層與整合，剝離和組合等方式優(yōu)化了APP應(yīng)用的整體架構(gòu)，在關(guān)鍵技術(shù)實(shí)現(xiàn)上，本文也給出了一定的技術(shù)指導(dǎo)。在應(yīng)用的設(shè)計(jì)開(kāi)發(fā)中使用分層架構(gòu)模式，一方面能提高APP的功能性、穩(wěn)定性和可維護(hù)性，另一方面提高了用戶的產(chǎn)品使用體驗(yàn)，這樣才能促使APP產(chǎn)品長(zhǎng)期發(fā)展下去。