安卓实战之如何快速搭建app架构

Posted 2022-07-29 Herman-Hong



http://blog.csdn.net/u013278099/article/details/51485476?ref=myread

前言

最近公司的另一个项目又要立项了，作为公司的唯一安卓工程师任务来了（新来的移动端的老大说项目还是主要你负责，我就负责帮你们安排下进度），听了这话我是伤心的在这公司不管是几个还是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

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打造万能的适配器，觉得翔哥的封装的不错[ 打造万能的适配器](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文件进行数据库操作，从而避免了因反射带来的性能损耗和效率低下。但是由于需要人工生成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架构就是盖房子，砖少就盖矮点吗，但是必须保证得结实，就像 框架不一定要强大但是必须健壮具有扩展性。

时间不早了，各位早点休息。

更多的Material Design系列效果，请去star 我的https://github.com/zilianliuxue/AndroidStudy