关于终端业务组件化的几点思考

模块化和业务组件化

在终端开发中常常会因为项目的复杂度越来越高，而需要不断对业务做划分和分组，在Android中称为模块化，模块化的意义在于不断对项目做业务和代码层面的分离，从而最终做到业务的隔离和代码的复用，这种思想在其它平台也有所体现，例如WEB的前后端分离。在Android中一般来说，最终模块后架构大体如下：

其中上层可以依赖下层，业务模块之前不能相互依赖。这样做的好处在于：

• 因为业务模块不能依赖，所以业务之间理论上是隔离的，每一个业务只需要少部分人维护即可。
• 新人上手容易，只需要理解当前业务模块即可。
• 出现问题可控，修改代码只会影响当前模块。
• 对于大型APP来说，多个部门的APP代码可以分成多个git库管理，各个部门单独管理自己的代码，在打包的时候合并在一起即可。

当然，模块化的构建过程中会遇到一些问题，个人在实践过程中，遇到的最大的两个问题：

• 业务的划分。这是非技术问题，如何对业务做精准的划分，这涉及到产品层面和公司战略层面了。总而言之，模块化构建应当是服务于公司业务和部门业务的。
• 模块之间如何通信。虽然做了业务上的划分，但是无论无何也会存在业务模块之间进行相互耦合的情况，比如隶属于账户模块的授权系统可能会被其它模块所调用，并且返回数据。

第一个问题属于业务问题，需要项目负责人根据公司现状去做决策。第二问题在业界其实都有比较好的解决办法，模块化实践最好的莫过于微信了，微信Android模块化架构重构实践这篇文章对于第二个问题有自己的解决办法（lib的方式）。对于部门隔离要求不那么严格项目来说，这个解决方案也不失为一种好的方式。

上面聊的都是模块化，业务组件化其实是属于模块化的一种细分，模块化是从大的业务层级来进行梳理和代码隔离的，而业务组件化注重的是UI层面的组件化，但是又比UI组件更加粗粒度，业务组件化就像是搭积木，积木就是这个组件。可以想象也一个页面由产品列表、购买按钮组成，其中，产品列表和购买按钮就是一个组件，购买按钮不仅仅是一个按钮，它包含整个购买逻辑：

• 购买产品信息的输入和结算
• 购买流程的处理
• 数据的返回和异常情况的处理

本质上来看，对于终端来说，所谓的业务组件化其实就是一个绑定了特定业务的UI组件，这个UI组件可以针对很多类似场景进行数据的输入和输出，并处理特定的业务。

这样做优点是显而易见的

• 通过预先定好的组件，开发工作量大量减少。
• 可配置性强，甚至可以让服务端通过下发配置动态生成页面。

业务组件化的难点

Android业务组件化在技术方面来讲，其实和其它项目组件化没有本质化的不同，其它组件化需要考虑到问题都需要考虑：

• 多业务组件的管理，组件管理器。
• 业务层的管理和定义，业务层。
• 组件间的通信机制，通信层。
• 基层UI组件的定义，UI层。

根据上面思路，粗略画了一个图

为了防止组件的耦合需要设计一个组件之间的通讯机制，这个通讯模块设计原理和模块化的通信类似。个人认为这种组件化设计其实是不难的，只需要在设计的时候考虑多复用和易用性即可。

那么，业务组件化最难的是什么呢？

个人认为业务组件化，到了编码阶段其实是不难的，真正难的是在于编码之前的阶段：

产品经理如何定义业务组件？

设计师如何规范统一风格业务组件？

这两个问题，考验的是整个项目的的统一协调能力，考验的是整个项目的规划性和整个公司战略方向。

产品经理如何定义好一个业务组件？

• 考虑这是一个业务组件吗？
• 这个后期需要复用或者更改吗？
• 需要预先定义好哪些可能的变化?
• 整个项目类似的功能能够保持一致性吗？

这些问题和技术无关，和产品思路和公司整体战略有关，非产品和技术负责人不能推动。

设计师如何定义一套风格类似的组件？

• 整个项目有标准的UI规范吗？
• 如何让每个设计师能够设计出风格一致的设计？
• 技术如何能够遵守这个设计规范，并形成通用型UI组件？

考虑一个登陆授权组件，一般来说可能流程是这样的：

用户点击页面上的某个登陆按钮-》按钮跳转到一个授权登陆页面-》用户输入授权信息-》根据用户的授权信息，通过服务器去验证-》返回授权结果。

其中，设计师可能需要考虑：

• 登陆授权按钮风格是否是固定的，是否需要排除到业务组件外面？
• 授权页面是否整个项目公用？设计风格是否不同页面会发生变化？
• 在整个组件进行过程中，异常情况如何提示给用户？如何做出风格一致的反馈和设计？

产品经理考虑可能：

• 这个授权系统是否需要产品复用？
• 不同用户类型授权方式是否需要预先留好接口？
• 统一的风格是否符合产品意图？
• 异常情况下如何处理？

整个过程如果没有沟通清楚就会导致整个业务组件的定义失败。登陆授权还是简单的业务，如果遇到类似于支付宝这种复杂业务的产品，就需要在开发产品前考虑到这些问题。

从技术层面来说，越早定义好业务组件，实现就越简单，在业务还没有铺开、代码复杂度越低的时候实现就越简单。因此，业务组件化应当是一个持续的过程，特别是对于一个快速迭代的项目来说，业务组件化应当贯穿整个产品的所有开发过程。

总结

业务组件化非常难以推行，往往不是因为技术方面的问题，大都是因为产品层面导致的。当然，一个有权威、了解产品负责人进行业务组件化跨部门推进也是非常关键的，因此，如果你想推行业务组件化，那就先从产品层面梳理项目，并选一个靠谱、有权威的负责人来推进吧！