组件化代码隔离也难不倒组件的按序初始化

2020-10-19 08:37 Android技术之家

前言


        时至今日,Android项目中的组件化大家都已经非常熟悉了,但在各个细节方面还是有一些门门道道的内容,如果没有趁手的中间件支持,推行组件化的过程中还是会遇到阻碍。继2017年逻辑思维得到项目团队开源其组件化方案思路和核心gradle构建插件后,笔者一直投身其中并致力于插件的功能升级和中间件生态完善


       其实在2018年就有部分同学提出了“增加按序初始化组件”的需求,限于个人精力以及需求的优先级,当时被搁置了,这个需求一拖也就拖了两年了。这次终于抽出时间完成了这个中间件,特此写了一篇博客,介绍其中的一些知识点和这个中间件Maat。Github仓库 https://github.com/leobert-lan/Maat

方便阅读,导图附上。

注:即使你没有使用上面提到的得到组件化方案(DDComponentForAndroid)或者我们后续维护的JIMU,也不影响本篇文章的理解。

问题的根源

这里我们再花一点时间来了解下问题的根源:组件化的基础是模块化,在做到模块化的同时,模块与模块在编写、编译期间也就达成了完全代码隔离,组件间的交互依靠 底层接口+服务发现(或者服务注册) 或者更加抽象为 “基于协议、隐藏实现”。这带来了编写、编译期间激增的代码耦合。


我知道这样说实在是太晦涩了,一点也不接地气,我们以一个简单的例子来配合说明。

interface IComponent {    fun onCreate()    fun onDestroy()}

我们定义这样的接口来代表一个组件模型。案例设定为:一个宿主H+两个互无关联的组件A、B

那么有:

class A : IComponent {    override fun onCreate() {        // A初始化逻辑    }        override fun onDestroy() {    }}
class B : IComponent { override fun onCreate() { // B初始化逻辑 } override fun onDestroy() { }}

另有

class H :Application {    override fun onCreate() {        A().onCreate()        B().onCreate()    }}

我们以最简单的代码演示组件的加载和初始化环节。这里隐藏了一个问题:如果是手工编码,那么是存在代码边界的,编写、编译期间H无法直接访问A和B,我们只能通过反射去实现(否则编译不通过)。当然,也可以通过字节码技术实现

如果我们要让B先于A初始化,那么就调整其顺序,这对于手工编码方式而言,可能就是将编码变为:

XXX.loadComponent("Bpackage.B") //"Bpackage.B"为B的类路径XXX.loadComponent("Apackage.A")

而利用字节码技术的,则需要增加排序功能或者读取全量配置功能。

案例2:此时A组件依赖于B,必须等B组件初始化成功并得到结果后才能初始化。


思路1:先加载和初始化B,利用代码同步的特性,再初始化A

思路2:先加载和初始化B,修改组件模型,增加callback作为入参,异步初始化A

思路1存在很大的限制,比如其初始化需要参与网络通信或者数据库操作;思路2对于手工编码来说,会产生回调地狱,而对于字节码技术实现而言,就是一个噩梦

而且,JIMU已经投入使用挺长一段时间了,如果不是毫无选择,对于基类或者接口做无法版本兼容的操作都不应该被采纳

思路2的改进版:增加上下文,使得回调嵌套扁平化。

既然我们决定增加一个上下文,那么将初始化的管理工作进行封装就成了顺理成章的事情


为什么不使用官方StartUp而选择造轮子

在思考这个问题时,我们必须要清楚Startup的设计意图

Startup 中文介绍

可在应用启动时简单、高效地初始化组件。借助 App Startup 库,可在应用启动时简单、高效地初始化组件。库开发者和应用开发者都可以使用 App Startup 来简化启动序列并显式设置初始化顺序。

我们知道,在Startup发布之前,各大SDK采用的初始化方式一般为两种:

  • 显式API调用,需要Application实例

  • 内部提供一个ContentProvider,并在其中获取Application实例。因为其特性,会在应用启动时被自动加载,而不再需要使用者显式的API调用


一般为了方便开发者,在manifest文件中写入SDK参数配置并利用Context(为了不造成泄漏,使用Application是最好的选择)读取配置的做法更受推荐。所以第二种方式的使用越来越多。

这就带来了一个问题:引入越多的SDK就会引入更多的ContentProvider,他们并不会随着初始化工作完成而消亡,而且加重了应用启动时AMS的负担。

业内存在一个著名的编程范式:约定优于配置,既然使用ContentProvider作为初始化入口已经被广泛接受,那么Google作为生态维护者提供一个官方库,使用统一的初始化入口,使用者只需要按照约定暴露初始化逻辑,并且提供了前置依赖使得任务可排序的功能。


到这里我们就可以明白这样几件事情:

  • StartUp中使用异步和其排序加载之间存在“矛盾”

  • StartUp不提供依赖有向无环图校验


因为StartUp更主要的是面向SDK,提供统一标准。SDK库之间出现“存在性上的先后关系”的场景本身就非常小,如果有“依赖”,SDK生产者在库内部都处理好了,一般也不会出现代码边界。


所以,Maat并不是一个和StartUp一较长短的功能库,而是为了解决特定问题而编写的功能库。这些问题又恰恰是StartUp所不涉及的


设计思路

相信大家对“同步”和“异步”都有比较深的理解,我们先提出三个参与初始化的角色:

  • 任务:初始化工作的最小单元,清晰的知道自己的所依赖的任务,只有依赖的任务都执行完毕后才能执行,我们以Task=Name[dependency1,dependency2,...]来表示任务,例如 B[] ==> 无前置依赖的任务B, A[B] ==> 任务A、依赖任务B

  • 任务集:所有任务的集合,可分析任务的所有前置依赖并判断是否存在循环依赖,对任务进行排序,记为 TaskGroup={Task1,Task2,...}

  • 任务调度器:从任务集中取出任务派发执行的调度器

回顾我们最开始给出的例子,组件之前有存在性先后关系,必须要让依赖的组件完成初始化后才能开始加载那么任务调度器的工作方式是“同步”的,在“被依赖的任务”执行完毕前,依赖他的任务都必须阻塞等待

但是思考一个问题:两个互相独立的任务,必须阻塞等待吗?答案显然,不是必须的。


这里举一些例子:

有任务集:{A[],B[],C[A,B]},A和B是无依赖的,C依赖任务A和B,

那么任务调度器可以按照A、B、C的顺序进行调度,

也可以按照B、A、C的顺序进行调度每个任务执行中,任务调度器都阻塞等待,


也可以让AB两个任务并发(需要分配到不同线程)阻塞等待AB均完成后调度C。在第一个版本设计中,我还没有采用这个方案,目前让库保持足够轻量。当存在多组初始化路径时,其复杂程度远大于本处的例子


有向无环图(DAG)


接下来我们适当花一些篇幅来讨论DAG。在我们上面提到的任务集这一角色中,我们使用了DAG来处理拓扑排序和依赖无环校验。

我们将任务看做是图中的顶点,任务的依赖关系看做是边,方向和依赖方向相反,即A[B]意味着有从B到A的边。将所有的任务合并起来后我们将得到一份有向图,显然,成环的依赖是不被允许的。


为了更好的理解,我们人为的添加一个虚拟的顶点Start,作为初始化任务集的第一个任务,将所有无依赖的任务人为添加一个前置依赖:Start。


一个合法的任务集,必然没有成环的依赖,所以一定不是强连通图,在我们添加了虚拟顶点start后,其基图一定是连通图,故而合法的任务集(包含虚拟Start节点)是一个弱连通图

环校验

我们采用DFS方式递归遍历,受益于我们制定的虚拟顶点Start,我们可以直接从这个顶点开始。


定义深度集合 deepPathList,选定起始顶点S, 定义回环顶点列表 loopbackList, 定义路径列表 pathList

直接上代码 getEdgeContainsPoint(startPoint, Type.X) 代表取出所有以startPoint为起始点的边

fun recursive(startPoint: T, pathList: MutableList<T>) {    if (pathList.contains(startPoint)) {          loopbackList.add("${debugPathInfo(pathList)}->${startPoint.let(nameOf)}")          return      }      pathList.add(startPoint)      val edgesFromStartPoint = getEdgeContainsPoint(startPoint, Type.X)      if (edgesFromStartPoint.isEmpty()) {          val descList: ArrayList<T> = ArrayList(pathList.size)          pathList.forEach { path -> descList.add(path) }          deepPathList.add(descList)      }      edgesFromStartPoint.forEach {          recursive(it.to, pathList)      }
pathList.remove(startPoint)}

如果loopbackList不为空,则代表存在回环,回环的信息就存放在loopbackList中

契合需求的排序方式

上面我们已经提到了深度优先遍历(DFS),但是这种方式作出的拓扑排序不适合我们的需求,他适合寻找最优或者最差路径。而广度优先遍历(BFS)才契合需求。

直接给出代码:

private fun DAG<JOB>.bfs(): JobChunk {
val zeroDeque = ArrayDeque<JOB>() val inDegrees = HashMap<JOB, Int>().apply { putAll(this@bfs.inDegreeCache) } inDegrees.forEach { (v, d) -> if (d == 0) zeroDeque.offer(v) }
val head = JobChunk.head() var currentChunk = head
val tmpDeque = ArrayDeque<JOB>()
while (zeroDeque.isNotEmpty() || tmpDeque.isNotEmpty()) { if (zeroDeque.isEmpty()) { currentChunk = currentChunk.append() zeroDeque.addAll(tmpDeque) tmpDeque.clear() } zeroDeque.poll()?.let { vertex -> currentChunk.addJob(vertex)
this.getEdgeContainsPoint(vertex, Type.X).forEach { edge -> inDegrees[edge.to] = (inDegrees[edge.to] ?: 0).minus(edge.weight).apply { if (this == 0) tmpDeque.offer(edge.to) } } } } return head}

其中JubChunk是一组无关联的Job 即前文提到的初始化任务,前面提到目前没有让任务的执行可并发,JobChunk是为了可支持并发做准备的

关于DAG的部分我们就不再花篇幅介绍了,有兴趣的同学可以自行查阅相关资料

任务的描述

先上代码:

abstract class JOB {    abstract val uniqueKey: String
abstract val dependsOn: List<String>
abstract val dispatcher: CoroutineDispatcher
internal fun runInit(maat: Maat) { MainScope().launch { flow { init(maat) emit(true) } .flowOn(dispatcher) .catch { maat.onJobFailed(this@JOB,it) }.flowOn(Dispatchers.Main) .collect { maat.onJobSuccess(this@JOB) } } }
abstract fun init(maat: Maat)}

考虑到kotlin已经被官方推荐很长时间了,并且在去年Retrofit已经开始支持协程,姑且认为大部分项目中都已经开始使用协程了。所以很偷懒的直接使用了协程和Flow

  • uniqueKey 是当前任务名,需要人为确保唯一性

  • dependsOn 是当前任务所依赖的任务的uniqueKey的集合,虽然使用了List,但是顺序无关。

  • dispatcher 指定任务执行被分配到的线程类型

  • fun init(maat: Maat) 实际初始化逻辑,注意:按需求分析初始化代码块是否需要 “同步、阻塞”,如果部分代码是“异步、基于回调”且无法更改,这个实际场景(必须要异步获取结果,且该结果被另一个组件使用)想来很少见,第一个版本中我没有考虑,下个版本我会加上

示例代码模拟了4个初始化任务,有点长,具体的使用可以看一下Demo

val maat = Maat.init(application = this, printChunkMax = 6,    logger = object : Maat.Logger() {        override val enable: Boolean = true

override fun log(msg: String, throws: Throwable?) { Log.d("maat", msg, throws) }
}, callback = Maat.Callback(onSuccess = {}, onFailure = { maat, job, throwable ->
}))
maat.append(object : JOB() { override val uniqueKey: String = "a" override val dependsOn: List<String> = emptyList() override val dispatcher: CoroutineDispatcher = Dispatchers.IO
override fun init(maat: Maat) { Log.e( "maat", "run:" + uniqueKey + " isMain:" + (Looper.getMainLooper() == Looper.myLooper()) ) //test exception// throw NullPointerException("just a test") }
override fun toString(): String { return uniqueKey }
}).append(object : JOB() { override val uniqueKey: String = "b" override val dependsOn: List<String> = arrayListOf("a") override val dispatcher: CoroutineDispatcher = Dispatchers.Main /* + Job()*/
override fun init(maat: Maat) { Log.e( "maat", "run:" + uniqueKey + " isMain:" + (Looper.getMainLooper() == Looper.myLooper()) ) }
override fun toString(): String { return uniqueKey }
}).append(object : JOB() { override val uniqueKey: String = "c" override val dependsOn: List<String> = arrayListOf("a") override val dispatcher: CoroutineDispatcher = Dispatchers.IO /* + Job()*/
override fun init(maat: Maat) { Log.e( "maat", "run:" + uniqueKey + " isMain:" + (Looper.getMainLooper() == Looper.myLooper()) ) }
override fun toString(): String { return uniqueKey }
}).append(object : JOB() { override val uniqueKey: String = "d" override val dependsOn: List<String> = arrayListOf("a", "b", "c") override val dispatcher: CoroutineDispatcher = Dispatchers.Main
override fun init(maat: Maat) { Log.e( "maat", "run:" + uniqueKey + " isMain:" + (Looper.getMainLooper() == Looper.myLooper()) ) }
override fun toString(): String { return uniqueKey }
}).start()

在JIMU中使用

JIMU是一种很彻底的组件化方案,意味着编写代码时存在代码边界,即使是空壳宿主和业务组件之间也存在。前面也提到了,JIMU是使用字节码技术织入的组件加载代码(设置为自动加载组件时),而织入的代码是在Application的onCreate最后执行。

这这一前提下,如果通过javasist实现Maat的任务设置部分,他的可维护性将很差。所以我建议将任务设置部分放在组件的初始化入口处,这样可读性和可维护性都相对好一点.

以原先的分享业务组件为例:

public class ShareApplike implements IApplicationLike {
UIRouter uiRouter = UIRouter.getInstance();
@Override public void onCreate() { uiRouter.registerUI("share"); Log.e("share","share on create"); Maat.Companion.getDefault().append(new JOB() { @NotNull @Override public String getUniqueKey() { return "share"; }
@NotNull @Override public List<String> getDependsOn() { return Collections.singletonList("reader"); }
@NotNull @Override public CoroutineDispatcher getDispatcher() { return Dispatchers.getMain(); }
@Override public void init(@NotNull Maat maat) { Log.d("share", "模拟初始化share,context:" + maat.getApplication().getClass().getName()); }
@Override public String toString() { return getUniqueKey(); } }); }
@Override public void onStop() { uiRouter.unregisterUI("share"); }}

当然,务必不要忘记在Application的onCreate()中先初始化Maat:

Maat.Companion.init(this, 8, new Maat.Logger() {            @Override            public boolean getEnable() {                return true;            }
@Override public void log(@NotNull String s, @Nullable Throwable throwable) { if (throwable != null) { Log.e("maat",s,throwable); } else { Log.d("maat",s); } } }, new Maat.Callback(new Function1<Maat, Unit>() { @Override public Unit invoke(Maat maat) { Maat.Companion.release(); return null; } }, new Function3<Maat, JOB, Throwable, Unit>() { @Override public Unit invoke(Maat maat, JOB job, Throwable throwable) { return null; } }));

而Maat的启动API调用,自然由javasist织入了。配合最新的gradle插件 build-gradle:1.3.4方可使用,启用开关为:

combuild {    useMaat = true/false}

非常重要:

请务必分析项目的组件初始化场景,在Maat适用你的应用场景时再使用。

目前Maat保持了轻量化,如果您有一些合理的需求,欢迎留言或者提issue交流


作者:leobert-lan
链接:https://juejin.im/post/6884492604370026503

关注我获取更多知识或者投稿


本文章转载自公众号:jszj2014215

首页 - Android 相关的更多文章: