Android 開發有什麼好的架構么?
做了幾年Android開發，也算是個半吊子的開發者了。但是從大公司到小公司，要麼程序的結構亂七八糟，別說耦合什麼的了，根本找不到功能的代碼；要麼就是有個看似牛逼的架構師(往往是j2me或者j2ee轉過來的），然後搞一套套的設計方法，設計模式，代碼到是比較能看懂，但是冗餘多的令人髮指，動不動就是interface factory abs類一坨坨，最後就做了別人十幾行代碼的事兒。
各位有推薦什麼好的Android開發框架或者好的開源項目也行，不勝感激。
現在很厲害的
GitHub - googlesamples/android-architecture: A collection of samples to discuss and showcase different architectural tools and patterns for Android apps.—————以前很厲害的———————————
最近正在學習google/iosched · GitHub，Google出品，異曲同工，比下面原答案更易學，更優雅。
這個是我們團隊一直推崇而且現在正在使用的架構
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推薦幾篇文章：
App工程結構搭建：幾種常見Android代碼架構分析
Architecting Android…The clean way?A useful stack on android #1, architecture · Saúl M.......自己寫了篇博客： MVVM_Android-CleanArchitecture你說這個我想了上次還被老大批了--過度設計了。過多考慮未來的需求和變動了就設計過度了，於是出現了就真是幾十行的代碼，寫出各種類各種介面。 最近學到的倒是基於android特性進行開發，ui上可以從需求分析到android控制項的選擇比如fragment,slidingmenu,actionbar,navigation drawer等。 整體架構上，資料庫層和ui刷新，數據非同步讀取，使用contentprovider（資料庫操作像rest api一樣的風格）,cursorloader,網路請求的intentservice,resultreceiver,gson等。 設計思路上，分層--還是走的mvc嘛，雖然最近也有用mvp，不過不管怎麼樣關鍵還是要有分層的意識吧；解耦--面向介面編程啊，依賴倒置都是；抽象能力：其實我覺得抽象能力很重要的，不過自己現在抽象能力也很弱，沒啥建議。 好的開源項目：我覺得倒是沒什麼統一框架，可以看看foursquare,google io app的源碼都是相當好的，android源碼永遠是值得讀的。
文中很多知識學自這逼@李彬，建議關注，不過這逼很裝逼。
網上真的很少有人出來講Android的架構或重構，所以我打算將自己的經驗總結分享出來。有興趣的也可看看，一起討論：
Android項目重構之路:架構篇
Android項目重構之路:界面篇
Android項目重構之路:實現篇
Android本身就是一個MVC框架，Java也是一個重量級的語言。我覺得，不需要再加新的框架了，增加團隊學習成本了。你的精力應該花在拆解業務，分成若干個library，如何集成如何分工上面。
Android開發，或者說移動終端開發的入門易就不可避免的精通難。低門檻和低要求導致了J2EE程序猿可能要5年才開始考慮的東西移動開發者甚至1年後就開始感到迷茫，例如架構。不才的本人與題主相仿，也是在畢業寫Android幾年後開始從如何實現轉而思考怎麼更好的實現。如何抽象，如何介面，如何實現可擴展。當時去github瘋狂的尋找開源工程讀源碼，但大多找到的也只是「寫的很漂亮的代碼」而已。移動終端單打獨鬥的特點也許也註定了代碼比起架構更注重完整性和功能性。
所以現在對這點看的挺淡的，盡量將代碼寫的漂亮些，但不過多苛求。也許敏捷的大流行也從一個側面證明了移動開發不要過多的關注架構？
Android基本就是一個MVC框架了，你不需要再特別找其他所謂框架進行包裝。我建議從component-oriented design入手，善用繼承來寫出customized widgets。說實話，你只要按照Android Online Documentation操作即可。。。
最近有人寫出了一篇Android Clean Architecture的簡化版，原文在這裡：
A detailed guide on developing Android apps using the Clean Architecture pattern相比之前Uncle Bob的那一篇的源代碼，GitHub - android10/Android-CleanArchitecture: This is a sample app that is part of a series of blog posts I have written about how to architect an android application using Uncle Bob"s clean architecture approach.
這一篇的源代碼，GitHub - dmilicic/Android-Clean-Boilerplate: This is starter template for writing Android apps using Clean architecture
更加簡單，之前的那一篇使用了RxJava，Dagger 2等需要花時間理解學習的框架，再加上本身Clean Architechture也需要一些精力去理解，因此顯得比較繞人。這一篇將之前的那一篇中使用的高大上的框架拋棄了，因此會顯得邏輯更加清晰易懂一些。看完了這一篇，再去看之前的那一篇Uncle Bob的，可能會有一種撥雲見日的感覺。安卓開發也多年，從傳統J2EE開發轉過來，深知過度設計的危害。這些年一直追求把代碼在最小架構下寫的通俗易懂。只是說起來容易做起來難。其實做架構是什麼？是把複雜系統高內聚低耦合的能力，往往是應付幾十個人同時協同作戰時能夠有序穩定，相對有節奏。但話說回來，對於app層面的開發，2到3個能力差不多的人就能形成一個高效的整體，一款產品這個開發規模能應付大部分情況，過度複雜的架構設計越來越沒法適應快速的移動產品演進，所以，盡量在基本mvc分層基礎上把代碼寫的通俗易懂，適度重構。
寫安卓代碼就是在搭積木，一個工程關聯七八個library工程是很常見的，難點在如何抽象這些可重用的工程，這也是架構層面需要關注的地方。
安卓開發需要研究的東西實在太多，架構層面個人感覺倒不是安卓上最應該花特別多時間去學習的方向。有時候架構設計能力的提升反倒是學習了另外一門語言瞬間的領悟～
最近看了不少Android開發架構方面的文章和DEMO，也想說下我的理解:
比較流行開發架構有：The clean architecture（Presentation/UI展示層、DOMAIN層/業務邏輯層，data/數據層）, 還有 MVP/MVVM（UI展示層、業務邏輯層），都是基於軟體架構分層的思想。分層是為了讓每一層各自執行特定的職能，並且通過介面進行隔離，降低耦合性，避免在軟體迭代過程中，需求改動導致牽一髮而動全身，影響功能的穩定性，增加項目維護的成本。另外，如果涉及到單元測試，也可以充分體現軟體分層架構的意義和價值。在實際開發中，到底採用什麼架構？分層是分2層、3層，甚至更多層？其實按我的理解，應該根據項目的業務需求來決定。不能不考慮實際的業務需求而抱死一種開發架構不放，就目前Android開發方面的情況來說，大多數APP的實現的流程都是從服務端拉取數據，然後進行展示，可能不涉及特定領域內特別複雜的業務邏輯，採用mvp/mvvm的開發模式是比較合適的，但某些APP，在獲取到數據後，還涉及安全、支付、驗證等特定領域的業務邏輯處理，那麼再獨立分出一個「Domain/業務邏輯層」還是有必要的，增加分層其實就是為了隔離變化，方便擴展。
總之，我認為軟體架構設計歸根結底是一種根據需求進行分層設計的規範，另外，Android客戶端目前也出現不少新的技術，如：dragger2, rxjava, retrofit 都是幫助我們提升開發效率或降低耦合性的技術方案，我們在實際開發過程中，可以不採用或者選擇性採用這些新技術，但都不影響我們按照分層的思路去設計或選擇軟體架構。
附帶一些參考文章鏈接：
一. The Clean Architecture相關文章
1. The clean Architecture （出處：Bob大叔最早提出分層框架）
原文:The Clean Architecture
翻譯:乾淨的架構The Clean Architecture2. Fernando Cejas基於「The Clean Architecture」的思想將其應用到android開發領域
2.1. Architecting Android…The clean way?(一種更清晰的Android架構？)
原文：http://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/翻譯：一種更清晰的Android架構 - 開發技術前線 - 知乎專欄2.2. Architecting Android…The evolution（實戰解析Android架構設計原則）
原文：http://fernandocejas.com/2015/07/18/architecting-android-the-evolution/翻譯：實戰解析Android架構設計原則-CSDN.NETgithub地址：
GitHub - android10/Android-CleanArchitecture: This is a sample app that is part of a series of blog posts I have written about how to architect an android application using Uncle Bob"s clean architecture approach.備註：在Issues目錄下有大家針對這個架構提出的疑問，如果在是使用過程中有疑惑也可以參考下。二. MVP方面的文章太多了，推薦一篇圖文並茂、通熟易懂的文章：
1. ANDROID應用開發架構概述
Android應用開發架構概述
備註：講清楚了MVC如何演變到MVP的過程以及為什麼要採用mvp開發模式。2. ANDROID應用架構之MVP實現
Android應用架構之MVP實現備註：github代碼：GitHub - liuguangli/MVPTeach: 登錄為業務場景對比非MVP和MVP設計的例子源碼包含 nolevel(不分層的代碼)、 badmvp(不好的mvp代碼)、 mvplevel（正確的例子），方便對比：）Android學習之路Android學習之路別人整理的幾個android開源框架值得推薦的android開源框架別人整理的一些Android項目Trinea/android-open-project · GitHub
我這幾天正好學習mvp，你可以看下這個GitHub - liuyanggithub/SuperMvp: 新聞+美圖大全+天氣預報+MVP+Material+Rx+Retrofit+Glide+leakcanary+butterknife(Android一些新技術的合集)
菜鳥級別不喜輕噴。當一個只需要做較為簡單頁面交互和展示和數據交互邏輯，使用MVP，MVVM就足夠了。當公司迅速發展，需要承載更多的業務的時候，這時會發現，只用MVP，你的任務（Task）是各式各樣，你要保存一個一份數據發現了N種介面（FileUtils, SharePrefrence等等），http，downloader是和邏輯相關沒有框架只有各種耦合。這時需要把任務隊列、Cache，Downloder，http寫成一個通用的模塊（框架）。當業務更為複雜的時候，你會發現，除了公用模塊之外，其它都無法復用了，複雜的業務邏輯（如訂單管理，購物車，等等），這時需要把複雜的業務做成獨立的模塊（組件）。鄙人認為，好的架構需要根據特定業務（需求）而言的，MVP（MVC）只是架構的一個點。鄙人也見過，拉取各種開源框架，搭建一個項目（架構），最後他也不知道這是幹嘛的，要解決什麼問題，或者說拉取一個EventBus特么就在一個頁面和服務間進行通信而不是把整個項目標準化使用標準通信庫，最後也是各種混亂。鄙人設計過一個千萬級用戶量的app的Android端架構（也挺爛的，也夠用），架構分為三層，頁面（數據）交互層，該層使用的是MVP模式，中間為通用的模塊層（ImageLoader, Cache, Downloader, Http, Json2Obj, JobManager等），底層為核心模塊層（socket和一些管理模塊[如插件管理器]）。總得來說，相對於有些app，整體看起來沒那麼複雜，新人半天即可知道整體架構和規範。結對編程也相對容易，A寫的代碼交給我，立馬就知道問題在哪裡了。鄙人還認為，做架構，應該知道怎麼分層，把複雜的問題簡單化，盡量讓模塊是可復用的。要了解設計模式，了解MVP,MVVM,MVC，了解AOP，響應式編程，驅動模型，插件框架等。大概想到這麼多，歡迎大神指正。
按我的感受來說,android開發架構目前追求的主要還是功能性,更多的是以一種"快速開發模板"的意義存在的.對設計模式,介面規範,等等東西看的沒那麼重.
我覺得這個和移動終端開發的特性有關係.
一,移動終端的性能目前來說依然遠遠不及桌面終端,而且是不可擴展的(當然,除非你換手機).而在成熟的EE框架中,大量的抽象,代理,託管,緩存等核心元素,都不可避免地佔用資源.伺服器可以通過升級配置,分散式來解決,但對於性能相對低下且不可擴展的移動終端來說,這些東西有時候就太奢侈了.
二,移動互聯網項目,目前來說遠比傳統項目需要更為靈活快速的開發方式.現在很多項目都是搶時間,這周定一個需求下周就得上,這種時候對於開發人員來說,更願意接受一個有基礎功能的開發模板,通過快速的開發來達到需要的功能.這種時候,開發人員很傾向於把常用的,相對固定的業務邏輯固化入這個模板以節省時間.所以在我看到的一些所謂框架中,個人風格都比較濃.很可能一家公司視若珍寶完善了很久的框架,在另外一家公司就一文不值--因為基礎的業務邏輯考慮的根本就不一樣.我設計實現了我們公司app的基礎架構，目前實現了
1 業務邏輯和ui邏輯徹底隔離
2 api和activity跳轉均實現配置化管理
3 logcat的配置管理
4 業務邏輯同時支持同步和非同步調用，使得可以方便進行業務邏輯本身的拓展和ui調用之間的拓展
5 實現了一套依賴注入框架
6 實現了一套eventbus
7 自定義asyncTask
最近在逐漸開源。文檔和單元測試在慢慢完善。話說單元測試正是個好東西。是時候安利自己寫的關於MVP架構的文章了。?Android架構篇－－從零開始搭建 一個完善的 MVP模式開發框架（一），MVP模式的簡單介紹篇Android架構篇——從零開始搭建一個完善的MVP開發框架（二），通過泛型和抽象，簡化MVP框架。Android框架篇—— 從零開始搭建一個完善的MVP開發框架(三)，對列表型數據請求進行抽象，優化列表型數據的處理第四篇還在編寫中，我得文筆比較爛，估計很多人會看不懂。所以下面的大招是github源碼：這是我寫的關於優化MVP模式的一個框架，目前還不是十分完善，歡迎大家一起探討。GitHub - DobbyTang/mvp-android-framework下面是我的blog地址，裡面會不定期更新關於Android的一些技術文章技術乾貨分享, Android, RxJava TANG BLOG
Android應用開發架構概述
androidbootstrap
Java語言本身就有過度設計的嫌疑。這是我個人的看法。
開發中，我保持的原則是
儘可能簡潔。
重重構而輕設計。
將類用作重構的手段而不是設計手段。
代碼發展的走向是介面和模塊設計良好，而不是無盡的繼承。
有意識地讓代碼走向混亂，然後重構。
無可奈何才使用設計模式。1、AndBase框架， 項目地址： https://code.jd.com/zhaoqp2010_m/andbase
2、XUtil框架， 項目地址：https://github.com/wyouflf/xUtils
3、ThinkAndroid框架，項目地址：https://github.com/white-cat/ThinkAndroid
4、LoonAndroid，項目地址：https://github.com/gdpancheng/LoonAndroid
5、volley，項目地址 ：https://github.com/smanikandan14/Volley-demo
6、android-async-http，項目地址：https://github.com/loopj/android-async-http
文檔介紹：http://loopj.com/android-async-http/
7、Afinal框架,項目地址：https://github.com/yangfuhai/afinal
最後再推薦一款APP數據統計分析工具Cobub Razor，開源項目下載地址https://github.com/cobub/razor
推薦閱讀：
※Android 應用的真正入口是哪裡？
※有哪些大齡非 CS 科班出身的青年轉行程序員，結果失敗的例子？
※怎樣搭高質量的Android項目框架，框架的結構具體描述？
※Android的UI底層是用CPU繪圖的還是GPU繪圖的呢？以及surfaceview,window,普通view是如何實現的？