做了幾年Android開發，也算是個半吊子的開發者了。但是從大公司到小公司，要么程序的結構亂七八糟，別說耦合什么的了，根本找不到功能的代碼；要么就是有個看似牛逼的架構師(往往是j2me或者j2ee轉過來的），然后搞一套套的設計方法，設計模式，代碼到是比較能看懂，但是冗余多的令人發指，動不動就是interface factory abs類一坨坨，最后就做了別人十幾行代碼的事兒。
各位有推薦什么好的Android開發框架或者好的開源項目也行，不勝感激。修改 舉報 添加評論? 分享 ???邀請回答 按投票排序按時間排序

28 個回答

贊同18 反對，不會顯示你的姓名 豆沙包，愛健身的Androider 多多洛、背你進京趕考、張東?等人贊同 這個是我們團隊一直推崇而且現在正在使用的架構
android10/Android-CleanArchitecture · GitHub

說說用下來的優缺點，如有紕漏，還請指正。

無論從架構還是代碼上看，分層都是三層：視圖層(Presentation Layer)、控制層(Domain Layer)、數據流層(Data Layer)。
層級之間通過添加接口層作為分隔實現解耦。

簡單來說，優點有以下
1.層次分明，各層級之間都不管對方如何實現，只關注結果；
2.在視圖層(Presentation Layer)使用MVP架構，使原本臃腫的Activity(或Fragment)變得簡單，其處理方法都交給了Presenter。
3.易于做測試，只要基于每個模塊單獨做好單元測試就能確保整體的穩定性。
4.易于快速迭代，基于代碼的低耦合，只需在業務邏輯上增加接口，然后在相應的層級分別實現即可，絲毫不影響其他功能。
....等等

目前發現的缺點：
1.由于視圖層(Presentation Layer)使用MVP模式，每個有獨立邏輯的Activity(Fragment)都擁有獨立的Presenter，當View多起來時候Presenter維護起來就顯得略麻煩
2.上手難度比較大，學習曲線比較陡峭

推薦閱讀?
http://fernandocejas.com/
https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html 編輯于 2015-09-16?8 條評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同19 反對，不會顯示你的姓名 陳昱全，程序員 Jackson、孟田田、魏竇哲?等人贊同 你說這個我想了上次還被老大批了--過度設計了。過多考慮未來的需求和變動了就設計過度了，于是出現了就真是幾十行的代碼，寫出各種類各種接口。
最近學到的倒是基于android特性進行開發，ui上可以從需求分析到android控件的選擇比如fragment,slidingmenu,actionbar,navigation drawer等。
整體架構上，數據庫層和ui刷新，數據異步讀取，使用contentprovider（數據庫操作像rest api一樣的風格）,cursorloader,網絡請求的intentservice,resultreceiver,gson等。
設計思路上，分層--還是走的mvc嘛，雖然最近也有用mvp，不過不管怎么樣關鍵還是要有分層的意識吧；解耦--面向接口編程啊，依賴倒置都是；抽象能力：其實我覺得抽象能力很重要的，不過自己現在抽象能力也很弱，沒啥建議。
好的開源項目：我覺得倒是沒什么統一框架，可以看看foursquare,google io app的源碼都是相當好的，android源碼永遠是值得讀的。
文中很多知識學自這逼@李彬，建議關注，不過這逼很裝逼。 編輯于 2013-09-18?9 條評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同15 反對，不會顯示你的姓名 Rocko，http://rocko.xyz Jackson、呵呵后、david-wei?等人贊同 推薦幾篇文章：
App工程結構搭建：幾種常見Android代碼架構分析
Architecting Android…The clean way?
A useful stack on android #1, architecture · Saúl M.
......
自己寫了篇博客：?MVVM_Android-CleanArchitecture 編輯于 2015-11-07?1 條評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同7 反對，不會顯示你的姓名 亖葉酢漿草，簡單易懂的現代魔法 Jackson、溫葉、張洋?等人贊同 Android開發，或者說移動終端開發的入門易就不可避免的精通難。低門檻和低要求導致了J2EE程序猿可能要5年才開始考慮的東西移動開發者甚至1年后就開始感到迷茫，例如架構。不才的本人與題主相仿，也是在畢業寫Android幾年后開始從如何實現轉而思考怎么更好的實現。如何抽象，如何接口，如何實現可擴展。當時去github瘋狂的尋找開源工程讀源碼，但大多找到的也只是“寫的很漂亮的代碼”而已。移動終端單打獨斗的特點也許也注定了代碼比起架構更注重完整性和功能性。
所以現在對這點看的挺淡的，盡量將代碼寫的漂亮些，但不過多苛求。也許敏捷的大流行也從一個側面證明了移動開發不要過多的關注架構？ 發布于 2013-07-31?2 條評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同9 反對，不會顯示你的姓名 Golion，會寫代碼 會畫畫 ACG宅 孫海華、Jackson、溫葉?等人贊同 Android本身就是一個MVC框架，Java也是一個重量級的語言。
我覺得，不需要再加新的框架了，增加團隊學習成本了。
你的精力應該花在拆解業務，分成若干個library，如何集成如何分工上面。 發布于 2015-01-01?添加評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同4 反對，不會顯示你的姓名 程睿，Programming nerd 彭芊、許文杰、點墨?等人贊同 Android基本就是一個MVC框架了，你不需要再特別找其他所謂框架進行包裝。我建議從component-oriented design入手，善用繼承來寫出customized widgets。說實話，你只要按照Android Online Documentation操作即可。。。 發布于 2014-07-17?2 條評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同11 反對，不會顯示你的姓名 Keegan小鋼，移動開發者，個人博客：… 王百思、彭芊、程路?等人贊同 網上真的很少有人出來講Android的架構或重構，所以我打算將自己的經驗總結分享出來。有興趣的也可看看，一起討論：

Android項目重構之路:架構篇

Android項目重構之路:界面篇

Android項目重構之路:實現篇

編輯于 2015-10-24?2 條評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同3 反對，不會顯示你的姓名 world hello Jackson、王三、張濤?贊同 KJFrameForAndroid框架，是一個android開發框架，非常好用，直接一行代碼搞定一切，文檔和demo也很齊全。最大的優勢是這個框架是一直在維護的，不像其他的一些爛玩意，用上幾天，一堆問題還沒人維護。https://github.com/kymjs/KJFrameForAndroid 發布于 2014-08-15?3 條評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同1 反對，不會顯示你的姓名 0xc0de4f，程序猿/自由職業者/ruby愛好者 Jackson?贊同 把代碼耦合降低，能抽象的抽象，提高代碼的復用能力。MVC模塊各司其職，不要參雜無關的東西。其實最主要的就是對業務的熟悉吧，把要實現的功能進行合理劃分抽象基本就可以寫出不錯的代碼了 發布于 2014-07-18?添加評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同1 反對，不會顯示你的姓名 Kaede，暇な時、君を想うと、戀いしくて、すれば… Jackson?贊同 除了使用MVP模式，其他的都不要。 發布于 2015-09-03?3 條評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同9 反對，不會顯示你的姓名 于敬業，最美鎖屏，最美壁紙，最美應用，最美的你 孫海華、Jackson、大灰狼?等人贊同 安卓開發也多年，從傳統J2EE開發轉過來，深知過度設計的危害。這些年一直追求把代碼在最小架構下寫的通俗易懂。只是說起來容易做起來難。其實做架構是什么？是把復雜系統高內聚低耦合的能力，往往是應付幾十個人同時協同作戰時能夠有序穩定，相對有節奏。但話說回來，對于app層面的開發，2到3個能力差不多的人就能形成一個高效的整體，一款產品這個開發規模能應付大部分情況，過度復雜的架構設計越來越沒法適應快速的移動產品演進，所以，盡量在基本mvc分層基礎上把代碼寫的通俗易懂，適度重構。

寫安卓代碼就是在搭積木，一個工程關聯七八個library工程是很常見的，難點在如何抽象這些可重用的工程，這也是架構層面需要關注的地方。

安卓開發需要研究的東西實在太多，架構層面個人感覺倒不是安卓上最應該花特別多時間去學習的方向。有時候架構設計能力的提升反倒是學習了另外一門語言瞬間的領悟～ 發布于 2014-07-17?2 條評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同6 反對，不會顯示你的姓名 Lippi OuYang，樂于造輪子 Jackson、木頭人、溫葉?等人贊同 Android學習之路Android學習之路
別人整理的幾個android開源框架值得推薦的android開源框架
別人整理的一些Android項目Trinea/android-open-project · GitHub 編輯于 2015-03-29?添加評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同3 反對，不會顯示你的姓名 歐陽繼超，http://blog.oyanglul.us Jackson、溫葉、匿名用戶?贊同 androidbootstrap 發布于 2013-09-30?添加評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同6 反對，不會顯示你的姓名 陳陽，Andrpid開發工程師。No coding no life 王百思、Jackson、風清云淡?等人贊同 我設計實現了我們公司app的基礎架構，目前實現了

1 業務邏輯和ui邏輯徹底隔離

2 api和activity跳轉均實現配置化管理

3 logcat的配置管理

4 業務邏輯同時支持同步和異步調用，使得可以方便進行業務邏輯本身的拓展和ui調用之間的拓展

5 實現了一套依賴注入框架

6 實現了一套eventbus

7 自定義asyncTask

最近在逐漸開源。文檔和單元測試在慢慢完善。話說單元測試正是個好東西。 編輯于 2015-09-01?11 條評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同2 反對，不會顯示你的姓名 徐鑫炎，Android開發者 kaffa、匿名用戶?贊同 ThinkAndroid首頁、文檔和下載

ThinkAndroid是一個免費的開源的、簡易的、遵循Apache2開源協議發布的Android開發框架，其開發宗旨是簡單、快速的進行Android應用程序的開發，包含Android mvc、簡易sqlite orm、ioc模塊、封裝Android httpclitent的http模塊,具有快速構建文件緩存功能，無需考慮緩存文件的格式，都可以非常輕松的實現緩存，它還基于文件緩存模塊實現了圖片緩存功能，在android中加載的圖片的時候，對oom的問題，和對加載圖片錯位的問題都輕易解決。他還包括了一個手機開發中經常應用的實用工具類，如日志管理，配置文件管理，android下載器模塊，網絡切換檢測等等工具。

目前Think

發布于 2014-07-13?1 條評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同3 反對，不會顯示你的姓名 匿名用戶 許文杰、點墨、沈利峰?贊同 Java語言本身就有過度設計的嫌疑。這是我個人的看法。

開發中，我保持的原則是

盡可能簡潔。

重重構而輕設計。

將類用作重構的手段而不是設計手段。

代碼發展的走向是接口和模塊設計良好，而不是無盡的繼承。

有意識地讓代碼走向混亂，然后重構。

無可奈何才使用設計模式。 發布于 2014-04-17?3 條評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同4 反對，不會顯示你的姓名 吳凱航，密集恐懼癥/尖銳恐懼癥/強迫癥/不發呆會… 九天翼垂云、zh1992、vince wong?等人贊同 按我的感受來說,android開發架構目前追求的主要還是功能性,更多的是以一種"快速開發模板"的意義存在的.對設計模式,接口規范,等等東西看的沒那么重.

我覺得這個和移動終端開發的特性有關系.

一,移動終端的性能目前來說依然遠遠不及桌面終端,而且是不可擴展的(當然,除非你換手機).而在成熟的EE框架中,大量的抽象,代理,托管,緩存等核心元素,都不可避免地占用資源.服務器可以通過升級配置,分布式來解決,但對于性能相對低下且不可擴展的移動終端來說,這些東西有時候就太奢侈了.

二,移動互聯網項目,目前來說遠比傳統項目需要更為靈活快速的開發方式.現在很多項目都是搶時間,這周定一個需求下周就得上,這種時候對于開發人員來說,更愿意接受一個有基礎功能的開發模板,通過快速的開發來達到需要的功能.這種時候,開發人員很傾向于把常用的,相對固定的業務邏輯固化入這個模板以節省時間.所以在我看到的一些所謂框架中,個人風格都比較濃.很可能一家公司視若珍寶完善了很久的框架,在另外一家公司就一文不值--因為基礎的業務邏輯考慮的根本就不一樣. 發布于 2013-08-09?添加評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同2 反對，不會顯示你的姓名 張三 truistic、AndroidLin?贊同 圖片加載框架：fresco?Universal-Image-Loader?GLIDE PICASSO
網絡連接框架：volley?okhttpandroid-async-http
緩存框架：greenDAO 編輯于 2015-10-28?2 條評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同1 反對，不會顯示你的姓名 阮鵬飛 王湘云?贊同 androidannotations 極力推薦一塊高效運行的控件注入框架 發布于 2015-07-14?添加評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同0 反對，不會顯示你的姓名 王冕，只會C 私以為，在能夠保證工程師素養的前提下，敏捷開發，快速迭代才是最有效的開發模式。 編輯于 2014-09-19?添加評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同0 反對，不會顯示你的姓名 匿名用戶 覺著只要掌握了Android本身的東西，框架就無所謂了，如果想偷懶的話，學一個也是不錯 發布于 2015-02-17?添加評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同0 反對，不會顯示你的姓名 妄想癥的貓，yi.desk shinado/netframe · GitHub
試試這個吧 發布于 2015-03-20?添加評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同0 反對，不會顯示你的姓名 王生輝 大家發的開運項目 都不錯的樣子啊。 發布于 2015-06-04?添加評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同0 反對，不會顯示你的姓名 小馬甲，android手機軟件開發人員 mark一下. 發布于 2015-08-27?添加評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同0 反對，不會顯示你的姓名 doxvxob，說出來被嘲笑的夢想才有實現的價值 馬一個 發布于 2015-10-19?添加評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同0 反對，不會顯示你的姓名 匿名用戶 mark一下. 發布于 2015-10-30?添加評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同1 反對，不會顯示你的姓名 匿名用戶 曾藝樂?贊同 高煥堂老師的EIT架構，可以去看看Android橫掃千軍系列中的架構知識。 發布于 2013-09-30?添加評論?感謝? 分享 ?收藏???沒有幫助??? 舉報 ???作者保留權利 贊同0 反對，不會顯示你的姓名 洪俊敏，stay out of your comfort zone android本身即是MVC了，所以我覺得可以發揮的地方是這三個模塊的解耦和模塊內的設計，比如怎么設計自定義的組件（builder模式等），組件能否與業務和呈現分離；能否用基類等方式設計抽象出比如activity生命周期回調，異步線程調用的共同的流程；用style和include等方法盡量讓布局文件易于維護和復用。閉包等概念都能讓你設計出更好的模型。這些東西在Android 源碼和類似 efficient java中都能學到。我目前在做公司三個APP的合并，抽象出可以復用的業務邏輯和工具性的代碼作為lib,也就是android studio里的module， 也是覺得要耗費一番精力。

總結

以上是生活随笔為你收集整理的Android 开发有什么好的架构么?的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。