SPI是什么

SPI全称Service Provider Interface，是Java提供的一套用来被第三方实现或者扩展的API，它可以用来启用框架扩展和替换组件。

整体机制图如下：

Java SPI 实际上是“基于接口的编程＋策略模式＋配置文件”组合实现的动态加载机制。
模块之间基于接口编程，模块之间不对实现类进行硬编码，实现解耦，而且实现可插拔替换。

解耦过程

场景：同时有多个同品类第三方SDK需要使用，实现统一的api接口，根据不同的条件路由到不同的SDK。

1.pluginManager方式

最初的实现方式：

从图中可以看出，3个module实现了同一个api，而APP强依赖了3个module。
怎么解耦呢？
APP并不想关心有多少个module实现了api，只关心调用的api接口。如图所示，我们增加manager来管理多个module。

从这个图来看，我们怎么进一步让manager和多个module进行解耦呢？可不可以使manager轻松一点呢？

让各个module自己来注册吧，manager负责动态加载呢？我们来看下实现的GitHub Demo-PluginManger

demoA实现接口api

class DemoImplA : ABaseApi {
    private val TAG = "DemoImpl"
    override fun init() {
        Log.d(TAG, "init DemoImplA")
    }
}

AEnginePlugin 获取api对应的demo

public class AEnginePlugin implements IAEnginePlugin {
    @Override
    public ABaseApi getAEngineInstance() {
        return new DemoImplA();
    }
}

APluginManager 负责往EnginePluginManager里的map注册添加，manager负责load

public class APluginManager extends EnginePluginManager.HolderPlugin {
    private static final AEnginePlugin aEnginePlugin = new AEnginePlugin();
    @Override
    protected void configure() {
        registerService(IAEnginePlugin.class, aEnginePlugin);
    }
}

    private static String[] providers = new String[]{
            "com.ghp.impledemoa.APluginManager",
            "com.ghp.impledemob.BPluginManager",
            "com.ghp.impledemoc.CPluginManager"
    };

    private static final HashMap<Class, Object> classObjectHashMap = new HashMap<>(providers.length);

    public static <T> T service(Class<T> a2) {
        return (T) classObjectHashMap.get(a2);
    }

    static {
        loadRouter();
    }
    private static void loadRouter() {
        for (String provider : providers) {
            try {
                HolderPlugin basePlugin = (HolderPlugin) Class.forName(provider).newInstance();
                basePlugin.configure();
                Log.d("EnginePluginManager", provider + " loadRouter!");
            } catch (ClassNotFoundException e) {
                e.printStackTrace();
            } catch (InstantiationException e) {
                e.printStackTrace();
            } catch (IllegalAccessException e) {
                e.printStackTrace();
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }
    public abstract static class HolderPlugin {

        protected abstract void configure();

        protected static void registerService(Class c, Object object) {
            classObjectHashMap.put(c, object);
        }
    }
}

最终根据路由调用，具体代码参见GitHub Demo-PluginManger

EnginePluginManager.service(IAEnginePlugin.class).getAEngineInstance()

2.Annotation方式

到这里已经实现APP和多个module的解耦，还可以进一步优化吗？每个module都要实现往manager注册过程的代码，挺麻烦的。我们可以把这个注册管理的过程，使用注解来进行代替。

每个module只需添加annotation，编译生成api和module的对应关系，然后呢，optimus根据对应关系加载module。

这样APP只需依赖api和optimus就可以。

详细的processor如何生成对应关系和optimus如何根据接口加载实现类，代码参见GitHub Demo-AnnotationManager

也可以使用 ServiceLoader + @AutoService 实现

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface OptimusService {
    /** Returns the interfaces implemented by this service provider. */
    Class<?> value();
}

@OptimusService(ABaseApi.class)
public class DemoImplA implements ABaseApi {
    private final String TAG = "DemoImpl";
    @Override
    public void init() {
        Log.d(TAG, "init DemoImplA");
    }
}

注意：如果用的是kotlin，将 annotationProcessor 改为 kapt，添加 plugins { id 'kotlin-kapt' }
生成的optimus位置在 build/tmp/kapt3/classes

加载优化

到此annotation+processor+optimus是已支持各组件解耦，无论多少个不同的module和api，APP都只依赖api和optimus就可以。

那还能不能进一步再优化呢？比如加载提前初始化？初始化放在哪里合适呢？

为了不影响应用启动的速度，又能提前初始化，我们放在首页创建的时候吧。

通过ActivityLifecycleCallbacks监听activity的创建，反射调用垂直化SDK统一入口的初始化方法。

public class OptimusProvider extends ContentProvider {

    @Override
    public boolean onCreate() {
        Application application = Utils.getApplication();
        if (application != null) {
            application.registerActivityLifecycleCallbacks(new OptimusLifecycle());
        }
        return true;
    }
    ……
  }

public class OptimusLifecycle implements Application.ActivityLifecycleCallbacks {

    private static final String TAG = "OptimusLifecycle";

    private final AtomicInteger createdCounter = new AtomicInteger();
    private final AtomicBoolean isChangingConfigurations = new AtomicBoolean(false);

    @Override
    public void onActivityCreated(@NonNull Activity activity, @Nullable Bundle savedInstanceState) {
        if (createdCounter.getAndIncrement() == 0 && !isChangingConfigurations.getAndSet(activity.isChangingConfigurations())) {
            initOptimus(activity.getApplication());
        }
    }

    ……

    @Override
    public void onActivityDestroyed(@NonNull Activity activity) {
        createdCounter.getAndDecrement();
        isChangingConfigurations.set(activity.isChangingConfigurations());
    }

    private void initOptimus(Application application) {
        OptimusExecutor.getInstance().executorCallerRunsPolicy(() -> {
            // 反射调用垂直化SDK统一入口的初始化方法
            try {
                final Class<?> optimusSdkClass = Class.forName("com.ghp.optimus.OptimusSdk");
                final Field sdkInfos = optimusSdkClass.getDeclaredField("SDK_INFOS");
                sdkInfos.setAccessible(true);
                Class<?> initCallbackClass = Class.forName("com.ghp.optimus.InitCallback");
                Method init = optimusSdkClass.getMethod("init", Context.class, initCallbackClass);
                init.invoke(null, application, null);
            } catch (Throwable ignore) {
            }
        });
    }

}

可插拔

前面已经通过SPI机制实现了解耦，模块可插拔，那怎么让包大小也一起优化呢？

在Android里有 fat-aar-android 插件，该插件提供了将library以及它依赖的library一起打包成一个完整aar的解决方案。

可以根据配置文件，利用fat-arr将各个module自由选择的打包，这里不多介绍，可以查看 fat-aar-android的使用。

最终在Jenkins打包添加配置

……
type "%contains%"
call gradle engine:build -PCONTAIN="%contains%"
……

Android组件化SPI