谁阻碍了你做组件化开发？

前言

之前写了一篇关于总结一波安卓组件化开源方案的文章，反响还不错，很高兴能够对大家整体了解android组件化技术有所帮助。

有些开发者在了解组件化开发的好处及相关开源框架后，想要对自己所负责的项目进行组件化改造以解决多人（多团队）协同开发困难及单工程开发编译时间过长等问题，但一直难以下决心真正开始实施，停留在了解阶段或仅仅写个demo体验一把的阶段，其中很大一部分原因是迭代开发任务排的很紧，很难空出一段时间来实施，而且组件化改造是纯技术上的优化，产品经理和业务部门并不太关心。

为此，本文将介绍一下如何用 CC 框架来破解android组件化不易上手的难题（想要了解CC实现原理的细节，请戳这里）

一、谁阻碍了你

先来解决几个可能阻挡我们下决心实施组件化改造的拦路石：

1. 怕配置复杂，容易遗漏或出错
   • CC将配置封装到了一个cc-settings.gradle文件，在需要组件化的module的build.gradle中添加一行依赖cc-settings.gradle文件的代码即可
2. 怕一开始就需要很大的改动
   • 使用CC可以先不改变当前项目中现有的代码，无需添加注解，只需新增一个接口的实现类即可定义一个组件，将其服务暴露给其它组件调用，后续有空的时候再逐步拆分
3. 怕组件化开发框架学习成本高，团队内每个人都了解需要较长时间
   • CC提供了统一的调用方式和实现方式
   • 定义组件仅需实现1个接口类，并确保通过调用CC.sendCCResult(callId, cCResult)将组件调用的执行结果发送给调用者即可
   • 调用组件仅需了解一下CC链式调用即可，例如：（CC.obtainBuilder("demo.ComponentA").setActionName("login").addParam("id", 12345).build().callAsync(callback)）
   • 另外library模式切换成application的方式简化为在local.properties中配置一行module名称=true即可，而且local.properties不会被提交到代码仓库中，不会因为误操作导致在jenkins上编译出错的情况
   • 几乎零门槛就可以进行组件化开发
4. 怕增加项目的维护成本
   • CC采用了编译时自动注册插件AutoRegister来自动维护组件的注册工作，无需手动维护
   • 组件化框架下进行开发跟普通的开发一样，未使用hook等黑科技
   • 组件将业务隔离在内部，并且可单独调试，能降低项目维护成本
5. 刚开始组件化时如果调用其它组件必须要打包一起运行，则享受不到单组件运行的便利
   • CC支持跨app调用
   • CC支持一个module中包含多个组件类，即使没有进行拆分，也可以在主工程中定义这些组件类（在主app moudle或在被调用功能所在的module都可以），暴露调用入口给其它组件调用，后续在进行组件拆分时将组件类一同拆分出去即可
   • 所以，可以将需要被调用到的功能先定义好组件，供新建的组件跨app调用，无需与主工程一起打包，从一开始就可以单独运行组件
6. Fragment不好组件化
   • 其它组件化方案采用下沉接口的方式提供组件间调用，但只是获取了Fragment对象，难以进行后续的通信
   • CC框架下，获取Fragment对象的方式跟其它组件调用完全一样，并且后续可以将此Fragment对象作为参数回传给原组件进行Fragment内部功能的调用，真正做到业务隔离在组件内部进行处理
7. 有自定义View或者第三方View的功能不好组件化，例如将第三方地图SDK封装成组件，由于其它组件页面中要用到MapView控件，是否需要强依赖？
   • CC同样支持View的组件化，详情请戳Fragment和View的组件化

二、推荐的组件化实施步骤

设想一下，在做组件化改造之前，如果按照如下步骤来实施，是不是可行性更高一些，让我们更快地享受到组件化给我们带来的便利和好处，不至于因为迭代任务节奏快而迟迟不能落实：

2.1 快速上手

• 先不用修改当前项目中现有的代码（最大程度地降低工作量及出错概率）
• 可以选择将新的业务按照组件化的方式来进行开发，单独以apk的方式编译运行&调试（也可以选择一个耦合度较低且相对独立的业务来进行这一步）
• 在主工程中创建新组件所需要调用到的主工程业务的组件类
• 在这些组件类在组件尚未完整拆分之前即可按照组件化的方式对其它组件暴露调用入口
• 恭喜，组件化改造的第一步已经成功迈出。

2.2 全局规划

由于组件化是全局的架构，提前规划好整个工程的组件划分并明确各自的业务边界，会让我们实施组件化改造的过程更加有章法，项目结构更加清晰，责任更加明确，组件的可复用性更强。

关于组件如何划分，不同的团队有不同的理解，不同的业务应用场景下也有不同的要求。一般常用的划分方式以下2种，可以结合起来使用：

• 按UI(Activity/Fragment/View)划分，每个页面或控件都作为独立的组件。
  • 优点是粒度较细，方便复用，某个页面发生变化不会影响其他页面
  • 缺点是如果页面多，会导致组件太多，并且如果一个业务有多个页面，这种方式导致业务内部太松散，不方便管理。
  • 另外需要将非页面性的一些服务封装为组件
• 按业务/功能来划分，将同一个业务下的不同功能和页面划分在同一个组件中
  • 优点是可以统一管理本业务下的所有功能（包括页面和服务），提高了内聚性，改造方便
  • 缺点是如果掌控不好粒度可能会比较粗

不管具体如何划分，有一点是相通的：单一职责。即需要确定好业务边界，将组件的业务隔离在自己内部，只暴露调用协议给外部。

举个栗子：

与用户账号相关的业务，根据业务复杂程度及组件在不同app中复用的需求等不同情况，可以将其整体划分为1个组件，也可以划分为登录组件、设置组件、地址管理组件等各种更细粒度的组件，如果你愿意，也可以每个页面1个组件再加上账号相关的服务组件。

但需要注意的是必须有明确的业务边界。比如其中的登录组件，就只负责用户的账号登录/注册等功能，不能将各种登录后的页面跳转业务需求耦合到登录组件中，可以采用这种方式来实现：实现登录成功再进入目标界面功能

再举个JsBridge的栗子：

由于每个组件的业务都内聚在自身内部，所以JsBridge可以封装得十分优雅，回归其本质:仅作为js与java通信的桥梁，与其它组件完全解耦，不需要下沉业务BridgePlugin接口

• js调用java时，在JsBridge组件中直接将参数转发给对应的组件
• java调用js时，在JsBridge组件中根据调用参数调用对应页面的js
• 做好对应业务组件找不到时的降级处理

再也不需要在application中注册一系列的Plugin

详情请戳让jsBridge更优雅

2.3 有空再弄

组件化改造中工作量最大的是要进行业务隔离，逐个组件抽离、解耦，这是一个比较长的过程，不能一蹴而就，可以在迭代任务有空闲的时候一个个进行拆分，拆分的难度取决于原来项目中代码的耦合程度：

• 已封装完好的业务module，只暴露一个或多个入口给别的module调用
  • 这种最简单，仅需创建一个IComponent实现类，并将原来直接类调用的代码改成组件调用即可
• 耦合度比较高的业务
  • 这种业务的拆分需要一定的时间，可以安排在迭代任务没那么繁忙的时间段来做。如果正好有改版的需求就更好了，可以借着改版的机会用组件化的方式来开发，替换原来的代码。
  • 也可以暂时先粗粒度地拆分，但按照全局的规划创建多个IComponent接口实现类，相当于一个module中包含多个组件，后续有时间再进一步拆分
• 各种Base类、工具类
  • 这种module建议仍然下沉作为公共库的形式供其它组件依赖

三、常见问题

3.1 自定义类型如何在组件间传递？

• 下沉到公共库中，作为公共类型
  • 适用于使用频次高或对性能要求特别敏感的场景
• json传递 & bean冗余：即在每个用到此类型的组件，通过冗余bean的方式来传递
  • 适用于使用频次较低且对性能要求不是十分敏感的场景

3.2 如何确定一个module到底是该作为组件提供服务还是下沉为base基础库供其它组件依赖？

由于组件有可单独运行调试、无强类型耦合、AOP等优点，除非有特殊情况，原则上绝大多数的业务module都应该作为组件来封装。

这些特殊情况有：

• 各种Base类、工具类
• 在组件间传递的公共自定义类型

其它诸如Fragment/View的组件化CC都已经支持了，如果有您需要的功能CC还未支持欢迎给我提issue

四、总结

本文主要介绍了如何更方便地使用CC框架来进行组件化改造，看完这篇文章后，对老项目进行组件化改造所需的成本应该有个比较直观的认识。

如果您虽然很想在自己负责的项目中实施组件化改造，渴望组件化开发带来的便利，但还有本文中未涉及到的其它顾虑导致尚未开始执行，欢迎在评论中给我留言！

QQ交流群

或者扫描下方二维码加群聊

image