Android換膚功能設計與實現（4）——控制層設計與實現

    根據Android本身的特性來說，我們可以這麼說，其系統標準的控制層是Activity，為什麼這麼說那，從Activtiy的生命週期入手來簡單說明一下：什麼叫做控制層那，我們知道控制層就是串連View表現層，與Model模型層的部分，主要實現各種互動，這裡的互動是廣義的互動，對於一個APP來說，包括兩部分，與人的互動，與系統內容的互動。對Activity來說，同樣要從這兩個角度來說明。

 

    與人的互動主要指的是APP接受使用者的點擊操作，改變相關的介面顯示，通過介面的不同的變化，提示使用者當前的APP狀態，而一步步實現與使用者的互動。其實通過APP與人的互動的簡單定義我們就可以知道，與人的互動的主體其實就是介面，也就是View。這就是為什麼各種互動都是以View為核心。這就是目前廣泛使用的SDK設計方式。將所有與使用者的互動綁定在View上。我們可以通過View所實現的介面來說明這種設計思路，View實現了與使用者進行互動的所有的介面，點擊、拖拽、手勢等等。從物件導向的角度很好理解這種設計思路，畢竟與使用者進行互動的最小個體就是APP介面上的一個個View。當然，SDK為了更方便的、快速的開發應用，抽象出了各種控制項，如Button、Switch、ListView......等等，通過對View的整合形成ViewGroup，抽象出各種布局類型LinearLayout、RelativeLayout、FrameLayout等，（我們在這裡只從互動的角度來說這個問題，在後面的說明中，會從繪製的角度來說明。）從互動的角度來說，可以這麼來理解，各種控制項的主要功能是提供進行互動過程中標準的介面變化的一種抽象；如Button、Switch、等等，對於這些控制項來說，其主要目的是實現標準的互動外觀，標準的互動響應。如Button的正常、按下、選中的不同的外觀，Switch在開關狀態下不同的表現等等。控制項符合與使用者互動的標準介面響應。而ViewGroup則更關注於介面的整體布局，ViewGroup為互動提供的是View的父子關係樹，提供了互動事件如Touch事件的通知樹，通過View的層次關係來管理對互動事件的響應。歸根結底來說，不管是控制項還是ViewGroup都是對View的一個擴充，不管是控制項所強調的介面變化，還是ViewGroup所偏重的互動事件的前敵，都是與人互動的兩個方面的強調。

    上面簡單說了一下與人的互動，下面再來說一下與系統的互動，與系統的互動主要指的是系統對APP的各種調度，也就是各種系統事件的處理，對Android來說，最主要的就是其Activity類了。針對當前APP的不同的狀態，處於其生命週期不同的階段，系統會調用Activity不同的方法。除了生命週期上的互動，與系統的互動還包括各種系統按鍵的響應，如MENU，BACK，HOME，對於系統按鍵，APP響應的介面也主要在Activity中。在Android4.0中對ActionBar的引入，也可以看做是與系統的互動行為。    這就是在Android應用中，Activity類往往是最複雜、程式碼數最多的類之一的原因，因為在Activity承載著控制層的所有入口，包括在其onCreate方法中，引入View的布局，在其不同的生命週期介面，完成與系統的各種互動，這在很大程度上使Activity類承載了大量的功能，最終變化為繁多、複雜的代碼。為了分擔這部分的工作，簡化Activity設計與實現的邏輯，Android在3.0後引入的Fragment的概念，顧名思義Fragment也就是介面的一部分，在Android中將Fragment作為是一部分介面的控制層，從Fragment的生命週期可以看出，Fragment承載了與Activity相類似的方法，在Activity的生命週期基本在Fragment都有相對應的反應，從這個角度可以看出Android為了適應大螢幕、同時也是為了簡化Activity邏輯的複雜程度，所作的努力，在Android3.0後的APP，可以考慮使用Fragment來構建自己的APP，將APP以不同的介面劃分為不同的功能某塊，將各個某塊實現為不同的Fragment，在不同的介面切換過程中，通過Fragment的互動、切換來實現。    

 

    在開發Android換膚功能過程中，對控制邏輯的設計，就是通過上述思想，以Fragment為基礎，對整個功能介面進行劃分，對不同介面的控制邏輯進行分別的設計。這樣可以有效避免對Activity的過度依賴，以及Activity邏輯上的過度臃腫；應該說Fragment是Android為開發比較大型應用而設計的子控制層。通過Fragment實現基於小介面的與使用者的互動及與系統的互動，而實現控制層的主要工作。

 

    在設計控制層過程中，除了以各個子介面為基礎而設計、實現的Fragment之外，在設計控制層邏輯時，需要考慮的是將邏輯較複雜的模組盡量獨立出來。這雷根據具體應用的特點，主要將Menu,ActionBar部分獨立為單獨的一類，專門負責ActionBar、MENU的互動及介面變化。在控制層設計中，同樣需要考慮的就是與系統其它模組的互動，將這部分盡量集中在一起，通過介面模式訪問系統資源，接收系統的廣播。最後實現為兩個類，SystemFacade負責訪問系統下載管理員，及與下載管理員相關的互動動作，ThemeReceiver負責系統發出的廣播接收與響應。

    上面基本對控制層設計過程中，的設計思路，及在新版本Android系統中如何利用新特性，新功能盡量設計出簡單、穩定的控制層邏輯。如果為老版本的Android系統應用設計相應控制層，完全可以將對新特性的使用自己建立一類，單獨進行管理，這裡主要利用的是Fragment的設計思路，即將控制邏輯以不同的介面為主要互動對象，分別獨立為不同的控制模組，進行一一實現，在Activity中對各模組進行綜合管理。設計、實現控制層的主要目標就是邏輯簡單、結構清新、耦合度盡量低（可以將耦合的部分集中在一個類中，如Activity就是一個很好的耦合類，將表現層、模組層的主要提供者都集中在Activity中）。

                            ——歡迎轉載，請註明出處
http://blog.csdn.net/zyplus——