跨态通信方法和通道驱动装置与流程

本公开涉及通信
技术领域：
，尤其是涉及一种跨态通信方法和通道驱动装置。
背景技术：
：在当前信息行业普遍使用的linux系统架构中，内核态(也即，程序工作在内核空间)和用户态(也即，程序工作在用户空间)是操作系统的两种运行级别。操作系统将硬件内存资源按需分别划分给内核态和用户态，两者不能随意访问彼此的空间，以达到系统安全防护作用。但对于实际数据交互业务，特别是在控制层面相关业务应用中，内核态与用户态之间的数据交互却成为必不可少的环节。netlink技术就是在这样的背景下应运而生，并逐渐成为了内核态与用户态之间的主要通信手段。然而，内核态与用户态采用传统的netlink技术进行通信的过程，存在如下问题：在内核空间中的多个内核子系统对应用户空间中的多个应用app的多对多场景中，消息并发交互所需的协议通道数量会受到操作系统所支持的最大协议号限制，消息并发数量受限会影响到内核态和用户态之间的跨态通信。技术实现要素：有鉴于此，本公开的目的在于提供一种跨态通信方法和通道驱动装置，以使内核态与用户态之间的消息并发数量不再受限，从而较好地提升了跨态通信的并发效果。为了实现上述目的，本公开实施例采用的技术方案如下：第一方面，本公开实施例提供了一种跨态通信方法，所述方法应用于位于操作系统内核空间的通道驱动装置，所述通道驱动装置与所述操作系统的用户空间通过各个应用app进程共享的协议通道传输消息，所述方法包括：所述通道驱动装置接收第一app进程发送给第一内核子系统的第一消息；其中，所述第一消息的目的端为所述第一内核子系统的标识、源端为所述第一app进程的标识；所述通道驱动装置根据所述第一内核子系统的标识和所述第一消息的类型，获取所述第一内核子系统的回调接口，并通过所述回调接口将所述第一消息中的第一操作内容传递给所述第一内核子系统；其中，所述第一操作内容还携带有所述第一app进程的标识；所述通道驱动装置接收所述第一内核子系统返回的第二消息；其中，所述第二消息的源端为所述第一内核子系统的标识、目的端为所述第一app进程的标识；所述通道驱动装置根据所述第一内核子系统的标识和所述第一app进程的标识将所述第二消息传递给所述第一app进程。第二方面，本公开实施例还提供一种跨态通信装置，所述通道驱动装置位于操作系统的内核空间，且所述通道驱动装置与所述操作系统的用户空间通过各个app进程共享的协议通道传输消息，所述通道驱动装置包括：第一接收单元，用于接收第一app进程发送给第一内核子系统的第一消息；其中，所述第一消息的目的端为所述第一内核子系统的标识、源端为所述第一app进程的标识；第一传递单元，用于根据所述第一内核子系统的标识和所述第一消息的类型，获取所述第一内核子系统的回调接口，并通过所述回调接口将所述第一消息中的第一操作内容传递给所述第一内核子系统；其中，所述第一操作内容还携带有所述第一app进程的标识；第二接收单元，用于接收所述第一内核子系统返回的第二消息；其中，所述第二消息的源端为所述第一内核子系统的标识、目的端为所述第一app进程的标识；第二传递单元，用于根据所述第一内核子系统的标识和所述第一app进程的标识将所述第二消息传递给所述第一app进程。第三方面，本公开实施例提供了一种电子设备，包括处理器和机器可读存储介质，所述机器可读存储介质存储有能够被所述处理器执行的机器可执行指令，所述处理器执行所述机器可执行指令以实现上述跨态通信方法。第四方面，本公开实施例提供了一种机器可读存储介质，所述机器可读存储介质存储有机器可执行指令，所述机器可执行指令在被处理器调用和执行时，所述机器可执行指令促使所述处理器实现上述跨态通信方法。上述跨态通信方法、装置、电子设备和机器可读存储介质，操作系统的内核空间配置有通道驱动装置，该通道驱动装置与用户空间通过各个app进程共享的协议通道传输消息。通道驱动装置接收第一消息(目的端为第一内核子系统的标识、源端为第一app进程的标识)，并基于第一消息查找第一内核子系统对应的回调接口；进而通过查找到的回调接口将第一消息中的第一操作内容传递给第一内核子系统；通道驱动装置接收第二消息(源端为第一内核子系统的标识、目的端为第一app进程的标识)，并基于第二消息将其传递给第一app进程。本公开提供的上述方式中，由于配置有可确定app进程和内核子系统的对应关系的通道驱动装置，在通道驱动装置的协助下，只需共享的协议通道即可实现内核态与用户态之间的多对多跨态通信，内核态与用户态之间的消息并发数量不再受限，从而较好地提升了跨态通信效果。本公开的其他特征和优点将在随后的说明书中阐述，或者，部分特征和优点可以从说明书推知或毫无疑义地确定，或者通过实施本公开的上述技术即可得知。为使本公开的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。附图说明为了更清楚地说明本公开具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本公开的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。图1示出了本公开实施例所提供的一种netlink通信模式示意图；图2示出了本公开实施例所提供的一种应用app主动发起通信的多对多通信示意图；图3示出了本公开实施例所提供的一种内核子系统主动发起通信的多对多通信示意图；图4示出了本公开实施例所提供的一种内核态与用户态之间的多对多通信示意图；图5示出了本公开实施例所提供的一种跨态通信方法流程图；图6所示的本公开实施例所提供的一种app与内核子系统的交互过程示意图；图7示出了本公开实施例所提供的另一种内核态与用户态之间的多对多通信示意图；图8示出了本公开实施例所提供的一种应用app与内核子系统的交互过程示意图；图9示出了本公开实施例所提供的另一种应用app与内核子系统的交互过程示意图；图10示出了本公开实施例所提供的一种通道驱动装置的结构框图；图11示出了本公开实施例所提供的一种电子设备的结构示意图。具体实施方式为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合附图对本公开的技术方案进行清楚、完整地描述，显然，所描述的实施例是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。netlink是linux操作系统中一种特殊ipc(interprocesscommunication，进程间通信)技术，属于异步网络通信机制，具有使用简单、层次抽象、屏蔽对内核模块的依赖、增加系统的安全性、降低开发难度等优点。netlink技术常见的内核态操作有单播netlink_unicast和广播netlink_broadcast两种传播方式。其中，netlink_unicast用于内核空间中的内核子系统与用户空间中的应用进程间一对一的数据通信模式；netlink_broadcast用于内核空间中的内核子系统与用户空间中的应用进程间一对多的数据通信模式。现有的内核子系统的数量通常为多个，多个内核子系统在与多个应用进程进行通信时，又可称为内核态与用户态之间的多对多的数据通信模式。具体可参见图1所示的一种netlink通信模式示意图，示意出内核态与用户态之间基于netlink技术的一对一通信(一个内核子系统对应一个app，也即app_1)、一对多通信(一个内核子系统对应多个app，也即app_1至app_n)，以及多对多通信(多个内核子系统对应多个app，也即内核子系统1至内核子系统n对应app_1至app_n。其中，本公开实施例提及的app又可称为用户app或app进程，表征一个用户态进程。内核子系统为linux内核的功能块；内核子系统可以随着设备开机自动加载，也可由用户手动加载启动。对于netlink的多对多通信，关键在于使消息并发传输时的内核子系统与应用app之间的消息一一对应。为此，相关技术中主要采用多条netlink协议通道实现内核态与用户态之间的多对多通信，通常基于netlink的内核态与用户态之间的跨态通信模式分为两类，以下进行详细说明：第一类：app主动发起通信的模式(简称get\set类操作)。该通信模式主要采用单播netlink_unicast实现。结合图2所示的一种app主动发起通信的多对多通信示意图可知，每个app进程分别需要一条netlink协议通道与对应的内核子系统进行通信，主要步骤简述如下：步骤1，用户空间的app向内核空间执行send操作，把app的pid(也即，进程id)和操作消息发送给内核空间中的内核子系统。步骤2，内核子系统接收并解析app发送过来的操作消息，然后执行相应操作。步骤3，内核子系统根据上述步骤2中的相应操作，构造需要反馈的回复消息。步骤4，内核子系统调用netlink_unicast发送待回复的消息。步骤5，app的接收进程即可接收到自己对应的netlink协议通道传输的来自内核子系统的消息，完成用户空间与内核空间的跨态交互。第二类：内核子系统主动发起通信的模式(简称event类操作)。该通信模式主要采用广播netlink_broadcast实现。结合图3所示的一种内核子系统主动发起通信的多对多通信示意图可知，每个内核子系统都分别需要一条netlink协议通道与对应的一个或多个app进行通信(可理解为组播通信)，主要步骤简述如下：步骤1，app启动netlink协议通道进行监听，准备接收消息。步骤2，内核态子系统主动构造相关消息。步骤3，内核子系统调用netlink_broadcast主动发送上述步骤2中构造的消息。步骤4，监听在同一个netlink协议通道上的所有的app都能收到来自内核子系统的消息。图2和图3均示意出，无论是第一类跨态通信模式还是第二类跨态通信模式，都需要采用多条netlink协议通道实现。netlink建立的用户态与内核态之间的netlink协议通道实际是特殊的socket(套接)通道，每条通道以一个0-31之间的数字体现给代码开发者；每个数字就是一个协议号，每个协议号代表一条netlink通信。app与内核子系统之间的跨态通信就是通过这个协议号建立对应关系。然而，当前linux系统中最多支持32个netlink协议号，而操作系统已经占据前22个协议号，其中17、20、21是自定义功能协议号以及未使用的10个协议号，因此操作系统最多支持13对协议通道进行基于传统netlink的消息并发传输，也即内核态与用户态之间的消息并发数量会受到操作系统所支持的最大协议号限制，由于协议通道的数量受限，消息并发通信会受到影响。此外，由上述两类跨态通信模式的通信步骤可见，通信发起端不同，netlink传输机制也不同；也即，消息发起端依赖于netlink传输机制。而且对于第二类跨态通信模式，当内核子系统主动发送消息时，用户态所有监听在该协议通道上的进程，不论当前app是否需要该内核子系统发送的消息，都会接收。也即，内核子系统主动发送的消息会混杂到达所有的app。为了使内核态与用户态之间的消息并发数量不再受限，以进一步提升内核态和用户态之间的消息并发通信效果，本公开实施例提供的一种跨态通信方法、装置及电子设备，该技术可应用于设备中需要进行内核态与用户态之间的通信管理中，以下对本公开实施例进行详细介绍。本公开实施方式首先提供了一种跨态通信方法，该方法应用于配置有通道驱动装置的电子设备，可参见图4所示的一种内核态与用户态之间的多对多通信示意图，通道驱动装置(例如，可以是基于netlink协议的驱动模块)位于操作系统的内核空间，且与操作系统的用户空间通过各个app进程共享的协议通道(如基于netlink协议的通道)传输消息，例如数据消息；用户空间中的多个app(也即，app进程)与内核空间中的多个内核子系统(也即，内核空间中的多个功能模块)之间通过较少的协议通道(例如一条或两条)即可实现多对多通信，从而使得内核态与用户态之间的消息并发数量不再受限。具体通信方式可参见图5所示的一种跨态通信方法流程图，该方法首先示意出app主动向内核子系统发起通信的步骤，具体参见如下：步骤s502，通道驱动装置接收第一app进程发送给第一内核子系统的第一消息；其中，第一消息的目的端为第一内核子系统的标识、源端为第一app进程的标识。其中，第一消息的类型可以包括获取类(get类)消息和设置类(set类)消息。第一消息为应用app通过协议通道发送给内核子系统的，主要借助通道驱动装置实现消息的转发。app进程的标识可称为app的进程标识，具体可以为app的进程id，也可以为app的进程编码标识，进程编码标识也即采用预设编码方式(例如哈希运算)对进程id进行编码所得到的编码值，编码方式在此不进行限制。当然也可以为人为设置的其它用于区分不同app进程的数值，只需不同的app进程具有不同的进程标识即可。一种实施方式中第一消息可带有pid、srcid、destid和opcode等信息，其中，pid、srcid、destid和opcode等信息位于第一消息的消息头，通道驱动装置通过消息头即可确知该app要将第一消息发送给哪个内核子系统。具体而言，pid表征发送第一消息的app的进程id；srcid为发送第一消息的app的进程编码标识；pid和srcid是同一个应用进程的两个身份标识值，由于pid的数值通常较大，为避免其浪费内存空间，因此为其对应编码了数值较小的srcid。在实际应用中，上述第一app进程的标识可以选用pid和/或srcid，只要能够唯一标识app进程即可。destid为目的端的内核子系统标识；也即，destid为上述第一内核子系统的标识。opcode是操作码，表示消息类型，诸如get类消息或set类消息等。应当注意的是，传统的跨态通信模式中，内核可以理解为一个大进程，而内核子系统是这个内核大进程中的一些功能块，并没有内核子系统的标识。内核子系统的标识是本公开实施例中特意为每个内核子系统附加的，用以标识一个内核子系统的身份id，以便建立app与内核子系统的对应关系。步骤s504，通道驱动装置根据第一内核子系统的标识和第一消息的类型，获取第一内核子系统的回调接口，并通过回调接口将第一消息中的第一操作内容传递给第一内核子系统；其中，第一操作内容还携带有第一app进程的标识。上述回调接口又可称为操作接口，也是第一内核子系统处理和响应第一消息的接口，可用于构造针对第一消息的回复消息。具体而言，第一内核子系统在接收到第一app进程发过来的第一消息后，根据第一消息中的操作内容，第一内核子系统会得到相应的响应消息，但是该响应消息的格式可能不是协议通道的发送格式，因此，回调接口需要将内核子系统得到的响应消息按照协议通道的数据格式进行重新组织(也即重构)，之后通道驱动装置才能把该重构的响应消息返回至对应的第一app进程。其中，每个内核子系统对某类消息的处理方式可能不同，因此不同的内核子系统的回调接口也就不一样；而且，不同消息类型对应的回调接口也会不同。步骤s506，通道驱动装置接收第一内核子系统返回的第二消息；其中，第二消息的源端为第一内核子系统的标识、目的端为第一app进程的标识。步骤s508，通道驱动装置根据第一内核子系统的标识和第一app进程的标识将第二消息传递给第一app进程。本申请提供的上述方法中，通过内核空间的通道驱动装置与用户空间通过各个app进程共享的协议通道传输消息。在通道驱动装置接收到第一消息(目的端为第一内核子系统的标识、源端为第一app进程的标识)时，基于第一消息查找第一内核子系统对应的回调接口；进而通过查找到的回调接口将第一消息中的第一操作内容传递给第一内核子系统；通道驱动装置接收到第二消息(源端为第一内核子系统的标识、目的端为第一app进程的标识)时，基于第二消息将其传递给第一app进程。这种方式仅需要通道驱动装置使用共享的协议通道即可实现内核态与用户态之间的多对多跨态通信，内核态与用户态之间的消息并发数量不再受限，从而较好地提升了跨态通信效果。为便于理解，本公开实施方式中以多个app进程共享一条netlink协议通道为例，提供了一种app向内核子系统主动发起通信的简单示例，如图6所示的一种app与内核子系统的交互过程示意图，该交互过程包括以下步骤：步骤s602，app1向内核子系统1发送get类消息时，构建第一消息。其中，第一消息的目的端为内核子系统1的标识s1、源端为app1的进程标识a1。在实际应用中，app1的进程标识a1可以为app的进程id(如，上述pid)，当然也可以为app的进程编码标识(如，上述srcid)，或者二者同时携带，在此不进行限制。步骤s604，app1通过共享的netlink协议通道将第一消息发送至通道驱动装置。步骤s606，通道驱动装置根据第一消息的s1和get类型，获取内核子系统1的回调接口1。步骤s608，将第一消息传递至回调接口1，以使回调接口解析第一消息得到第一操作内容。步骤s610，通道驱动装置通过回调接口1将第一消息中的第一操作内容传递给内核子系统1。步骤s612，内核子系统1针对第一消息生成处理结果，将处理结果返回至回调接口1，以使回调接口1基于处理结果构造netlink协议格式的第二消息。其中，第二消息的目的端为app1的进程标识a1，源端为内核子系统1的标识s1。步骤s614，内核子系统1通过回调接口1将第二消息回传至通道驱动装置。步骤s616，通道驱动装置通过共享的netlink协议通道将第二消息传递给app1。app1收到第二消息后，发现第二消息的目的端标识为自身，则确定该消息为自身的，从而进行后续处理，而其它app根据消息的目的端识别该消息不属于自己，则不进行相关处理。通过上述方式，app1在向内核子系统1主动发起通信时，在通道驱动装置的协助下，只需共享的netlink协议通道即可实现app1与内核子系统1的跨态通信，不再受协议通道的数量限制，有助于更好地实现消息并发交互，提升跨态通信效果。通道驱动装置在根据第一内核子系统的标识和第一消息的类型，获取第一内核子系统的回调接口时可以通过读取第一消息的消息头，即可获知第一内核子系统的标识和第一消息的类型，然后可以应用第一内核子系统的标识和第一消息的类型查找预存的第一映射表，得到第一消息对应的回调接口；其中，第一映射表预先存储有内核空间中的内核子系统的标识、消息类型和回调接口的对应关系。上述第一映射表是设备启动时，由内核子系统向通道驱动装置注册得到的；第一映射表的注册环节发生在每个内核子系统的初始化阶段，每个内核子系统的初始化流程在其启动时只执行一次。内核子系统在注册之后，只要整机系统不重启或用户不手动重启某内核子系统，内核子系统就无需再次注册。具体而言，通道驱动装置在内核空间初始化过程中，接收内核空间中的各个内核子系统的注册信息，并将注册信息写入第一映射表。其中，注册信息包括内核子系统对应的回调接口(可理解为回调函数地址或指针)；第一映射表包含内核子系统的标识、消息类型和回调接口间的对应关系；通道驱动装置将注册信息中的内核子系统对应的处理各类消息的回调接口标识保存至第一映射表。在一种实施方式中，可参见表1所示的第一映射表：表1内核子系统标识消息类型回调接口内核子系统1的标识get类消息回调接口1内核子系统1的标识set类消息回调接口2内核子系统2的标识get类消息回调接口3内核子系统2的标识set类消息回调接口4表1简单示意出了内核子系统、消息类型与回调接口的映射关系，因为待处理消息的消息类型不同，一个内核子系统可以对应多个回调接口，诸如，内核子系统1可对应get类消息的回调接口和set类消息的回调接口。而且，同类型消息的回调接口也可能因内核子系统的处理方式不同而不同。诸如，同样是get类消息，内核子系统1对应回调接口1，内核子系统2对应回调接口3。相应地，通道驱动装置在根据第一内核子系统的标识和第一消息的类型，获取第一内核子系统的回调接口时，可以应用第一内核子系统的标识和第一消息的类型查找预存的第一映射表，从而得到第一消息对应的回调接口。在查找到回调接口之后，通道驱动装置即可通过回调接口将第一消息中的第一操作内容传递给对应的第一内核子系统。例如：回调接口将第一消息中的第一操作内容的存储地址通知第一内核子系统，第一内核子系统收到通知后在该存储地址读取第一消息中的第一操作内容。为了减少存储空间的消耗，该第一操作内容中携带的第一app进程的标识优选为上述srcid。在一种实施方式中，可以参照如下步骤实现：(1)通道驱动装置将第一消息传递至查找到的回调接口；(2)回调接口解析第一消息得到第一操作内容，将第一操作内容交由第一内核子系统执行后返回处理结果；该处理结果也即第一内核子系统针对第一操作内容进行处理后生成的响应消息。(3)回调接口基于处理结果构造协议通道对应的协议格式的第二消息，将第二消息回传至通道驱动装置，该第二消息也携带了上述第一app进程的标识，如上述srcid。此外，第二消息中还可以包括completion，其表示第一消息的最终执行结果，诸如成功或失败等。在本实施例中，如果app进程启动，通道驱动装置会接收到app进程启动时发送的初始化信息，并将初始化信息写入第二映射表；一种实施方式中，第二映射表可以仅包含有app进程的进程id与内核子系统的标识间的对应关系，在另一种实施方式中，该第二映射表可以包含有app进程的进程id、app进程的编码标识和内核子系统的标识间的对应关系。以下通过表2示意性列出第二种实施方式下的第二映射表：表2pidapp进程的编码标识内核子系统标识app1进程的进程idapp1进程的编码标识内核子系统1的标识app2进程的进程idapp2进程的编码标识内核子系统2的标识app3进程的进程idapp3进程的编码标识内核子系统1的标识如表2所示，第二映射表示意出了app进程与内核子系统之间的映射关系，具体示意出了app进程的进程id(表中的pid)、app进程的编码标识和内核子系统标识间的对应关系。通过预先建立的第二映射表，通道驱动装置即可应用第一内核子系统的标识和第一app进程的编码标识查找到第一app进程的进程id。当然，如果内核子系统需要将消息发送给多个app进程，则可以在第二映射表中预先配置内核子系统与多个app进程的对应关系，然后在第二映射表中查找命中的app进程，从而将消息分别发送给每个表内命中的app进程。相应地，第一app进程的标识可以为第一app进程的进程id对应的编码标识(也即，上述srcid)；第一app进程的编码标识的位数少于第一app进程的进程id(也即，上述pid)的位数。当通道驱动装置接收到第二消息，并根据第一内核子系统的标识和第一app进程的标识将第二消息传递给第一app进程时，可以首先应用第一内核子系统的标识和第一app进程的编码标识查找预存的第二映射表，得到第一app进程的进程id；然后将第二消息中的目的端由第一app进程的编码标识替换为第一app进程的进程id，并通过协议通道将替换目的端后的第二消息传递给第一app进程。考虑到app启动(也即，上线)后，诸如app进程id可能会发生改变，因此上线app进程会向通道驱动装置发送初始化消息，该初始化消息被通道驱动装置接收到之后，通道驱动装置建立或刷新第二映射表。具体而言，通道驱动装置接收用户空间的上线app进程发送的初始化消息，初始化消息携带有上线app进程的进程id、上线app进程的编码标识和上线app对应的内核子系统标识；通道驱动装置将初始化消息携带的进程id、编码标识和内核子系统标识保存至第二映射表。也即，每当应用app启动时，第二映射表都可进行刷新，以更新表内信息。如果app进程启动后又下线，则表2中的pid会被设置为无效值，例如初始值。具体实现时，可以是内核子系统定时遍历进程任务队列链表以查看进程状态，或者采用app下线时主动下发下线通知等方式来判断app进程是否下线，以便于及时更新表2中的pid。以上述表2中的app1进程启动后又下线为例，如果通道驱动装置在预设的时间内没有监测到该app1的进程，则更新表2中对应的app1进程的进程id为初始值，该初始值以-1为例，具体更新后的表2如表3所示：表3pidapp进程的编码标识内核子系统标识-1app1进程的编码标识内核子系统1的标识app2进程的进程idapp2进程的编码标识内核子系统2的标识app3进程的进程idapp3进程的编码标识内核子系统1的标识本实施例提供的上述跨态通信方法，操作系统的内核空间配置有通道驱动装置，该通道驱动装置与用户空间通过各个app进程共享的协议通道传输消息。通道驱动装置接收第一消息(目的端为第一内核子系统的标识、源端为第一app进程的标识)，并基于第一消息查找第一内核子系统对应的回调接口；进而通过查找到的回调接口将第一消息中的第一操作内容传递给第一内核子系统；通道驱动装置接收第二消息(源端为第一内核子系统的标识、目的端为第一app进程的标识)，并基于第二消息将其传递给第一app进程。本公开提供的上述方式中，由于配置有可确定应用app进程和内核子系统的对应关系的通道驱动装置，在通道驱动装置的协助下，只需共享的协议通道即可实现内核空间与用户空间之间的跨态通信，不再受协议通道的数量限制，从而更好地实现消息并发交互，提升跨态通信效果。考虑到如果内核子系统主动向app发送消息时，如果app未启动(也即，未上线)，消息可能会丢失。因此本公开实施例进一步通道驱动装置中增加了消息缓存队列，用以暂存内核子系统发给app的消息。基于此，上述方法还包括：通道驱动装置接收第二内核子系统向第二app进程发送的事件类消息(源端为第二内核子系统的标识，目的端为第二app进程的编码标识)，通道驱动装置将事件类消息存储至第二app进程的编码标识对应的消息缓存队列并激活发送线程；发送线程判断第二app进程当前是否上线；如果是，发送线程处理消息缓存队列中的事件类消息。如果否，该事件类消息将继续存储于第二app进程的编码标识对应的消息缓存队列中，不进行出队列操作，等待下次发送线程被激活时再处理。通过采取这种缓存方式，可以避免因app未启动而导致内核子系统发送的消息丢失，有效地保证了数据完整性。上述发送线程可以在事件类消息存储至消息缓存队列后激活，也可以是通道驱动装置在发送线程休眠时长达到设定时长时，激活发送线程。其中，设定时长可以根据实际需求而灵活设置，诸如设定为2s。也即，发送线程若要运行，需要两个条件：(1)被别的程序代码上下文激活；(2)超时激活。实际应用中，可以预先设定发送线程只需满足上述条件之一即可激活，或者设定发送线程需均满足上述条件才可激活。具体实施时，激活动作也就是更改发送线程的运行状态值。上述发送线程在判断所述第二app进程当前是否上线时，可以在app在线记录表中，查找第二app进程的编码标识对应的在线记录是否为预设初始值；如果否，确定第二app进程上线。其中，本实施方式中采用了更为直观的app在线记录表，app在线记录表中可记录有第二app进程的编码标识与在线记录的对应关系。如果第二app进程不在线，则其在线记录为预设初始值，诸如“-1”；如果第二app进程在线，则其在线记录为常规的pid值，也即第二app进程的进程id值。在具体实现时，app在线记录表可以根据当前的第二映射表而更新。通道驱动装置通过第二app进程的编码标识查找app在线记录表中的编码标识所对应的在线记录是否为预设初始值，从而判断第二app进程是否上线。也即，检查app在线记录表中是否记录事件类消息对应的进程id，以判断该事件类消息对应的第二app进程是否合法(已启动)。为便于理解，本实施例结合图7给出了一种应用前述跨态通信方法的具体示例，可参见图7所示的另一种内核态与用户态之间的多对多通信示意图，其在图4的基础上又进一步示意出通道驱动装置包括第一映射子模块、第二映射子模块、消息缓存队列和消息发送线程。其中，第一映射子模块用于在内核子系统向通道驱动装置注册消息处理的回调接口时，构建回调接口与内核子系统的映射关系，生成当前的第一映射表。第二映射子模块用于在上线app进程向通道驱动装置发送初始化消息时，构建app进程id、app进程的编码标识和内核子系统标识之间的映射关系，生成当前的第二映射表。消息缓存队列用于缓存内核子系统主动发起的事件类消息，在该消息对应的app未启动时缓存该消息，防止该消息丢失。消息发送线程用于根据第二映射表中app进程的进程id，查找消息缓存队列可以出队的消息，将可以出队的消息传递至对应的app进程。应当注意的是，第二映射子模块、消息缓存队列和消息发送线程是内核子系统主动发起通信时才需要用到的。另外，内核子系统在主动发起通信时，由于内核可看成一个大进程，作为其中的功能块的内核子系统可以直接调用内核提供的发送接口发送event类消息，发送接口不在第一映射子模块中，也无需第一映射子模块维护。基于上述已经建立好的第一映射表和第二映射表，以下分别阐明app主动发起通信的模式以及内核子系统主动发起通信的模式的操作过程。(一)应用app主动发起通信的模式，参见图8所示的一种app与内核子系统的交互过程示意图，本公开实施方式中以多个app进程共享一条netlink协议通道为例进行说明，该交互过程包括以下步骤：步骤s802，内核子系统1向通道驱动装置注册相应的回调接口，添加(或更新)第一映射表。其中，第一映射表中的内核子系统1对应的表项具体为：内核子系统1的标识s1，opcode1和opcode1对应的回调接口1，以及内核子系统1的标识s1，opcode2和opcode2对应的回调接口2。opcode1和opcode2为操作类型标识，包括get类、set类。步骤s804，app1向内核子系统1发送get类消息时，构建第一消息；该第一消息携带的源端(srcid)为app1的pid1和app_id1、目的端(destid)为内核子系统1的标识s1，操作码为opcode1等信息，其中，pid1、app_id1为app1进程的进程id和该进程id对应的编码标识，opcode1为get类消息的操作码。步骤s806，app1通过共享的netlink协议通道将第一消息发送至通道驱动装置。步骤s808，通道驱动装置在预先存储的第一映射表中查找与第一消息中的s1和opcode1对应的回调接口1。步骤s810，通道驱动装置将第一消息传递至回调接口1，以使回调接口解析第一消息得到第一操作内容。步骤s812，通道驱动装置通过回调接口1将第一消息中的第一操作内容传递给内核子系统1。步骤s814，内核子系统1针对第一消息生成处理结果，将处理结果返回至回调接口1，以使回调接口1基于处理结果构造netlink协议格式的第二消息。其中，第二消息携带的destid为app_id1和srcid为s1，操作码为opcode1。步骤s816，内核子系统1通过回调接口1将第二消息回传至通道驱动装置。步骤s818，通道驱动装置在预先存储的第二映射表中查找与第二消息中的destid和srcid对应的pid，得到pid1。步骤s820，通道驱动装置将回调接口1中构造的第二消息传递至第一app进程的进程id为pid1的app1。app每次主动发起通信时，无论发送的消息是何种类型，均可参照上述步骤实现，在此不再赘述。通过上述方式，app在向内核子系统主动发起通信时，在通道驱动装置的协助下，只需共享的netlink协议通道即可将app发送的消息传递给对应的内核子系统，不再受协议通道的数量限制，从而更好地实现消息并发交互，提升跨态通信效果。(二)内核子系统主动发起通信的模式，参见图9所示的另一种app与内核子系统的交互过程示意图，本公开实施方式中以app共享一条netlink协议通道为例进行说明，该交互过程包括以下步骤：步骤s902，app2启动时发送初始化消息给通道驱动装置，用于添加(或更新)第二映射表。具体而言，app2启动时可更新第二映射表，也即在第二映射表中记录app2的上线记录项。该上线记录项包含有app2的进程id、app2的编码标识和对应的内核子系统的标识。如app2上线，第二映射表中的pid为该app2的进程id，否则为预设的初始值。本公开方式中，app2的进程id为pid2，app2的编码标识为app_id2，app2对应的内核子系统为内核子系统2，表示为s2。步骤s904，内核子系统2构建待发送给app2的event类消息。其中，event类消息中携带的srcid为内核子系统2的标识s2以及destid为app2的编码标识，即app_id2。步骤s906，内核子系统2将event类消息发送至通道驱动装置。步骤s908，通道驱动装置将event消息存储至event类消息中app_id2对应的消息缓存队列并激活通道驱动装置内的发送线程。在本公开实施例中，操作系统为每个app进程都设置有消息缓存队列，以便于在该app进程未上线时，缓存内核子系统发送给该app进程的消息。可以理解的是，消息缓存队列的数量可以为多个。发送线程的激活方式可以是：(1)通道驱动装置在将event类消息存储至消息缓存队列后，激活发送线程；(2)通道驱动装置在发送线程休眠时长达到设定时长时，激活发送线程。步骤s910，通道驱动装置通过发送线程查询第二映射表，判断app2是否上线。具体而言，判断第二映射表中的app_id2所对应的pid是否为初始值。步骤s912，当通道驱动装置通过发送线程确定app2上线时，对消息缓存队列中的event类消息进行出队操作。具体实现时，如果app_id2所对应的pid不为预设的初始值，确定app2上线。如果app_id2所对应的pid为预设的初始值，确定app2未上线。当通道驱动装置通过发送线程确定app2未上线时，发送线程不做任何处理，等待下一次激活。步骤s914，通道驱动装置中的发送线程通过共享的netlink协议通道将event类消息发送给app2。通过上述方式，内核子系统在向app主动发起通信时，在通道驱动装置的协助下，只需共享的netlink协议通道即可将内核子系统发送的消息传递给对应的app，不再受协议通道的数量限制，从而更好地实现消息并发交互，提升跨态通信效果。应当注意的是，图8和图9均以app共享一条netlink协议通道为例进行说明，在实际应用中，netlink协议通道也可以设置为两条，其中，获取类消息(也即，get类消息)和设置类消息(也即，set类消息)在传输时共用一条netlink协议通道，事件类消息(也即，event类消息)在传输时使用另一条netlink协议通道。通过上述方式，无论是应用app主动发起通信的模式，还是内核子系统主动发起通信的模式，由于通过通道驱动装置可确知内核子系统与app进程的对应关系，因此只需少量的netlink协议通道即可实现并发数量不受限制的跨态数据交互；而且也保证了内核子系统和应用app在多对多通信场景下的消息一一对应传输。此外，采用上述方式的消息发起端即便不同，但netlink的消息传输机制均相同，也即统一了netlink的消息传输机制。除此之外，因为设置了消息缓存队列，也极大地降低了内核子系统主动发起通信时，因应用app未启动而可能出现的消息丢失现象，进一步保障了跨态通信的可靠性。综上所述，本公开实施例提供的跨态通信方法，具有如下优势：(1)突破了传统的netlink跨态通信模式的消息并发量受限于操作系统的最大协议号的限制。不论是应用app主动发起通信，还是内核子系统主动发起通信，由于通过通道驱动装置可确知应用app和内核子系统的对应关系，只需要少量的协议通道(诸如，1条或2条)就能实现数量不受限制的应用app和内核子系统之间的消息并发交互。(2)与传统的netlink跨态通信模式中，通信发起端不同，netlink传输机制也不同相比，本公开实施例统一了netlink的消息传输机制。无论是应用app主动发起通信，还是内核子系统主动发起通信，消息传输机制均相同。(3)与传统的netlink跨态通信模式中，内核子系统主动发送的消息会混杂到达所有的应用app相比，本公开实施例实现了在多对多通信场景下的消息一一对应传输。(4)与传统的netlink跨态通信模式中内核子系统主动发起通信时，应用app未启动时可能会丢失消息相比，本公开实施例能够避免数据丢失现象的发生，较好地保证了数据完整性，保障了跨态通信的可靠性。综上所述，本公开实施例提供的上述跨态通信方法，可以在保证正常数据传输完整性与顺序性的同时，还提高了跨态通信的并发性，达到了多对多场景下通信双发并发无损的通信目的。对应于上述方法实施方式，本实施例提供了一种跨态通信装置，该装置应用于配置有通道驱动装置的电子设备，通道驱动装置位于电子设备的操作系统和的内核空间，且通道驱动装置与电子设备的用户空间通过各个app共享的netlink协议通道传输消息，如图10所示，该通道驱动装置包括如下单元：第一接收单元1002，用于接收第一app进程发送给第一内核子系统的第一消息；其中，第一消息的目的端为第一内核子系统的标识、源端为第一app进程的标识；第一传递单元1004，用于根据第一内核子系统的标识和第一消息的类型，获取第一内核子系统的回调接口，并通过回调接口将第一消息中的第一操作内容传递给第一内核子系统；其中，第一操作内容还携带有第一app进程的标识；第二接收单元1006，用于接收第一内核子系统返回的第二消息；其中，第二消息的源端为第一内核子系统的标识、目的端为第一app进程的标识；第二传递单元1008，用于根据第一内核子系统的标识和第一app进程的标识将第二消息传递给第一app进程。本实施例提供的上述跨态通信装置，由于配置有可确定app和内核子系统的对应关系的通道驱动装置，在通道驱动装置的协助下，只需一条netlink协议通道即可实现内核空间与用户空间之间的数的跨态通信，不再受协议通道的数量限制，从而更好地实现消息并发交互，提升跨态通信效果。在一种实施方式中，上述装置还包括：注册单元，用于在内核空间初始化过程中，接收内核空间中各个内核子系统的注册信息，将注册信息写入第一映射表；其中，第一映射表包含内核子系统的标识、消息类型和回调接口间的对应关系；第一传递单元还用于：应用第一内核子系统的标识和第一消息的类型查找预存的第一映射表，得到第一消息对应的回调接口。在一种实施方式中，上述装置还包括：初始化单元，用于接收app进程启动时发送的初始化信息，将初始化信息写入第二映射表；第二映射表包含app进程的进程id、app进程的编码标识和内核子系统的标识间的对应关系；相应地，第一app进程的标识为第一app进程的编码标识；第二传递单元还用于：应用第一内核子系统的标识和第一app进程的编码标识查找预存的第二映射表，得到第一app进程的进程id；将第二消息中的目的端由第一app进程的编码标识替换为第一app进程的进程id，并通过协议通道将替换目的端后的第二消息传递给第一app进程。在一种实施方式中，通道驱动装置还包括：第三接收单元，用于接收第二内核子系统向第二app进程发送的事件类消息；其中，所述事件类消息的源端为所述第二内核子系统的标识，目的端为所述第二app进程的编码标识；缓存单元，用于将所述事件类消息存储至所述第二app进程的编码标识对应的消息缓存队列，并激活发送线程；上线判断单元，用于通过所述发送线程判断所述第二app进程当前是否上线；消息处理单元，用于在上线判断单元的判断结果为是时，通过发送线程处理所述消息缓存队列中的事件类消息。上述上线判断单元单元进一步用于：通过发送线程在app在线记录表中，查找所述第二app进程的编码标识对应的在线记录是否为预设初始值；如果否，确定第二app进程上线。上述第一传递单元还用于：将所述第一消息传递至查找到的所述回调接口，以使所述回调接口解析所述第一消息得到第一操作内容，将第一操作内容交由所述第一内核子系统执行后返回处理结果；以及使所述回调接口基于所述处理结果构造协议通道对应的协议格式的第二消息，将所述第二消息回传至所述通道驱动装置。在一种实施方式中，用户空间和所述内核空间传输的消息的消息类型包括获取类消息、设置类消息和事件类消息；协议通道为一条，获取类消息、设置类消息和事件类消息在传输时共用一条协议通道；或者，协议通道为两条，获取类消息和设置类消息在传输时共用一条协议通道，事件类消息在传输时使用另一条协议通道。本公开实施方式所提供的跨态通信装置，其实现原理及产生的技术效果和前述方法实施方式相同，为简要描述，装置实施方式部分未提及之处，可参考前述方法实施方式中相应内容。在上述实施方式的基础上，本公开实施方式还提供了一种电子设备，包括处理器和机器可读存储介质，机器可读存储介质存储有能够被处理器执行的机器可执行指令，处理器执行机器可执行指令以实现上述实施方式中的方法。在实际应用中，处理器由电子设备的操作系统驱动，通道驱动装置是操作系统的一个功能块，其运行于处理器上。参见图11所示的一种电子设备的结构示意图，该电子设备包括处理器100和存储器101；其中，存储器101即为机器可读存储介质，用于存储一条或多条计算机指令，一条或多条计算机指令被处理器执行，以实现上述跨态通信步骤。进一步，图11所示的电子设备还包括总线102和通信接口103，处理器100、通信接口103和存储器101通过总线102连接。其中，存储器101可能包含高速随机存取存储器(ram，randomaccessmemory)，也可能还包括非不稳定的存储器(non-volatilememory)，例如至少一个磁盘存储器。通过至少一个通信接口103(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。总线102可以是isa总线、pci总线或eisa总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图11中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。处理器100可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器100中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器100可以是通用处理器，包括中央处理器(centralprocessingunit，简称cpu)、网络处理器(networkprocessor，简称np)等；还可以是数字信号处理器(digitalsignalprocessor，简称dsp)、专用集成电路(applicationspecificintegratedcircuit，简称asic)、现场可编程门阵列(field-programmablegatearray，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本公开实施方式中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本公开实施方式所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器101，处理器100读取存储器101中的信息，结合其硬件完成前述实施方式的方法的步骤。本公开实施例还进一步提供了一种机器可读存储介质，机器可读存储介质存储有机器可执行指令，机器可执行指令在被处理器调用和执行时，机器可执行指令促使处理器实现前述跨态通信方法。本公开实施例所提供的跨态通信方法、装置及电子设备的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见方法实施例，在此不再赘述。所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。在本公开的描述中，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。最后应说明的是：以上所述实施例，仅为本公开的具体实施方式，用以说明本公开的技术方案，而非对其限制，本公开的保护范围并不局限于此，尽管参照前述实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本
技术领域：
的技术人员在本公开揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本公开实施例技术方案的精神和范围，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应以所述权利要求的保护范围为准。当前第1页12