我改进了我们的构建系统并激活了增量构建和编译,如本问题中所述。令我失望的是,增量编译并没有像阅读Gradles 博客文章所期望的那样缩短构建时间。
经过一番调查,我意识到问题在于,即使我只在应用程序深处的某个小类中添加了评论,显然几乎整个代码库都被重建了。事实上,我接触哪个类并不重要,Gradles--debug
输出显示它基本上总是重新编译 476 个类。
476 个类的增量编译在 12.51 秒内完成。
虽然我知道public static
更改文件中的常量会触发完全重新编译(只是稍微慢一点),但我不明白如何正确分解类依赖项以便增量编译真正起作用。确定影响增量编译的类依赖项的确切规则是什么?我可以在这里阅读一些示例,但它似乎根本不适用于我们的(相当标准的)项目。
我自己的一些测试产生了以下结果:
// One of my main classes that has lots of class dependencies
public class A{
public void foo() {
// This line produces a dependency between A and B. So changing just
// a comment in B triggers recompilation of all classes attached to A
B b1 = new B();
}
}
// A small helper class that I want to change
public class B {
public void bar() {
// This line does not create a dependency, so B can still be compiled by
// itself. But usually, that's not the "common" direction you have.
A a1 = new A();
// I make the change here and then trigger a new build
}
}
为什么 A 在实现细节而不是 B 的接口发生变化时需要重新编译?
我还尝试在接口 C 后面“隐藏”B。我认为这将是打破依赖关系的正确方法(尽管通常非常麻烦)。但事实证明它根本没有帮助。
public class A{
public void foo() {
C c1 = C.cFactory();
}
}
public class B implements C {
public void bar() {
// I make the change here and then trigger a new build
}
}
public interface C {
void bar();
public static C cFactory() {
return new B();
}
}
在我看来,我们有这么大的依赖 blob,我不确定这是否可以合理地改变,即使我认为我们有一个设计合理的代码库。Android 开发人员中是否有可以有效改进增量编译的最佳实践、指南或设计模式?
我确实想知道其他人是否和我们有同样的问题,如果没有,你做了什么?