随着项目的不断迭代,复杂的业务模块及项目自身的基础技术组件迅速扩张,以往基于单个模块的项目往往显得过于臃肿。代码目录结构,包名混乱,代码模块职责不清晰,耦合度高,不便维护。基础公共组件没有抽取并剥离干净,新人上手较难,项目整体编译慢,等等。于是,近几年来,基于 Gradle
构建的模块化方案得到迅速应用,甚至在划分模块的同时,也可以将基础公共组件抽取独立的项目,并以单独的 Git
库进行管理和维护。
模块化的方案,整体上能够很好的将各个模块按照自身的职责进行独立划分,无论是基于业务的,还是基于技术的角度,得以能够达到“高内聚,低耦合”的效果。
但现实中,往往还存在一种“居中”的情况。
1,基于业务或者技术角度划分的模块,在职责界定时往往是有粒度的,这种粒度,有可能很大,也可以很小,如果以过大的粒度划分模块,模块内的代码耦合和隔离等情况依然存在问题,如果以过小的粒度分化模块,使得整个项目最终形成的模块往往过多,也不太利于整体理解和维护管理。
2,最终形成的项目模块,应该是粒度适中的,如基于业务维护的划分(从产品或用户视角下的产品功能),基于基于技术视角的基于职责的基础技术库的模块剥离。
3,最终形成的项目模块,尤其是基于业务维护的划分,最终模块内依然会存在多个子级粒度的业务,此时,在不宜进一步继续直接模块化的基础上,应该有一套类似模块化本身思维的技术方案,以实现模块内的模块划分,或称之为代码隔离。
子级粒度的业务,往往不仅包含既有的 java
代码,还包括了可能的 jar
包或 so
文件引入,可能图片资源,字符串类型资源,以及常见的布局文件等,此时,如果仅仅是传统方案下的 java
源码级别的按照目录形式的划分,往往是不够彻底的。
于是,微信最早对外发布的文章,微信Android架构历史,其中详细介绍了其模块内的代码隔离方案,pins。
后来,美团外卖中也是参照同样的思路实现了模块内的代码隔离。具体参见: 美团外卖Android平台化架构演进实践
在思维模式上, pins
其实与项目模块化本身,具有异曲同工之妙。并且也是在充分利用了 Android Gradle
构建工具基础上,通过修改指定的源集逻辑,显示隔离后的代码及资源文件的重新组合。
在技术原理上, pins
自身并没有太多的技术本身,更多的充分利用了 Android Gradle
构建工具,比较巧妙的实现了模块内的再次隔离。
1,将模块内按照子级业务再次抽取,最终形成与 src/main
同样级别的目录划分(与上图中的微信pins目录结构有所不同),抽取的子级模块以 p_子级模块名
命名,其中, p_
开头是为了后续修改源集逻辑时候的区分标识;
2,对应剥离具体的子级业务,包含 java
代码,其他资源文件等;
3,修改对应模块的 Android Gradle
构建时的源集逻辑,主要通过如: java.srcDir
、 res.srcDir
等方法将 p_子级模块名
对应添加上去。
对应修改源集逻辑主体部分如下:
android { sourceSets { main { def src_dir = new File(projectDir, 'src') def dirs = src_dir .listFiles() .toList() .stream() .filter(new Predicate<File>() { @Override boolean test(File file) { return file.getName().startsWith("p_") } }) .map { return it.getName() } .collect(Collectors.toList()) println("pins-module: " + dirs) dirs.each { dir -> java.srcDir("src/$dir/java") res.srcDir("src/$dir/res") } } } } 复制代码
项目整体,依托模块化进行整体大的业务和技术模块划分,模块内,依据业务粒度,子级别的参照 pins
思路实现模块内的进一步代码及资源隔离,基础的公共技术组件,抽取成单独的 Git
项目库管理,以形成项目整体上的模块化实践方案。