一、组件化的意义
随着Android 项目代码和结构逐渐复杂，维护成本会指数型上升，通常我们会利用Android Studio自带的Module去拆分项目代码。但这种拆分显然需要基于一定逻辑和结构，目前主流的拆分思路有两种：分别是①基于业务拆分；②基于功能拆分。前者通常会将一个App划分为若干模块，每一个模块对应一个Module。如一个短视频APP（类似某音）通常会被拆分为：首页、登录模块、视频模块、广告模块、直播模块…
但是这样划分会带来一个问题：模块与模块之前会存在重复功能，比如视频模块和直播模块中会同时存在视频解码、流媒体播放等相关功能；但如果把两个模块合并又会导致代码量过于庞大，且上层业务并不存在强关联，这显然违背了软件工程中的低耦合高内聚的基本原则。这就要引出我们的组件化了，也就是第二种拆分方式了：基于功能拆分。还是以一个短视频App举例，基于功能拆分通常会将一个App拆分为三个层次，分别是基础层、组件层和业务层
基础库：主要是一些通用的和业务无任何关联的功能，如：网络通信、音视频解码播放、数据存储、SP操作、图片加载等，这部分会统一放在一个Module下，每一个小功能对应一个或多个类；
组件层：主要是按照业务功能进行拆分的独立功能，这部分是业务核心逻辑代码，如登录组件、个人中心组件、直播核心组件等，通常每一个组件对应一个Module；
业务层：具体的用户可感知的业务模块，由一个或多个组件组成，如直播功能模块包括直播核心组件和礼物组件。
注：上图只是简单列一下便于理解组件化拆分逻辑，实际场景下会比这个图复杂。
二、组件化带来的优点
业务模块分开，解耦的同时也降低了项目的复杂度，结构非常清晰，如需替换某项组件，只需保持接口不变，替换过程中上层业务无感知，比较典型的场景就是更换项目的网络通信库、图片加载库；每个模块可独立编译，提高了编译速度（在巨无霸型APP中效果尤为明显）；需求可以基于组件拆分，多人协同完成同一需求时可以显著提升效率；可以灵活的对业务模块进行组装和拆分；避免重复造轮子，节省开发维护成本；三、组件化需要解决的问题
从上面的结构图其实也可以看出，对于一个项目进行组件化改造，其路径不是唯一的，如对于上图中的直播场景，可以拆分为直播核心组件+礼物打赏组件+其他附属组件，当然也可以拆分为直播视频组件+礼物及交易组件+打赏组件+其他附属组件，这两种并没有绝对的孰优孰劣。但是组件化需要解决的问题是确定的，当你需要对项目进行组件化改造时，一定是以组件化需要解决的问题作为出发点，主要问题包括：
每个组件都是一个完整的整体，所以组件开发过程中要满足单独运行及调试的要求，这样还可以提升开发过程中项目的编译速度（大型Android项目编译一次30分钟+真不是闹着玩的）。数据传递与组件间方法的相互调用，这也是上面我们提到的一个必须要解决的问题。组件间界面跳转，不同组件之间不仅会有数据的传递，也会有相互的页面跳转。在组件化开发过程中如何在不相互依赖的情况下实现互相跳转？主项目不直接访问组件中具体类的情况下，如何获取组件中 Fragment 的实例并将组件中的 Fragment 实例添加到主项目的界面中？组件开发完成后相互之间的集成调试如何实现？还有就是在集成调试阶段，依赖多个组件进行开发时，如果实现只依赖部分组件时可以编译通过？这样也会降低编译时间，提升效率。组件解耦的目标以及如何实现代码隔离？不仅组件之间相互隔离，还有第五个问题中模块依赖组件时可以动态增删组件，这样就是模块不会对组件中特定的类进行操作，所以完全的隔绝模块对组件中类的使用会使解耦更加彻底，程序也更加健壮。
*关于组件化在项目中的具体代码实践，埋个坑，关注后续系列博客~~~~*
