Android 项目组件化重构的一些考虑

重构的目的

一言以蔽之：重构就是为了改善既有代码的设计。

在既不修正错误，又不增加新的功能性前提下，重构是用于提高代码的可维护性、改善代码内部结构与设计、移除冗余代码、增强代码可阅读性、降低业务耦合的重要手段。

通过重构代码来增进内部的清晰性和一致性，面向代码未来的生命周期，使其在将来更具有维护性，可以说这是一种项目可持续的技术演进。

重构内容

考虑到实际中的项目情况，项目重构的主要工作内容分为下面几个方面：

• 构建组件化多模块项目架构，分离业务组件和基础模块，提高业务组件的可测试性和基础模块的可复用性；
• 重复代码的提炼，剔除重复代码，提出核心库；
• 按照实际需求场景，整理竞品相关资料，统一业务逻辑、规范接口、解耦、增强模块扩展性；
• 代码优化，拆分冗长的类，Review 代码逻辑，完善业务流程；
• 提取继承体系中重复的属性与方法到父类，重新封装提告可复用性；

具体实施过程

构建模块化基础架构

这个可以根据项目实际情况，针对项目组件化开发进行预研，确定了合适的技术选型方案，并考虑构建了组件化的项目基础架构。

关于组件化和模块化的区别，相信很多开发者对于两者的定义都有各自的理解。

模块化就是将一个程序按照其功能做拆分，分成相互独立的模块，以便于每个模块只包含与其功能相关的内容。模块我们相对熟悉,比如登录功能可以是一个模块，搜索功能可以是一个模块。

组件化就是基于可重用的目的，将一个大的软件系统按照分离关注点的形式，拆分成多个独立的组件，降低耦合。所以一个组件也可以是模块，一个模块也可以是一个组件。

模块化和组件化本质思想是一样的，都是“大化小”，两者的目的都是为了重用和解耦，如果非要说区别，那么可以认为模块化粒度更小，更侧重于代码功能上的重用，而组件化粒度稍大于模块，更侧重于业务解耦。

所以组件化的核心思想其实是为业务解耦服务的，一个组件最大的特点是具有了独立运行的能力，可以作为一个能偶进行独立开发、运行、测试、发布的工程项目，所以最大的优势是大大缩减了工程结构直接降低了编译时间，让开发和测试可以同时进行，业务既可以整合也可以独立拆分。

纵向维度划分——分层架构思想

说到分层结构，就不得不提到 Uncle Bob 写的 The Clean Architecture 这篇文章。关于这篇文章中提到的 Clean 模型，有一个很重要的思想就是：代码结构用一个依赖规则分离到洋葱状的层来表示：内层不应该知道任何关于外层的东西，也就是外层依赖应该指向里面。

The Clean Architecture.png

通常在 App 开发中提到的 3 层架构可以说是一种物理分层概念，从上往下即展示层、业务层、持久层，也从上往下由上一层依赖下一层。不同层之间也是高内聚低耦合的体现，层内高内聚，层间低耦合，所谓的层是对层内具体工作的高度抽象。低耦合则是依赖倒转原则体现出来，高层依赖于下层的抽象而不是具体。

传统的过程性系统的设计方法倾向于使高层次的模块依赖于低层次的模块，抽象层次依赖于具体层次。倒置原则就是要把这个错误的依赖关系倒转过来。也就是常说的要针对接口编程，不要针对实现编程。高层的模块依赖于低层的模块时，这些高层模块就很难在不同的环境中复用。但是当那些高层模块独立于低层模块时，它们就能很简单地被复用了。这正是位于框架设计的最核心之处的原则。

而对于项目中开发中经常提到的采用了 M-V-C 或 M-V-P 或 M-V-VM 架构设计，其实为了区别开 3 层架构的分层结构，M-V-X更适合说是一种项目设计模式，这些都是为了解决拥有图像界面的程序开发复杂性而产生的模式。

按照我开发中所面对的实际业务场景，如果从开发者 App 到 SDK 从外到内这个过程来划分，项目大致可分为业务核心层、数据模型层、 基础服务层三个层次。按照事件从外到内，数据从里及外的传递。每一层都有各自独立的功能模块，上层依赖于下一层的服务，下一层为上层的业务提供服务支撑。

这里举个之前做 SDK 开发的例子。我们把现有业务 SDK 的不同业务类型作为划分业务组件的依据，实现了业务组件之间的相互独立，业务逻辑不会有相互耦合，而组件内部又是可以单独开发、运行调试、打包测试、单独发布。项目的基础服务层实现了多模块化，网络请求、缓存控制作为了数据核心模块单独提出，从各业务模块中抽离可共用的公共模块，提升可复用性，为上层业务提供统一的基础服务。

基础架构.png

参考资料：

The Clean Architecture

Android业务组件化开发实践

Android 跨 module 交互和方法调用

Android架构思考(模块化、多进程)

Android 开发:由模块化到组件化(一)