随着项目的不断迭代，复杂的业务模块及项目自身的基础技术组件迅速扩张，以往基于单个模块的项目往往显得过于臃肿。代码目录结构，包名混乱，代码模块职责不清晰，耦合度高，不便维护。基础公共组件没有抽取并剥离干净，新人上手较难，项目整体编译慢，等等。于是，近几年来，基于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
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。