比较早期的时候,我们开发APP都是采用单一工程模式,随着业务的发展,APP越来越庞大,开发人员越来越多,所以必然面临着将老项目进行组件化的过程。
在将老项目进行组件化的过程中,会面临很多的问题,以我自己的经验为例,主要有以下点:
- 代码年久失修,文档缺失,不敢随意修改,否则会牵一发而动全身,引起现有正常业务的运行;
- 进行组件化重构需要花费比较长的时间,业务不可能停下来等着你去重构;
- 组件化重构后,需要全量回归测试,测试比较花费时间;
相信每个人都会碰到这些问题,组件化重构势在必行,但是老板不可能专门给你几个月,啥业务都不做就让你进行代码重构。那怎么办呢,我这里讲讲自己的一些经验,供大家参考。
1. 优先集成路由框架
首先,在老项目中引入路由框架,不管是自己简单设计的也好,还是采用第三方框架,新开发的功能页面跳转一律采用路由,老的页面跳转逐步替换。这样做的目的是尽量减少代码耦合,为后面进行模块拆分打下基础。
2. 业务模块拆分
一个老项目必然经过很多人的手,你不一定要对所有代码都很熟悉,但是你必须要基本了解所有的业务功能,在此基础上对所有业务进行初步的模块划分。这个业务模块划分,粒度可以粗一点,原则上一个业务模块只是实现某一个子功能。
以我自己为例,我会采用xmind或类似工具,将所拆分的业务画出来,就像一个公司的组织架构一样:公司由若干个大的事业部组成,每个事业部包含若干个二级部门,二级部门又有可能包含三级部门。将你的项目划分成几个大的业务,每个大的业务再细化成若干个小的业务,业务层次划分不必太细,一般保持2层即可,否则设计的组件太多,实施起来会更加繁琐。
![img_a85efefbd755d3378b4fce7cb80f5272.png](https://i-blog.csdnimg.cn/blog_migrate/72b3a3983c11ad4855c6ae8240478d3e.png)
总之,最后你一定要有一张你的整体业务架构图,如上图所示,它仅仅是你对APP所有业务的模块划分。
3. 尝试抽取出一个基础的业务组件
罗马不是一天造成的,人不能一口吃成一个胖子。同样,你也不可能一下子将所有的业务,都进行组件化剥离出来。万事开头难,特别是老项目在进行组件化重构时,往往我们会有无从下手的感觉。回顾一下上一节中你整理出来的业务架构图,从中找出一个你觉得最核心最基础的业务,也就是你觉得这个业务必须最先进行组件化重构。通常情况下,我会选择“注册/登录”这个业务模块,在我们的应用里,很多业务都是需要用户登录的。
首先,新建一个工程,不管三七二十一,把老工程里的注册、登录相关的代码拷贝过来,包括Activity类、布局xml文件、图片文件等,其他的暂时不要考虑。这个时候,你会发现新的工程里,到处都是红色的警告错误,要么依赖的某个类不存在,要么依赖的某个资源文件不存在,根本无法编译运行。不能运行就对了,显然这种粗暴的方式行不通,如果你尝试去解决,你会发现类似这样的依赖路径:A -> B -> C ->D,你得把所有依赖的类或资源拷贝到新工程里,这可能会形成一颗巨大的依赖树,实施起来难度太大了,基本不现实。
显然,想直接把老工程的代码原样复制过来,期望一次性成功,大部分情况下都不会成功。那么我们要怎么做呢,现在又会有一种无从下手的感觉了。
4. 画出代码的依赖关系图
我们把老工程的代码复制过来之后,发现依赖的资源太多了,压根没法编译运行。既然我想把“注册、登录”这个业务模块做成一个独立的组件,那么这个业务模块里所依赖的其他资源,是不是也得是个独立的组件。同样,采用xmind画出“注册、登录”这个业务所依赖的其他资源,如下图所示:
![img_45b2d70a7fbac780b9e5730648b1b2d4.png](https://i-blog.csdnimg.cn/blog_migrate/a80678d4a9dc25cd43ecbb73fed8c936.png)
通过查看新工程里报错的地方,大概可以总结出“注册、登录”业务需要依赖上图所示的这些资源。
5. 抽取出基础功能组件
当我们把“注册、登录”所有依赖的资源列举出来之后,我们先把这些依赖的东西,从老工程中抽取出来,做成单独的组件。
- 日志记录
打印或者记录程序运行时日志。 - 网络请求
请求服务端接口用到的网络框架,例如OkHttp、Retrofit等,或者是自己封装的框架。 - 数据库等数据存储
用户登录后,需要保存登录信息到本地,采用数据库或者SharedPreference等存储。 - 图片、样式、字符串等资源
UI相关的各种资源,有些资源是全局通用的,有些是该业务里独有的,我们只把通用的UI资源放到组件里,因为这些需要共用的。 - 常用的一些工具类
例如字符串处理、日期格式化、dp与px转换等。 - BaseActivity等Base类
BaseActivity是所有Activity都必须继承的父类,在这里定义一些Activity通用的行为,例如友盟统计埋点等。
我们先按照这些功能,建立对应的基础功能组件模块,然后将注册、登录业务里需要用到的从老工程移到对应的组件模块里。刚开始的时候,我们的目标是先创建组件,组件的功能也许很薄弱,代码也许很凌乱,规范也没有,但是我们先不管它,先做到能用就行。先有基本的框架,等架子搭起来之后,我们再去丰满血肉。
6. 重新封装基础业务组件
上一节中的基础功能组件封装好之后,在“注册、登录”这个组件工程里,依赖需要的基础组件,然后逐步解决冲突错误等,直到该工程能够独立运行。最后,我们需要花时间调整代码规范,优化代码结构等。
7. 新老代码共存
到现在为止,我们已经将一个业务组件独立出来。接下来,我们需要将该组件集成到老工程里去,只需要将注册、登录的跳转入口改一下,就可以使用了。经过测试之后,逐步删除老工程里的旧代码,这样下来之后,注册、登录使用的是新的组件,而其他功能依旧没变。
接下来的时间里,我们采取开发新功能与重构并行的方式,每周安排一部分人去重构,一部分人依旧在老工程里开发,经过一段时间之后,逐步将老工程的业务全部组件化,到最后老工程里应该几乎没代码了。但是在这个期间,我们的项目工程里可能会包含很多冗余的代码、冗余的资源文件等,这也会导致APP的包大小增大,但这些是不可避免的。
小结
老项目组件化是一个渐进的过程,我们必须先选定一个突破口,完成一个组件之后,后面其他的业务实施组件化就会相对容易多了。我们必须控制好整个组件化实施的周期,严格按照计划执行,同时要把握好新功能开发与重构之间的度。
系列文章
Android组件化开发实践(一):为什么要进行组件化开发?
Android组件化开发实践(二):组件化架构设计
Android组件化开发实践(三):组件开发规范
Android组件化开发实践(四):组件间通信问题
Android组件化开发实践(五):组件生命周期管理
Android组件化开发实践(六):老项目实施组件化
Android组件化开发实践(七):开发常见问题及解决方案
Android组件化开发实践(八):组件生命周期如何实现自动注册管理
Android组件化开发实践(九):自定义Gradle插件