1. 程式人生 > >Android-框架-App工程結構搭建:幾種常見Android程式碼架構分析

Android-框架-App工程結構搭建:幾種常見Android程式碼架構分析

        架構是有關軟體整體結構與元件的抽象描述,用於指導大型軟體系統各個方面的設計。其是對儲存在Active Directory中的物件類別和屬性的描述。對於每一個物件類別來說,該架構定義了物件類必須具有的屬性,它也可以有附加的屬性,並且該物件可以是它的父物件。本文主要介紹幾款在常見的app工程結構搭建中的Android程式碼架構。

        對於Android架構,由於個人手機的限制,目前也沒打算要大談特談,但是從安卓開發的角度上看,看到整齊的程式碼,擁有優美的分層總是一種舒服與觸動視覺的享受的。

        但從藝術的角度上看,這其實也是我們在追求一種美。

       於本文,首先分析幾個時下比較流行的android軟體包,在最後我們需要汲取其中覺得非常優秀的部分,用此來搭建我們自己的通用android工程模板。


1. 微盤

  微盤的架構比較簡單,我把最基本,最主幹的畫了出來:

       

微盤架構

  第一層:com.sina.VDisk:com.sina(公司域名)+app(應用程式名稱) 。

  第二層:各模組名稱(主模組VDiskClient和實體模組entities)

  第三層:各模組下具體子包,實現類。

  在圖片的分析中,我們可以得到上述一個最簡單最經典的結構,一般在應用程式包下放一些全域性的包或者類,倘若有多個大的模組,這個可以分成多個包,以及其中包括一個主模組。

  在主模組中定義基類,例如BaseActivity等,假設主模組下還有子模組,可以在主模組下建立子模組相應的包。需要重申一下,有的時候如果只有一個主模組,我們也可以完全省略掉模組這一層,那就是在BaseActivity.java及其子模組上直接提至第二層。

  在實體模組中,其本應該定義甚至說只定義相應的實體類,供全域性呼叫,但實際上並沒有這樣。在微盤應用中,幾乎所有的實體類是以 xxx+info命名的,這種命名也是我贊成的一種命名,從語義上我覺得xxxModel.java這種命名更生動更真實,xxxModel給我一種太機 械太死板的感覺,這點完全是個人觀點,具體操作中以個人習慣為主。還有一點,在具體的xxxInfo,java中有很多實體類中是沒有get/set的方 法,而是直接使用public的欄位名。這一點,我是推薦這種方式的,特別是在移動開發中,get/set方法很多時候是完全沒有必要的,而且是有效能消 耗的。當然如果需要對欄位設定一定的控制,get/set方法也是可以酌情使用的。

  2. 久憶日記

  相比於微盤的工程結構,久憶日記的結構稍微複雜了一些。如下圖:

       

久憶日記的結構

  1).第一層和前面微盤一樣的.

  2).第二層則沒有模組分類,直接把需要的具體實現類都放在下面,主要日記的一些日記相關的Activity。

  3).第二層的實體包命令為model包,裡面不僅存放了實體類xxx.java,而且存放了更高一級的實體類的相關類,比如 xxxManager.java,xxxFactory.java.關於這一點,我們可以參考一下android.jar中結構,我們發 現,Activity.java和ActivityManager.java,View.java和 ViewManager.java,Bitmap.java和BitmapFactory.java等等N多類似的一對類都在同一個包下,我個人覺得實體 包下存放實體類相應的Manager和Factoty類也是正確的,是我們應該採納的一種結構。這裡就打破了前面微盤中說的實體包下存放且只存放實體類的說法了。在而現實中,應該從靈活和合理的角度,久憶日記的這種實體包中存放物件內容更加實用。

  4).第二層中增加了前面微盤中沒有涉及到的config,constant和common包。第一,其中config中儲存一些系統配置,比如名稱,應 用引數等系統級的常量或者靜態變數,當然,如果你有其他大模組的配置,比如如果擁有複雜的使用者管理模組的話,完全可以增加一個 UserConfig.java中儲存使用者的一些配置資訊等等。第二,constant包,此包下存放的都是public static final常量,定義狀態,型別等等。出於效能考慮,android開發中我不推薦使用列舉。common包中定義一個公用庫,這裡因為應用單一,無法很好的說明common包內容結構。

  5).common包要涉及後面多個軟體比較後我們再得出結論。

  通過久憶日記的分析,也能借鑑到很多很有價值的東西,這也能使我們的架構變得更豐滿更強大了。

3. 網易新聞

  在網易上,其新聞確實是做得不錯,從其應用的角度上看,這是我最欣賞的應用之一。那麼它的工程結構是怎樣的構架的呢?

        

網易新聞

  網易新聞的工程結構和前面兩個app又有很多的不同,它並非按照模組來分,而是主要根據元件的型別來分的,然後把此型別所有的類全部放在其下。那麼這種把所有activity全部放在activity包下的分法的確在android開發中比較普遍。

  1).第一層被分成了兩層,可以看出來,這裡肯定是採用了公用包jar,這樣一來,我們所開發公用包的時候也應該按照"公司域名+公用模組名稱"組合方式來命名會比較規範。

  2).第三層(綠色層)中activity和service包下都是存放所有的activity元件和service元件,其實這裡麵包含了一種程式碼習慣。往往activity相關的類如監聽器,執行緒,介面卡等非常多的類,這些不好直接丟在activity包下,而是直接寫在相應的activity中以匿名或者內部類形式定義,否則activity包和service包看上去會比較雜亂。

  因為android的app很可能不是很大,activity或者service包也不會雜亂,所以網易新聞的這種方式也是很有參考借鑑價值的。

4. 小米應用

  說說小米應用吧,小米應用包括3個應用,小米分享,小米閱讀,小米標籤,從實際程式碼開發來看,我感覺不是同一個團隊,或者同一組人開發的。這種情形下,它們的架構有是怎樣的呢?小米應用

       

小米應用架構

  上面的結構以及結構內部的細節其實很多地方我都是不大苟同的,但是能做出來好東西就是值得大家學習的,所以我只把其中我認為最值得學習的一點拿出來說。

  首先,widget,provider這些特殊模組分類建立單獨的模組包即可,在這就不一一介紹了。

  第二,通過觀察,我們發現小米分享中每個應用都有common包,不僅有應用程式級別的common包,而且有應用程式內級別的common包。我想說的 是,android開發中隨著專案開發的積累,確能提取到很多公用的方法、類、功能模組。各個專案之間如此,各個專案內部也是如此,所以針對專案類被各個模組呼叫的方法,類也可以提取出相應的公用庫。

  那麼這裡有個問題,公用common包的內部包可能涉及到很多的內容,是否要分包分級呢,又如何分包分級?我覺得,這個因情況而已,一般來說移動開發,為 了減少包的大小,我們會控制common包的膨脹,往往common包僅僅包括一些最簡潔最經典的東西,東西又很少的話就無需分包,但是如果貴公司開發成 百上千,每個專案都用到行為分析,意見反饋等公用模組,分一下包會更清楚一點。總之,分不分包無關緊要,但儘量讓你的程式碼結構清晰,思路瞭然就好。

5. 聚各家之長,集大家之成

  上面粗略的分析之後,我們應該對android程式的架構有一個感覺,清晰而雜亂。我也沒有去了看更多其他應用的結構,暫時就總結一下,得出一個我們自己的通用的工程結構。

  假如公司名為tianxia,目前公司準備開發讀書應用,交友應用,生活服務應用。

  第一時間我們應該得出下面這種整個的架構(具體的app開發當然要分開):

       

APP架構

  公司下開發3個應用reader,friend,life,其中common包為這三個應用共用,config,oauth為可選,view存放一些最通 用的自定義view,比如對話方塊,定製的列表等,如果你覺得有些view可能不會通用,最好把它放在應用程式類的common包下。

  如果各位看過Android學習系列(6)--App模組化及工程擴充套件的話,對於這種多應用模式,應該存在android庫共用情況,來解決資源替換,工程複用的問題。所以我又修改如下:

             

android庫

  其中BaseApplication做一些所有app都會用到的基礎初始化或者配置。之後其他應用的application應該都繼承此BaseApplication。

  base是一個android庫,也是一個完整的android工程,而common只是一個jar檔案,當然你也可以根據需要作為android庫來開發。其他主工程reader,friend,life應該引用base工程。

  ad包存放公司自定義的一些軟廣告。

  feedback包下儲存一些使用者反饋等通用功能模組。

  其實,很多情況下,upgrade模組也可以新增到base工程下,制定統一的軟體升級機制。

  接下來我們以reader為例子,來詳細完成它的工程結構的設計。

工程架構

  其中,config包下的AppConfig.java存放應用程式的根配置,比如版本,目錄配置等等。

  module包下分為各個模組,blog為部落格模組,bbs為論壇模組,person為整站個人資訊模組,widget表示一種特殊功能模組。

  common包下存放一些工具類,本應用程式的一些自定義View等等。

  再結合之前所講的內容,我們把整個串起來,完善一個reader的最後的架構如下(兩外兩個freind和life亦是類似如此):

架構

  注意:

1).功能模組和型別模組均可以劃分,如果沒有需要的話,模組的劃分都可以省略。

  2).activity和service這類元件劃分,如果沒有需要的話,元件的劃分都可以省略。

  3).所有的劃分,如果沒有需要的話,所有的劃分都可以省略。

  綜上文,主要是通過幾個常用的APP工程結構來介紹Android程式碼架構,首先是微盤的架構,然後是久憶日記的結構和網易新聞的架構,再來是小米應用的架構,微盤主要是分三層來介紹,首先是主模組和實體模組和個模組下的子包,久憶日記的話第一層是和微盤的一樣,但第二層是沒有模組分類的,而且實體包命令為model包以及第二層中增加config,constant和common包。小米應用的話主要是三個應用,分別是小米分享,小米閱讀,小米標籤。網易新聞分成三層,一二層主要主要是採用公用包jar,第三層是在activity和service包下新增他們的activity和service元件。