亲宝软件园·资讯

展开

Android开发Spi机制

Pika 人气:3

Spi机制介绍

SPI 全称是 Service Provider Interface,是一种将服务接口与服务实现分离以达到解耦、可以提升程序可扩展性的机制。嘿嘿,看到这个概念很多人肯定是一头雾水了,没事,我们直接就可以简单理解为是一种反射机制,即我们不需要知道具体的实现方,只要定义好接口,我们就能够在运行时找到一个实现接口的类,我们具体看一下官方定义

举个例子

加入我是一个库设计者,我希望把一个接口暴露给使用者实现具体的逻辑,那么我肯定不能够写死实现类对吧,不然我们怎么扩展嘛!比如我们有以下接口

package com.example.newtestproject
interface TestSpi {
    fun getSpi();
}

如果我在使用的过程中,想不关心具体的实现类/又或者想兼容多个实现,那么怎么办呢?(比如日常开发的gradle,如果我想兼容多个agp版本在自己库的运行,一个个写死肯定是一个非常糟糕的实现,如果出了新版本,那么我们还要更改代码),我们能不能只定义一个规范,即上面的TestSpi就可以不关心以后的扩展呢?很简单,我们只需要在resource/META-INF/services目录下定义一个以该接口为名称的文件,文件内容是具体的接口实现类即可,如图

内容是实现类的全名称,假如我们有以下实现类

class TheTestSpi:TestSpi {
    override fun getSpi() {
        Log.i("hello","i am the interface implementation from TheTestSpi")
    }
}

那么文件只需要写入com.example.newtestproject.TheTestSpi即可。

在我们想要用到TestSpi的功能的时候,就可以通过以下方式进行使用,从而不用关心具体的实现,达到了解耦合的目的

// spi test
val load = ServiceLoader.load(TestSpi::class.java)
load.forEach {
    it.getSpi()
    if(it is TheTestSpi){
        Log.i("hello","theTestSpi")
    }
}

ServiceLoader.load

从上面我们可以看到,最关键的是调用了ServiceLoader.load方法,这个就是Spi具体的实现了,本质是什么呢?相信都能够猜到了,其实就是反射,我们来跟一下源代码

public static <S> ServiceLoader<S> load(Class<S> service) {
    // 获取了一个当前类的classloader,做好了准备
    ClassLoader cl = Thread.currentThread().getContextClassLoader();
    return ServiceLoader.load(service, cl);
}

紧接着就会调用到

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

我们可以看到,执行的时候有这么一句String fullName = PREFIX + service.getName();,很容易想到,如果我们要反射的话,是不是需要类全称,PREFIX 其实就是

private static final String PREFIX = "META-INF/services/";

可以看到,之所以我们需要在resource下定一个文件路径是META-INF/services,是因为在ServiceLoader中定义好了,所以ServiceLoader会按照约定的路径,去该文件夹下查找service.getName()(TestSpi)的实现类,最后通过

private S nextService() {
    if (!hasNextService())
        throw new NoSuchElementException();
    String cn = nextName;
    nextName = null;
    Class&lt;?&gt; 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");
    }
    .....

Class.forName(cn, false, loader) 去进行了类查找操作,因为我们通过foreach去遍历,其实就是通过迭代器去获取了每个实例,所以才能够调用到了实现类TheTestSpi的getSpi() 方法。

在Android中的应用

SPI机制在很多库的设计上都有应用,比如Coroutine(kotlin协程库)就有用到,比如我们经常用到的 MainCoroutineDispatcher,如果我们希望一个任务运行在主线程,在Android就可以通过handler的方式去向主线程post一个消息,那如果在其他环境呢?

kotlin不仅仅是想在android的世界立足,还有很多比如如果在native环境呢?在服务器环境呢?多平台环境呢(如KMM),那就不一定有Handler这个概念对不对!但是都有一个主线程的概念,所以Coroutine把这部分就通过SPI的方式去实现了,如

定义了这个接口 MainDispatcherFactory::class.java 用于给具体环境的主线程实现类进行实现,具体的实现类就是

internal class AndroidDispatcherFactory : MainDispatcherFactory {
    override fun createDispatcher(allFactories: List&lt;MainDispatcherFactory&gt;) =
        HandlerContext(Looper.getMainLooper().asHandler(async = true))
    override fun hintOnError(): String? = "For tests Dispatchers.setMain from kotlinx-coroutines-test module can be used"
    override val loadPriority: Int
        get() = Int.MAX_VALUE / 2
}

可以看到,在Android中就通过了Handler去实现,最后我们可以在源码中看到,SPI相关的注册信息

总结

通过SPI技术去实现的解耦合工作的出色工程还有很多很多,比如我们用的APT,还有didi开源的Booster,都有用到这方面的知识。

加载全部内容

相关教程
猜你喜欢
用户评论