pins-模块内的代码及资源隔离方案
随着项目的不断迭代,复杂的业务模块及项目自身的基础技术组件迅速扩张,以往基于单个模块的项目往往显得过于臃肿。代码目录结构,包名混乱,代码模块职责不清晰,耦合度高,不便维护。基础公共组件没有抽取并剥离干净,新人上手较难,项目整体编译慢,等等。于是,近几年来,基于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
项目库管理,以形成项目整体上的模块化实践方案。
作者:HappyCorn
链接:https://juejin.im/post/5c710d16518825626463d372
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
笔者水平有限,若有错漏,欢迎指正,如果转载以及CV操作,请务必注明出处,谢谢!