1、前言
前段时间由于工作需要,学习了关于组件化和插件化架构相关的知识。查阅了很多Android开发架构的资料,组件化自己写了个简单的Demo
并且开始了原有项目的改造,插件化自己也尝试了滴滴的VirtualAPK
框架。这篇记录一下架构方面的相关知识总结以及自己学习后对模块化、组件化和插件化这三化概念的理解。具体的搭建组件化方法可以看我写的这篇文章。Android组件化入门:一步步搭建组件化架构。
2、MVC、MVP、MVVM
2.1 MVC
Model-View-Controller
,即模型-视图-控制器。Model
负责获取数据,View
负责界面展示,Controller
负责交互控制,是最经典的架构模式。例如Android
中的ListView
就是MVC
运用的典型例子。界面里的ListView
是View
,Adapter
是Controller
,数据集合是Model
,Model
和View
通过Adapter
这个Controller
联系起来。MVC
架构使得代码之间分工明确,降低了代码耦合性,提高了代码重用性。但是MVC
中View
和Controller
联系太过紧密,Android
开发中往往把Activity
充当Controller
的角色,使得Activity
的代码过于庞大。
2.2 MVP
Model-View-Presenter
,和MVC
类似,Model
负责获取数据,View
负责界面展示,Presenter
作为中间调度者,负责交互逻辑控制。在MVP
中Model
和View
间没有任何联系,全靠Presenter
进行传递控制,使得Model
和View
完全的隔离,并且Presenter
还可以重用。Android
开发中使用MVP
将控制逻辑从Activity
中转移到Presenter
中,大大减轻了Activity
的负担,让Activity
单纯的充当View
的角色。
2.3 MVVM
Model-View-ViewModel
,还是和之前的类似,Model
负责获取数据,View
负责界面展示,而ViewModel
成为了View
和Model
沟通的桥梁,通过数据绑定技术实现了数据与界面的双向绑定,数据有变动了通知界面更新,界面数据有改动通知数据也修改。Android
中通过Google
官方推出的DataBinding
上来实现数据的双向绑定,MVVM
模式进一步降低了代码耦合性。
3、模块化
关于模块化,我第一次接触Module
是在开始使用Android Studio
的时候,相比原来使用Eclipse
的时候多了这样一个Module
的概念,这个Module
就是模块。
在刚开始学习开发的时候或者开发一个单一功能应用的时候,因为功能简单,所以项目架构也可以很简单,或者说也不需要什么架构,全部写在一个模块里问题也不大,而且用这种方式开发上手快,开发效率高,没有这样那样的设计模式,啥也不用管,拿起键盘就是码,简单粗暴,对新手而言十分的友好。
单一模块项目
模块化
但是一旦项目的业务功能稍微复杂一些,或者是多人协作开发,这种简单粗暴的方式就不行了,开发效率直线下降,所有功能的代码耦合在一起,简直是一团乱麻,多人开发面对不是自己写的代码更是噩梦,这样开发不仅耦合度高,而且代码冗余也会很高。所以Android开发者按照原先后端的项目开发方法,开始使用MVC
的分层架构进行开发,这样让代码结构更加清晰,耦合度和冗余也大大降低。在MVC
使用了一段时间之后又相继出现了MVP
、MVVM
等适合移动端的分层架构方式,这些架构的出现让复杂项目的开发也变得仅仅有条,各层代码分工明确,逻辑清晰,项目开发效率也有显著提高。但是光光这样还不够,单模块的项目架构在迭代久了之后,代码量变大,变得十分臃肿。所以不仅要将代码分层,还需要根据业务逻辑将单模块项目拆分成多个业务模块,抽出公共模块和基础模块。这样多模块的开发就是模块化。在开发中修改一行代码就能引入Module
或者剔除Module
,也是非常的灵活方便。
引入不同模块
模块化的开发进一步降低了代码的耦合,每个模块各司其职,解决了单个模块的臃肿问题。多人开发过程中,每个人负责不同模块,分工明确,效率也会提高。这种多模块加分层架构解决了项目开发中的大部分问题,也最简单常见的架构模式。
模块化多个模块
4、组件化
在模块化开发了一段时间之后,随着项目业务的增加,模块越来越多,又会出现一些问题。例如:
- 由于模块太多使得每次调试都要编译整个项目,编译速度太慢。
- 项目运行依赖于所有模块,模块间若有冲突,使开发这这无法专注于单个模块的功能。
- 多个项目要使用一个模块时,无法对业务模块进行灵活的组装
组件化很好的解决了这些问题。通过一个APP
空壳工程,将多个组件组装成一个应用。组件化为单个组件配置了单独的启动入口Activity
,使得单个组件既可以作为application
单独运行,又可以作为library
引入项目。这样在多人开发时,每个开发者只需要专注于自己组件的功能问题,调试时只需要调试单个组件,只编译一个组件大大提高了编译速度,提升了开发效率。而且还可以将一些常用组件打成aar
包进行单独版本维护,在其他项目需要时直接引入就行。 组件化其实和模块化有点类似,我觉得可以这样理解,组件化就是模块化的一个升级加强版,组件化比起模块化更加的灵活,耦合度更低,而且单个组件可以独立运行,不必每次编译整个项目,提高了开发效率。
组件化
组件化工程
组件可以作为单独应用运行
5、插件化
插件化技术的产生也是类似,由于业务进一步复杂,项目规模进一步的变大,模块越也来越多,耦合度变高,并且有时候需求要求不再是单独的应用,可能要接入其他应用的业务功能,而且太多个组件接入应用会使得应用的体积变得很大,而且编译时间也会变的很长。还有Android
中655536
方法的限制,模块增多代码增多方法很容易就超过65536
个,而且应用也会占用很大内存。所以插件化技术应运而生,插件化技术从本质上来说是一种动态加载技术。插件化中存在宿主APK
和插件两个概念,宿主APK
就是指先被安装到手机中的APK
,插件指经过处理的APK
、so
、dex
等文件,插件可以被宿主进行加载。插件化的应用一开始加载到内存的只有宿主应用,当使用到其他插件时才会加载对应插件到内存中,减少了内存的占用。现在很多大厂都早已推出了自己的插件化框架,例如VirtualApk
、RePlugin
等等。
插件化
6、总结
内容本身比较简单,就是基础概念的总结。对于开发架构的选择来说,没有最好的架构只有最合适的架构,规模大业务多的项目不选择好合适的架构,项目开发将无法顺利进行,功能单一内容简单的项目也没必要什么技术架构都往项目里上,徒增开发成本。只有使用最合适自己项目的架构才能保证项目开发能快速、高效、顺利的进行。