Android架构演进(MVVM与组件化结合)

毕业工作4年的时间里，前两年基本都是充满激情地撸起袖子就是干，开发了几个全新的APP，这两年都是接手问题多多的旧项目不停地迭代版本与重构，是时候总结一下这几年来Android原生开发的架构演进经验，希望对看到这篇文章的你有所帮助。

一、从MVC到MVP在到现在的MVVM

如果你是一位新手并且对这三种模式不了解的话，可以先去搜索相关文章了解一番，因为比较简单，这里就不在进行说明以及比较了。在使用MVC或者说连MVC都不算的情况下我开发了工作中的第一个APP，因为是新手，代码写得也比较臃肿与杂乱，每一个Activity或者Fragment 都是上帝般的存在，代码复用性不高，耦合比较严重，维护相对困难。

1、风靡一时的MVP

风靡一时的MVP模式当时也引起了我的注意，就赶紧学了起来，很快就在第二个新项目里运用了起来。MVP的核心就是使用P层将Model层与View进行解耦，P层作为它们之间的桥梁进行通信，并且处理部分业务逻辑。同时在业务逻辑不变或者变化比较小的情况下，界面变化不会影响到Model层与P层，这就是MVP带来的好处，解耦以及便于维护。

2、引领潮流的JatPack，成就MVVM

MVVM模式其实在Android开发很早就已经提出来了，记得在DataBingding出来的时候就已经开始兴起了，而我是在JetPack出来的时候才正式开始使用MVVM这种模式的，因为DataBingding带给我的吸引力远远不够ViewModel以及LiveData来的大。放弃MVP是因为它不能想ViewModel以及LiveData带给我的优势，ViewModel能很好地管理数据，而LiveData能帮我管理好生命周期，不需要过多的手动干预View的生命周期，防止内存泄漏，不要担心View被销毁而崩溃等问题，这里的View指的是Fragment或Activity。推荐阅读官方相关文章应用架构指南。

下面这张图是官网推荐的应用架构图，如果您已经有编写 Android 应用的好方法，则可以按照现在的方式。

官网贴图

二、组件化开发

组件化的本质就是模块化，随着项目的迭代，项目的功能越来越多，也越来越难以管理，这个时候将项目进行模块拆分是一个不错的选择，又或者说是必经之路。模块化的其实就是一种分而治之的思想，降低解耦、方便测试与功能迭代，便于多人开发。而组件化的不同之处是在于在开发阶段，每个组件都可以独立运行、独立测试，相当于一个APP，到发布的时候再将多个组件合并成一个完成的APP。下面是一个教育APP的组件化架构图

组件化机构图

这个图从下往上看其实是比较简单的，第一个“核心服务库”后面再介绍

1、核心基础库

这个库提供的功能是最具通用性的，通用到你甚至可以为大部分应用使用，而不局限于你现在的几个APP。所以里面包含的功能也是比较通用性的，不具有任何的业务代码，你甚至可以开源出来都没问题。这个库个功能主要有：
1.网络框架的封装
2.图片框架的封装
3.MVVM框架的搭建
4.常用工具类
其实里面还有许多其他功能的，只要你觉得可以提供给大部分APP使用的，都可以放在这里。

2.APP基础库

这个虽然说也是一个基础库，但里面提供的资源或者功能都是跟你的APP有关的，只不过是这个APP有多个模块或组件都有使用，所以称为APP基础库。例如主题颜色，主题样式，APP多个地方用到的自定义View，Activity父类等。

3.课程组件

作为一个教育行业APP，有一个课程组件也是很常见的，里面用到的核心功能就是视频点播，所以该组件会依赖于“点播模块”，而点播模块为什么会依赖于“点播基础模块”呢？这个就该你的具体业务了，因为我们这边的点播有用到两个平台的服务，上半年用平台1的点播，下半年用平台2的点播。如何实现这种平台无缝切换平台呢？所以“点播基础模块”就出现了，因为我们更换的知识点播平台，业务逻辑还是不变的，没有必要在两个“点播模块”都写一遍业务逻辑，这样做显然并不符合一个成熟程序员的气质，我们将业务逻辑抽到“点播基础模块”做为“点播模块”的依赖，这样更换“点播模块”就简单很多，无需重新写一套业务逻辑。举两个例子：

1.点播都有“暂停”、“播放”等公共的方法，将这些方法写在“点播基础库”的一个抽象类中，让“点播模块”的具体播放类实现这个抽象类，按照这个规则写，我们的业务逻辑就不会乱。
2.课程下载会弹窗提示选择清晰度，这个弹窗也应该放在“点播基础库”中。

4.直播组件

直播组件跟点播组件是类似的，这里说一下绿色部分的“点播、直播公共库”，这个库放的自然是这两个库的公共资源，例如手势控件、弹幕控件等。

5.主项目

这个就是库基本是没什么功能的，例如启动页、首页Activity等。

如何做到各组件彻底解耦

做到彻底解耦之后，各组件是无法感知对方的存在的，也就是直播组件无法直接使用点播组件的资源、类等任何东西。

1、使用路由进行界面跳转，可以使用Arouter这个开源框架
2、将组件或者库的功能通过接口+实现的方式注册到“核心服务库”，再从这个库当中获取你想要的服务。这种通信方式有点类似进程间使用Binder的通信方式了，进程间的资源也是不共享的，需要使用内核空间，利用Binder进行进程间通信。通俗易懂地将就是两个不认认识的人可以通过双方都认识的人进行沟通。
3.“主项目”使用的依赖方式是runtimeOnly，就是为了将“主项目”与各组件进行解耦，这样做可以避免去除组件时不需要进行代码修改，直接取消依赖即可。
4.拥有各自独立的Application，在“主项目”的Application通过反射调用。这样做可以让那些本该在Application初始化的代码不会出现无处安放的尴尬。

三、总结

组件化大概就是这些，将一个混沌体的项目进行组件化的过程中注定是痛苦的，各种文件与资源迁移，各种代码解耦，但收获也是满满的，对解耦以及面向接口编程会有更深的体会。对组件化后的项目，后面迭代开发也是更加简单、轻松、安心，对于测试人员也是能减少不少工作量，不会说改了一个模块的功能影响到另一个模块的功能。如有任何疑问欢迎提问，大家一起交流学习进步。