Android应用架构前世今生

前言

Android的开发生态系统发展迅速,在开发Android的几年的时间里,用来构建Android应用的架构与技术一直在不断进化。随着项目的不断更新迭代,应用的架构也有不一样的变化。由于开发人员的数量、项目的业务复杂度、需求的开发时间、应用的使用量级,使用的技术架构也不相同。没有最好的架构,只有最合适的。通过设计使程序模块化,做到模块内部的高聚合和模块之间的低耦合。这样做的好处是使得程序在开发的过程中,开发人员只需要专注于一点,提高程序开发的效率,便于项目的后期维护。下面总结及汇总一下目前Android使用的主要应用架构及其优缺点和使用的学习心得,如有不对之处,欢迎交流纠正。

mvc

还记得以前学生时代学习.NET的时候,第一次接触到项目架构叫三层架构。应用层、业务逻辑层及数据访问层。mvc的思想其实也一样,都是一种软件设计典范,用一种业务逻辑、数据、界面显示分离的方法组织代码,在改进和个性化定制界面及用户交互的同时,不需要重新编写业务逻辑。Android的项目设计本身也是采用了mvc的设计思想。

115截图20180108120929.png
  • 视图层(View)
    一般采用XML文件进行界面的描述,使用的时候可以非常方便的引入。同时便于后期界面的修改。逻辑中与界面对应的id不变化则代码不用修改,大大增强了代码的可维护性。

  • 控制层(Controller)
    Android的控制层主要就是Activity层。相关View层交互触发及数据展示逻辑都在Activity中进行编码。

  • 模型层(Model)

我们通常针对业务数据,都会定义好对应的Model层。数据库的操作、对网络等的操作都应该在Model里面处理,当然对业务计算等操作也是必须放在的该层的

所以一直以来我们使用Android默认的项目结构开发,主要都是在采用mvc的架构思想。

优点: 适用了简单的页面展示,业务逻辑不复杂。开发效果高,代码层级也简单易懂

缺点: 当业务复杂时,Activity非常臃肿,不便于维护及测试

mvp

mvp这是目前我们项目中主要采用的应用架构方式,MVP从更早的MVC框架演变过来,与MVC有一定的相似性:Controller/Presenter负责逻辑的处理,Model提供数据,View负责显示。mvp架构的演变,解决了Activity代码臃肿的问题,当我们将Activity复杂的逻辑处理移至另外的一个类(Presenter)中时,Activity其实就是MVP模式中的View,它负责UI元素的初始化,建立UI元素与Presenter的关联(Listener之类),同时自己也会处理一些简单的逻辑(复杂的逻辑交由 Presenter处理)。项目开发中,UI是容易变化的,且是多样的,一样的数据会有N种显示方式;业务逻辑也是比较容易变化的。为了使得应用具有较大的弹性,我们期望将UI、逻辑(UI的逻辑和业务逻辑)和数据隔离开来,而MVP是一个很好的选择。在MVP模式里通常包含3个要素(加上View interface是4个):

115截图20180108122650.png
  • View:负责绘制UI元素、与用户进行交互(在Android中体现为Activity)

  • Model:负责存储、检索、操纵数据(有时也实现一个Model interface用来降低耦合)

  • Presenter:作为View与Model交互的中间纽带,处理与用户交互的负责逻辑。

  • View interface:需要View实现的接口,View通过View interface与Presenter进行交互,降低耦合,方便进行单元测试

优点:

  1. Model与View完全分离,修改互不影响
  2. 更高效地使用,因为所有的逻辑交互都发生在一个地方—Presenter内部
  3. 一个Preseter可用于多个View,而不需要改变Presenter的逻辑(因为View的变化总是比Model的变化频繁)。
  4. 更便于测试。把逻辑放在Presenter中,就可以脱离用户接口来测试逻辑(单元测试)

缺点: 需要拿捏好Presenter、View interface的颗粒度设计,容易出现Presenter过于简单或则复杂化。

mvvm

MVVM可以算是MVP的升级版,其中的VM是ViewModel的缩写,ViewModel可以理解成是View的数据模型和Presenter的合体,ViewModel和View之间的交互通过Data Binding完成,而Data Binding可以实现双向的交互,这就使得视图和控制层之间的耦合程度进一步降低,关注点分离更为彻底,同时减轻了Activity的压力

115截图20180108140536.png
  • View(视图层)采用XML文件进行界面的描述;
  • Model(模型层)通过网络和本地数据库获取视图层所需数据;
  • ViewModel(视图-模型层)负责View和Model之间的通信,以此分离视图和数据。

View和Model之间通过Android Data Binding技术,实现视图和数据的双向绑定;ViewModel持有Model的引用,通过Model的方法请求数据;获取数据后,通过Callback(回调)的方式回到ViewModel中,由于ViewModel与View的双向绑定,使得界面得以实时更新。同时,界面输入的数据变化时,由于双向绑定技术,ViewModel中的数据得以实时更新,提高了数据采集的效率。

采用ViewModel解决MVP中View(Activity)和Presenter相互持有对方应用的问题,界面由数据进行驱动,响应界面操作无需由View(Activity)传递,数据的变化也无需Presenter调用View(Activity)实现,使得数据传递的过程更加简洁,高效。

推荐教程:
精通 Android Data Binding

优点:

  1. 双向绑定技术,当Model变化时,View-Model会自动更新,View也会自动变化。很好做到数据的一致性
  2. Google官方支持databing,易于集成

缺点:

  1. 数据绑定使得 Bug 很难被调试
  2. 数据双向绑定不利于代码重用及扩展
  3. 代码的阅读性降低

android-architecture

google在官方示例中给出了一系列不同架构的app实现,项目目的是通过展示各种架构app的不同方式来帮助开发者解决架构问题。项目中通过不同的架构概念及方式实现了功能相同的app。

Google官方MVP架构示例项目

TODO-MVP-RXJAVA

115图片20180108151621.png

使用RXJAVA对数据流进行处理,并且通过Repository进行数据的集中管理,通过协议类XXXContract来对View和Presenter的接口进行内部继承,在presenter的实现类中,可以对Model数据进行操作。实例中,数据的获取、存储、数据状态变化都是model层的任务,presenter会根据需要调用该层的数据处理逻辑并在需要时将回调传入。这样model、presenter、view都只处理各自的任务,实现单一责任原则。

推荐教程:
Google官方MVP+Rxjava项目详解

组件化

随着项目的推进,及企业业务的发展。有一天可以发现团队内部需要开发多个APP,且多个APP中存在相同的业务模块,一开始的做法为了赶项目进度可能就是黏贴复制,到后面就慢慢发现越来越吃力,重复劳动。
慢慢随着时间的推移,恶性循环。慢慢发现项目代码结构混乱、层次不清,各业务技术方案不统一;甚至连基本的包结构也是胡乱不堪,都是不停地往上堆砌代码添加新功能,前人挖坑后人填。可见组件化对于不断迭代的项目有着深远的意义

  1. 避免重复造轮子,提高开发效率
  2. 减低耦合度,提高复用性
  3. 保持团队的技术方案统一性
  4. 便于维护升级

基础组件化

通常项目中常用的结构如下:

115截图20180108161144.png

看似没什么问题,但通常我们的一些库都是以代码的形式集成在代码中,随着项目推进,慢慢发现一些比较严重的问题。

  1. 业务代码侵入组件代码中 (例如一些全局的网络返回响应,直接在库中编码等)
  2. 团队内部没约束,各自集成不同的基础库(例如图片加载有的用Glide,有的用ImageLoader)
  3. 部分第三方组件停止更新,项目代码耦合高,替换新方案难

所以在实际设施组件化的过程中,建议参考:

  1. 独立library库(Common基础组件),避免在主工程中直接以代码集成,使用aar方式引用
  2. 第三方的库调用最好再装一层接口,以便后续维护升级
  3. 有成员专门负责维护,可以以SDK的方式提供业务层的调用

业务模块化

随着项目逻辑不断的增加,慢慢是不是发现代码编译速度是不是越来越慢?(PS:我们目前项目编译一次2分钟,且已是经过一些优化处理)
另外当团队内部有多个项目时,是不是经历过产品经理让你把项目A的某个功能移到项目B去,这个时候... ...

115截图20180108163926.png

业务模块化的作用性就很明显了

  1. 业务模块间避免耦合,提高复用性
  2. 业务模块独立编译运行

推荐教程:
DDComponentForAndroid
Android彻底组件化方案实践

总结

思考

  1. 项目架构都是不断演进,不是一蹴而就
  2. 没有最好的架构,只有在适当的时机,最合适的架构
  3. 项目重构过程是艰难的,但长痛不如短痛

推荐业内架构演变

安居客Android项目架构演进

饿了么移动APP的架构演进

微信Android客户端架构演进之路

参考资料

Android App的设计架构:MVC,MVP,MVVM与架构经验谈

Android 开发:由模块化到组件化(一)

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 211,639评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,277评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,221评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,474评论 1 283
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,570评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,816评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,957评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,718评论 0 266
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,176评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,511评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,646评论 1 340
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,322评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,934评论 3 313
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,755评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,987评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,358评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,514评论 2 348

推荐阅读更多精彩内容