如何搭建app架构

标签: app 架构 | 发表时间:2016-05-24 06:44 | 作者:u013278099
出处:http://blog.csdn.net

前言

最近公司的另一个项目又要立项了,作为公司的唯一安卓工程师任务来了( 新来的移动端的老大说项目还是主要你负责,我就负责帮你们安排下进度),听了这话我是伤心的在这公司不管是几个还是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架构就是盖房子,砖少就盖矮点吗,但是必须保证得结实,就像 框架不一定要强大但是必须健壮具有扩展性。

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

作者:u013278099 发表于2016/5/23 22:44:56 原文链接
阅读:164 评论:0 查看评论

相关 [app 架构] 推荐:

如何搭建app架构

- - CSDN博客推荐文章
最近公司的另一个项目又要立项了,作为公司的唯一安卓工程师任务来了(. 新来的移动端的老大说项目还是主要你负责,我就负责帮你们安排下进度),听了这话我是伤心的在这公司不管是几个还是1个安卓开发都是我来搭建,干着与工资不符的事情,好的一点是开发没有人干涉平时也能学习自己想学的东西. 如何选择app架构(MVC/MVP/MVVM).

Hybrid APP架构设计思路

- - SegmentFault 最新的文章
关于Hybrid模式开发app的好处,网络上已有很多文章阐述了,这里不展开. 本文将从以下几个方面阐述Hybrid app架构设计的一些经验和思考. 原文及讨论请到 github issue. 作为一种跨语言开发模式,通讯层是Hybrid架构首先应该考虑和设计的,往后所有的逻辑都是基于通讯层展开.

CouchDB 最佳 App 大奖得主 blitz.io 技术架构剖析

- jiaosq - NoSQLFan
Blitz是一家提供压力测试服务的公司,最近它获得了在CouchConf上评选的最佳CouchDB App大奖,本文就是讲述Blitz的CouchDB使用架构. 他们何以能被评为最佳CouchDB App的,其具体技术架构都将在本文中为大家呈现. 从图上我们大概能看到,他们在不同的地区分别部署了两个CouchDB集群,这两个集群分别服务不同区域的数据写入,并保持双向的数据同步.

Udacity分享他们在Google App Engine上的架构

- - InfoQ cn
Udacity是一个以提供个性化计算机教育免费在线课程为主的网站,虽然该网站上目前只有18种课程,但是它的流量却相当可观,目前在Alexa的排名是11926. Chris Chew是该网站的资深软件工程师. 日前,他在Google App Engine的官方博客上分享了如何使用App Engine来构建Udacity.

掌上指路标 —– APP架构与导航设计

- - 百度MUX
一款小小的手机应用,却包罗万象,融合这复杂的信息内容或功能逻辑. 要让用户在使用中获得最好的体验,迅速掌握应用的框架结构,其导航的设计是一个重要的环节. 手机应用的导航和现实世界中的路标或者地图的作用很类似. 它是应用软件的虚拟框架,对用户具有指示标识以及识别的功能. 比如,如同路标,导航能在使用中,定位用户当前在哪儿,为用户突出当前视图重要的功能,告知用户可以去哪儿,在不同的视图和区域迅速地切换信息,记录使用的操作轨迹防止用户迷失等.

大数据的未来是App 而非基础架构

- - 互联网的那点事
本文作者Justin LaFayette,为我们解读他眼中大数据的未来. 在大数据被各种媒体热炒的同时,真相被蒙蔽了:App才是大数据的未来. 过去基础架构和平台一直是被捧吹的对象,但它们只提供了承载大数据的环境,无法利用大数据创造长期价值,所以它们并不是大数据的未来核心. 在市场上它需要公司提供大数据App,能够洞察特定市场版块或业务流程、及时反馈数据、到达尽可能多的调差对象.

App 和 iCloud

- 笑炊 - 爱范儿 · Beats of Bits
iCloud 的技术细节还在 NDA 的保护下. 但是大家的好奇心不能等到 NDA 失效再满足. 本文基于对 iCloud 的猜测写成,靠谱与否,等待时间检验. 打开浏览器,嗯,今天用 Safari , Chrome , IE 或者 Firefox. 输入 Twiter.com ,啊,不对,是 Twitter.com.

App Internet 革命

- Cary - Mr. Jamie 看網路與創投
Apple 公布最新一季的財報,3 個月賣出了破紀錄的 3,500 萬台 iDevices (iPhone, iPad & iPods). Google 公布最新數字,全球有 1.9 億支 Android 已經被啟用. 大家很興奮「智慧型手機」、「行動裝置」革命終於來到,我卻隱隱感覺到另一件更重大的事情正在發生,我們所熟知的「網路」,即將經歷另一次大幅度的轉變.

浅析App Engine

- - 搜索研发部官方博客
在国内外,云计算正在大步的走向商业化的道路,也得到了越来越多公司的重视. 其中平台即服务(Platform-as-a-Service  PaaS)已经称为业界探讨云计算的热点方式之一,采用PaaS模式来构建应用运行平台App Engine是一种重要的实现方式. 本文主要是对App Engine的背景、特点、需求等进行分析整理,并据此对业界主要的App Engine进行了调研分析.

Mobile App 将死?!

- - Tech2IPO
日前,Mozilla 产品副总监 Jay Sullivan 称移动应用不久即将成为历史,未来将是移动 Web 应用的天下. 光盘好歹还能当杯垫,可怜 Mobile App,难道就这样一下跌落进历史的垃圾堆. Mozilla 的产品副总监杰 • 沙利文 (Jay Sullivan, 上图) 日前表示,移动终端应用(Mobile App)没有未来,真正有前途的是移动 Web 应用(Mobile Web App).