大型移动应用解决之道 - 组件化

读者在阅读本篇文章时，建议先看下“插件化”那边文章介绍的研发痛点与研发流程。

在插件化那篇文件中，我们介绍了插件化解决了很多痛点问题，很完美的方案，不管是研发还是产品都爱不释手，但是插件化的实现并不是这么容易就能应用到产品中，还是要折腾折腾的，其次还要看团队中有没有大神级人物能hold住。在replugin没有开源之前，我一直没有信心插件化可以落户每个Android应用，因为稳定性问题是阻碍插件化的最大绊脚石，这么美的东西得不到手，实在是让人怀疑人生，随着replugin的开源，世界又变的如此的美好了。即便是这样，插件化仍然也有一定的门槛，让一些团队望而却步。但是面临如此多的问题：方法数限制、安装包体积、团队耦合严重、编译打包慢、灵活性差等等问题，该如何解决？ 答案就是组件化，组件化不能解决以上所有问题，但是也能帮助我们解决一些燃眉之急。

组件化不像插件化那样强大，解决众多问题，但是组件化同样是一员猛将，也会让人爱不释手。

组件化可以解决以下问题：

1. 团队耦合严重

2. 部分灵活性问题

组件化不像插件化那样解决灵活性问题那么彻底，比如：电商应用中的不需要安装即可上线的一些需求，组件化是无能无力的。组件化和插件化一样都具备模块化的要求，即我们都会产生模块化的仓库，产品可随意组装拼接(安装包体积可控)，像搭积木一样灵活，各组件的实现在编译阶段任意替换。

3. 调试定位问题慢

分析

与插件化分析思路相同，将应用进行拆分分解到不同的组件中，插件化与组件化在对业务的拆分原则上相同（可参照插件化的分析章节），各个插件与组件都尽量走可独立运行的路线，而在插件化的开发中，插件化与组件化应该是一种并存的状态，并不是所有的业务需求都是一个可独立运行的单元，如果你的架构足够细化，一定会提炼出很多组件，向各个插件提供支持。通常这种组件不能独立运行，需要被集成，扩展或配置之后才可运行，这种组件可能是业务上的，也有可能是技术上的。另外，完成组件化的架构之后后续转移到插件化会相对容易很多。

通常组件的拆分，大致见下图：

什么是组件化？

个人总结：组件化是基于模块化基础之上，旨在解决开发阶段导致团队耦合严重等问题的一种开发模式。

组件化与插件化的区别？

我们先看下组件化的研发流程，组件化的研发流程可分为两个部分:

1. 开发阶段

从上图我们可以清晰的看到，与插件化的研发流程上基本相同，但是大家要注意这仅是“开发阶段”，这样发布的版本仅是build版本，只供QA测试使用。这样做的目的仅是为了减少上面提到的在开发阶段耦合严重，定位问题慢等问题。 由于将整个应用拆分成了若干业务模块，每个模块在开发阶段独立开发，打包，测试，各模块间通过接口协议来进行通信。当某个模块无法向另外一个模块提供接口实现时，则由当前模块团队提供模拟的接口实现来进行测试实现。

2. 发布阶段

从上图可以看出，在真正要发布版本时，流程是不同的，整个打包发布流程是串行的，各个组件的负责人需要将正式的组件版本发布到Maven仓库中，由集成打包测试服务器来进行集成打包，这样一来真正发布的产品是对所有组件的集成（安装包体积仍没有改善，同时面临升级转化，流量，内存等问题），而在插件化中任何阶段的打包发布流程都是并行的，并且发布的产品只包括核心的功能需求（安装包体积小），其余均按需下载支持。

通过上面的描述，相信读者对插件化与组件化区别有了一定的了解。

组件化开发中遇到的问题？

组件化开发中会面临各种各样的问题，相对插件化好解决一些，我们来简单介绍下相关问题：

1. Context问题

由于每个组件在开发阶段独立开发，其他组件可能有自己的application，各自组件都通过自己的application去获取context显然是错误的，因为当被打包到一起时，组件内的application不会被做为主Application(不会被执行attach)，即使组件内的application对象可以创建，但是组件的application不含LoadedApk等信息，不是一个真正的Context对象。 在组件内可通过ActivityThead#currentThread()#getApplication()来获取。

2. Activity跳转问题

组件间存在依赖，互相调用UI的情况是很常见的，如何调用？

1)通过定义不同的action来实现；

2)通过在activity中定义schema,host,path也就是uri来实现（推荐使用）；

3. View id的问题

由于每个组件在开发时是独立的，而每个组件的layout文件中的view的id是通过@+id/xx来实现的，那么在合并时组件作为lib，在编译main时如果使用的是@+id会重新生成ID这样会导致view找不到的问题，所以需要强制view不能进行编译，需要在ids.xml和public.xml中进行定义。而每个layout文件则需要使用@id/xx的方式使用，不要使用+号。

4. 资源名称冲突

由于在最终打包时会将A组件中的资源合并到main中进行编译，那么A组件中的资源名称不允许与main中的资源重名，所以每个组件中的资源前缀需要添加自己组建的名称；

5.在各个组件开发阶段最好使用同uid来实现。

6.包重复加载问题（如果我们各个组件均通过gradle从maven去获取，这个问题gradle会屏蔽掉）

写到这里，不知道读者是不是已经对组件化有了一些了解。如果读者在实现的过程中有任何问题，我们可以一起讨论。