EventBus3的基本使用指南

使用EventBus可以省略繁杂的Handler,效果也是类似的,使用方法也很简单。这里从官网上面做一个小小的总结,可以看得更全面一些。入门贴官方教程定义事件事件就是一个普通的Java类,POJO就好。public class MessageEvent { public final Strin

使用EventBus可以省略繁杂的Handler,效果也是类似的,使用方法也很简单。这里从官网上面做一个小小的总结,可以看得更全面一些。

入门贴

官方教程

定义事件

事件就是一个普通的Java类,POJO就好。

public class MessageEvent {
    public final String message;
    public MessageEvent(String message) {
        this.message = message;
    }
}

订阅事件

事件的订阅者会被调用以处理相应的事件。使用@Subscribe定义。EventBus 3对函数名没有要求。

// 当MessageEvent事件被发送的时候,此方法会被调用(在主线程中)
@Subscribe(threadMode = ThreadMode.MAIN)
public void onMessageEvent(MessageEvent event) {
    Toast.makeText(getActivity(), event.message, Toast.LENGTH_SHORT).show();
}
//当SomeOtherEvent方法被发送的时候,此方法会被调用
@Subscribe
public void handleSomethingElse(SomeOtherEvent event) {
    doSomethingWith(event);
}

事件的订阅函数所在的地方,需要先声明订阅,并且最好在相应的时候取消事件的订阅。只有订阅了,才会收到事件消息。因此一般会在ActivityFragment的生命周期中进行上述操作。

@Override
public void onStart() {
    super.onStart();
    EventBus.getDefault().register(this);
}
 
@Override
public void onStop() {
    EventBus.getDefault().unregister(this);
    super.onStop();
}

发送事件

你可以在任何代码中进行事件的发送。所有对匹配此事件的订阅者都将会收到此事件。

EventBus.getDefault().post(new MessageEvent("Hello everyone!"));

指定订阅者函数执行的线程

如果不指定线程,那么将默认与发送事件处于相同的线程。

ThreadMode 说明
POSTING 默认模式,与发送事件时所处的线程相同。
MAIN 主线程。注意在订阅函数内不用做太多耗时的操作,以免堵塞主线程。如果事件是在主线程中发送的,那么订阅者将会立即执行对于的函数。
MAIN_ORDERED 主线程。如果已经有一个订阅者的函数在执行,那么将等待它执行完毕后,才执行当前订阅者的函数。与其名字相呼应吧!
BACKGROUND background线程。如果事件不是在主线程中发送的,那么订阅者将立刻在此发送线程中执行;如果是在主线中发送的,那么将会开启一个线程,并在此线程中依次发送所有的事件,当订阅者收到此事件时,将会在此线程中执行吧!
ASYNC 会开启一个独立的线程来执行订阅者函数。可以考虑将比较耗时的操作设为此模式,如网络访问。这些线程会被一个线程池管理,以提高重新利用的效率。

配置

示例是配置当没有订阅者时的一些操作。

EventBus eventBus = EventBus.builder()
    .logNoSubscriberMessages(false)
    .sendNoSubscriberEvent(false)
    .build();

上面获取到EventBus实例的方式与之前示例中获取到EventBus实例不太一样。其中的差距此处获取到的只是当前的实例,后者是默认的实例。如何才能配置默认的实例呢?

EventBus.builder().throwSubscriberException(BuildConfig.DEBUG).installDefaultEventBus();

其中installDefaultEventBus()只能调用一次。

参考

Read more

Volcano 与 Kubernetes GPU 调度学习笔记

本笔记系统整理 Volcano 调度器、Kubernetes 调度框架、GPU Device Plugin、HAMi 等云原生 AI 调度领域的核心知识,适合用于学习、复习和工程实践参考。 目录 * 第一部分:Volcano 入门 * 1. Volcano 是什么 * 2. 安装与快速使用 * 3. 核心特性一览 * 第二部分:Volcano 整体架构 * 4. Volcano 解决的核心问题 * 5. 整体架构与数据流 * 6. 三层抽象模型 * 第三部分:Volcano 核心实现原理 * 7. Session 机制 * 8. Gang Scheduling 实现 * 9. Queue 与 DRF 公平调度

容器镜像(4):镜像的常用工具箱

容器镜像(4):镜像的常用工具箱

前几篇在讲多架构镜像时已经用过 skopeo 和 crane 做镜像复制,这篇系统整理这两个工具的完整能力,同时介绍几个日常操作镜像时同样好用的工具。 一、skopeo:不依赖 Daemon 的镜像瑞士军刀 skopeo 的核心价值是绕过 Docker daemon,直接与 Registry API 交互。上一篇用它做镜像复制和离线传输,但它的能力远不止于此。 1.1 安装 # Ubuntu / Debian sudo apt install -y skopeo skopeo --version # skopeo version 1.15.1 1.2 inspect:免拉取检查镜像元数据 docker inspect 需要先把镜像拉到本地,skopeo inspect 直接向 Registry

容器镜像(3):多架构镜像构建

容器镜像(3):多架构镜像构建

一、什么是多架构镜像 1.1 OCI Image Index 上一篇介绍了单平台镜像的结构:一个 Manifest 指向 Config 和若干 Layer blob。多架构镜像在此之上多了一层——OCI Image Index(也叫 Manifest List),是一个轻量的索引文件,把多个单平台 Manifest 组织在一起: $ docker manifest inspect golang:1.22-alpine { "schemaVersion": 2, "mediaType": "application/vnd.oci.image.index.v1+json", "manifests&

容器镜像(2):containerd 视角下的镜像

容器镜像(2):containerd 视角下的镜像

一、为什么需要了解 containerd 如果你只用 docker run 跑容器,从来不关心底层,那可以不了解 containerd。但如果你在用 Kubernetes,或者想真正理解"容器运行时"是什么,containerd 是绕不开的。 事实上,当你执行 docker run 的时候,containerd 早就在后台悄悄工作了——Docker 从 1.11 版本开始,就把核心运行时剥离出来交给 containerd 负责。 1.1 Docker 的架构演变 早期的 Docker(1.10 及之前)是一个"大一统"的单体程序:一个 dockerd