SPI & AutoService

上一篇文章中APT技术的基本使用中用到了AutoService（https://github.com/google/auto） 这个框架，那么为什么我们写了一个AnnotationProcessor之后，再加一个@AutoService(Processor.class)注解，在javac的过程中就会执行我们的AnnotationProcessor呢？
首先需要了解一下SPI的开发模式。

SPI

简介

SPI（Service Provider Interface），SPI技术就是可以根据某个接口找到其实现类，然后根据不同的业务场景使用不同的实现类。比如我们现在有一个的Login登录功能，然后针对不同的渠道包需要用不同的实现。 一般情况我们会创建一个Login对外的接口，比如LoginService，内容大概如下：

public class LoginService {
    public static void login(String userName，String password) {
        if (渠道 == A) {
            useLoginAImpl(userName，password)
        } else if (渠道 == B) {
            useLoginBImpl(userName，password)
        }
    }
}

这样子，假如我们的渠道包的映射关系发生了变化的话我们就需要来修改这部分代码，并且两份实现都会被打入apk中。所以这个时候就可以使用到SPI设计了，下面通过一个demo来了解一下SPI的基本使用。

demo

demo主要分为api模块，里面主要是接口；然后还有连个实现模块functionA，functionB分别实现了api接口。最后app模块使用这个接口。

api module

这是一个java library工程，我们在里面定义一个接口IFunction

public interface IFunction {
    String getName();
    void doFunction();
}

functinA module

这也是一个java library工程，这里我们实现api module中定义的接口。

@AutoService(IFunction.class)
public class FunctionA implements IFunction {
    @Override
    public String getName() {
        return "FunctionA";
    }

    @Override
    public void doFunction() {
        
    }
}

可以看到我们在这个类上面添加了@AutoService（IFunction.class）的注解修饰。build.gradle文件需要添加以下依赖关系：

    api 'com.google.auto.service:auto-service:1.0-rc6'
    annotationProcessor 'com.google.auto.service:auto-service:1.0-rc6'
    implementation project(":api")

functionB module

functionB module和functionA module是一样的，这里就不展开了。

app module

build.gradle 中需要添加以下依赖：

    implementation project(":api")
    annotationProcessor 'com.google.auto.service:auto-service:1.0-rc6'
    implementation project(":functionA")
    implementation project(":functionB")

然后我们就可以在代码中通过ServiceLoader找到我们的具体实现类了。

private fun loadServices() {
        ServiceLoader.load(IFunction::class.java).forEach {
            Log.i("MainActivity", "function class = " + it::class.java + " function name = " + it.name)
        }
    }

这段代码跑起来会打印出我们的IFunction接口的两个实现类。这样子我们就可以使用到这两个实现类了。

假如说我们现在只需要使用到A实现，那么我们的app module就依赖Amodule，如果要使用到B实现，那么就依赖Bmodule，就避免了编码的修改与多余代码的打包。并且模块的耦合度进一步降低。更多代码详情请见demo （https://github.com/huanghuanhuanghuan/SPIDemo.git）

原理

那么demo的实现原理是什么呢？我们都知道我们使用@AutoService(IFunction.class)修饰后，在编译打成jar包的时候就会生成META-INF.services文件夹。然后其中会有以我们的注解中的class全路径命名的文件，文件内部有其实现类。就上面demo的例子来说就会有一个com.example.api.IFunction的文件，functionA module中的这个文件内容就是com.example.functiona.FunctionA，而functionB module中的内容则是：com.example.functiona.FunctionB。
而对于app module来说的话则会把这两个都合并到一起。我们可以拆开apk看一下，就会发现com.example.api.IFunction文件的内容为：

com.example.functionb.FunctionB
com.example.functiona.FunctionA

所以说AutoService的工作就是在META-INF.services文件夹中创建一个以接口类名为文件名，所有的接口实现类全名保存在其中的一个key - list 的映射。

而ServiceLoader则是java提供的一个api。主要是用来读取解析而这个key - list 的映射关系的。

    public static  ServiceLoader load(Class service) {
        ClassLoader cl = Thread.currentThread().getContextClassLoader();
        return ServiceLoader.load(service, cl);
    }
    
    public static  ServiceLoader load(Class service,
                                            ClassLoader loader)
    {
        return new ServiceLoader<>(service, loader);
    }
    
    public void reload() {
        providers.clear();
        lookupIterator = new LazyIterator(service, loader);
    }

    private ServiceLoader(Class svc, ClassLoader cl) {
        service = Objects.requireNonNull(svc, "Service interface cannot be null");
        loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
        AccessController.getContext() : null;
        reload();
    }

可以看到最终会创建一个LazyIterator迭代器，这里使用了Lazy load，我们用到的时候才会去load这个Class。

对于迭代器我们需要关心两个方法，hasNext和next方法，而这两个方法则直接调用了hasNextService和nextService方法。

    private static final String PREFIX = "META-INF/services/";
Iterator pending = null;
private boolean hasNextService() {
    if (nextName != null) {
        return true;
    }
    if (configs == null) {
        try {
            String fullName = PREFIX + service.getName();
            if (loader == null)
                configs = ClassLoader.getSystemResources(fullName);
            else
                configs = loader.getResources(fullName);
        } catch (IOException x) {
            fail(service, "Error locating configuration files", x);
        }
    }
    while ((pending == null) || !pending.hasNext()) {
        if (!configs.hasMoreElements()) {
            return false;
        }
        pending = parse(service, configs.nextElement());
    }
    nextName = pending.next();
    return true;
}

可以看到，这里的逻辑就是读取指定接口(key 文件) 的 实现列表（value 文件内容）。

 private S nextService() {
    if (!hasNextService())
        throw new NoSuchElementException();
    String cn = nextName;
    nextName = null;
    Class c = null;
    try {
        c = Class.forName(cn, false, loader);
    } catch (ClassNotFoundException x) {
        fail(service,
             // Android-changed: Let the ServiceConfigurationError have a cause.
             "Provider " + cn + " not found", x);
             // "Provider " + cn + " not found");
    }
    if (!service.isAssignableFrom(c)) {
        // Android-changed: Let the ServiceConfigurationError have a cause.
        ClassCastException cce = new ClassCastException(
                service.getCanonicalName() + " is not assignable from " + c.getCanonicalName());
        fail(service,
             "Provider " + cn  + " not a subtype", cce);
        // fail(service,
        //        "Provider " + cn  + " not a subtype");
    }
    try {
        S p = service.cast(c.newInstance());
        providers.put(cn, p);
        return p;
    } catch (Throwable x) {
        fail(service,
             "Provider " + cn + " could not be instantiated",
             x);
    }
    throw new Error();          // This cannot happen
}

这里则是load 具体的实现类，然后保存到providers中。

所以本质上就是通过注解生成接口与实现的信息(也可以手动写，只是AutoService帮我们做了而已)，然后运行时通过这部分信息来获取具体的实现类。

@AutoService

上面的demo简单实现了一下SPI的开发模式。而其中使用了@AutoService进行了接口与实现的声明，接下来我们来看看AutoService如何生成这部分映射关系的。

@Documented
@Retention(SOURCE)
@Target(TYPE)
public @interface AutoService {
  /** Returns the interfaces implemented by this service provider. */
  Class[] value();
}

可以看到AutoService也是一个注解。其主要的实现逻辑在AutoServiceProcessor中，他也是一个注解处理器。

我们看一下process方法：

public boolean process(Set annotations, RoundEnvironment roundEnv) {
    try {
      return processImpl(annotations, roundEnv);
    } catch (Exception e) {
      // We don't allow exceptions of any kind to propagate to the compiler
      StringWriter writer = new StringWriter();
      e.printStackTrace(new PrintWriter(writer));
      fatalError(writer.toString());
      return true;
    }
  }

主要是调用了processImpl方法

private boolean processImpl(Set annotations, RoundEnvironment roundEnv) {
    if (roundEnv.processingOver()) {
      generateConfigFiles();
    } else {
      processAnnotations(annotations, roundEnv);
    }
    return true;
  }

这里则是判断这个环是否已经完成了，而这个是否完成了的指标会根据多个AnnotationProcessor的process结果来衡量，如果APT过程中生成的类也需要进行注解处理的话则需要返回false，方便再一次执行。如果生成的类不需要进行注解处理的话，那么则可以返回true。这里因为生成的都是文件内容，不包含需要再次处理的类文件，所以一趟就可以搞定。

如果还没有完成则processAnnotations

private void processAnnotations(Set annotations,
      RoundEnvironment roundEnv) {

    Set elements = roundEnv.getElementsAnnotatedWith(AutoService.class);

    for (Element e : elements) {
      TypeElement providerImplementer = (TypeElement) e;
      AnnotationMirror annotationMirror = getAnnotationMirror(e, AutoService.class).get();
      Set providerInterfaces = getValueFieldOfClasses(annotationMirror);
      if (providerInterfaces.isEmpty()) {
        error(MISSING_SERVICES_ERROR, e, annotationMirror);
        continue;
      }
      for (DeclaredType providerInterface : providerInterfaces) {
        TypeElement providerType = MoreTypes.asTypeElement(providerInterface);

        if (checkImplementer(providerImplementer, providerType)) {
          providers.put(getBinaryName(providerType), getBinaryName(providerImplementer));
        } else {
          String message = "ServiceProviders must implement their service provider interface. "
              + providerImplementer.getQualifiedName() + " does not implement "
              + providerType.getQualifiedName();
          error(message, e, annotationMirror);
        }
      }
    }
  }

可以看到这里把AutoService注解修饰的类作为key，把注解的value值作为value。这样子value就可以存在重复的情况了。如果是反过来的话则需要保存为key - list的形式。

private void generateConfigFiles() {
    Filer filer = processingEnv.getFiler();

    for (String providerInterface : providers.keySet()) {
      String resourceFile = "META-INF/services/" + providerInterface;
      try {
        SortedSet allServices = Sets.newTreeSet();
        try {
          FileObject existingFile = filer.getResource(StandardLocation.CLASS_OUTPUT, "",
              resourceFile);
          Set oldServices = ServicesFiles.readServiceFile(existingFile.openInputStream());
          allServices.addAll(oldServices);
        } catch (IOException e) {
          log("Resource file did not already exist.");
        }

        Set newServices = new HashSet(providers.get(providerInterface));
        if (allServices.containsAll(newServices)) {
          log("No new service entries being added.");
          return;
        }

        allServices.addAll(newServices);
        log("New service file contents: " + allServices);
        FileObject fileObject = filer.createResource(StandardLocation.CLASS_OUTPUT, "",
            resourceFile);
        OutputStream out = fileObject.openOutputStream();
        ServicesFiles.writeServiceFile(allServices, out);
        out.close();
        log("Wrote to: " + fileObject.toUri());
      } catch (IOException e) {
        fatalError("Unable to create " + resourceFile + ", " + e);
        return;
      }
    }
  }

全部处理ok了就调用generateConfigFiles方法，这里通过遍历之前存的provider map，value就是他们要写入的文件名，然后将这些配置写入到配置文件中区，当然还有考虑到了已有的数据情况，对旧数据进行了拷贝处理。

总结

主要学习了SPI设计模式，对于高内聚低耦合的可替代功能，可以考虑使用SPI模式，模块的插拔式设计。另外也了解到了AutoService注解处理的基本逻辑，它不仅仅可以用于APT，也有其他的用途。