##D-Bus三层架构
DBus是一个为应用程序间通信的消息总线系统, 用于进程之间的通信。它是个3层架构的IPC 系统，包括：
1、函数库libdbus ，用于两个应用程序互相联系和交互消息。
2、一个基于libdbus构造的消息总线守护进程，可同时与多个应用程序相连，并能把来自一个应用程序的消息路由到0或者多个其他程序。
3、基于特定应用程序框架的封装库或捆绑（wrapper libraries or bindings ）。例如，libdbus-glib和libdbus-qt，还有绑定在其他语言，例如Python的。大多数开发者都是使用这些封装库的API，因为它们简化了D-Bus编程细节。libdbus被有意设计成为更高层次绑定的底层后端（low-levelbackend ）。大部分libdbus的 API仅仅是为了用来实现绑定。
##总线
在D-Bus中，“bus”是核心的概念，它是一个通道：不同的程序可以通过这个通道做些操作，比如方法调用、发送信号和监听特定的信号。在一台机器上总线守护有多个实例(instance)。这些总线之间都是相互独立的。
###一个持久的系统总线（system bus）：
它在引导时就会启动。这个总线由操作系统和后台进程使用，安全性非常好，以使得任意的应用程序不能欺骗系统事件。它是桌面会话和操作系统的通信，这里操作系统一般而言包括内核和系统守护进程。这种通道的最常用的方面就是发送系统消息，比如：插入一个新的存储设备；有新的网络连接；等等。
###会话总线（session buses）：
这些总线当用户登录后启动，属于那个用户私有。它是用户的应用程序用来通信的一个会话总线。同一个桌面会话中两个桌面应用程序的通信，可使得桌面会话作为整体集成在一起以解决进程生命周期的相关问题。
D-Bus是低延迟而且低开销的，设计得小而高效，以便最小化传送的往返时间。另外，协议是二进制的，而不是文本的，这样就排除了费时的序列化过程。从开发者的角度来看，D-BUS 是易于使用的。有线协议容易理解，客户机程序库以直观的方式对其进行包装。D-Bus的主要目的是提供如下的一些更高层的功能：
A、结构化的名字空间
B、独立于架构的数据格式
C、支持消息中的大部分通用数据元素
D、带有异常处理的通用远程调用接口
E、支持广播类型的通信
##Bus daemon总线守护
Bus daemon是一个特殊的进程：这个进程可以从一个进程传递消息给另外一个进程。当然了，如果有很多applications链接到这个通道上，这个 daemon进程就会把消息转发给这些链接的所有程序。在最底层，D-Bus只支持点对点的通信，一般使用本地套接字（AF_UNIX）在应用和bus daemon之间通信。D-Bus的点对点是经过busdaemon抽象过的，由busdaemon来完成寻址和发送消息，因此每个应用不必要关心要把消息发给哪个进程。D-Bus发送消息通常包含如下步骤（正常情况下）：
创建和发送消息 给后台bus daemon进程，这个过程中会有两个上下文的切换。
后台bus daemon进程会处理该消息，并转发给目标进程，这也会引起上下文的切换目标程序接收到消息，然后根据消息的种类，做不同的响应：要么给个确认、要么应答、还有就是忽略它。最后一种情况对于“通知”类型的消息而言，前两种都会引起进一步的上下文切换。
综上原因，如果你准备在不同的进程之间传递大量的数据，D-Bus可能不是最有效的方法，最有效的方法是使用共享内存，但是对共享内存的管理也是相当复杂的。
D-Bus常见概念
##原生对象和对象路径
所有使用D-BUS的应用程序都包含一些对象, 当经由一个D-BUS连接收到一条消息时，该消息是被发往一个对象而不是整个应用程序。在开发中程序框架定义着这样的对象，例如JAVA，GObject，QObject等等，在D-Bus中成为native object。
对于底层的D-Bus协议，即libdbus API，并不理会这些native object，它们使用的是一个叫做object path的概念。通过object path，高层编程可以为对象实例进行命名，并允许远程应用引用它们。这些名字看起来像是文件系统路径，例如一个对象可能叫做“/org/kde/kspread/sheets/3/cells/4/5”。易读的路径名是受鼓励的做法，但也允许使用诸如“/com/mycompany/c5yo817y0c1y1c5b”等，只要它可以为你的应用程序所用。Namespacing的对象路径以开发者所有的域名开始（如 /org/kde）以避免系统不同代码模块互相干扰。
简单地说：一个应用创建对象实例进行D-Bus的通信，这些对象实例都有一个名字，命名方式类似于路径，例如/com/mycompany，这个名字在全局（session或者system）是唯一的，用于消息的路由。
##方法和信号Methodsand Signals
每一个对象有两类成员：方法和信号。方法就是JAVA中同样概念，方法是一段函数代码，带有输入和输出。信号是广播给所有兴趣的其他实体，信号可以带有数据payload。
在 D-BUS 中有四种类型的消息：方法调用（method calls）、方法返回（method returns）、信号（signals）和错误（errors）。要执行 D-BUS 对象的方法，您需要向对象发送一个方法调用消息。它将完成一些处理（就是执行了对象中的Method，Method是可以带有输入参数的。）并返回，返回消息或者错误消息。信号的不同之处在于它们不返回任何内容：既没有“信号返回”消息，也没有任何类型的错误消息。
##接口Interface
每一个对象支持一个或者多个接口，接口是一组方法和信号，接口定义一个对象实体的类型。D-Bus对接口的命名方式，类似org.freedesktop.Introspectable。开发人员通常将使用编程语言类的的名字作为接口名字。
##Proxies代理
代理对象用来表示其他的remote object。当我们触发了proxy对象的method时，将会在D-Bus上发送一个method_call的消息，并等待答复，根据答复返回。使用非常方便，就像调用一个本地的对象。
##Bus Names总线名字
当一个应用连接到bus daemon，daemon立即会分配一个名字给这个连接，称为unique connection name ，这个唯一标识的名字以冒号：开头，例如:34-907，这个名字在daemon的整个生命周期是唯一的。但是这种名字总是临时分配，无法确定的，也难以记忆，因此应用可以要求有另外一个名字well-known name 来对应这个唯一标识，就像我们使用域名来对应IP地址一样。例如可以使用com.mycompany来映射:34-907。应用程序可能会要求拥有额外的周知名字（well-knownname ）。例如，你可以写一个规范来定义一个名字叫做 com.mycompany.TextEditor。你的协议可以指定自己拥有这个名字，一个应用程序应该在路径/com/mycompany /TextFileManager下有一个支持接口org.freedesktop.FileHandler的对象。应用程序就可以发送消息到这个总线名字，对象，和接口以执行方法调用。
当一个应用结束或者崩溃是，OS kernel会关闭它的总线连接。总线发送notification消息告诉其他应用，这个应用的名字已经失去他的owner。当检测到这类notification时，应用可以知道其他应用的生命周期。这种方式也可用于只有一个实例的应用，即不开启同样的两个应用的情况。
来源：CSDN
作者：一只会笑的小猪
链接：https://blog.csdn.net/a_studycx/article/details/86742607