EventBus原理解析笔记以及案例实战(结合demo)

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: EventBus原理解析笔记以及案例实战(结合demo)

笔记概述

  • EventBus简介

  • EventBus方法介绍

  • EventBus实际运用

EventBus简介

Event bus for Android and Java that simplifies communication between Activities, Fragments, Threads, Services, etc. Less code, better quality.
即,
**Event 简化了活动、碎片、进程、服务等之间的通讯方式;
使APP项目用更少的代码量实现更好的质量;**

  • 关于EventBus的优势

  • 简化组件间的通讯方式

    • 解耦合事件发送者和接收者
    • 使活动、碎片和后台的线程实现更高的执行效率
    • 防止复杂的有错误(倾向)的依赖以及生命周期的问题
  • 让你的代码简洁
  • 运行快
  • 库小
  • EventBus主页简洁:

EventBus is an open-source library for Android and Java using the publisher/subscriber pattern for loose coupling. EventBus enables central communication to decoupled classes with just a few lines of code – simplifying the code, removing dependencies, and speeding up app development.
即,
**EventBus是一个开源库,
使用发布/订阅机制来对代码进行解耦。
简化项目的集中通讯(仅仅通过几行代码就可以解耦各个类),
移除了一些不必要的依赖,加速移动应用的开发。**

**关于大项目,如果还是用Java/Android原生的调用,
两个Activity之间的通讯,
还用 startActivity()/startActivityForResult()这类通信方式的话,
代码会非常的 冗余
例如Activity和Fragment之间的通讯就需要不断地调用 相关的函数
使用 EventBus可以解除这些耦合;
否则如果代码耦合性非常大的话,
会大大增加后期维护的难度!**


EventBus架构

  • Publisher

调用post()方法,
把Event发送到EventBus;

  • EventBus(类似于快递中心)

分发Publisher发布的Event
给对应的Subscriber(订阅者);

  • Subscriber接收Event;

EventBus概述

  • **EventBus是一个Android端优化的

publish/subscribe消息总线;**

  • 简化了应用程序内各组件间、组件与后台线程间的通讯;
  • 举例一个EventBus可简化代码的场景:

请求网络时候,等网络返回时通过Handler或Broadcast通知UI;
两个Fragment之间需要通过Listener通讯;
以上都可以用EventBus来代替;

  • EventBus作为一个消息总线,有三个主要的元素:

    • Event:事件

Event可以是任意对象,
用来描述传递的数据事件类型
一般Event是由开发者按照需求自己定义的,
里面封装要传递的事件类型和数据

- **Subscriber:事件订阅者,接收待定的事件**

在Event中,使用约定制定事件订阅者简化使用

在3.0之前,EventBus还没使用注解的方式,
消息处理的方法也仅限于:
onEventonEventMainThreadonEventBackgroundThreadonEventSync
分别代表四种线程模型

在3.0之后消息处理的方法可以随便取名
但是需要
添加一个注解@Subscribe
并且要指定线程的模型

- **Publisher:事件发布者,用于通知`Subscriber`有事件发生**

**可以在任意线程、任意位置发送事件,
直接调用EventBuspost(Object)方法即可;**

- **调用`EventBus.getDefault()`方法,实例化EventBus对象**


EventBus线程模型

ThreadMode

ThreadMode指定了会调用的函数,
只能有以下四种(因为每个订阅事件都是和一个线程模型相关的):
**`PostThread、
BackgroundThread、
MainThread、
Async`**

PostThread: 在相同的进程中做EventBus通信

  • 事件的处理事件的发送相同的进程

所以事件的处理时间不应太长,
不然会影响事件的发送线程
而这个线程可能是UI线程

  • 对应的函数名是onEvent

一般在UI线程使用,
**如果堵塞时间较长则会影响其他线程的刷新
引起界面的卡顿;**
打个比方说你在UI线程中卡了两秒等下UI就不动,不刷新了

相关地举一个案例

  • 这里有两个Activity:

按下Activity1中的Button,
会跳转到Activity2;

按下Activity2中的button,
会通过EventBus去通知Activity1;

Activity1会通过OnEvent接收,
如果接收到Activity2发送过来消息,
然后触发Toast;

接下来新建一个项目,根据官方GitHub添加依赖,

implementation 'org.greenrobot:eventbus:3.1.1'

下面是主布局(Activity1):

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">

    <Button
        android:id="@+id/bt_toAc2"
        android:text="跳转到Activity2"
        android:layout_width="match_parent"
        android:layout_height="wrap_content" />

</LinearLayout>
  • 然后根据需求定义Event(类似于Module类),

这里没什么特别需求,
定义一个简单的Event就可以了:

public class MyEvent {

    public String msg;

    public MyEvent() {}

    public MyEvent(String msg) {
        this.msg = msg;
    }
}
  • **接下来,

要在我们这个“Activity1”里面注册 OnEvent ,**
这个OnEvent 是在跟 发送事件的线程 同一个线程里面 接收事件的,

我们这里**虽然是分开两个Activity,
但是Activity本身就都是在主线程里面的;
所以这里 事件的发送(在Activity2), 事件的接收(在Activity1)
都在同一个线程中;**

即,以上所说的PostThread线程类型中,
事件的发送 跟 事件的接收 是在同一个线程里面的;


**下面注册一个onEvent(),
如果接收到Activity2发送过来消息,触发Toast;**

    /**
     * 注册onEvent(),
     * 注意写上注解!
     */
    @Subscribe
    public void onEvent(MyEvent event) {
        popOutToast("接收到Event:" + event.msg);
    }
    /**
     * 封装弹出短时Toast提示
     * @param text 企图弹出的文本内容
     *
     */
    private void popOutToast(String text) {
        Toast.makeText(MainActivity.this,text,Toast.LENGTH_SHORT).show();
    }
  • 使用EventBus的接收方法的活动,需要在onCreate中注册
        EventBus.getDefault().register(this);
  • 反注册
    @Override
    protected void onDestroy() {
        super.onDestroy();
        EventBus.getDefault().unregister(this);
    }
  • 整个Activity1的java代码:
public class MainActivity extends AppCompatActivity {

    private Button mButton;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        //使用EventBus的接收方法的活动,需要注册
        EventBus.getDefault().register(this);

        mButton = findViewById(R.id.bt_toAc2);
        mButton.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                Intent intent = new Intent(MainActivity.this, SecondActivity.class);
                startActivity(intent);
            }
        });
    }

    /**
     * 注册onEvent(),
     * 注意写上注解!
     */
    @Subscribe
    public void onEvent(MyEvent event) {
        popOutToast("接收到Event:" + event.msg);
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        EventBus.getDefault().unregister(this);
    }

    /**
     * 封装弹出短时Toast提示
     * @param text 企图弹出的文本内容
     *
     */
    private void popOutToast(String text) {
        Toast.makeText(MainActivity.this,text,Toast.LENGTH_SHORT).show();
    }
}

创建第二个活动SecondActivity,布局:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">

    <Button
        android:id="@+id/bt_sendMsg"
        android:text="发送消息"
        android:layout_width="match_parent"
        android:layout_height="wrap_content" />

</LinearLayout>

java:

public class SecondActivity extends AppCompatActivity {

    private Button mButton;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_second);

        mButton = findViewById(R.id.bt_sendMsg);
        mButton.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                EventBus.getDefault().post(new MyEvent("洞妖洞妖我是栋二!!!"));
            }
        });
    }
}

运行效果图:
Activity1:
跳到Activity2,点击按钮,弹出Toast:

补充

  • 以上这种场景,

如果不用EventBus,
我们可能需要用到Handler + Runnable的方式,
但是如果有十个Activity向Activity1发消息,
我们就需要写十个Handler了,
这样子相当繁琐;
而使用EventBus,
这里只要稍微用代码注册一下就可以了,
明显方便很多,
一个方post、一个onEvent,也很轻松地解耦了;

  • **另外一个需要注意的地方就是,

EventBus.getDefault().register(this);系列的注册与反注册代码,
onEvent()系列的接收函数是紧密绑定的;
用时缺一不可,不用时存一不可,同生同灭;

也就是说一个活动注册onEvent()系列的接收函数了,
则必须用EventBus.getDefault().register(this);去注册,
不然会报错;

而一个活动它没有写onEvent()系列的接收函数,
却用EventBus.getDefault().register(this);去注册了,
同样也会报错!**

  • onEvent()处理时间比较长,会导致线程堵塞;

如以下再onEvent()中挂起线程3秒,模拟3秒处理时间:

    @Subscribe
    public void onEvent(MyEvent event) {

        //消耗时间模拟
        try {
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        popOutToast("接收到Event:" + event.msg);
    }

接着运行项目的话,
会发现我们在Activity2中点击发送消息的按钮之后,
要等到3秒钟,主线程才会刷新UI(弹出Toast),
这样子在实际运用中用户体验很差;

MainThread

  • 其机制同onEvent()其实是差不多的,

发送接收都是在同一个线程 主线程 / UI线程中进行;

使用:基于PostThread的代码,
加多一行(threadMode = ThreadMode.MAIN)即可:

    //MainThread
    @Subscribe(threadMode = ThreadMode.MAIN)
    public void onEvent(MyEvent event) {

        //消耗时间模拟
        try {
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        popOutToast("接收到Event:" + event.msg);
    }

BackgroundThread

  • 事件的处理会在一个后台线程中执行,

对应的函数名是onEventBackgroundThread

  • 虽然名字是BackgroundThread,

事件的处理是在后台线程,
但事件的处理时间还是不宜太长;

  • 如果发送事件的线程是在后台线程,

会直接执行事件;

  • 如果当前线程是UI线程,

事件会被加到一个队列中,
由一个线程依次处理这些事件,

如果某个事件处理时间太长,
会阻塞队列中 排在后面的事件的派发或处理;

图解

对于PostThread和MainThread

一次执行
  • 当只有一个线程的时候,

post(发送)和onEvent()是在同一个线程中去跑的,
一个线程里面的话,
宏观上来说,其代码便是一次执行的:

对于BackgroundThread

一一对应
  • 这里有两个线程,UI主线程和后台线程,

这个后台线程 专门用来
处理onEventBackgroundThread方法及其对应的事件的;

也就是说,
比如现在主线程里面有一个post
它会对应执行到后台的一个onEventBackgroundThread()

顺序执行,前者执行,后者等待阻塞
  • 一个前台线程的post

会对应执行到一个后台线程的onEventBackgroundThread()
来了第二个post,
就对应第二个onEventBackgroundThread()

  • 后台线程中的onEventBackgroundThread()

是按照post顺序依次执行的;
如果前面一个post对应的onEventBackgroundThread();没有执行完,
这时候又post了一下,
那么对应的后面的这个onEventBackgroundThread()会等待前面一个onEventBackgroundThread()执行完,它才执行;

  • 来个例子,修改MainActivity代码:
    //BackgroundThread
    @Subscribe(threadMode = ThreadMode.BACKGROUND)
    public void onEvent(MyEvent event) {

        Log.d(TAG, "onEvent Start!!!!!!!! ");
        //消耗时间模拟
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        Log.d(TAG, "onEvent End!!!!!!!! ");

//        popOutToast("接收到Event:" + event.msg);
    }
  • 接着运行代码,

**老规矩,Activity1跳转到Activity2,
点击“发送信息”按钮,
连续点击两次(根据以上SecondActivity中写的按钮点击事件,
这里可以理解成连续post两次,一前一后),
观察logcat:**

  • 我们可以观察到两对Start和End是顺序执行的;
  • 执行时候没有交叉,先第一对,后第二对;

这里也便验证了以上理论——
**即,
一一对应,一个post对应一个event,
event顺序执行,
前post者对应的event执行中,
则后post者对应的event等待阻塞;**

  • 其实把代码改成MainThread的,

再运行,连续点击三次,
同样是能体现一一对应,顺序执行,前者执行,后者等待阻塞的特性:

    @Subscribe(threadMode = ThreadMode.MAIN)
    public void onEvent(MyEvent event) {

        Log.d(TAG, "onEvent Start!!!!!!!! ");
        //消耗时间模拟
        try {
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        Log.d(TAG, "onEvent End!!!!!!!! ");

//        popOutToast("接收到Event:" + event.msg);
    }

  • 但区别在于,

**Main是执行在主线程,
而Background是执行在后台线程,
而且我们前面说过,
在主线程中执行占用资源多、占用时间长的任务是不合适的,
既不规范,也影响体验;**

  • PostThread/MainThread缺点:

执行在主线程,
事件的个数,事件的耗时,
都需要做比较严格的限制

  • BackgroundThread缺点:

运行在后台线程,不占用主线程资源,
PostThread/MainThread好那么一点,
但是还是没有解决——
多个( >= 2 个)事件时,
**一次处理一个,依次处理,
前者执行,后者等待阻塞**的问题,
不适合事件中有耗时较长的任务

Async adj.异步的;

sync n.同时,同步;
  • **事件处理会在单独的线程中执行,

主要用于在后台线程中执行耗时操作,
每个事件会开启一个线程
(程序初始化时,已经帮我们创建好一个线程池,
每次POST一下框架都会去取一个线程来执行),
但最好限制线程的数目
(线程过多,CPU使用大,设备耗电快);

每次POST一下框架都会去取一个线程来执行
线程池中线程之间互相不干扰,可以同时运行;**

更改代码:

    //AsyncThread
    @Subscribe(threadMode = ThreadMode.ASYNC)
    public void onEvent(MyEvent event) {

        Log.d(TAG, "onEvent Start!!!!!!!! ");
        //消耗时间模拟
        try {
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        Log.d(TAG, "onEvent End!!!!!!!! ");
    }

执行效果:

这次我们可以看到,
事件的处理就没有——
一次处理一个,依次处理,前者执行中,后者等待阻塞的特性了,
因为各个post的事件,
都有各自独立的线程去处理,
所以事件的处理运行是同时的、异步的;

小结

  • PostThread:发送和接收在同一个线程;
  • MainThread:发送和接收同在主线程;

(应用范围上被PostThread包括)

  • BackgroundThread
  • PostThread/MainThread缺点:

一般执行在主线程,
事件的个数,事件的耗时,
都需要做比较严格的限制

  • BackgroundThread缺点:

运行在后台线程,不占用主线程资源,
PostThread/MainThread好那么一点,
但是还是没有解决——
多个( >= 2 个)事件时,
**一次处理一个,依次处理,
前者执行,后者等待阻塞**的问题,
不适合事件中有耗时较长的任务

以上三种线程都是不适合跑耗时操作的;

Async adj.异步的;
核心:异步,同时,高效

  • **事件处理会在单独的线程中执行,

主要用于在后台线程中执行耗时操作,
每个事件会开启一个线程
(程序初始化时,已经帮我们创建好一个线程池,
每次POST一下框架都会去取一个线程来执行),
但最好限制线程的数目
(线程过多,CPU使用大,设备耗电快);

每次POST一下框架都会去取一个线程来执行
线程池中线程之间互相不干扰,可以同时运行**

补充:

  • 优先级(priority)就是字面上的意义,

值越高,优先级越高;

  • **sticy即粘性发送,

发送方法EventBus.getDefault().postSticky(new MyEvent());
注销粘性event的方法EventBus.getDefault().removeStickyEvent(new MyEvent());
发送(postSticky)的时候,
项目中有多少Fragment、Activity等载体,
事件MyEvent就发送多少份;
粘性其意义在于,
无论项目中载体类中
是否使用EventBus.getDefault().register(this);对EventBus注册过,
都会对其发送事件,**
若载体注册了,则接收处理该粘性事件;
若载体未注册,则该粘性事件会缓存起来,
一旦载体注册,马上接收处理事件
**但由于这种粘性发送在项目比较大的时候
需要占用一定量的缓存资源,
所以一般使用较少;**

  • **另外一个需要注意的地方就是,

EventBus.getDefault().register(this);系列的注册与反注册代码,
onEvent()系列的接收函数是紧密绑定的;
用时缺一不可,不用时存一不可,同生同灭;

也就是说一个活动注册onEvent()系列的接收函数了,
则必须用EventBus.getDefault().register(this);去注册,
不然会报错;

而一个活动它没有写onEvent()系列的接收函数,
却用EventBus.getDefault().register(this);去注册了,
同样也会报错!**

使用技巧

  • **事件只需要传递一个状态 / 指令,无需传递数据时,

event自定义类内容可以为空;**

比如一个只需要传递“清空位置信息列表”这个指令的事件,
可以这么定义:就是定义一个Event类,但是内容为空;

无需传递数据,
仅仅event类的类名已经具备传递的事件、指令意义;

  • **一个Fragment或者Activity需要接收处理多个Event时候,

通过建立多个注解方法,并以不同的event 形参
区分处理,接收到不同的event时,该做的对应的逻辑**;





参考资料:慕课网

相关文章
|
17天前
|
安全 算法 网络协议
解析:HTTPS通过SSL/TLS证书加密的原理与逻辑
HTTPS通过SSL/TLS证书加密,结合对称与非对称加密及数字证书验证实现安全通信。首先,服务器发送含公钥的数字证书,客户端验证其合法性后生成随机数并用公钥加密发送给服务器,双方据此生成相同的对称密钥。后续通信使用对称加密确保高效性和安全性。同时,数字证书验证服务器身份,防止中间人攻击;哈希算法和数字签名确保数据完整性,防止篡改。整个流程保障了身份认证、数据加密和完整性保护。
|
9天前
|
机器学习/深度学习 数据可视化 PyTorch
深入解析图神经网络注意力机制:数学原理与可视化实现
本文深入解析了图神经网络(GNNs)中自注意力机制的内部运作原理,通过可视化和数学推导揭示其工作机制。文章采用“位置-转移图”概念框架,并使用NumPy实现代码示例,逐步拆解自注意力层的计算过程。文中详细展示了从节点特征矩阵、邻接矩阵到生成注意力权重的具体步骤,并通过四个类(GAL1至GAL4)模拟了整个计算流程。最终,结合实际PyTorch Geometric库中的代码,对比分析了核心逻辑,为理解GNN自注意力机制提供了清晰的学习路径。
158 7
深入解析图神经网络注意力机制:数学原理与可视化实现
|
8天前
|
数据采集 JSON 数据可视化
JSON数据解析实战:从嵌套结构到结构化表格
在信息爆炸的时代,从杂乱数据中提取精准知识图谱是数据侦探的挑战。本文以Google Scholar为例,解析嵌套JSON数据,提取文献信息并转换为结构化表格,通过Graphviz制作技术关系图谱,揭示文献间的隐秘联系。代码涵盖代理IP、请求头设置、JSON解析及可视化,提供完整实战案例。
JSON数据解析实战:从嵌套结构到结构化表格
|
10天前
|
机器学习/深度学习 缓存 自然语言处理
深入解析Tiktokenizer:大语言模型中核心分词技术的原理与架构
Tiktokenizer 是一款现代分词工具,旨在高效、智能地将文本转换为机器可处理的离散单元(token)。它不仅超越了传统的空格分割和正则表达式匹配方法,还结合了上下文感知能力,适应复杂语言结构。Tiktokenizer 的核心特性包括自适应 token 分割、高效编码能力和出色的可扩展性,使其适用于从聊天机器人到大规模文本分析等多种应用场景。通过模块化设计,Tiktokenizer 确保了代码的可重用性和维护性,并在分词精度、处理效率和灵活性方面表现出色。此外,它支持多语言处理、表情符号识别和领域特定文本处理,能够应对各种复杂的文本输入需求。
50 6
深入解析Tiktokenizer:大语言模型中核心分词技术的原理与架构
|
12天前
|
开发框架 .NET 中间件
.net8 使用 license 证书授权案例解析
本文介绍了如何使用 `.NET CLI` 创建并改造一个 `ASP.NET Core Web API` 项目,以实现基于许可证的授权机制。具体步骤包括创建项目、添加必要的 NuGet 包(如 `Standard.Licensing` 和 `Swashbuckle.AspNetCore`),以及修改 `Program.cs` 文件以集成自定义的许可证验证中间件。项目结构中新增了 `LicenseController` 接口用于处理授权相关操作,并通过测试流程验证了默认天气接口在未授权和授权状态下的响应情况。整个过程确保了应用程序能够在启动时正确验证许可证,保障系统的安全性与可控性。
50 8
.net8 使用 license 证书授权案例解析
|
1月前
|
机器学习/深度学习 算法 数据挖掘
解析静态代理IP改善游戏体验的原理
静态代理IP通过提高网络稳定性和降低延迟,优化游戏体验。具体表现在加快游戏网络速度、实时玩家数据分析、优化游戏设计、简化更新流程、维护网络稳定性、提高连接可靠性、支持地区特性及提升访问速度等方面,确保更流畅、高效的游戏体验。
77 22
解析静态代理IP改善游戏体验的原理
|
1月前
|
编解码 缓存 Prometheus
「ximagine」业余爱好者的非专业显示器测试流程规范,同时也是本账号输出内容的数据来源!如何测试显示器?荒岛整理总结出多种测试方法和注意事项,以及粗浅的原理解析!
本期内容为「ximagine」频道《显示器测试流程》的规范及标准,我们主要使用Calman、DisplayCAL、i1Profiler等软件及CA410、Spyder X、i1Pro 2等设备,是我们目前制作内容数据的重要来源,我们深知所做的仍是比较表面的活儿,和工程师、科研人员相比有着不小的差距,测试并不复杂,但是相当繁琐,收集整理测试无不花费大量时间精力,内容不完善或者有错误的地方,希望大佬指出我们好改进!
99 16
「ximagine」业余爱好者的非专业显示器测试流程规范,同时也是本账号输出内容的数据来源!如何测试显示器?荒岛整理总结出多种测试方法和注意事项,以及粗浅的原理解析!
|
21天前
|
Java 数据库 开发者
详细介绍SpringBoot启动流程及配置类解析原理
通过对 Spring Boot 启动流程及配置类解析原理的深入分析,我们可以看到 Spring Boot 在启动时的灵活性和可扩展性。理解这些机制不仅有助于开发者更好地使用 Spring Boot 进行应用开发,还能够在面对问题时,迅速定位和解决问题。希望本文能为您在 Spring Boot 开发过程中提供有效的指导和帮助。
71 12
|
18天前
|
开发框架 监控 JavaScript
解锁鸿蒙装饰器:应用、原理与优势全解析
ArkTS提供了多维度的状态管理机制。在UI开发框架中,与UI相关联的数据可以在组件内使用,也可以在不同组件层级间传递,比如父子组件之间、爷孙组件之间,还可以在应用全局范围内传递或跨设备传递。
36 2
|
15天前
|
数据可视化 测试技术 API
GraphQL开发工具选型指南:Apipost高效调试与文档生成实战解析
本文深入解析了GraphQL开发工具Apipost在高效调试与文档生成方面的优势,对比同类工具Apifox,突出其可视化界面、实时调试及自动化文档生成等特性。Apipost通过智能代码补全、错误提示等功能简化复杂Query编写,支持一键生成标准化文档,显著提升开发效率和团队协作效果,尤其适合中大型团队应对复杂业务场景。

热门文章

最新文章

推荐镜像

更多