赞同18 反对，不会显示你的姓名

这个是我们团队一直推崇而且现在正在使用的架构
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 反对，不会显示你的姓名

你说这个我想了上次还被老大批了--过度设计了。过多考虑未来的需求和变动了就设计过度了，于是出现了就真是几十行的代码，写出各种类各种接口。
最近学到的倒是基于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 反对，不会显示你的姓名

推荐几篇文章：
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 反对，不会显示你的姓名

Android开发，或者说移动终端开发的入门易就不可避免的精通难。低门槛和低要求导致了J2EE程序猿可能要5年才开始考虑的东西移动开发者甚至1年后就开始感到迷茫，例如架构。不才的本人与题主相仿，也是在毕业写Android几年后开始从如何实现转而思考怎么更好的实现。如何抽象，如何接口，如何实现可扩展。当时去github疯狂的寻找开源工程读源码，但大多找到的也只是“写的很漂亮的代码”而已。移动终端单打独斗的特点也许也注定了代码比起架构更注重完整性和功能性。
所以现在对这点看的挺淡的，尽量将代码写的漂亮些，但不过多苛求。也许敏捷的大流行也从一个侧面证明了移动开发不要过多的关注架构？

发布于 2013-07-31 2 条评论 感谢

收藏 • 没有帮助 •

• 作者保留权利

赞同9 反对，不会显示你的姓名

Android本身就是一个MVC框架，Java也是一个重量级的语言。
我觉得，不需要再加新的框架了，增加团队学习成本了。
你的精力应该花在拆解业务，分成若干个library，如何集成如何分工上面。

发布于 2015-01-01 添加评论 感谢

收藏 • 没有帮助 •

• 作者保留权利

赞同4 反对，不会显示你的姓名

Android基本就是一个MVC框架了，你不需要再特别找其他所谓框架进行包装。我建议从component-oriented design入手，善用继承来写出customized widgets。说实话，你只要按照Android Online Documentation操作即可。。。

发布于 2014-07-17 2 条评论 感谢

收藏 • 没有帮助 •

• 作者保留权利

赞同11 反对，不会显示你的姓名

网上真的很少有人出来讲Android的架构或重构，所以我打算将自己的经验总结分享出来。有兴趣的也可看看，一起讨论：

Android项目重构之路:架构篇

Android项目重构之路:界面篇

Android项目重构之路:实现篇

编辑于 2015-10-24 2 条评论 感谢

收藏 • 没有帮助 •

• 作者保留权利

赞同3 反对，不会显示你的姓名

KJFrameForAndroid框架，是一个android开发框架，非常好用，直接一行代码搞定一切，文档和demo也很齐全。最大的优势是这个框架是一直在维护的，不像其他的一些烂玩意，用上几天，一堆问题还没人维护。https://github.com/kymjs/KJFrameForAndroid

发布于 2014-08-15 3 条评论 感谢

收藏 • 没有帮助 •

• 作者保留权利

赞同1 反对，不会显示你的姓名

把代码耦合降低，能抽象的抽象，提高代码的复用能力。MVC模块各司其职，不要参杂无关的东西。其实最主要的就是对业务的熟悉吧，把要实现的功能进行合理划分抽象基本就可以写出不错的代码了

发布于 2014-07-18 添加评论 感谢

收藏 • 没有帮助 •

• 作者保留权利

赞同1 反对，不会显示你的姓名

除了使用MVP模式，其他的都不要。

发布于 2015-09-03 3 条评论 感谢

收藏 • 没有帮助 •

• 作者保留权利

赞同9 反对，不会显示你的姓名

安卓开发也多年，从传统J2EE开发转过来，深知过度设计的危害。这些年一直追求把代码在最小架构下写的通俗易懂。只是说起来容易做起来难。其实做架构是什么？是把复杂系统高内聚低耦合的能力，往往是应付几十个人同时协同作战时能够有序稳定，相对有节奏。但话说回来，对于app层面的开发，2到3个能力差不多的人就能形成一个高效的整体，一款产品这个开发规模能应付大部分情况，过度复杂的架构设计越来越没法适应快速的移动产品演进，所以，尽量在基本mvc分层基础上把代码写的通俗易懂，适度重构。

写安卓代码就是在搭积木，一个工程关联七八个library工程是很常见的，难点在如何抽象这些可重用的工程，这也是架构层面需要关注的地方。

安卓开发需要研究的东西实在太多，架构层面个人感觉倒不是安卓上最应该花特别多时间去学习的方向。有时候架构设计能力的提升反倒是学习了另外一门语言瞬间的领悟～

发布于 2014-07-17 2 条评论 感谢

收藏 • 没有帮助 •

• 作者保留权利

赞同6 反对，不会显示你的姓名

Android学习之路Android学习之路
别人整理的几个android开源框架值得推荐的android开源框架
别人整理的一些Android项目Trinea/android-open-project · GitHub

编辑于 2015-03-29 添加评论 感谢

收藏 • 没有帮助 •

• 作者保留权利

赞同3 反对，不会显示你的姓名

androidbootstrap

发布于 2013-09-30 添加评论 感谢

收藏 • 没有帮助 •

• 作者保留权利

赞同6 反对，不会显示你的姓名

我设计实现了我们公司app的基础架构，目前实现了

1 业务逻辑和ui逻辑彻底隔离

2 api和activity跳转均实现配置化管理

3 logcat的配置管理

4 业务逻辑同时支持同步和异步调用，使得可以方便进行业务逻辑本身的拓展和ui调用之间的拓展

5 实现了一套依赖注入框架

6 实现了一套eventbus

7 自定义asyncTask

最近在逐渐开源。文档和单元测试在慢慢完善。话说单元测试正是个好东西。

编辑于 2015-09-01 11 条评论 感谢

收藏 • 没有帮助 •

• 作者保留权利

赞同2 反对，不会显示你的姓名

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 反对，不会显示你的姓名

按我的感受来说,android开发架构目前追求的主要还是功能性,更多的是以一种"快速开发模板"的意义存在的.对设计模式,接口规范,等等东西看的没那么重.

我觉得这个和移动终端开发的特性有关系.

一,移动终端的性能目前来说依然远远不及桌面终端,而且是不可扩展的(当然,除非你换手机).而在成熟的EE框架中,大量的抽象,代理,托管,缓存等核心元素,都不可避免地占用资源.服务器可以通过升级配置,分布式来解决,但对于性能相对低下且不可扩展的移动终端来说,这些东西有时候就太奢侈了.

二,移动互联网项目,目前来说远比传统项目需要更为灵活快速的开发方式.现在很多项目都是抢时间,这周定一个需求下周就得上,这种时候对于开发人员来说,更愿意接受一个有基础功能的开发模板,通过快速的开发来达到需要的功能.这种时候,开发人员很倾向于把常用的,相对固定的业务逻辑固化入这个模板以节省时间.所以在我看到的一些所谓框架中,个人风格都比较浓.很可能一家公司视若珍宝完善了很久的框架,在另外一家公司就一文不值--因为基础的业务逻辑考虑的根本就不一样.

发布于 2013-08-09 添加评论 感谢

收藏 • 没有帮助 •

• 作者保留权利

赞同2 反对，不会显示你的姓名

图片加载框架：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， 也是觉得要耗费一番精力。