淺談android架構設計，android架構設計

淺談android架構設計，android架構設計

       到目前為止，android開發在網路上或者社區上沒有公認的或者統一的開發架構，好多架構都是基於對方法的封裝。今天在這淺談兩年來對android開發的理解，主要是思想上的理解，希望對大家有協助。

       我認為android開發可以從兩個方面去總結架構的設計，在這裡對於實現只做陳述：

       一，就是大多數人的設計思路，對方法的封裝。

       在這裡我根據開發的習慣對工程進行包的設計：

       1. http：網路要求方法封裝。這裡建議採用線程+Handler的模式，把Http 中get方法和post兩種請求方式分開，對於正常的操作邏輯採用post的方式，方便資料的封裝，加密和安全。對於擷取圖片，視頻這個可以通過一個URL直接拿來主義的操作用get的方式，速度快且不複雜。

       2. thread：既然http要採用線程的方式那麼自然的線程管理就是一個重點，建議整個App對線程進行統一的管理，根據線程池的特性封裝多線程和單線程，每次要啟用線程的時候都到線程池裡面去取，這樣整個App的線程數，佔用記憶體的大小基本就在掌控之中了。

       3. download：對apk的下載或者對圖片，視頻的下載管理。期間結合多線程，軟引用，本機存放區，記憶體儲存的方式就可以多線程下在圖片。下載圖片處理結果有兩種方式一種直接傳遞顯示Imageview顯示，但是這種方式想對返回的圖片進行處理就不是很方便了，所以建議再加上回掉的方式，傳遞迴掉的對象，需要回掉到頁面處理就添加回掉事件。

       4. upload：上傳檔案，圖片，視頻等，這塊上傳的時候可以進行對檔案的壓縮再上傳會更好些。

       5. dao：對資料庫的操作，建表，版本控制，添加資料，對資料的增，刪，改，查。

       6. file：對檔案的操作。

       7. utils：工具類。

       8. exception：異常類，異常類主要是結合http請求返回的錯誤碼進行解析，還有項目運行中對一些細節進行捕獲。

       9. log：log的封裝須實現三種，a：開發調試；b：發布時錯誤log儲存本地；c：發布是必要錯誤記錄檔發送伺服器。

      10. bean：資料封裝bean。傳遞資料建議通過bean用Json和Gson相互轉換的方式進行。

      

       二，可以從根據資料以及資料的商務邏輯處理進行設計。

      以上是大多數人的封裝思路，主要是針對方法的封裝，下面要說的是對上面的封裝整合到實際項目業務中處理的方式，主要是針對業務的封裝，在這裡大方向上主要應用了兩個設計模式：中介者模式，MVP模式。其間大量用到原廠模式，單利模式，模板模式，觀察者模式等等。

     整體思想是：

      11. daorest，httprest，filerest：這幾個包主要封裝了app與各個渠道的互動之間的介面，可根據實際的項目需求進行添加，裡面沒有實現方法，所有的類全部是介面。

      12. mediator：中介，如果用普通的方式進行互動的話我們用A，B，C代替三個來源不同的介面，如果有個頁面V需要用到這三個來源，那麼就會有V和A互動，V和B，V和C兩兩互動，要是有複雜的關係沒準會有V和AB互動等等，這樣互動關係就像一個沒有規則的網，很難理清楚。這時候我們用一個中介的話問題就會大大改善，我們引入一個中介M這個時候ABC被整合到M中，ABC對於V的關係無論多複雜，由內部整合，最後由M統一發出對V的互動，這時候關係就很清楚。V和ABC無論誰需要改變都不會影響到對方，M充當了一個調停的關係所以中介模式又叫調停者模式。

      13. presenter：這就是MVP模式中的P。很多人都說android不能很好的區分MVC模式，因為Activity中既包含了V也包含了C，其實android真正的V層我感覺應該是XML層，但是XML層沒法動態改變資料。所以索性我們退一步，讓activity也作為我們唯一的V層，這個時候MVP就誕生了。其中的MV跟MVC中的MV是一樣的，P就是我們添加的一個處理Activity中業務的層，我們把他命名為Presenter。P的主要作用就吧原來Activity中一切的資料業務處理挪到了P層，讓Activity成為一個純純的V。具體的實現方式可參考：http://blog.csdn.net/zhouyinhui/article/details/4614474

      14. view：Activity實現層。

       最終總結下來工程的目錄也大概出來了，這裡主要介紹的就是Mediator+MVP模式的架構結構以及大致實現思想，其中還有好多細節，比如說各層業務中各個業務介面就需要abstracts限制，管理就需要用原廠模式，代碼的實現方式就需要模板，View層狀態的變更就需要觀察者模式等等。需要寫好一個架構是要很大功夫的需要不斷的積累不斷的重構。啊，對了還差幾個目錄一併補上。

       15.service：android服務不會隨應用的關閉而關閉。經常會被第三方軟體關掉。

       16.broadcase：廣播，再通知各個activity之間的狀態的時候很管用，跟觀察者模式類似。

       希望所寫對大家有協助，互相學習！