Android基础知识:项目架构基础概述

2019-06-28 10:26:19 浏览数 (1)

1、前言

前段时间由于工作需要,学习了关于组件化和插件化架构相关的知识。查阅了很多Android开发架构的资料,组件化自己写了个简单的Demo并且开始了原有项目的改造,插件化自己也尝试了滴滴的VirtualAPK框架。这篇记录一下架构方面的相关知识总结以及自己学习后对模块化、组件化和插件化这三化概念的理解。具体的搭建组件化方法可以看我写的这篇文章。Android组件化入门:一步步搭建组件化架构。

2、MVC、MVP、MVVM

2.1 MVC

Model-View-Controller,即模型-视图-控制器。Model负责获取数据,View负责界面展示,Controller负责交互控制,是最经典的架构模式。例如Android中的ListView就是MVC运用的典型例子。界面里的ListViewViewAdapterController,数据集合是ModelModelView通过Adapter这个Controller联系起来。MVC架构使得代码之间分工明确,降低了代码耦合性,提高了代码重用性。但是MVCViewController联系太过紧密,Android开发中往往把Activity充当Controller的角色,使得Activity的代码过于庞大。

2.2 MVP

Model-View-Presenter,和MVC类似,Model负责获取数据,View负责界面展示,Presenter作为中间调度者,负责交互逻辑控制。在MVPModelView间没有任何联系,全靠Presenter进行传递控制,使得ModelView完全的隔离,并且Presenter还可以重用。Android开发中使用MVP将控制逻辑从Activity中转移到Presenter中,大大减轻了Activity的负担,让Activity单纯的充当View的角色。

2.3 MVVM

Model-View-ViewModel,还是和之前的类似,Model负责获取数据,View负责界面展示,而ViewModel成为了ViewModel沟通的桥梁,通过数据绑定技术实现了数据与界面的双向绑定,数据有变动了通知界面更新,界面数据有改动通知数据也修改。Android中通过Google官方推出的DataBinding上来实现数据的双向绑定,MVVM模式进一步降低了代码耦合性。

3、模块化

关于模块化,我第一次接触Module是在开始使用Android Studio的时候,相比原来使用Eclipse的时候多了这样一个Module的概念,这个Module就是模块。

在刚开始学习开发的时候或者开发一个单一功能应用的时候,因为功能简单,所以项目架构也可以很简单,或者说也不需要什么架构,全部写在一个模块里问题也不大,而且用这种方式开发上手快,开发效率高,没有这样那样的设计模式,啥也不用管,拿起键盘就是码,简单粗暴,对新手而言十分的友好。

单一模块项目

模块化

但是一旦项目的业务功能稍微复杂一些,或者是多人协作开发,这种简单粗暴的方式就不行了,开发效率直线下降,所有功能的代码耦合在一起,简直是一团乱麻,多人开发面对不是自己写的代码更是噩梦,这样开发不仅耦合度高,而且代码冗余也会很高。所以Android开发者按照原先后端的项目开发方法,开始使用MVC的分层架构进行开发,这样让代码结构更加清晰,耦合度和冗余也大大降低。在MVC使用了一段时间之后又相继出现了MVPMVVM等适合移动端的分层架构方式,这些架构的出现让复杂项目的开发也变得仅仅有条,各层代码分工明确,逻辑清晰,项目开发效率也有显著提高。但是光光这样还不够,单模块的项目架构在迭代久了之后,代码量变大,变得十分臃肿。所以不仅要将代码分层,还需要根据业务逻辑将单模块项目拆分成多个业务模块,抽出公共模块和基础模块。这样多模块的开发就是模块化。在开发中修改一行代码就能引入Module或者剔除Module,也是非常的灵活方便。

引入不同模块

模块化的开发进一步降低了代码的耦合,每个模块各司其职,解决了单个模块的臃肿问题。多人开发过程中,每个人负责不同模块,分工明确,效率也会提高。这种多模块加分层架构解决了项目开发中的大部分问题,也最简单常见的架构模式。

模块化多个模块

4、组件化

在模块化开发了一段时间之后,随着项目业务的增加,模块越来越多,又会出现一些问题。例如:

  • 由于模块太多使得每次调试都要编译整个项目,编译速度太慢。
  • 项目运行依赖于所有模块,模块间若有冲突,使开发这这无法专注于单个模块的功能。
  • 多个项目要使用一个模块时,无法对业务模块进行灵活的组装

组件化很好的解决了这些问题。通过一个APP空壳工程,将多个组件组装成一个应用。组件化为单个组件配置了单独的启动入口Activity,使得单个组件既可以作为application单独运行,又可以作为library引入项目。这样在多人开发时,每个开发者只需要专注于自己组件的功能问题,调试时只需要调试单个组件,只编译一个组件大大提高了编译速度,提升了开发效率。而且还可以将一些常用组件打成aar包进行单独版本维护,在其他项目需要时直接引入就行。 组件化其实和模块化有点类似,我觉得可以这样理解,组件化就是模块化的一个升级加强版,组件化比起模块化更加的灵活,耦合度更低,而且单个组件可以独立运行,不必每次编译整个项目,提高了开发效率。

组件化

组件化工程

组件可以作为单独应用运行

5、插件化

插件化技术的产生也是类似,由于业务进一步复杂,项目规模进一步的变大,模块越也来越多,耦合度变高,并且有时候需求要求不再是单独的应用,可能要接入其他应用的业务功能,而且太多个组件接入应用会使得应用的体积变得很大,而且编译时间也会变的很长。还有Android655536方法的限制,模块增多代码增多方法很容易就超过65536个,而且应用也会占用很大内存。所以插件化技术应运而生,插件化技术从本质上来说是一种动态加载技术。插件化中存在宿主APK和插件两个概念,宿主APK就是指先被安装到手机中的APK,插件指经过处理的APKsodex等文件,插件可以被宿主进行加载。插件化的应用一开始加载到内存的只有宿主应用,当使用到其他插件时才会加载对应插件到内存中,减少了内存的占用。现在很多大厂都早已推出了自己的插件化框架,例如VirtualApkRePlugin等等。

插件化

6、总结

内容本身比较简单,就是基础概念的总结。对于开发架构的选择来说,没有最好的架构只有最合适的架构,规模大业务多的项目不选择好合适的架构,项目开发将无法顺利进行,功能单一内容简单的项目也没必要什么技术架构都往项目里上,徒增开发成本。只有使用最合适自己项目的架构才能保证项目开发能快速、高效、顺利的进行。

0 人点赞