Gradle源码解读（二）

概述

之前分析了从执行 gradlew assemble 命令开始，gradle是如何一步步执行起来的，上文说到最后会执行this.executer.execute方法，这一篇我就从这里开始继续往下走，顺便看一下this.executer的创造方法。

在追溯this.executer是什么的过程中发现了一种很巧妙的构造模式，因为它是提供某种类型实例的创建，所以我把它叫做工厂模式，但是和传统的工厂模式相比又有特别的地方，我不知道该怎么命名它，它是通过注册方法的反射调用来创建对应类型的实例的，暂且就叫它方法工厂模式吧。

在传统的工厂模式应用中，我们通常会创建一个工厂类，然后通过某个getInstance方法来创建对应实例，而这个升级版本就是通过反射把所谓的工厂实例来生成，过程中需要的参数实例都通过配置的工厂类型来创建，这些用到的所有类型都通过方法定义来配置，所有的方法都会封装成包含方法反射信息的对象，之后需要的时候通过反射来调用对应方法来生成需要的实例。

下面通过代码来看看是如何实现的。

代码入口

上次追溯到在BuildActionsFactory的runBuildInProcess方法中：

private Runnable runBuildInProcess(StartParameterInternal startParameter, DaemonParameters daemonParameters) {
    ServiceRegistry globalServices = ServiceRegistryBuilder.builder().displayName("Global services").parent(this.loggingServices).parent(NativeServices.getInstance()).provider(new GlobalScopeServices(startParameter.isContinuous())).build();
    return this.runBuildAndCloseServices(startParameter, daemonParameters, (BuildActionExecuter)globalServices.get(BuildExecuter.class), globalServices, globalServices.get(GradleUserHomeScopeServiceRegistry.class));
}

这个方法里有一句(BuildActionExecuter)globalServices.get(BuildExecuter.class)，这句代码返回的对象就是传递下去的this.executer，很显然它是一个BuildActionExecuter类型，但是它的实现类我们现在无法得知，需要通过globalServices.get(BuildExecuter.class)来查找。

globalServices通过ServiceRegistryBuilder.builder()的build方法生成：

public ServiceRegistry build() {
      //这里的parents传递数组只会包含第一个元素
    DefaultServiceRegistry registry = new DefaultServiceRegistry(this.displayName, (ServiceRegistry[])this.parents.toArray(new ServiceRegistry[0]));
    Iterator var2 = this.providers.iterator();
      
    while(var2.hasNext()) {
        Object provider = var2.next();
        registry.addProvider(provider);
    }

    return registry;
}

可见返回了一个DefaultServiceRegistry对象，而这个对象就是整个工厂模式的入口。

DefaultServiceRegistry

从名字上可以看出，这是一个默认的服务注册的地方。来看一下它的构造方法：

private final OwnServices ownServices;
private final ServiceProvider allServices;
private final ServiceProvider parentServices;
private final String displayName;
private final ServiceProvider thisAsServiceProvider;

public DefaultServiceRegistry(String displayName, ServiceRegistry... parents) {
    this.state = new AtomicReference(DefaultServiceRegistry.State.INIT);
    this.displayName = displayName;
    this.ownServices = new OwnServices();
    if (parents.length == 0) {
        this.parentServices = null;
        this.allServices = this.ownServices;
    } else {
        this.parentServices = setupParentServices(parents);
        this.allServices = new CompositeServiceProvider(new ServiceProvider[]{this.ownServices, this.parentServices});
    }

    this.thisAsServiceProvider = this.allServices;
    this.findProviderMethods(this);
}

回看前面的ServiceRegistryBuilder.builder的build方法，发现parent方法其实是把参数传递给DefaultServiceRegistry的parentServices，而provider方法则是通过addProvider方法把参数传递给了ownServices：

public DefaultServiceRegistry addProvider(Object provider) {
    this.assertMutable();
    this.findProviderMethods(provider);
    return this;
}

findProviderMethods方法只在两个地方调用，一个是构造方法里，传入的当前的DefaultServiceRegistry对象，还有就是通过addProvider方法调用的。

globalServices.get(BuildExecuter.class)

public <T> T get(Class<T> serviceType) throws UnknownServiceException, ServiceLookupException {
    return serviceType.cast(this.get((Type)serviceType));
}

public Object get(Type serviceType) throws UnknownServiceException, ServiceLookupException {
    Object instance = this.find(serviceType);
    if (instance == null) {
        throw new UnknownServiceException(serviceType, String.format("No service of type %s available in %s.", format(serviceType), this.getDisplayName()));
    } else {
        return instance;
    }
}

public Object find(Type serviceType) throws ServiceLookupException {
    assertValidServiceType(unwrap(serviceType));
    Service provider = this.getService(serviceType);
    return provider == null ? null : provider.get();
}

private Service getService(Type serviceType) {
    this.serviceRequested();
    return find(serviceType, this.allServices);
}

private static Service find(Type serviceType, ServiceProvider serviceProvider) {
    if (serviceType instanceof ParameterizedType) {
        ParameterizedType parameterizedType = (ParameterizedType)serviceType;
        Type rawType = parameterizedType.getRawType();
        Type typeArg;
        if (rawType.equals(Factory.class)) {
            typeArg = parameterizedType.getActualTypeArguments()[0];
            return getFactoryService(typeArg, serviceProvider);
        }

        if (rawType instanceof Class) {
            if (((Class)rawType).isAssignableFrom(List.class)) {
                typeArg = parameterizedType.getActualTypeArguments()[0];
                return getCollectionService(typeArg, serviceProvider);
            }

            assertValidServiceType((Class)rawType);
            return serviceProvider.getService(serviceType);
        }
    }

    if (serviceType instanceof Class) {
        assertValidServiceType((Class)serviceType);
        return serviceProvider.getService(serviceType);
    } else {
        throw new ServiceValidationException(String.format("Locating services with type %s is not supported.", format(serviceType)));
    }
}

可以看到，这里的get方法最终就是调用了DefaultServiceRegistry的allServices的getService方法。

通过前面的构造方法可以知道，parents不为空的情况下，allServices就是CompositeServiceProvider，而他的getService就是遍历它的ServiceProvider[]（也就是ownServices和parentServices），调用它们的getService方法找到第一个不为空的Service返回。

findProviderMethods

private void findProviderMethods(Object target) {
    Class<?> type = target.getClass();
    RelevantMethods methods = RelevantMethods.getMethods(type);
    Iterator var4 = methods.decorators.iterator();

    ServiceMethod method;
    while(var4.hasNext()) {
        method = (ServiceMethod)var4.next();
        if (this.parentServices == null) {
            throw new ServiceLookupException(String.format("Cannot use decorator method %s.%s() when no parent registry is provided.", type.getSimpleName(), method.getName()));
        }

        this.ownServices.add(new FactoryMethodService(this, target, method));
    }

    var4 = methods.factories.iterator();

    while(var4.hasNext()) {
        method = (ServiceMethod)var4.next();
        this.ownServices.add(new FactoryMethodService(this, target, method));
    }

    var4 = methods.configurers.iterator();

    while(var4.hasNext()) {
        method = (ServiceMethod)var4.next();
        this.applyConfigureMethod(method, target);
    }

}

这个方法一开始就会根据target的类型检索出所有的方法信息并封装成方法信息对象，放在不同的数组里，总共有三种。

RelevantMethods.getMethods(type)

public static RelevantMethods getMethods(Class<?> type) {
    RelevantMethods relevantMethods = (RelevantMethods)METHODS_CACHE.get(type);
    if (relevantMethods == null) {
        relevantMethods = buildRelevantMethods(type);
        METHODS_CACHE.putIfAbsent(type, relevantMethods);
    }

    return relevantMethods;
}

实际上通过buildRelevantMethods方法生成RelevantMethods：

private static RelevantMethods buildRelevantMethods(Class<?> type) {
    RelevantMethodsBuilder builder = new RelevantMethodsBuilder(type);
    addDecoratorMethods(builder);
    addFactoryMethods(builder);
    addConfigureMethods(builder);
    RelevantMethods relevantMethods = builder.build();
    return relevantMethods;
}

这里的三个方法分别会生成RelevantMethods的decorators,、factories、configurers。

• addDecoratorMethods

  private static void addDecoratorMethods(RelevantMethodsBuilder builder) {
      Class<?> type = builder.type;
      Iterator<Method> iterator = builder.remainingMethods.iterator();
  
      while(true) {
          Method method;
          do {
              if (!iterator.hasNext()) {
                  return;
              }
  
              method = (Method)iterator.next();
          } while(!method.getName().startsWith("create") && !method.getName().startsWith("decorate"));
  
          if (method.getReturnType().equals(Void.TYPE)) {
              throw new ServiceLookupException(String.format("Method %s.%s() must not return void.", type.getSimpleName(), method.getName()));
          }
                  //这个方法会判断方法的参数类型中是否有和其返回类型一样的
          if (takesReturnTypeAsParameter(method)) {
              builder.add(iterator, builder.decorators, method);
          }
      }
  }
  

  可以看到这里会把所有以create或decorate开头的、且参数类型中有和其返回类型一样的方法都添加到decorators中。

• addFactoryMethods

  private static void addFactoryMethods(RelevantMethodsBuilder builder) {
      Class<?> type = builder.type;
      Iterator<Method> iterator = builder.remainingMethods.iterator();
  
      while(iterator.hasNext()) {
          Method method = (Method)iterator.next();
          if (method.getName().startsWith("create") && !Modifier.isStatic(method.getModifiers())) {
              if (method.getReturnType().equals(Void.TYPE)) {
                  throw new ServiceLookupException(String.format("Method %s.%s() must not return void.", type.getSimpleName(), method.getName()));
              }
  
              builder.add(iterator, builder.factories, method);
          }
      }
  
  }
  

  这里会把create开头的、非静态的方法都添加到factories中。

• addConfigureMethods

  private static void addConfigureMethods(RelevantMethodsBuilder builder) {
      Class<?> type = builder.type;
      Iterator<Method> iterator = builder.remainingMethods.iterator();
  
      while(iterator.hasNext()) {
          Method method = (Method)iterator.next();
          if (method.getName().equals("configure")) {
              if (!method.getReturnType().equals(Void.TYPE)) {
                  throw new ServiceLookupException(String.format("Method %s.%s() must return void.", type.getSimpleName(), method.getName()));
              }
  
              builder.add(iterator, builder.configurers, method);
          }
      }
  
  }
  

  这里会把名叫configure的方法都添加到configurers中。

这三种方法的返回类型都不能是void，因为我们工厂方法是用来生产特定类型实例的，所以也很好理解。

上面的remainingMethods来自于RelevantMethodsBuilder的构造方法：

RelevantMethodsBuilder(Class<?> type) {
    this.type = type;
    this.remainingMethods = new LinkedList();

    for(Class<?> clazz = type; clazz != Object.class && clazz != DefaultServiceRegistry.class; clazz = clazz.getSuperclass()) {
        this.remainingMethods.addAll(Arrays.asList(clazz.getDeclaredMethods()));
    }

}

可以看到，remainingMethods包含了目标类和其所有父类（不包含Object和DefaultServiceRegistry）的所有方法。

接下来，我们来看findProviderMethods下面的操作。

findProviderMethods接下来的操作

反射得到方法信息数组之后呢，接下来会遍历decorators和factories数组的元素，对其每一个都封装进一个FactoryMethodService实例，并添加到ownServices中，OwnServices的add方法如下：

public void add(ServiceProvider serviceProvider) {
    DefaultServiceRegistry.this.assertMutable();
    if (!(serviceProvider instanceof SingletonService)) {
        throw new UnsupportedOperationException("Unsupported service provider type: " + serviceProvider);
    } else {
        this.stoppable.add(serviceProvider);
          //这里的两个参数其实就是key和value值
        this.analyser.addProviderForClassHierarchy(((SingletonService)serviceProvider).serviceClass, serviceProvider);
    }
}

analyser是ProviderAnalyser类型，OwnServices的一个内部类，addProviderForClassHierarchy方法最终会以方法的返回类型（包括这个类的所有父类，因为子类一定可以类型转换成其父类的）为key，FactoryMethodService为value添加到OwnServices的providersByType这个Map中，后面我们会看到哪里会用到它。

最后一种configurers数组元素会通过applyConfigureMethod方法遍历执行每一个的configure方法：

private void applyConfigureMethod(ServiceMethod method, Object target) {
    Object[] params = new Object[method.getParameterTypes().length];

    for(int i = 0; i < method.getParameterTypes().length; ++i) {
        Type paramType = method.getParameterTypes()[i];
        if (paramType.equals(ServiceRegistration.class)) {
            params[i] = this.newRegistration();
        } else {
            Service paramProvider = find(paramType, this.allServices);
            if (paramProvider == null) {
                throw new ServiceLookupException(String.format("Cannot configure services using %s.%s() as required service of type %s is not available.", method.getOwner().getSimpleName(), method.getName(), format(paramType)));
            }

            params[i] = paramProvider.get();
        }
    }

    try {
        method.invoke(target, params);
    } catch (Exception var7) {
        throw new ServiceLookupException(String.format("Could not configure services using %s.%s().", method.getOwner().getSimpleName(), method.getName()), var7);
    }
}

注意，这里的方法参数构造除了ServiceRegistration类型之外，其他的类型都是通过find方法去创建，这和一开始的get(BuildExecuter.class)最终调用的find方法一样。 这就是巧妙的地方，我们通过同一套逻辑不仅可以构造目标Service，而且在过程中需要的中间Service实例也可以构造，我们要做的就是在DefaultServiceRegistry的实现类中定义好可以产生对应类型的方法及其构造逻辑即可。

但是经过查找，this.loggingServices（也就是CommandLineLogging）和NativeServices中都没有定义返回类型是BuildExecuter的方法，它们也没有配置parentServices、没有给ownServices添加额外的ServiceProvider，好像查找过程被打断了...不要慌，我们还有一个configure方法没有看，或许有其他的Service在那里被注册了，这个方法在findProviderMethods流程中被调用过。

我们在GlobalScopeServices中找到了这个方法（还记得吗，这个类在开头通过provider方法传入到findProviderMethods流程）：

void configure(ServiceRegistration registration, ClassLoaderRegistry classLoaderRegistry) {
    registration.add(ClassLoaderScopeListeners.class);
    List<PluginServiceRegistry> pluginServiceFactories = (new DefaultServiceLocator(new ClassLoader[]{classLoaderRegistry.getRuntimeClassLoader(), classLoaderRegistry.getPluginsClassLoader()})).getAll(PluginServiceRegistry.class);
    Iterator var4 = pluginServiceFactories.iterator();

    while(var4.hasNext()) {
        PluginServiceRegistry pluginServiceRegistry = (PluginServiceRegistry)var4.next();
          //添加到DefaultServiceRegistry的ownServices中
        registration.add(PluginServiceRegistry.class, pluginServiceRegistry);
          //双向绑定
        pluginServiceRegistry.registerGlobalServices(registration);
    }
}

那么通过上面的applyConfigureMethod方法得知，configure方法的第一个参数通过newRegistration方法构造：

private ServiceRegistration newRegistration() {
    return new ServiceRegistration() {
        public <T> void add(Class<T> serviceType, T serviceInstance) {
            DefaultServiceRegistry.this.add(serviceType, serviceInstance);
        }

        public void add(Class<?> serviceType) {
            DefaultServiceRegistry.this.ownServices.add(new ConstructorService(DefaultServiceRegistry.this, serviceType));
        }

        public void addProvider(Object provider) {
            DefaultServiceRegistry.this.addProvider(provider);
        }
    };
}

public <T> DefaultServiceRegistry add(Class<T> serviceType, T serviceInstance) {
    this.assertMutable();
    this.ownServices.add(new FixedInstanceService(this, serviceType, serviceInstance));
    return this;
}

第二个参数则又是通过这种工厂方法去调用find查找，我们在GlobalScopeServices中找到了这个注册方法：

ClassLoaderRegistry createClassLoaderRegistry(ClassPathRegistry classPathRegistry, LegacyTypesSupport legacyTypesSupport) {
    return (ClassLoaderRegistry)(GradleRuntimeShadedJarDetector.isLoadedFrom(this.getClass()) ? new FlatClassLoaderRegistry(this.getClass().getClassLoader()) : new DefaultClassLoaderRegistry(classPathRegistry, legacyTypesSupport, DirectInstantiator.INSTANCE));
}

这里只是知道configure的参数是怎么通过工厂模式方法构造的即可，具体用的哪个ClassLoaderRegistry不影响流程。

我们看一下DefaultServiceLocator的getAll方法：

public <T> List<T> getAll(Class<T> serviceType) throws UnknownServiceException {
    List<ServiceFactory<T>> factories = this.findFactoriesForServiceType(serviceType);
    ArrayList<T> services = new ArrayList();
    Iterator var4 = factories.iterator();

    while(var4.hasNext()) {
        ServiceFactory<T> factory = (ServiceFactory)var4.next();
        services.add(factory.create());
    }

    return services;
}

private <T> List<ServiceFactory<T>> findFactoriesForServiceType(Class<T> serviceType) {
    return this.factoriesFor(serviceType, this.implementationsOf(serviceType));
}

private <T> List<ServiceFactory<T>> factoriesFor(Class<T> serviceType, List<Class<? extends T>> implementationClasses) {
    List<ServiceFactory<T>> factories = new ArrayList();
    Iterator var4 = implementationClasses.iterator();

    while(var4.hasNext()) {
        Class<? extends T> implementationClass = (Class)var4.next();
        factories.add(new ServiceFactory(serviceType, implementationClass));
    }

    return factories;
}

上面代码的流程是，返回一个ArrayList<PluginServiceRegistry> ，每一个PluginServiceRegistry都来自于ServiceFactory的create方法：

public T create() {
    return this.newInstance();
}

public T newInstance(Object... params) {
    try {
        return DirectInstantiator.instantiate(this.implementationClass, params);
    } catch (ObjectInstantiationException var3) {
        ObjectInstantiationException t = var3;
        throw new RuntimeException(String.format("Could not create an implementation of service '%s'.", this.serviceType.getName()), t);
    }
}

其实就是通过反射来构造一个无参构造方法生成实例。那Class来自哪里呢，继续看implementationsOf方法，这个方法实际上调用了findServiceImplementations方法：

private <T> List<Class<? extends T>> findServiceImplementations(Class<T> serviceType) throws IOException {
    String resourceName = "META-INF/services/" + serviceType.getName();
    Set<String> implementationClassNames = new HashSet();
    List<Class<? extends T>> implementations = new ArrayList();
    Iterator var5 = this.classLoaders.iterator();

    while(var5.hasNext()) {
        ClassLoader classLoader = (ClassLoader)var5.next();
        Enumeration<URL> resources = classLoader.getResources(resourceName);

        while(resources.hasMoreElements()) {
            URL resource = (URL)resources.nextElement();

            List implementationClassNamesFromResource;
            try {
                implementationClassNamesFromResource = this.extractImplementationClassNames(resource);
                  ...
            }...

            Iterator var15 = implementationClassNamesFromResource.iterator();

            while(var15.hasNext()) {
                String implementationClassName = (String)var15.next();
                if (implementationClassNames.add(implementationClassName)) {
                    try {
                        Class<?> implClass = classLoader.loadClass(implementationClassName);
                          ...
                        implementations.add(implClass.asSubclass(serviceType));
                    } ...
                }
            }
        }
    }

    return implementations;
}

在源码的META-INF/services/路径下找到org.gradle.internal.service.scopes.PluginServiceRegistry文件：

org.gradle.tooling.internal.provider.LauncherServices
org.gradle.caching.internal.BuildCacheServices
org.gradle.internal.service.scopes.ExecutionServices
org.gradle.internal.service.scopes.VirtualFileSystemServices
org.gradle.internal.build.event.BuildEventServices
org.gradle.workers.internal.WorkersServices
org.gradle.api.internal.artifacts.DependencyServices
org.gradle.composite.internal.CompositeBuildServices
org.gradle.plugin.internal.PluginUsePluginServiceRegistry
org.gradle.internal.resource.transport.http.HttpResourcesPluginServiceRegistry
org.gradle.vcs.internal.services.VersionControlServices
org.gradle.caching.http.internal.HttpBuildCacheServiceServices
org.gradle.buildinit.plugins.internal.services.BuildInitServices
org.gradle.api.reporting.components.internal.DiagnosticsServices
org.gradle.plugins.ide.internal.tooling.ToolingModelServices
org.gradle.plugins.ide.internal.IdeServices
org.gradle.ide.xcode.internal.services.XcodeServices
org.gradle.api.publish.ivy.internal.IvyServices
org.gradle.api.internal.tasks.compile.GroovyServices
org.gradle.language.java.internal.JavaToolChainServiceRegistry
org.gradle.language.java.internal.JavaLanguagePluginServiceRegistry
org.gradle.language.jvm.internal.JvmPluginServiceRegistry
org.gradle.language.nativeplatform.internal.registry.NativeLanguageServices
org.gradle.language.scala.internal.toolchain.ScalaToolChainServiceRegistry
org.gradle.api.publish.maven.internal.MavenPublishServices
org.gradle.platform.base.internal.registry.ComponentModelBaseServiceRegistry
org.gradle.jvm.internal.services.PlatformJvmServices
org.gradle.nativeplatform.internal.services.NativeBinaryServices
org.gradle.play.internal.toolchain.PlayToolChainServiceRegistry
org.gradle.api.internal.tasks.CompileServices
org.gradle.api.plugins.internal.PluginAuthorServices
org.gradle.api.publish.internal.service.PublishServices
org.gradle.internal.resource.transport.gcp.gcs.GcsResourcesPluginServiceRegistry
org.gradle.internal.resource.transport.aws.s3.S3ResourcesPluginServiceRegistry
org.gradle.internal.resource.transport.sftp.SftpResourcesPluginServiceRegistry
org.gradle.api.internal.tasks.testing.TestingBasePluginServiceRegistry
org.gradle.jvm.test.internal.services.JvmTestingServices
org.gradle.nativeplatform.test.internal.services.NativeTestingServices
org.gradle.language.cpp.internal.tooling.ToolingNativeServices

所有注册的PluginServiceRegistry都在这了。

逐一查找他们的registerGlobalServices方法，最终在第一个类——LauncherServices中找到：

public void registerGlobalServices(ServiceRegistration registration) {
    registration.addProvider(new ToolingGlobalScopeServices());
}

ToolingGlobalScopeServices中找到了返回BuildExecuter类型的注册方法：

BuildExecuter createBuildExecuter(List<BuildActionRunner> buildActionRunners, List<BuildEventListenerFactory> registrations, ListenerManager listenerManager, BuildOperationListenerManager buildOperationListenerManager, TaskInputsListeners inputsListeners, StyledTextOutputFactory styledTextOutputFactory, ExecutorFactory executorFactory, LoggingManagerInternal loggingManager, GradleUserHomeScopeServiceRegistry userHomeServiceRegistry, FileSystemChangeWaiterFactory fileSystemChangeWaiterFactory) {
    return new SetupLoggingActionExecuter(new SessionFailureReportingActionExecuter(new StartParamsValidatingActionExecuter(new GradleThreadBuildActionExecuter(new SessionScopeBuildActionExecuter(new SubscribableBuildActionExecuter(new ContinuousBuildActionExecuter(new BuildTreeScopeBuildActionExecuter(new InProcessBuildActionExecuter(new RunAsBuildOperationBuildActionRunner(new BuildCompletionNotifyingBuildActionRunner(new ValidatingBuildActionRunner(new BuildOutcomeReportingBuildActionRunner(new ChainingBuildActionRunner(buildActionRunners), styledTextOutputFactory)))))), fileSystemChangeWaiterFactory, inputsListeners, styledTextOutputFactory, executorFactory), listenerManager, buildOperationListenerManager, registrations), userHomeServiceRegistry))), styledTextOutputFactory, Time.clock()), loggingManager);
}

很明显，这又是一个代理模式，一级一级地往下传递执行execute方法，就不一一贴源码了，这里只大概描述每个Executer的作用：

• SetupLoggingActionExecuter

  启动日志输出程序，监听执行过程并输出build过程日志，在代理链执行完成后stop。

• SessionFailureReportingActionExecuter

  给build过程包裹try块，在发生异常时解析异常信息并输出日志。

• StartParamsValidatingActionExecuter

  获取StartParameter，如果配置了的话则检查它的buildFile、settings.gradle、initScripts文件是否存在。

• GradleThreadBuildActionExecuter

  这里会配一个静态的ThreadLocal对象来标志当前是否正在build，设置为true，在build结束后置为false，避免重复构建冲突。

• SessionScopeBuildActionExecuter

  build session生命周期的监听。

• SubscribableBuildActionExecuter

  一些外部添加的监听。

• ContinuousBuildActionExecuter

  这里会根据是否开启了持续性构建配置而分成两个分支，持续性构建逻辑和非持续性构建。

• BuildTreeScopeBuildActionExecuter

  构建一个BuildTreeScopeServices对象传递到execute中。

• InProcessBuildActionExecuter

  public BuildActionResult execute(final BuildAction action, final BuildRequestContext buildRequestContext, BuildActionParameters actionParameters, ServiceRegistry contextServices) {
      //得到的是DefaultIncludedBuildRegistry
      BuildStateRegistry buildRegistry = (BuildStateRegistry)contextServices.get(BuildStateRegistry.class);
      final PayloadSerializer payloadSerializer = (PayloadSerializer)contextServices.get(PayloadSerializer.class);
      BuildOperationNotificationValve buildOperationNotificationValve = (BuildOperationNotificationValve)contextServices.get(BuildOperationNotificationValve.class);
      buildOperationNotificationValve.start();
  
      BuildActionResult var9;
      try {
          //得到DefaultRootBuildState
          RootBuildState rootBuild = buildRegistry.createRootBuild(BuildDefinition.fromStartParameter(action.getStartParameter(), (PublicBuildPath)null));
          var9 = (BuildActionResult)rootBuild.run(new Transformer<BuildActionResult, BuildController>() {
              public BuildActionResult transform(BuildController buildController) {
                  //buildController是GradleBuildController
                  BuildActionRunner.Result result = InProcessBuildActionExecuter.this.buildActionRunner.run(action, buildController);
                  if (result.getBuildFailure() == null) {
                      return BuildActionResult.of(payloadSerializer.serialize(result.getClientResult()));
                  } else {
                      return buildRequestContext.getCancellationToken().isCancellationRequested() ? BuildActionResult.cancelled(payloadSerializer.serialize(result.getBuildFailure())) : BuildActionResult.failed(payloadSerializer.serialize(result.getClientFailure()));
                  }
              }
          });
      } finally {
          buildOperationNotificationValve.stop();
      }
  
      return var9;
  }
  

  这里通过DefaultRootBuildState的run方法得到一个GradleBuildController对象：

  public <T> T run(Transformer<T, ? super BuildController> buildAction) {
      //this.gradleLauncher是DefaultGradleLauncher
      GradleBuildController buildController = new GradleBuildController(this.gradleLauncher);
      RootBuildLifecycleListener buildLifecycleListener = (RootBuildLifecycleListener)this.listenerManager.getBroadcaster(RootBuildLifecycleListener.class);
      GradleInternal gradle = buildController.getGradle();
      buildLifecycleListener.afterStart(gradle);
  
      Object var5;
      try {
          var5 = buildAction.transform(buildController);
      } finally {
          buildLifecycleListener.beforeComplete(gradle);
      }
  
      return var5;
  }
  

  继续往下走，InProcessBuildActionExecuter.this.buildActionRunner就是下一级的RunAsBuildOperationBuildActionRunner。

• RunAsBuildOperationBuildActionRunner

  一些监听、日志。接着继续往下执行BuildCompletionNotifyingBuildActionRunner的run方法。

• BuildCompletionNotifyingBuildActionRunner

  通知监听器build的结果成功或失败。

• ValidatingBuildActionRunner

  public BuildActionRunner.Result run(BuildAction action, BuildController buildController) {
      BuildActionRunner.Result result = this.delegate.run(action, buildController);
      if (!result.hasResult()) {
          throw new UnsupportedOperationException(String.format("Don't know how to run a build action of type %s.", action.getClass().getSimpleName()));
      } else {
          return result;
      }
  }
  

  这里只是简单的判断结果是否为空并作出提示。

• BuildOutcomeReportingBuildActionRunner

  输出结果信息，比如构建时间等。

• ChainingBuildActionRunner

  前面所有的都是对整个流程的监听、添加相应日志等操作，最后这一步才会触发最终的执行。这里会遍历ToolingGlobalScopeServices的createBuildExecuter方法的传参buildActionRunners中的所有的BuildActionRunner，也是通过相同的工厂模式获取的，经过查找，找到了这里的BuildActionRunner实现类是ExecuteBuildActionRunner，它的run方法如下：

  public BuildActionRunner.Result run(BuildAction action, BuildController buildController) {
      if (!(action instanceof ExecuteBuildAction)) {
          return Result.nothing();
      } else {
          try {
              buildController.run();
              return Result.of((Object)null);
          } catch (RuntimeException var4) {
              RuntimeException e = var4;
              return Result.failed(e);
          }
      }
  }
  

  可见这里是调用了前面GradleBuildController的run方法：

  public GradleInternal run() {
      //注意这里使用了java8的新特性 ‘::’
      return this.doBuild(BuildType.TASKS, GradleLauncher::executeTasks);
  }
  

  private GradleInternal doBuild(final GradleInternal.BuildType buildType, final Action<? super GradleLauncher> build) {
      GradleInternal var3;
      try {
          var3 = (GradleInternal)this.workerLeaseService.withLocks(Collections.singleton(this.workerLeaseService.getWorkerLease()), new Factory<GradleInternal>() {
              public GradleInternal create() {
                  GradleInternal gradle = GradleBuildController.this.getGradle();
  
                  try {
                      gradle.setBuildType(buildType);
                      GradleLauncher launcher = GradleBuildController.this.getLauncher();
                      //实际上是执行launcher的executeTasks方法
                      build.execute(launcher);
                      launcher.finishBuild();
                  } finally {
                      gradle.setBuildType(BuildType.NONE);
                  }
  
                  return gradle;
              }
          });
      } finally {
          this.state = GradleBuildController.State.Completed;
      }
  
      return var3;
  }
  
  //Action.java
  public interface Action<T> {
      void execute(T var1);
  }
  

  launcher是DefaultGradleLauncher，它的executeTasks方法如下：

  public GradleInternal executeTasks() {
      this.doBuildStages(DefaultGradleLauncher.Stage.RunTasks);
      return this.gradle;
  }
  

  private void doBuildStages(Stage upTo) {
      Preconditions.checkArgument(upTo != DefaultGradleLauncher.Stage.Finished, "Stage.Finished is not supported by doBuildStages.");
  
      try {
          //这里还会判断是否可以立即执行
          if (upTo == DefaultGradleLauncher.Stage.RunTasks && this.instantExecution.canExecuteInstantaneously()) {
              this.doInstantExecution();
          } else {
              this.doClassicBuildStages(upTo);
          }
      } catch (Throwable var3) {
          Throwable t = var3;
          this.finishBuild(upTo.getDisplayName(), t);
      }
  }
  
  private void doInstantExecution() {
      this.buildListener.buildStarted(this.gradle);
      this.instantExecution.loadScheduledWork();
      this.stage = DefaultGradleLauncher.Stage.TaskGraph;
      this.runWork();
  }
  

  如果不符合立即执行条件则调用doClassicBuildStages方法：

  private void doClassicBuildStages(Stage upTo) {
      if (this.stage == null) {
          this.instantExecution.prepareForBuildLogicExecution();
      }
  
      this.prepareSettings();
      if (upTo != DefaultGradleLauncher.Stage.LoadSettings) {
          this.prepareProjects();
          if (upTo != DefaultGradleLauncher.Stage.Configure) {
              this.prepareTaskExecution();
              if (upTo != DefaultGradleLauncher.Stage.TaskGraph) {
                  this.instantExecution.saveScheduledWork();
                  this.runWork();
              }
          }
      }
  }
  

  可见，两个分支最终都会执行runWork方法，根据名字猜测前面的prepareSettings、prepareProjects和prepareTaskExecution似乎和根据gradle配置文件转化成对应的代码有关，这些方法内部都使用了DefaultGradleLauncher的内部字段，他们通过其构造方法传入，看来我们得去找找这个构造入口。

  见下一篇。