做了几年Android开发，也算是个半吊子的开发者了。但是从大公司到小公司，要么程序的结构乱七八糟，别说耦合什么的了，根本找不到功能的代码；要么就是有个看似牛逼的架构师(往往是j2me或者j2ee转过来的），然后搞一套套的设计方法，设计模式，代码到是比较能看懂，但是冗余多的令人发指，动不动就是interface factory abs类一坨坨，最后就做了别人十几行代码的事儿。
各位有推荐什么好的Android开发框架或者好的开源项目也行，不胜感激。 修改
各位有推荐什么好的Android开发框架或者好的开源项目也行，不胜感激。 修改
按投票排序
按时间排序
28 个回答
这个是我们团队一直推崇而且现在正在使用的架构
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
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
你说这个我想了上次还被老大批了--过度设计了。过多考虑未来的需求和变动了就设计过度了，于是出现了就真是几十行的代码，写出各种类各种接口。
最近学到的倒是基于android特性进行开发，ui上可以从需求分析到android控件的选择比如fragment,slidingmenu,actionbar,navigation drawer等。
整体架构上，数据库层和ui刷新，数据异步读取，使用contentprovider（数据库操作像rest api一样的风格）,cursorloader,网络请求的intentservice,resultreceiver,gson等。
设计思路上，分层--还是走的mvc嘛，虽然最近也有用mvp，不过不管怎么样关键还是要有分层的意识吧；解耦--面向接口编程啊，依赖倒置都是；抽象能力：其实我觉得抽象能力很重要的，不过自己现在抽象能力也很弱，没啥建议。
好的开源项目：我觉得倒是没什么统一框架，可以看看foursquare,google io app的源码都是相当好的，android源码永远是值得读的。
文中很多知识学自这逼 @李彬，建议关注，不过这逼很装逼。
最近学到的倒是基于android特性进行开发，ui上可以从需求分析到android控件的选择比如fragment,slidingmenu,actionbar,navigation drawer等。
整体架构上，数据库层和ui刷新，数据异步读取，使用contentprovider（数据库操作像rest api一样的风格）,cursorloader,网络请求的intentservice,resultreceiver,gson等。
设计思路上，分层--还是走的mvc嘛，虽然最近也有用mvp，不过不管怎么样关键还是要有分层的意识吧；解耦--面向接口编程啊，依赖倒置都是；抽象能力：其实我觉得抽象能力很重要的，不过自己现在抽象能力也很弱，没啥建议。
好的开源项目：我觉得倒是没什么统一框架，可以看看foursquare,google io app的源码都是相当好的，android源码永远是值得读的。
文中很多知识学自这逼 @李彬，建议关注，不过这逼很装逼。
Android开发，或者说移动终端开发的入门易就不可避免的精通难。低门槛和低要求导致了J2EE程序猿可能要5年才开始考虑的东西移动开发者甚至1年后就开始感到迷茫，例如架构。不才的本人与题主相仿，也是在毕业写Android几年后开始从如何实现转而思考怎么更好的实现。如何抽象，如何接口，如何实现可扩展。当时去github疯狂的寻找开源工程读源码，但大多找到的也只是“写的很漂亮的代码”而已。移动终端单打独斗的特点也许也注定了代码比起架构更注重完整性和功能性。
所以现在对这点看的挺淡的，尽量将代码写的漂亮些，但不过多苛求。也许敏捷的大流行也从一个侧面证明了移动开发不要过多的关注架构？
所以现在对这点看的挺淡的，尽量将代码写的漂亮些，但不过多苛求。也许敏捷的大流行也从一个侧面证明了移动开发不要过多的关注架构？
Android基本就是一个MVC框架了，你不需要再特别找其他所谓框架进行包装。我建议从component-oriented design入手，善用继承来写出customized widgets。说实话，你只要按照Android Online Documentation操作即可。。。
KJFrameForAndroid框架，是一个android开发框架，非常好用，直接一行代码搞定一切，文档和demo也很齐全。最大的优势是这个框架是一直在维护的，不像其他的一些烂玩意，用上几天，一堆问题还没人维护。
https://github.com/kymjs/KJFrameForAndroid
安卓开发也多年，从传统J2EE开发转过来，深知过度设计的危害。这些年一直追求把代码在最小架构下写的通俗易懂。只是说起来容易做起来难。其实做架构是什么？是把复杂系统高内聚低耦合的能力，往往是应付几十个人同时协同作战时能够有序稳定，相对有节奏。但话说回来，对于app层面的开发，2到3个能力差不多的人就能形成一个高效的整体，一款产品这个开发规模能应付大部分情况，过度复杂的架构设计越来越没法适应快速的移动产品演进，所以，尽量在基本mvc分层基础上把代码写的通俗易懂，适度重构。
写安卓代码就是在搭积木，一个工程关联七八个library工程是很常见的，难点在如何抽象这些可重用的工程，这也是架构层面需要关注的地方。
安卓开发需要研究的东西实在太多，架构层面个人感觉倒不是安卓上最应该花特别多时间去学习的方向。有时候架构设计能力的提升反倒是学习了另外一门语言瞬间的领悟～
写安卓代码就是在搭积木，一个工程关联七八个library工程是很常见的，难点在如何抽象这些可重用的工程，这也是架构层面需要关注的地方。
安卓开发需要研究的东西实在太多，架构层面个人感觉倒不是安卓上最应该花特别多时间去学习的方向。有时候架构设计能力的提升反倒是学习了另外一门语言瞬间的领悟～
Android学习之路
Android学习之路
别人整理的几个android开源框架 值得推荐的android开源框架
别人整理的一些Android项目 Trinea/android-open-project · GitHub
别人整理的几个android开源框架 值得推荐的android开源框架
别人整理的一些Android项目 Trinea/android-open-project · GitHub
我设计实现了我们公司app的基础架构，目前实现了
1 业务逻辑和ui逻辑彻底隔离
2 api和activity跳转均实现配置化管理
3 logcat的配置管理
4 业务逻辑同时支持同步和异步调用，使得可以方便进行业务逻辑本身的拓展和ui调用之间的拓展
5 实现了一套依赖注入框架
6 实现了一套eventbus
7 自定义asyncTask
最近在逐渐开源。文档和单元测试在慢慢完善。话说单元测试正是个好东西。
1 业务逻辑和ui逻辑彻底隔离
2 api和activity跳转均实现配置化管理
3 logcat的配置管理
4 业务逻辑同时支持同步和异步调用，使得可以方便进行业务逻辑本身的拓展和ui调用之间的拓展
5 实现了一套依赖注入框架
6 实现了一套eventbus
7 自定义asyncTask
最近在逐渐开源。文档和单元测试在慢慢完善。话说单元测试正是个好东西。
ThinkAndroid首页、文档和下载
ThinkAndroid是一个免费的开源的、简易的、遵循Apache2开源协议发布的Android开发框架，其开发宗旨是简单、快速的进行Android应用程序的开发，包含Android mvc、简易sqlite orm、ioc模块、封装Android httpclitent的http模块,具有快速构建文件缓存功能，无需考虑缓存文件的格式，都可以非常轻松的实现缓存，它还基于文件缓存模块实现了图片缓存功能，在android中加载的图片的时候，对oom的问题，和对加载图片错位的问题都轻易解决。他还包括了一个手机开发中经常应用的实用工具类，如日志管理，配置文件管理，android下载器模块，网络切换检测等等工具。
目前Think
按我的感受来说,android开发架构目前追求的主要还是功能性,更多的是以一种"快速开发模板"的意义存在的.对设计模式,接口规范,等等东西看的没那么重.
我觉得这个和移动终端开发的特性有关系.
一,移动终端的性能目前来说依然远远不及桌面终端,而且是不可扩展的(当然,除非你换手机).而在成熟的EE框架中,大量的抽象,代理,托管,缓存等核心元素,都不可避免地占用资源.服务器可以通过升级配置,分布式来解决,但对于性能相对低下且不可扩展的移动终端来说,这些东西有时候就太奢侈了.
二,移动互联网项目,目前来说远比传统项目需要更为灵活快速的开发方式.现在很多项目都是抢时间,这周定一个需求下周就得上,这种时候对于开发人员来说,更愿意接受一个有基础功能的开发模板,通过快速的开发来达到需要的功能.这种时候,开发人员很倾向于把常用的,相对固定的业务逻辑固化入这个模板以节省时间.所以在我看到的一些所谓框架中,个人风格都比较浓.很可能一家公司视若珍宝完善了很久的框架,在另外一家公司就一文不值--因为基础的业务逻辑考虑的根本就不一样.
我觉得这个和移动终端开发的特性有关系.
一,移动终端的性能目前来说依然远远不及桌面终端,而且是不可扩展的(当然,除非你换手机).而在成熟的EE框架中,大量的抽象,代理,托管,缓存等核心元素,都不可避免地占用资源.服务器可以通过升级配置,分布式来解决,但对于性能相对低下且不可扩展的移动终端来说,这些东西有时候就太奢侈了.
二,移动互联网项目,目前来说远比传统项目需要更为灵活快速的开发方式.现在很多项目都是抢时间,这周定一个需求下周就得上,这种时候对于开发人员来说,更愿意接受一个有基础功能的开发模板,通过快速的开发来达到需要的功能.这种时候,开发人员很倾向于把常用的,相对固定的业务逻辑固化入这个模板以节省时间.所以在我看到的一些所谓框架中,个人风格都比较浓.很可能一家公司视若珍宝完善了很久的框架,在另外一家公司就一文不值--因为基础的业务逻辑考虑的根本就不一样.
图片加载框架：fresco
Universal-Image-Loader GLIDE PICASSO
网络连接框架：volley okhttp android-async-http
缓存框架：greenDAO
网络连接框架：volley okhttp android-async-http
缓存框架：greenDAO
扫一扫
5775
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
