Android业务组件化一

前言：

在自己的公司已经做了两个App项目，这两个项目自己一直是从头跟到尾。回想起做第一个项目的那段时间，想想真的是“黑暗时代”，由于框架结构搭建的不合理，所有的功能模块都糅合在一个modul里面，每个功能模块只是通过包名来区分，调用同事的开发界面都是通过startActivity的方式来调用，别人调用自己的页面也是这种方式，有时自己或者同事修改了跳转页面的参数，直接就导致了程序闪退。那个项目简直是在“堆积”功能，架构很是混乱，代码自己都不愿意去改。接着第二个项目开始之前，我们针对第一个项目开了一个技术研讨会，大家都认识到上个项目的架构思想引起业务之间高耦合性的弊病，所以决定对接下来的项目框架来一次全新改版。其实第一种架构思想对于那种小的应用程序、业务逻辑非常简单，一个人都能开发完成的应用是没有什么毛病的，但是对于那种业务模块比较多的应用就会发现，这个“死结”会随着开发深入，越系越大，后期如果新增一个模块都费劲。所以，我们就想到了组件化开发。

现状分析：

只有知道自己问题出在哪里我们才有可能“对症下药”，下面通过几张图来看看我们第一的项目的架构思想---单一项目结构

看上去这个结构也是很清晰的呀，每个业务都放在单独的包名下，网络库、图片加载库等第三方库与上层业务都完美的剥离了。再看看业务之间的依赖关系图。

各个业务之间代码相互引用，耦合性很大，牵一发而动全身。

从上面的分析我们可以得出适合业务组件化的集中情况：

• 业务较多、而且复杂
• 业务之间的依赖需要解耦
• 团队成员较多，需要哦各自开发相对独立的业务

业务组件化方向：

App业务组件化架构整改的方向就是告别结构臃肿的时代，让各个业务变得相对独立。模块工程和类库工程之间遵循向下依赖关系，各个模块之间遵循平级依赖的关系。先看看整改后的各个独立业务模块与类库工程之间的向下依赖关系图：

整个的方向由一个项目工程拆分成若干模块工程，由App壳工程提供好统一的入口，每个业务独立的模块module共享项目的依赖库。由壳工程集成需要引入的业务模块，至于各个独立的业务模块之间的调用依赖关系，我们借助一个中间层充当路由功能，这个路由我们放在各个业务模块共同引用的依赖库那一层。由路由统一调度他们之间的依赖关系，路由调度解决平级依赖问题示意图：

通过App壳工程提供的路由功能，各个模块之间调用不在采用传统的显式调用，而是采用隐式调用，从而使各个模块之间不在存在依赖关系。

App业务组件化架构整改技术方案：

组件化大致需要解决以下几个问题。

1）业务组件的生命周期

按照理想状态来看待的话，各个业务组件没有任何的依赖关系，这时我们可以把每个独立的业务组件看成一个可运行的app，所以业务组件的生命周期应与独立的App保持一致。

2）业务组件之间通信

在各个单独业务组件内，基本上保持原来的调用方式，组件之间通信采用URL Schema方式实现页面跳转，格式为schema://host/action?param1=value1¶m2=value2。关于schema映射表维护有上面提到的Router来维护。schema解析由系统Framework来维护，其中schema映射表可以做成后台配置文件形式，也可以代码维护，不过组件需要预先注册。以上说的对于传递基本参数没有问题，但是如果需要传递对象的话，转换成json字符串就可以了。
关于schema可以参考我的下一篇博客：Android业务组件化二

App业务组件化架构整改带来的好处：

如此大规模的架构整改需要付出更高的成本，还会涉及一些潜在的风险，那么整改后的架构能够代买哪些好处呢？

• 加快迭代速度，各个业务模块组件更加独立，不再因为业务耦合情况，在发版的时候，由于互相等待而迟迟不能发布版本。
• 稳定的公共模块采用依赖库方式，提供给各个业务线使用，减少重复开发和维护工作量。
• 迭代频繁的业务模块采用组件方式，各业务线研发可以互不干扰、提升协作效率，并控制产品质量。
• 为新业务随时集成提供了基础，所有业务可上可下，灵活多变。
• 降低团队成员熟悉项目的成本，降低项目的维护难度
• 加快编译速度，提高开发效率

总结：

组件化开发可以有效的降低业务板块之间的耦合性，提高工作效率，可能有些错误的观点，很多这样做的技术坑可能还没有遇到，如果遇到问题，会及时在本板块更新。