组件化之AutoService

最新推荐文章于 2024-05-15 06:11:42 发布

時咣℡¹⁴³³²²³

最新推荐文章于 2024-05-15 06:11:42 发布

阅读量5.2k

点赞数 26

分类专栏：学习 android 安卓文章标签： java android

本文链接：https://blog.csdn.net/weixin_43976155/article/details/123113848

版权

android 同时被 3 个专栏收录

12 篇文章 0 订阅

订阅专栏

安卓

12 篇文章 0 订阅

订阅专栏

学习

11 篇文章 0 订阅

订阅专栏

学习AutoService之前，首先我们需要了解一下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接口的两个实现类。这样子我们就可以使用到这两个实现类了。

原理

那么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;
      }
    }
  }