Android组件化开发实践（六）：老项目实施组件化-阿里云开发者社区

Android组件化开发实践（六）：老项目实施组件化

2018-10-08 1422

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 比较早期的时候，我们开发APP都是采用单一工程模式，随着业务的发展，APP越来越庞大，开发人员越来越多，所以必然面临着将老项目进行组件化的过程。在将老项目进行组件化的过程中，会面临很多的问题，以我自己的经验为例，主要有以下点：代码年久失修，文档缺失，不敢随意修改，否则会牵一发而动全身，引起现有正常业务的运行；进行组件化重构需要花费比较长的时间，业务不可能停下来等着你去重构；组件化重构后，需要全量回归测试，测试比较花费时间；相信每个人都会碰到这些问题，组件化重构势在必行，但是老板不可能专门给你几个月，啥业务都不做就让你进行代码重构。

比较早期的时候，我们开发APP都是采用单一工程模式，随着业务的发展，APP越来越庞大，开发人员越来越多，所以必然面临着将老项目进行组件化的过程。

在将老项目进行组件化的过程中，会面临很多的问题，以我自己的经验为例，主要有以下点：

代码年久失修，文档缺失，不敢随意修改，否则会牵一发而动全身，引起现有正常业务的运行；
进行组件化重构需要花费比较长的时间，业务不可能停下来等着你去重构；
组件化重构后，需要全量回归测试，测试比较花费时间；

相信每个人都会碰到这些问题，组件化重构势在必行，但是老板不可能专门给你几个月，啥业务都不做就让你进行代码重构。那怎么办呢，我这里讲讲自己的一些经验，供大家参考。

1. 优先集成路由框架

首先，在老项目中引入路由框架，不管是自己简单设计的也好，还是采用第三方框架，新开发的功能页面跳转一律采用路由，老的页面跳转逐步替换。这样做的目的是尽量减少代码耦合，为后面进行模块拆分打下基础。

2. 业务模块拆分

一个老项目必然经过很多人的手，你不一定要对所有代码都很熟悉，但是你必须要基本了解所有的业务功能，在此基础上对所有业务进行初步的模块划分。这个业务模块划分，粒度可以粗一点，原则上一个业务模块只是实现某一个子功能。

以我自己为例，我会采用xmind或类似工具，将所拆分的业务画出来，就像一个公司的组织架构一样：公司由若干个大的事业部组成，每个事业部包含若干个二级部门，二级部门又有可能包含三级部门。将你的项目划分成几个大的业务，每个大的业务再细化成若干个小的业务，业务层次划分不必太细，一般保持2层即可，否则设计的组件太多，实施起来会更加繁琐。

总之，最后你一定要有一张你的整体业务架构图，如上图所示，它仅仅是你对APP所有业务的模块划分。

3. 尝试抽取出一个基础的业务组件

罗马不是一天造成的，人不能一口吃成一个胖子。同样，你也不可能一下子将所有的业务，都进行组件化剥离出来。万事开头难，特别是老项目在进行组件化重构时，往往我们会有无从下手的感觉。回顾一下上一节中你整理出来的业务架构图，从中找出一个你觉得最核心最基础的业务，也就是你觉得这个业务必须最先进行组件化重构。通常情况下，我会选择“注册/登录”这个业务模块，在我们的应用里，很多业务都是需要用户登录的。

首先，新建一个工程，不管三七二十一，把老工程里的注册、登录相关的代码拷贝过来，包括Activity类、布局xml文件、图片文件等，其他的暂时不要考虑。这个时候，你会发现新的工程里，到处都是红色的警告错误，要么依赖的某个类不存在，要么依赖的某个资源文件不存在，根本无法编译运行。不能运行就对了，显然这种粗暴的方式行不通，如果你尝试去解决，你会发现类似这样的依赖路径：A -> B -> C ->D，你得把所有依赖的类或资源拷贝到新工程里，这可能会形成一颗巨大的依赖树，实施起来难度太大了，基本不现实。

显然，想直接把老工程的代码原样复制过来，期望一次性成功，大部分情况下都不会成功。那么我们要怎么做呢，现在又会有一种无从下手的感觉了。

4. 画出代码的依赖关系图

我们把老工程的代码复制过来之后，发现依赖的资源太多了，压根没法编译运行。既然我想把“注册、登录”这个业务模块做成一个独立的组件，那么这个业务模块里所依赖的其他资源，是不是也得是个独立的组件。同样，采用xmind画出“注册、登录”这个业务所依赖的其他资源，如下图所示：

通过查看新工程里报错的地方，大概可以总结出“注册、登录”业务需要依赖上图所示的这些资源。

5. 抽取出基础功能组件

当我们把“注册、登录”所有依赖的资源列举出来之后，我们先把这些依赖的东西，从老工程中抽取出来，做成单独的组件。

日志记录
打印或者记录程序运行时日志。
网络请求
请求服务端接口用到的网络框架，例如OkHttp、Retrofit等，或者是自己封装的框架。
数据库等数据存储
用户登录后，需要保存登录信息到本地，采用数据库或者SharedPreference等存储。
图片、样式、字符串等资源
UI相关的各种资源，有些资源是全局通用的，有些是该业务里独有的，我们只把通用的UI资源放到组件里，因为这些需要共用的。
常用的一些工具类
例如字符串处理、日期格式化、dp与px转换等。
BaseActivity等Base类
BaseActivity是所有Activity都必须继承的父类，在这里定义一些Activity通用的行为，例如友盟统计埋点等。

我们先按照这些功能，建立对应的基础功能组件模块，然后将注册、登录业务里需要用到的从老工程移到对应的组件模块里。刚开始的时候，我们的目标是先创建组件，组件的功能也许很薄弱，代码也许很凌乱，规范也没有，但是我们先不管它，先做到能用就行。先有基本的框架，等架子搭起来之后，我们再去丰满血肉。

6. 重新封装基础业务组件

上一节中的基础功能组件封装好之后，在“注册、登录”这个组件工程里，依赖需要的基础组件，然后逐步解决冲突错误等，直到该工程能够独立运行。最后，我们需要花时间调整代码规范，优化代码结构等。

7. 新老代码共存

到现在为止，我们已经将一个业务组件独立出来。接下来，我们需要将该组件集成到老工程里去，只需要将注册、登录的跳转入口改一下，就可以使用了。经过测试之后，逐步删除老工程里的旧代码，这样下来之后，注册、登录使用的是新的组件，而其他功能依旧没变。

接下来的时间里，我们采取开发新功能与重构并行的方式，每周安排一部分人去重构，一部分人依旧在老工程里开发，经过一段时间之后，逐步将老工程的业务全部组件化，到最后老工程里应该几乎没代码了。但是在这个期间，我们的项目工程里可能会包含很多冗余的代码、冗余的资源文件等，这也会导致APP的包大小增大，但这些是不可避免的。

小结

老项目组件化是一个渐进的过程，我们必须先选定一个突破口，完成一个组件之后，后面其他的业务实施组件化就会相对容易多了。我们必须控制好整个组件化实施的周期，严格按照计划执行，同时要把握好新功能开发与重构之间的度。