pins-模块内的代码及资源隔离方案

随着项目的不断迭代，复杂的业务模块及项目自身的基础技术组件迅速扩张，以往基于单个模块的项目每每显得过于臃肿。代码目录结构，包名混乱，代码模块职责不清晰，耦合度高，不便维护。基础公共组件没有抽取并剥离干净，新人上手较难，项目总体编译慢，等等。因而，近几年来，基于Gradle构建的模块化方案获得迅速应用，甚至在划分模块的同时，也能够将基础公共组件抽取独立的项目，并以单独的Git库进行管理和维护。html

模块化的方案，总体上可以很好的将各个模块按照自身的职责进行独立划分，不管是基于业务的，仍是基于技术的角度，得以可以达到“高内聚，低耦合”的效果。java

但现实中，每每还存在一种“居中”的状况。
1，基于业务或者技术角度划分的模块，在职责界定时每每是有粒度的，这种粒度，有可能很大，也能够很小，若是以过大的粒度划分模块，模块内的代码耦合和隔离等状况依然存在问题，若是以太小的粒度分化模块，使得整个项目最终造成的模块每每过多，也不太利于总体理解和维护管理。android

2，最终造成的项目模块，应该是粒度适中的，如基于业务维护的划分（从产品或用户视角下的产品功能），基于基于技术视角的基于职责的基础技术库的模块剥离。web

3，最终造成的项目模块，尤为是基于业务维护的划分，最终模块内依然会存在多个子级粒度的业务，此时，在不宜进一步继续直接模块化的基础上，应该有一套相似模块化自己思惟的技术方案，以实现模块内的模块划分，或称之为代码隔离。bash

子级粒度的业务，每每不只包含既有的java代码，还包括了可能的jar包或so文件引入，可能图片资源，字符串类型资源，以及常见的布局文件等，此时，若是仅仅是传统方案下的java源码级别的按照目录形式的划分，每每是不够完全的。微信

因而，微信最先对外发布的文章，微信Android架构历史，其中详细介绍了其模块内的代码隔离方案，pins。
后来，美团外卖中也是参照一样的思路实现了模块内的代码隔离。具体参见：美团外卖Android平台化架构演进实践架构

在思惟模式上，pins其实与项目模块化自己，具备殊途同归之妙。而且也是在充分利用了Android Gradle构建工具基础上，经过修改指定的源集逻辑，显示隔离后的代码及资源文件的从新组合。app

在技术原理上，pins自身并无太多的技术自己，更多的充分利用了Android Gradle构建工具，比较巧妙的实现了模块内的再次隔离。ide

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项目库管理，以造成项目总体上的模块化实践方案。