返回 登录
0

如何搭建app架构

前言

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


逻辑功能模块:

开发过程中第三方开源库的抉择

图片加载库:

  • 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架构就是盖房子,砖少就盖矮点吗,但是必须保证得结实,就像 框架不一定要强大但是必须健壮具有扩展性。

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

评论