关于settings.gradle的一些小建议

[QuincyJiang]

可以在settings.gradle中添加两个新的closure 比如

  includeModule ':projectA'
  includeApp ':app'

来替代原生的 include语法。
当module已发布为aar或者local maven之后，可以直接将settings.gradle对应的子project从编译路径中删除，这样可以节省子project的gradle evaluate时间

[JustAClamber]

我们后续有时间的话尝试下这种方式，或者如果你有精力能够帮我们完善这块优化就更好了。

[trycatchx]

@QuincyJiang 每一个子 project 不跑 configure 也就是 project evaluate，没法知道 每一个 project 的 dependency （依赖了哪些库）。也就是只有跑完 evaluate ，才能得到 dependency 。当然如果能减少每个模块的 configure 时间还可以减少 10% 以上的编译速度。是一个不错的思路。

[Hynsn]

顺便能请教一下，RN混合工程离线都打开了为啥gradle执行的时候还是每次去下载react-native.0.62.pom？
公司项目是RN混合的，观察到编译时这个步骤比较耗时，请教一下我能拦截或者跳过这个环节吗

[trycatchx]

@Hynsn 依赖的 version 是否使用了 + 号，或者 SNAPSHOT ，或者使用了 resolutionStrategy.cacheChangingModulesFor，
或者是其他的原因。当然你能找到对应的task 可以通过 task.enabled = false 进行禁止运行

[QuincyJiang]

@QuincyJiang 每一个子 project 不跑 configure 也就是 project evaluate，没法知道 每一个 project 的 dependency （依赖了哪些库）。也就是只有跑完 evaluate ，才能得到 dependency 。当然如果能减少每个模块的 configure 时间还可以减少 10% 以上的编译速度。是一个不错的思路。

初次解析settings的时候，可以全部加入subproject里，等project解析完可以知道所有模块的依赖信息的，这个可以缓存起来，在项目依赖结构没有调整的情况下可以一直使用 （占90%以上的case)。
当没有变更依赖关系的时候：
A模块修改后，根据依赖缓存可以把上层模块全部退化为源码，并加入到settings的include中。
有依赖变更 比如增加或者删除了 settings里include的module时，可以直接让这个依赖缓存全部失效，重新add所有子module并解析。

方案理论上可行，但是缓存的维护可能会比较复杂

[trycatchx]

@QuincyJiang 每一个子 project 不跑 configure 也就是 project evaluate，没法知道 每一个 project 的 dependency （依赖了哪些库）。也就是只有跑完 evaluate ，才能得到 dependency 。当然如果能减少每个模块的 configure 时间还可以减少 10% 以上的编译速度。是一个不错的思路。

初次解析settings的时候，可以全部加入subproject里，等project解析完可以知道所有模块的依赖信息的，这个可以缓存起来，在项目依赖结构没有调整的情况下可以一直使用 （占90%以上的case)。

当没有变更依赖关系的时候：

A模块修改后，根据依赖缓存可以把上层模块全部退化为源码，并加入到settings的include中。

有依赖变更 比如增加或者删除了 settings里include的module时，可以直接让这个依赖缓存全部失效，重新add所有子module并解析。

方案理论上可行，但是缓存的维护可能会比较复杂

是的，缓存方案是可以解决这个问题，理论上可能会带来一个副作用：模块的索引可能会消失。(譬如类的跳转) 。

当然这个会在下期需求进入研究，确定是否有可行性。