怎樣搭高質量的Android項目框架，框架的結構具體描述？

01-11

根據經驗，一個良好的架構設計可大致分三層：

— 上層是Activity、Fragment、ViewsWidget等視圖渲染和業務調用。

— 中層是針對業務的三方庫，以及主要邏輯實現，業務流程在這完成，此層還可以細分，不再多表。

— 底層是業務無關的框架庫，用之四海而皆準，各類庫內高內聚，不同庫間低耦合。

這樣一個結構，使得你的代碼快速在phone和pad以及tv之間遷移，便於業務的統一編寫與調用，且讓各模塊更為清晰。

如圖：

當然根據個人喜好不同，項目結構有區別，但基本要遵循MVC、邏輯視圖分離等設計思想。

以上為結構級別，再細粒度一些，推薦反覆理解實踐設計模式的六大原則與23種設計模式，讓項目整體更優雅可控。

自動化，智能化，約定優於配置等思想，恰當使用合需、輕量、可擴展的框架庫可以幫助項目更穩定簡單。

推薦閱讀

設計模式六大原則

chjavach的博客

iluwatar/java-design-patterns · GitHub

LiteHttp - Get Start

以上回答於2015-03-24，架構思路於2013年開始實踐。

——————————————————我是分割線——————————————————

由於業務和項目的發展，在以上結構的基礎上我又更下了一下整體架構，現補充答案如下。

為了快速支持不同App，以及同款App不同終端，我給項目設計了以下結構：

層級的組成：

Lite
SDK : 由HTTP、ORM、IOC、Async、Base/Common等通用組件組成。

App SDK：全部業務邏輯在這裡實現，邏輯控制、數據解析和模型等在這實現。

App View層：activity、fragment、layout、resource等在這裡。

層級的作用：

Lite
SDK : 功能層，重視通用、性能、便捷，作為底層快速支撐不同App。

App SDK：業務層，重視業務、邏輯、模型，作為中層快速支撐不同的終端。

App View層：視圖控制層，重視交互、體驗、布局、資源，作為上層快速實現視覺和界面----。

簡言之，LiteSDK因其通用性而快速支持不同App；AppSDK因其界面無關性而快速支持同款App的不同終端或者UI層；AppView層因兩外兩個底層的存在而得以快速開發視覺相關功能。

以上補充於2015-07-29，更多內容可以看我的開源站 http://def.so

不請自來說點廢話。樓上 Tian 前輩說的很好，而且有圖有真相。

一個好的框架設計是基於業務需求的，脫離了具體業務談框架也沒多大的意義。Tian 前輩很好地闡釋了 Android 應用的基本構成，康仁輝前輩則很好地說明了 Android 通用模塊的劃分。

就像前面說的，脫離了具體業務，談項目框架也就沒有意義。在此之前能做的，就像是康仁輝前輩說的，把一些通用的功能模塊抽象出來，作為服務提供給開發人員使用。比如 Http 請求方面 Volley，圖片非同步載入方面 ImageLoader，數據解析方面 GSON，還有各種 UI 效果 PullRefreshListView 等。

這些小的框架根據不同的業務需求，最後組裝成了你的整個 App 框架。拋開 App 大的框架不談，我們只說說如 Volley 這樣的小的框架，再設計方面應該注意哪些方面。

其實如 Tian 前輩所說，框架其實就是一種抽象，功能上的以及業務上的抽象。抽象的質量最終決定了代碼的質量以及能夠解決問題的複雜度。好的抽象應該是這樣的（其實就是設計原則）：

功能單一的。也就是設計法則中的單一職責。單一職責原則適用於類和方法的設計，同樣也適用於框架的設計。
良好的封裝以及簡單地 API 調用。框架作為服務提供者，很多情況下是為了提升開發效率，對於一個相對穩定的第三方框架，開發者是不會關注於其具體實現的。
良好的擴展性。也就是開閉原則，一個設計良好的模塊，應該在不被修改的前提下被擴展。我們擴展開來，一個設計良好的框架，應該在具體代碼業務不被修改的前提下進行修改。
低耦合高內聚。其實就是對前面1 2 3 點的總結。
穩定性高於一切。
測試覆蓋率，盡量保證每一個功能點都被覆蓋。

===============先挖個坑，有點餓了，吃點東西去。==============

書接上文。

7. 異常機制。就像前面所說的，穩定性高於一切。穩定性不光得益於良好的設計，還需要良好的異常機制的設計。對異常進行處理，不光適用於框架的設計，也適用於App 的設計。拋出異常來說明異常狀況，但是不要強迫客戶端使用異常來控制流。

8. 從普通使用者的角度去考慮抽象，即使（感謝 @i pikko 指正）增加一定的代碼量，這也是值得的。

9. 起一個萌一點的名字，最好能夠萌到看一眼就知道功能。這包括類的設計、方法的設計以及參數列表的命名。

10. 需要開發者配置的參數盡量對象化。比如一個方法參數可接受三種 int 型的值（1 ， 2， 3），用以表示不同的意思。那麼儘可能的創建一個 State 類，裡面有三個靜態常量 STATE_ONE ,STATE_TWO ,STATE_THREE 。

11. 對參數進行校驗。接收到參數之後，儘可能的對每一個參數進行非法驗證，比如非空判斷、參數無意義的判斷等，用異常的方式告知開發者需要傳遞正確的參數。

12. 儘可能簡單地方法參數。或者說儘可能多的重載方法。但是需要注意模稜兩可的重載。

13. 如12所說，延展說來就是盡量避免使用長參數列表。長參數列表更容易出差，而且對於維護以及編譯、運行並不友好。如有必要，創建參數助手類（參考11）。

14. 對可能會犯的錯誤進行預計，要用發展的思維來設計框架，這一點有點跟11意思一樣。

15. 版本兼容性。保證框架升級之後，對於老版本的支持。

16. 框架 API 生命周期的管理。具體的手段可以是設計 API 級別，比如內部、測試、開發、穩定等等。

借用 Google 以為大神的總結就是，框架設計需要滿足如下幾點：

簡單易學；
易於使用，即使沒有文檔；
很難誤用；
易於閱讀，代碼易於維護；
足夠強大，可以滿足需求；
易於擴展；
適合用戶。

最後，可以系統的學習一些好的開源項目，如 Volley、ImageLoader、國內幾個微博的開放 SDK 等等。

肥肥見識淺薄，在各位前輩面前班門弄斧，還望各位前輩不吝賜教。

有幾個開源的項目很值得參考，比如google的ioschd

框架首先是為了快速開發和性能更加穩定。

我認為常用android框架應該包括：

1 UI控制項

2 網路連接

3 緩存處理

4 數據解析

5 資料庫操作

6 一些常用工具類

結合android項目本身，根據需求盡量精簡框架，可以MVC，MVP，MVVM等（也可以創新）其中一個為標準來編寫，基於三層架構即可，注意分層，不要被框架約束自己的想法。高質量，可以通過測試，持續構建。

如果你的應用是基於HTTP進行網路數據請求的方式，google上面的一個框架volley是一個不錯的選擇。

google一下android MVP，有很多介紹文章。