-
概述
之前分析了从执行 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的内部字段，他们通过其构造方法传入，看来我们得去找找这个构造入口。
见下一篇。
-
网友评论