原文出處：http://www.kokojia.com/article/19289.html
架構是有關軟件整體結構與組件的抽象描述，用於指導大型軟件系統各個方面的設計。其是對存儲在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組件。