2022年第46周周报

2022年11月20日 · 阅读需 5 分钟

Simple Robot 首席吉祥物

大概是2022年第46周周报喵。

📦 核心库

核心库最近暂时没有什么更新，不过有一些暂定的更新计划。

在之前的某一次更新中，我们引入了 Application 的概念，并开始强调事件和BOT注册的 "预加载" ，比如：

createSimpleApplication {
    listeners {
        Event {
            // ...
        }
    }

    bots {
        // ...
    }
}

但是当开始支持动态监听函数后，这种操作便失去它的意义。在动态监听函数的支持之前，监听函数实际上是存在内部的解析与缓存的。彼时的监听函数管理器虽然实质上也是能支持动态增加监听函数的，但是对于监听函数的移除是十分低效的。

为了避免动态增删带来的低效，我们提倡监听函数的预注册，并在构建监听函数管理器的同时就进行解析，并为后续的缓存做准备。这也是为什么我们一度建议在 Application 构建过程中注册监听函数而不是构建结束后。

对监听函数进行基于事件类型的独立缓存的初衷是为了当接收到事件的时候能够快速得到所有与之匹配的监听函数，并适当地降低无用的事件被构建出来的概率。但是目前来看，这种措施似乎并不是非常的合适。

所以我们在某一次的更新中调整了内部的结构并支持的监听函数的完全动态化。因此，目前完全可以在 Application 构建完成后在进行事件的注册：

val application = createSimpleApplication {
    install(...)
}

application.register(fooListener)

接下来一个版本，我们会考虑由内部迁移一些监听函数的构建器到外部使用，并逐渐弃用内部的"预注册"API。

在 #497 中，我们开始讨论 "聚合消息回执" 的实施。

前段时间在对 Kook组件进行更新的时候发现，目前的消息链与消息发送机制对于不同组件来讲可能存在一定地限制。

比如对于消息链 Text("xxx") + Image(...) 来说，它代表一个文本内容加一个图片。可是并非所有的组件都允许这种组合消息的发送，比如 Kook，它的图片与文本都是独立的（不考虑使用 KMarkdown 中的纯超链接图片预览的情况）。

这时候就会产生一个问题：当用户发送这种复合消息，那么实际的处理逻辑应该是如何呢？

在进行simbot中消息回执与消息链的api设计时，我们考虑的是使用第2种方案。当时我们深入对接的组件只有 Mirai，因此也并没有考虑太多（因为QQ允许的复合消息比较丰富，不太会出现这种情况）。

但是目前来看，这似乎并不是那么合理，也因此诞生了 #497。后续的更新我们会考虑基于第3种方案重整消息回执和消息链的部分设计，届时将会某种程度上增加一个消息链在不同组件间的通用性。

还是躲不过

这大概率将是一种不兼容更新。