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

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、总结

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

​