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

    private ServiceLoader(Class<S> 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<String> 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<? extends TypeElement> 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<? extends TypeElement> annotations, RoundEnvironment roundEnv) {
    if (roundEnv.processingOver()) {
      generateConfigFiles();
    } else {
      processAnnotations(annotations, roundEnv);
    }
    return true;
  }

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

如果还没有完成则processAnnotations

private void processAnnotations(Set<? extends TypeElement> annotations,
      RoundEnvironment roundEnv) {

    Set<? extends Element> elements = roundEnv.getElementsAnnotatedWith(AutoService.class);

    for (Element e : elements) {
      TypeElement providerImplementer = (TypeElement) e;
      AnnotationMirror annotationMirror = getAnnotationMirror(e, AutoService.class).get();
      Set<DeclaredType> 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<String> allServices = Sets.newTreeSet();
        try {
          FileObject existingFile = filer.getResource(StandardLocation.CLASS_OUTPUT, "",
              resourceFile);
          Set<String> oldServices = ServicesFiles.readServiceFile(existingFile.openInputStream());
          allServices.addAll(oldServices);
        } catch (IOException e) {
          log("Resource file did not already exist.");
        }

        Set<String> newServices = new HashSet<String>(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，也有其他的用途。

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 203,230评论 5赞 476
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 85,261评论 2赞 380
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 150,089评论 0赞 336
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,542评论 1赞 273
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,542评论 5赞 365
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,544评论 1赞 281
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 37,922评论 3赞 395
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,578评论 0赞 257
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,816评论 1赞 296
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,576评论 2赞 320
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,658评论 1赞 329
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,359评论 4赞 318
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,937评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,920评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,156评论 1赞 259
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 42,859评论 2赞 349
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,381评论 2赞 342