博客原地址：http://blog.csdn.net/u013278099/article/details/51485476
前言
最近公司的另一个项目又要立项了，作为公司的唯一安卓工程师任务来了（新来的移动端的老大说项目还是主要你负责，我就负责帮你们安排下进度），听了这话我是伤心的在这公司不管是几个还是1个安卓开发都是我来搭建，干着与工资不符的事情，好的一点是开发没有人干涉平时也能学习自己想学的东西。
如何选择app架构（MVC/MVP/MVVM）
最近越来越多的人开始谈论架构。我周围的同事和工程师也是如此。尽管我还不是特别深入理解MVP，但是还是觉得比较牛逼,然后呢也想在公司的项目中去使用它。
项目时间紧迫：快速开发框架（迫不得已）
目前网络上也有一些针对Android的快速开发框架，下面介绍3个主要的快速开发框架。针对这些快速开发框架，个人认为可以参考，但并不推荐使用，因为App整体依赖一个个人维护的框架风险实在太大，框架存在一些学习成本，本身也不一定完全符合App的需求，使用后可能存在代码的臃肿，还有就是架构限制。
-
Afinal
GitHub项目地址：Afinal
Afinal是一个Android的IOC，ORM框架，内置了四大模块功能：FinalAcitivity, FinalBitmap, FinalDb, FinalHttp。通过FinalActivity，可以通过注解的方式进行绑定UI和事件。通过FinalBitmap，可以方便的加载Bitmap图片，而无需考虑OOM等问题。通过FinalDB模块，通过一行代码就可以对Android的SQlite数据库进行增删改查。通过FinalHttp模块，可以以Ajax形式请求Http数据。
然而项目从去年就没有人更新维护了，ioc框架很多人不太喜欢而且性能不好。
-
xUtils3.0
GitHub项目地址：xUtils3.0
- xUtils 支持超大文件(超过2G)上传，更全面的http请求协议支持(11种谓词)，拥有更加灵活的ORM，更多的事件注解支持且不受混淆影响…
- xUtils 最低兼容Android 4.0 (api level 14). (Android 2.3?)
-
xUtils3变化较多所以建立了新的项目不在旧版(github.com/wyouflf/xUtils)上继续维护, 相对于旧版本:
- HTTP实现替换HttpClient为UrlConnection, 自动解析回调泛型, 更安全的断点续传策略.
- 支持标准的Cookie策略, 区分domain, path…
- 事件注解去除不常用的功能, 提高性能.
- 数据库api简化提高性能, 达到和greenDao一致的性能.
- 图片绑定支持gif(受系统兼容性影响, 部分gif文件只能静态显示), webp; 支持圆角, 圆形, 方形等裁剪, 支持自动旋转…
可以看出xUtils3对于快速开发是一个不错的选择。
自己从零开始搭建app架构
简单的看下这三个架构模式：
- MVC：Model-View-Controller，经典模式，很容易理解，主要缺点有两个：
View对Model的依赖，会导致View也包含了业务逻辑；
Controller会变得很厚很复杂。 - MVP：Model-View-Presenter，MVC的一个演变模式，将Controller换成了Presenter，主要为了解决上述第一个缺点，将View和Model解耦，不过第二个缺点依然没有解决。
- MVVM：Model-View-ViewModel，是对MVP的一个优化模式，采用了双向绑定：View的变动，自动反映在ViewModel，反之亦然。
面对众多的架构模式你会选择哪个？
MVC，MVP还是MVVM？
越高级的模式复杂性越高，实现起来也越难。然后搭建项目时也是看项目的需求，别人说好你也有要实用才好，高效的实现项目的功能才是最好的架构模式。
那么，哪一个才是最好的呢？
个人觉得适合你的才是最好的，不要去盲目的跟风，大家说mvp好那你就使用咯，没有实践就没有话语权，所以说用哪种架构模式本人不发表任何意见：任何模式的动机都是一样的，那就是如何避免复杂混乱的代码，让执行单元测试变得容易，创造高质量应用程序，开发维护更高效。
在实际项目中思考架构时，也不会想着要用哪种模式，我只思考现阶段，以现有的人力资源和时间资源，如何才能更快更好地完成需求，适当考虑下如何为后期扩展或重构做准备。
我项目中的架构
这是我上一个项目的包架构：
当然咯，是按功能分的包，项目的功能不一样然后分包也不一样，但是基本大同小异。
所以确定架构分包的时候那就按你的需求来咯。
从上面可以看出：架构分包的时候我们包括逻辑功能和基础功能（通用功能）。
基础功能模块：
-
日志管理系统（LogManager）
不管哪个项目都需要自己的一套日志管理，一是为了生产调试时能更加高效的查看过滤日志，二是为了打包发布的时候用开关控制日志是否打印。 （我的日志用的是凯子哥的：Klog）
- 异常处理(crashManager)
作用：当程序遇见异常情况时我们能够自定义异常处理，二是程序对不同的机型有不同的反应，那么测试时候可能没有发现但是我们可以把捕获的crash上传到服务器，便于异常收集和bug修复。
-
utils(工具类)
根据你的项目需求来合理定制你的工具类，将会对你的项目开发速度有很大的提升（反馈，版本校验更新你肯定能够用到）
看下我上个项目的工具类：
- permission(权限管理系统)
这功能是绝对项目中需要的，别告诉我你的项目还没有适配安卓6.0，适配了就肯定会有权限管理，我这里用的是 安卓6.0权限处理在项目中的实践,也还可以吧，反正github上的权限管理的开源东西比较多，觉得合适就ok。
哈哈，这样你的基础功能都搭建好了，然后就是一些逻辑功能的封装了。
逻辑功能模块：
1.封装自己的application和baseActivity类，最大可能的节省代码，加入mvp的思想来架构。 2.选择自己喜欢的网络请求框架并且适当合理的进行封装，加快开发的效率。 3.针对带有滚动控件嵌套有可能产生的滑动冲突，或者显示不全我们优先自定义一下viewpager,listview,gridview等。 4.封装listView或者recyclerView打造万能的适配器，觉得翔哥的封装的不错[ 打造万能的适配器](https://github.com/hongyangAndroid/baseAdapter)。 5.一般的网络数据格式是json(我们就逗：普通数据json,刷卡交易数据xml),所以呢我json格式的用gson封装一下,xml格式暂时用的是pull解析后bean对象封装。 6.数据库的封装，对数据苦要求不高的话可以用原生的简单封装一下curd就好了，要求高点的话那就用第三方的好了。开发过程中第三方开源库的抉择
图片加载库：
-
Glide:相比较UIL，glide可以支持gif和短视频,支持与activity，fragment，application生命周期的联动,支持 okhttp、Volley
-
Fresco:三级缓存牛逼，对多帧动画图片支持更好，如 Gif、WebP
-
UIL：老牌的虽然不再更新维护，但功能强大
根据你的项目需求选择，熟悉UIL就用它，个人推荐Glide
网络请求库：
-
okhttp:
okhttp是高性能的http库，支持同步、异步，而且实现了spdy、http2、websocket协议，api很简洁易用，和volley一样实现了http协议的缓存。 -
retrofit:
简化了网络请求流程，同时自己内部对OkHtttp客户端做了封装，同时2.x把之前1.x版本的部分不恰当职责都转移给OkHttp了(例如Log，目前用OkHttp的Interceptor来实现)
-
volley:
volley是一个简单的异步http库，仅此而已。缺点是不支持同步，这点会限制开发模式；不能post大数据，所以不适合用来上传文件。
个人建议使用retrofit，volley的通用性不高（资料最多）。
事件总线库：
主要用来消息/事件的传递，却能实现组建之间的解耦。
eventBus3.0和otto都是使用注解的方式（@Subscribe、@Produce）来标注方法，Otto更多的使用场景是在主线程中，相对是轻量级的。
如果你对是不是轻量级不关心的话，我觉得两个差不多，但是还是很多人推荐使用otto。
依赖注入库：
butterknife8.0： https://github.com/JakeWharton/butterknife
在任何项目中使用butterknife都是正确且没有问题的. 非常轻量级的库，原因是性能高节省代码，而且不是你们所想的反射机制实现的。
Dagger2：它是不具有动态性的（使用时完全不使用反射）但是生成的代码的简洁性和性能都是与手写的代码同水准的。
2个都是很棒的，你可以选择额。
数据库存储：
-
LitePal：LitePal是一款开源的Android数据库框架，它采用了对象关系映射(ORM)的模式，LitePal很“轻”，jar包只有100k不到，使用起来也比较简单，源码地址为LitePal地址,郭神开发的就是牛。
-
greenDAO:greenDAO与LitePal不同，其原理不是根据反射进行数据库的各项操作，而是一开始就人工生成业务需要的Model和DAO文件，业务中可以直接调用相应的DAO文件进行数据库操作
扫一扫
1470
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
