zoukankan      html  css  js  c++  java
  • [转]Android App整体架构设计的思考

    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,前期需要哪些规划工作避免代码臃肿混乱?

    接上文:Android App整体架构设计的思考(一) ,本文主要介绍AOP以及一些快速开发框架。

    3 基于AOP的框架设计

            AOP(Aspect-Oriented Programming, 面向切面编程),诞生于上个世纪90年代,是对OOP(Object-Oriented Programming, 面向对象编程)的补充和完善。OOP引入封装、继承和多态性等概念来建立一种对象层次结构,用以模拟公共行为的一个集合。当我们需要为分散的对象引入公共行为的时候,OOP则显得无能为力。也就是说,OOP允许你定义从上到下的关系,但并不适合定义从左到右的关系。例如日志功能。日志代码往往水平地散布在所有对象层次中,而与它所散布到的对象的核心功能毫无关系。对于其他类型的代码,如安全性、异常处理和透明的持续性也是如此。这种散布在各处的无关的代码被称为横切(Cross-Cutting)代码,在OOP设计中,它导致了大量代码的重复,而不利于各个模块的重用。而AOP技术则恰恰相反,它利用一种称为“横切”的技术,剖解开封装的对象内部,并将那些影响了多个类的公共行为封装到一个可重用模块,并将其名为“Aspect”,即方面。所谓“方面”,简单地说,就是将那些与业务无关,却为业务模块所共同调用的逻辑或责任封装起来,便于减少系统的重复代码,降低模块间的耦合度,并有利于未来的可操作性和可维护性。

                                                                      

    3.1 AOP在Android中的使用

            AOP把软件系统分为两个部分:核心关注点和横切关注点。业务处理的主要流程是核心关注点,与之关系不大的部分是横切关注点。横切关注点的一个特点是,他们经常发生在核心关注点的多处,而各处都基本相似。AOP的作用在于分离系统中的各种关注点,将核心关注点和横切关注点分离开来。在Android App中,哪些是我们需要的横切关注点?个人认为主要包括以下几个方面:Http, SharedPreferences, Json, Xml, File, Device, System, Log, 格式转换等。Android App的需求差别很大,不同的需求横切关注点必然是不一样的。一般的App工程中应该有一个Util Package来存放相关的切面操作,在项目多了之后可以将其中使用较多的Util封装为一个Jar包供工程调用。

    4 总结

            在使用MVP和AOP对App进行纵向和横向的切割之后,能够使得App整体的结构更清晰合理,避免局部的代码臃肿,方便开发、测试以及后续的维护。目前很多尚停留在实践和思想,今年上半年会抽时间写一个基于MVP、AOP和IOC的Android框架。

    5 快速开发框架

            目前网络上也有一些针对Android的快速开发框架,下面介绍3个主要的快速开发框架。针对这些快速开发框架,个人认为可以参考,但并不推荐使用,因为App整体依赖一个个人维护的框架风险实在太大,框架存在一些学习成本,本身也不一定完全符合App的需求,使用后的收益并没有想象中大。

    5.1 Afinal

            Afinal是一个Android的IOC,ORM框架,内置了四大模块功能:FinalAcitivity, FinalBitmap, FinalDb, FinalHttp。通过FinalActivity,可以通过注解的方式进行绑定UI和事件。通过FinalBitmap,可以方便的加载Bitmap图片,而无需考虑OOM等问题。通过FinalDB模块,通过一行代码就可以对Android的SQlite数据库进行增删改查。通过FinalHttp模块,可以以Ajax形式请求Http数据。

    GitHub项目地址:Afinal

    5.2 xUtils

            xUtils目前主要包括4大模块:DbUtils, ViewUtils, HttpUtils, BitmapUtils。包含了很多实用的Android工具;支持大文件上传,更全面的Http请求协议支持,拥有更加灵活的ORM,更多的事件注解支持且不受混淆影响;最低兼容Android 2.2 (Api Level 8)。

    GitHub项目地址:xUtils

    5.3 ThinkAndroid

            ThinkAndroid是一个免费的开源的、简易的、遵循Apache2开源协议发布的Android开发框架,其开发宗旨是简单、快速的进行 Android应用程序的开发,包含Android MVC、简易SQlite ORM、IOC模块、封装Android HttpClitent的Http模块, 具有快速构建文件缓存功能,无需考虑缓存文件的格式,都可以非常轻松的实现缓存,它还基于文件缓存模块实现了图片缓存功能, 在Android中加载的图片的时候,对OOM的问题,和对加载图片错位的问题都轻易解决。他还包括了一个手机开发中经常应用的实用工具类, 如日志管理,配置文件管理,Android下载器模块,网络切换检测等等工具。

    GitHub项目地址:ThinkAndroid

    参考目录: AOP技术基础

                       从三层架构到MVC, MVP

                       MVC, MVP以及Model2

                       GOF等。

  • 相关阅读:
    zookeeper使用场景
    zookeeper安装配置
    hadoop 远程调试
    deep learning笔记
    Sentiment Analysis(1)-Dependency Tree-based Sentiment Classification using CRFs with Hidden Variables
    PRML阅读笔记 introduction
    Python 学习笔记(2)
    python nltk 学习笔记(5) Learning to Classify Text
    python nltk 学习笔记(4) Writing Structured Programs
    python nltk 学习笔记(3) processing raw text
  • 原文地址:https://www.cnblogs.com/l2rf/p/5983739.html
Copyright © 2011-2022 走看看