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

一、前言

前段时间因为工做须要，学习了关于组件化和插件化架构相关的知识。查阅了不少Android开发架构的资料，组件化本身写了个简单的Demo而且开始了原有项目的改造，插件化本身也尝试了滴滴的VirtualAPK框架。这篇记录一下架构方面的相关知识总结以及本身学习后对模块化、组件化和插件化这三化概念的理解。具体的搭建组件化方法能够看我写的这篇文章。Android组件化入门：一步步搭建组件化架构。

二、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模式进一步下降了代码耦合性。

三、模块化

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

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

单一模块项目

模块化

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

引入不一样模块

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

模块化多个模块

四、组件化

在模块化开发了一段时间以后，随着项目业务的增长，模块愈来愈多，又会出现一些问题。例如：

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

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

组件化

组件化工程

组件能够做为单独应用运行

五、插件化

插件化技术的产生也是相似，因为业务进一步复杂，项目规模进一步的变大，模块越也来越多，耦合度变高，而且有时候需求要求再也不是单独的应用，可能要接入其余应用的业务功能，并且太多个组件接入应用会使得应用的体积变得很大，并且编译时间也会变的很长。还有Android中655536方法的限制，模块增多代码增多方法很容易就超过65536个，并且应用也会占用很大内存。因此插件化技术应运而生，插件化技术从本质上来讲是一种动态加载技术。插件化中存在宿主APK和插件两个概念，宿主APK就是指先被安装到手机中的APK，插件指通过处理的APK、so、dex等文件，插件能够被宿主进行加载。插件化的应用一开始加载到内存的只有宿主应用，当使用到其余插件时才会加载对应插件到内存中，减小了内存的占用。如今不少大厂都早已推出了本身的插件化框架，例如VirtualApk、RePlugin等等。

插件化

六、总结

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