基于Android系統的移動應用整體架構分析與設計

于炳虎

摘要：近兩年，隨著智能手機的普及和移動互聯網的興起，帶動了移動應用市場的快速發展，移動APP逐漸成為互聯網用戶新入口，重要性越來越突出，用戶對APP產品的功能性和非功能性的要求也越來越高。然而，隨著大批APP應用的涌入市場，問題卻逐漸凸顯，眾多APP架構的先天不足直接影響了產品的功能性和穩定性，逐漸成為APP長期發展的瓶頸。本文從APP整體架構角度，將分析與設計相結合，闡述如何進行移動應用的整體構建，為后續廣大移動應用領域的APP開發者奠定架構基礎，提供參考價值。

關鍵詞：APP應用；整體架構；架構設計

中圖分類號：TP311.52 文獻標識碼：A 文章編號：1007-9416（2017）01-0133-03

1 引言

移動互聯網技術的不斷創新，帶動了移動互聯網市場的快速蓬勃發展。凱度中國觀察最近發布了2016年前三季度移動操作系統占有率報告，該報告顯示，全球Android手機的市場份額上升至87.5%，用戶的海量增長，致使APP應用市場“一片繁榮”，新的App更是層出不窮，今年1月份的數據顯示，以Android系統為主的Google Play應用商店，APP數量超過140萬，我們的日常生活已然被移動APP淹沒了，越來越多的APP改變了人們以往的生活方式和消費方式。

APP應用軟件數量已經多到不可計數，并且每天還有數以萬計的APP軟件不斷上新到應用市場，但是很多APP產品較為注重眼前利益，只注重前期用戶的快速積累和圈錢，而APP在設計開發之初，沒有重視產品的功能架構與后期的更新維護，導致產品在功能、性能和穩定性等方面存在很大的問題和隱患，用戶在使用的過程中體驗較差，用戶粘性較低，用戶逐漸流失。為此，本文提出一套基于Android系統的APP開發整體架構方案，旨在提高App產品的整體質量和用戶體驗，為后續廣大移動應用領域的APP開發者奠定架構基礎。

2 UI架構設計模式分析

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

2.1 MVC

MVC全名是Model View Controller，是模型（Model）、視圖（View）、控制器（Controller）的縮寫，是軟件架構中最常見的一種框架，并且是經典的框架模式之一，它在多個開發領域中都有廣泛的應用，尤其在Java EE領域。MVC簡單來說就是通過Controller的控制去操作Model層的數據，并且返回給View層展示，MVC架構設計見圖1所示。

MVC模式的最大優勢是將視圖的展示與數據處理和業務邏輯相分離，視圖層只需關注UI的展示。在Android應用開發中，業務邏輯和數據處理等擔任了Model角色，XML布局文件等擔任了View角色，Activity和Fragment擔任了Controller角色。控制器的角色可以看作一個中間橋梁的作用，通過接口通信來協同 View（視圖）和Model（模型）工作，起到了兩者之間的通信作用。控制器還起到了一定解耦的作用，將View視圖和Model模型分離，但是在Activity中依然有很多關于視圖UI的顯示代碼，可見View視圖和Activity控制器并不是完全分離的，也就是說一部分View視圖和Controller控制器Activity是綁定在一個類中的。

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

2.2 MVP

MVP是模型（Model）、視圖（View）、主持人（Presenter）的縮寫，分別代表項目中3個不同的模塊。MVP作為MVC的演化，更適用在移動應用的開發中，解決了MVC存在的缺點，對于Android來說，MVP的Model層相對于MVC是一樣的，而Activity和Fragment不再是Controller層，而是純粹的View層，所有關于用戶事件的轉發全部交由Presenter層處理。

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

在整個過程中，Presenter層充當了橋梁的作用，View層和Model層完全沒有聯系。在層與層的通信交互中，主要是通過接口和回調機制實現的。這樣分層的好處就是大大減少了Model與View層之間的耦合度。一方面可以使得View層和Model層單獨開發與測試，互不依賴。另一方面Model層可以封裝復用，可以極大的減少代碼量。不僅如此，還可以編寫測試用的View，模擬用戶的各種操作，從而實現對Presenter的測試。在MVC模式中測試和維護較難解決的問題，在MVP中都解決了。

2.3 MVVM

Android應用中的MVVM是在2015年Google的IO大會上推出的。提到MVVM，大多數開發者都會想Data Binding，Data Binding是Google官方推出的一個基于MVVM設計模式實現的框架，MVVM可以實現視圖和邏輯代碼的超級解耦，按照Google的說法，使用了MVVM的開發模式，還可以提高布局文件的解析速度。從圖3中可以看到，MVVM和MVP的結構上區別不大，Presenter層換成了ViewModel層，View層和ViewModel層是相互綁定的關系，這意味著當更新ViewModel層的數據的時候，View層的UI會相應的變動。

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

2.4 分析比較

經過上面的分析，可見MVC已不太適用Android等移動應用的開發設計中了，相比來說MVP和MVVM是更適合在移動應用的開發中使用，MVP和MVVM這兩個MVC的升級延續孰優孰劣，并沒有結論，還是要根據具體的項目、具體產品來分析。

3 整體架構的設計與實現

優秀的APP架構應該具有清晰的層次劃分，功能模塊劃分和業務邏輯劃分，同一層模塊間充分解耦，模塊內部高內聚，各分層設計符合面向對象設計六大原則，提高程序的封裝性、復用性、可維護性，最后應該在功能，性能，穩定性等方面達到綜合最優?；诖耍珹PP架構可分為四層，如圖4所示，最頂層是應用層，是面向用戶的第一層，然后是應用組件層，提供了封裝組件服務，再下是基礎組件層，為APP提供基礎功能組件，最下面是系統層，直接面向系統底層開發。

3.1 應用層

應用層專注于業務領域的實現，與需求的業務功能關聯，直接面向用戶，是用戶對產品感知的第一層，應用層包含以下細分的三層，如圖5所示。

（1）視圖層，與用戶直接交互的界面，是用戶和系統之間交流的橋梁，它一方面為用戶提供了交互的工具，另一方面也為顯示和數據處理實現了一定的邏輯，協調用戶和系統的操作。（2）業務層，包含了APP需要的所有功能上的算法和邏輯處理，并與數據層和視圖層交互。抽象的說，業務層是處理與業務相關的部分，包含一系列的執行與數據的操作。（3）數據層，提供訪問數據的功能，在分層設計中，所有讀取數據或寫入數據的工作都屬于這一層的任務，不做過多的數據邏輯處理，操作的是非原始數據。

3.2 應用組件層

應用組件層為上層封裝業務功能，以服務的表現形式提供，不涉及UI和平臺的特性，應用組件層的服務是獨立的，可移植的，不依賴特定的開發和使用環境，如圖6所示，主要包括有社交分享、推送服務、掃碼組件、鍵盤組件、手勢密碼等。

3.3 基礎組件層

基礎組件是相對于業務功能來說的，它是對復用率比較高的代碼的一種抽離，它提供APP的公有特性，實現依賴特定的平臺環境，這一層也是用戶對產品的一種感知，這種感知表現在穩定性、性能等方面，直接關系到產品的用戶體驗。如圖7所示主要包括有數據庫操作、網絡通信處理、日志記錄、圖片緩存、數據解析（JSON/XML）、加解密等。

3.4 系統層

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

4 關鍵技術實現

4.1 應用層

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

4.2 應用組件層

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

4.3 基礎組件層

基礎組件層提供APP的公有特性，數據庫操作是應盡量使用ORM框架，ORM是一種程序設計技術，用于實現面向對象編程語言里不同類型系統的數據之間的轉換?，F在較為成熟的是ORMLite與GreenDao。網絡、圖片、JSON等的處理，依靠成熟的框架是較為明智的選擇。日志記錄是一個基礎且極為重要的組件，可幫助開發人員代碼調試，快速錯誤定位，Android系統中提供了Log類來記錄日志，使用起來方便簡單，也可以使用功能更為強大的開源日志記錄庫Logger，具體的選擇依賴于開發者的使用習慣。

4.4 系統層

系統層的開發更偏向于Linux環境開發，Android系統是以Linux內核為基礎，所以對于進程的管理自然離不開Linux本身提供的機制。在Android系統中，進程可以大致分為系統進程和應用進程兩大類，開發者更多關注的是應用進程，Android應用程序是通過消息來驅動的，系統為每一個應用程序維護一個消息隊列，應用程序的主線程不斷地從這個消息隊列中獲取消息，然后對這些消息進行處理，這樣就實現了通過消息來驅動應用程序的執行。系統層的開發實現，Android提供了較為豐富的實現方式，包括上層Java的封裝實現，和下層C/C++的底層實現。本文不再詳細介紹。

5 結語

本文通過一系列的分層與整合，剝離和組合等方式優化了APP應用的整體架構，在關鍵技術實現上，本文也給出了一定的技術指導。在應用的設計開發中使用分層架構模式，一方面能提高APP的功能性、穩定性和可維護性，另一方面提高了用戶的產品使用體驗，這樣才能促使APP產品長期發展下去。