By

总阅读次

文章目录
  1. 1. 如何选择app架构（MVC/MVP/MVVM）
    1. 1.1. 项目时间紧迫：快速开发框架（迫不得已）
    2. 1.2. 自己从零开始搭建app架构
      1. 1.2.1. 简单的看下这三个架构模式：
      2. 1.2.2. 面对众多的架构模式你会选择哪个？
    3. 1.3. 我项目中的架构
      1. 1.3.1. 基础功能模块：
      2. 1.3.2. 逻辑功能模块：
    4. 1.4. 开发过程中第三方开源库的抉择
      1. 1.4.1. 图片加载库：
      2. 1.4.2. 网络请求库：
      3. 1.4.3. 事件总线库：
      4. 1.4.4. 依赖注入库：
      5. 1.4.5. 数据库存储：
      6. 1.4.6. 简单缓存
  2. 2. 总结

如何选择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

  1. xUtils 支持超大文件(超过2G)上传，更全面的http请求协议支持(11种谓词)，拥有更加灵活的ORM，更多的事件注解支持且不受混淆影响…
  2. xUtils 最低兼容Android 4.0 (api level 14). (Android 2.3?)

  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打造万能的适配器，觉得翔哥的封装的不错 打造万能的适配器。

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文件进行数据库操作，从而避免了因反射带来的性能损耗和效率低下。但是由于需要人工生成model和DAO文件，所以greenDAO的配置就略显复杂。

greenDAO用起来繁琐但是效率高点，LitePal用起来简单，所以你自己选择吧，个人还是觉得LitePal好用点。

简单缓存

ASimpleCache:ASimpleCache 是一个为android制定的 轻量级的 开源缓存框架。轻量到只有一个java文件（由十几个类精简而来）。

  • 可缓存普通的字符串、JsonObject、JsonArray、Bitmap、Drawable、序列化的java对象，和 byte数据。普通的字符串、JsonObject、JsonArray、Bitmap、Drawable、序列化的java对象，和 byte数据。
  • 替换SharePreference当做配置文件
  • 可以缓存网络请求数据，比如oschina的android客户端可以缓存http请求的新闻内容，缓存时间假设为1个小时，超时后自动失效，让客户端重新请求新的数据，减少客户端流量，同时减少服务器并发量。

哈哈项目需要的基本架构需要的开源库都有了，你可以放心的开发了。

总结

其实架构并不是那么难，也不要别人说怎么好就怎么干，你要相信总有一个东西是适合你的，打个比喻app架构就是盖房子，砖少就盖矮点吗，但是必须保证得结实，就像 框架不一定要强大但是必须健壮具有扩展性。

未经许可不得转载，转载请注明zilianliuxue的blog,本人保留所有版权。

文章目录
  1. 1. 如何选择app架构（MVC/MVP/MVVM）
    1. 1.1. 项目时间紧迫：快速开发框架（迫不得已）
    2. 1.2. 自己从零开始搭建app架构
      1. 1.2.1. 简单的看下这三个架构模式：
      2. 1.2.2. 面对众多的架构模式你会选择哪个？
    3. 1.3. 我项目中的架构
      1. 1.3.1. 基础功能模块：
      2. 1.3.2. 逻辑功能模块：
    4. 1.4. 开发过程中第三方开源库的抉择
      1. 1.4.1. 图片加载库：
      2. 1.4.2. 网络请求库：
      3. 1.4.3. 事件总线库：
      4. 1.4.4. 依赖注入库：
      5. 1.4.5. 数据库存储：
      6. 1.4.6. 简单缓存
  2. 2. 总结