Android App整体架构设计的思考(一)

        本文是对我在知乎一个回答的整理,其中的内容大多是对我平时的阅读和实践的总结,希望对Android的开发者有所帮助。但毕竟是个人的一些思考,难免有疏漏,也欢迎对本文的内容提出建议。

1. 架构设计的目的

        对程序进行架构设计的原因,归根到底是为了提高生产力。通过设计使程序模块化,做到模块内部的高聚合和模块之间的低耦合。这样做的好处是使得程序在开发的过程中,开发人员只需要专注于一点,提高程序开发的效率,并且更容易进行后续的测试以及定位问题。但设计不能违背目的,对于不同量级的工程,具体架构的实现方式必然是不同的,切忌犯为了设计而设计,为了架构而架构的毛病。举个简单的例子,一个Android App如果只有3个Java文件,那只需要做点模块和层次的划分就可以,引入框架或者架构反而提高了工作量,降低了生产力。但我当前开发的App最终代码量应该在10W行以上,本地需要进行复杂操作,同时也需要考虑到与其余的Android开发者以及后台开发人员之间的同步配合,那就需要在架构上进行一些思考。

2. 基于MVP的架构设计思路

        在App开发过程中,经常出现的问题就是某一部分的代码量过大,虽然做了模块划分和接口隔离,但也很难完全避免。从实践中看到,这更多的出现在UI部分,也就是Activity里。我曾见过2000+行以上基本不带注释的Activity,那时我的第一反应就是想吐。Activity内容过多的原因其实很好解释,因为Activity本身需要担负与用户之间的操作交互,再加上现在大部分的Activity还对整个App起到控制器的作用,这又带入了大量的逻辑代码,造成Activity的臃肿。为了解决这个问题,我们引入了MVP框架思路。

2.1 什么是MVP?

        MVP是一种使用广泛的基础架构模式,使用基于事件驱动的应用框架。MVP从更早的MVC框架演变过来的一种框架,与MVC有一定的相似性。MVP框架由3部分组成:View负责显示,Presenter负责逻辑处理,Model提供数据。MVP与MVC之间最主要的区别在控制层上,在MVP框架中,View与Model并不直接交互,所有的交互放在Presenter中;而在MVC里,View与Model会直接产生一定的交互。MVP的Presenter是框架的控制者,承担了大量的逻辑操作,而MVC的Controller更多时候承担一种转发的作用。因此在App中引入MVP的原因,是为了将此前在Activty中包含的大量逻辑操作放到控制层中,避免Activity的臃肿。MVP的变种有很多,其中使用最广泛的是Passive View模式,即被动视图。在这种模式下,整个框架内部模块之间的逻辑操作均由Presenter控制,View仅仅是整个操作的汇报者和结果接收者,Model根据Presenter的单向调用返回数据(图片来自网络)。并且MVP模式使得View与Model的耦合性更低,降低了Presenter对View的依赖,实现了关注点分离的初衷,方便开发人员的编码和测试工作。

                                        

        具体到Android App中,我一般将App根据程序的结构进行纵向划分,对应MVP分别为模型层,UI层和逻辑层。UI层一般包括Activity,Fragment,Adapter等直接和UI相关的类,UI层的Activity在启动之后实例化相应的Presenter,App的控制权后移,由UI转移到Presenter,两者之间的通信通过BroadCast、Handler或者接口完成,只传递事件和结果。举个简单的例子,UI层通知逻辑层(Presenter)用户点击了一个Button,逻辑层(Presenter)自己决定应该用什么行为进行响应,该找哪个模型(Model)去做这件事,最后逻辑层(Presenter)将完成的结果更新到UI层。

2.2 MVP架构存在的问题

        转移逻辑操作之后可能部分较为复杂的Activity内代码量还是不少,于是在分层的基础上再加入模板方法(Template Method)。具体做法是在Activity内部分层。其中最顶层为BaseActivity,不做具体显示,而是提供一些基础样式,Dialog,ActionBar在内的内容,展现给用户的Activity继承BaseActivity,重写BaseActivity预留的方法。如有必要再进行二次继承,App中Activity之间的继承次数最多不超过3次。

        模型层(Model)中的整体代码量是最大的,一般由大量的Package组成,针对这部分需要做的就是在程序设计的过程中,做好模块的划分,进行接口隔离,在内部进行分层。

        强化Presenter的作用,将所有逻辑操作都放在Presenter内也容易造成Presenter内的代码量过大,对于这点,我的方法是在UI层和Presenter之间设置中介者Mediator,将例如数据校验、组装在内的轻量级逻辑操作放在Mediator中;在Presenter和Model之间使用代理Proxy;通过上述两者分担一部分Presenter的逻辑操作,但整体框架的控制权还是在Presenter手中。Mediator和Proxy不是必须的,只在Presenter负担过大时才建议使用。最终的架构如下图所示:

                                               

知乎上我的回答链接:从零开始开发一款Android app,前期需要哪些规划工作避免代码臃肿混乱?

我的知乎个人主页:M.A.G.I

欢迎讨论和交流。

发布了10 篇原创文章 · 获赞 2 · 访问量 6万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览