CN111464642A - 车机消息推送的方法和装置 - Google Patents

Abstract

本申请提供一种车机消息推送的方法和装置，通过软件开发工具包的服务端与车机系统的多个应用程序进行通信。由软件开发工具包的服务端接收消息服务器发送的待推送消息，其中，待推送消息中携带有应用程序的包名。然后就利用应用程序的包名，从车机系统的多个应用程序中，筛选出与待推送消息对应的应用程序并向筛选出的应用程序推送待推送消息。由于软件开发工具包的服务端与所有的车机应用程序，建立一条共用的消息通道，所有的应用程序只需要在该消息通道中就可以接收到软件开发工具包的服务端推送的消息，就不会占用过多的系统资源，可以频繁、并发执行请求的跨进程通信，保证了车机系统消息推送的消息到达率。

Description

车机消息推送的方法和装置

技术领域

本发明涉及互联网应用技术领域，尤其涉及一种车机消息推送的方法和装置。

背景技术

随着社会的发展，汽车成为出行的重要交通工具之一。而汽车的车机系统早期只有一些基本功能，比如播放音乐、收音机等。但是，随着互联网的发展的，人们将互联网技术融入车机端，构建一个智能化的车机系统。一个车机系统中可以有多个应用程序，这些应用程序可以通过联网实现多种功能，其中就包括各个应用程序的消息推送。

在现有技术中，车机系统通常是针对单一车辆、单一功能定制开发。车机系统中的每一个应用程序会有一条对应的消息通道，这就导致了多个应用程序就会有多条消息通道，当服务器同时对多个应用程序进行消息推送时，就会占用过多的系统资源，难以频繁、并发执行请求的跨进程通信，影响了车机系统消息推送的消息到达率。

发明内容

有鉴于此，本申请提供车机消息推送的方法和装置，以解决当多个应用程序同时进行消息推送时，就会占用过多的系统资源，难以频繁、并发执行请求的跨进程通信，影响了车机系统消息推送的消息到达率的问题。

为实现上述目的，本申请实施例提供如下技术方案：

本申请第一方面公开了一种车机消息推送的方法，应用于软件开发工具包的服务端，所述服务端与车机系统的多个应用程序进行通信；其中，所述车机消息推送的方法，包括：

接收消息服务器发送的待推送消息；其中，所述待推送消息中携带有应用程序的包名；

利用所述应用程序的包名，从所述车机系统的多个应用程序中，筛选出与所述待推送消息对应的应用程序；

向所述筛选出的应用程序推送所述待推送消息。

可选的，上述的方法，所述向所述筛选出的应用程序推送所述待推送消息之前，还包括：

对所述待推送消息进行校验；

若校验出所述待推送消息不符合标准格式要求，则停止发送所述待推送消息。

可选的，上述的方法，还包括：

当所述应用程序启动时，则获取所述消息服务器中保存的所述应用程序的包名所对应的所有车机应用程序的接口密钥；

若所述应用程序存在多个所述车机应用程序的接口密钥，则对获取的多个所述车机应用程序的接口密钥进行筛选，得到不属于当前车机系统的车机应用程序的接口密钥；

将不属于当前车机系统的车机应用程序接口密钥与所述应用程序的包名解除绑定。

可选的，上述的方法，还包括：

对车机系统进行监听；

若监听到所述车机系统处于启动状态，则唤醒所述车机系统的每一个所述应用程序。

可选的，上述的方法，还包括：

对所述车机系统的每一个所述应用程序进行监听；

若监听到任何一个所述应用程序被唤醒，则唤醒所述车机系统中的其他应用程序。

本申请第二方面公开了一种车机消息推送的装置，应用于软件开发工具包的服务端，所述服务端与车机系统的多个应用程序进行通信；其中，所述车机消息推送的装置，包括：

接收单元，用于接收消息服务器发送的待推送消息；其中，所述待推送消息中携带有应用程序的包名；

第一筛选单元，用于利用所述应用程序的包名，从所述车机系统的多个应用程序中，筛选出与所述待推送消息对应的应用程序；

推送单元，用于向所述筛选出的应用程序推送所述待推送消息。

可选的，上述的装置，还包括：

检验单元，用于对所述待推送消息进行校验；

停止单元，用于若校验出所述待推送消息不符合标准格式要求，则停止发送所述待推送消息。

可选的，上述的装置，还包括：

获取单元，用于当所述应用程序启动时，则获取所述消息服务器中保存的所述应用程序的包名所对应的所有车机应用程序的接口密钥；

第二筛选单元，用于若所述应用程序存在多个所述车机应用程序的接口密钥，则对获取的多个所述车机应用程序的接口密钥进行筛选，得到不属于当前车机系统的车机应用程序的接口密钥；

解绑单元，用于将不属于当前车机系统的车机应用程序接口密钥与所述应用程序的包名解除绑定。

可选的，上述的装置，第一监听单元，用于对车机系统进行监听；

第一唤醒单元，用于若监听到所述车机系统处于启动状态，则唤醒所述车机系统的每一个所述应用程序。

可选的，上述的装置，第二监听单元，用于对所述车机系统的每一个所述应用程序进行监听；

第二唤醒单元，用于若监听到任何一个所述应用程序被唤醒，则唤醒所述车机系统中的其他应用程序。

从上述技术方案可以看出，本申请提供的一种车机消息推送的方法中，通过软件开发工具包的服务端与车机系统的多个应用程序进行通信。由软件开发工具包的服务端接收消息服务器发送的待推送消息，其中，待推送消息中携带有应用程序的包名。然后就利用应用程序的包名，从车机系统的多个应用程序中，筛选出与待推送消息对应的应用程序并向筛选出的应用程序推送待推送消息。由于软件开发工具包的服务端与所有的车机应用程序，建立一条共用的消息通道，所有的应用程序只需要在该消息通道中就可以接收到软件开发工具包的服务端推送的消息，就不会占用过多的系统资源，可以频繁、并发执行请求的跨进程通信，保证了车机系统消息推送的消息到达率。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请实施例公开的一种车机消息推送的方法的时序图；

图2为本申请另一实施例公开的一种车机消息推送的装置的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在本申请中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

并且，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

由背景技术可知，在现有技术中，车机系统通常是针对单一车辆、单一功能定制开发。车机系统中的每一个应用程序会有一条对应的消息通道，这就导致了多个应用程序就会有多条消息通道，当服务器同时对多个应用程序进行消息推送时，就会占用过多的系统资源，难以频繁、并发执行请求的跨进程通信，影响了车机系统消息推送的消息到达率。

基于此，本申请公开了一种车机消息推送的方法和装置，通过在车机系统中集成软件开发工具包(Software Development Kit，SDK)，将车机系统中的多个应用程序建立单一的消息通道进行消息推送，以解决当多个应用程序同时进行消息推送时，就会占用过多的系统资源，难以频繁、并发执行请求的跨进程通信，影响了车机系统消息推送的消息到达率的问题。

本申请实施例提供了一种车机消息推送的方法，参见图1，具体包括：

S101、业务系统将待推送消息推送到推送网关。

其中，待推送消息，为业务系统根据自身业务内容确定出的消息，用于推送给车机的应用程序。具体的，车机信息可以包括车机应用程序的接口密钥(Application ProgramInterface key，API key)、车机设备的名称(可以理解成是车机设备的唯一标识)、车机设备的地理位置信息以及车机应用程序订阅的消息标签。

需要说明的是，业务系统确定需要进行推送的消息，并将该消息推送到推送网关上。其中，业务系统推送的待推送消息中会携带有与当前待推送消息相关的车机应用程序的API key、车机设备的名称、车机设备的地理位置信息以及车机应用程序订阅的消息标签等信息中的一个或者多个信息。

还需要说明的是，API key由车机端的应用程序根据应用程序包名进行申请，并在申请后将API key传送到SDK服务端内部进行存储。然后，SDK服务端会向消息服务器，也称之为emq(Erlang/Enterprise/Elastic MQTT Broker)服务器，确认API key的正确性。如果正确，则SDK服务端连接到emq服务器，并在emq服务器上更新当前车机设备的名称、SDK版本信息、设备型号、安卓系统版本以及车机设备的地理位置等信息。

另外，业务系统会向推送网关定义消息标签。并且，车机应用程序可以绑定消息标签，具体的，车机应用程序通过SDK服务端，向推送网关发送消息标签的订阅请求，该订阅请求用于订阅当前应用程序需要订阅的消息标签。订阅的消息标签可以更明确当前应用程序需要接收哪些类型的消息。

并且，具有相同的消息标签的应用程序，接收业务系统推送的相同消息。

其中，SDK是软件工程师为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件时的开发工具的集合。车机设备的名称使用Java语言中的UUID方法，使生成的每一个车机设备的名称都是唯一的，不会出现车机设备的名称重复或者为空，导致车机端接收消息出现问题的情况。

在完成上述更新信息与订阅标签之后，将车机应用程序的API key、车机设备的名称、车机设备的地理位置信息以及车机应用程序订阅的消息标签等信息都上传到业务系统以及推送网关，业务系统就可以通过据API key、车机设备的名称等信息，确定要进行推送消息。

具体的，应用程序向业务系统反馈数据，反馈的数据包括车机应用程序的APIkey、车机设备的名称、车机设备的地理位置信息以及车机应用程序订阅的消息标签等信息。并且，业务系统可以将应用程序反馈的数据发送给推送网关，当然，业务系统向推送网关反馈的数据中，一般包括车机应用程序的API key、车机设备的名称、车机设备的地理位置信息以及车机应用程序订阅的消息标签等信息。

还需要说明的是，SDK服务端还可以将车机应用程序订阅的消息标签等消息，向推送网关发送，因此，推送网关可以从SDK服务端和业务系统两个渠道接收车机应用程序订阅的消息标签等消息，以便进行验证。

S102、推送网关接收待推送消息，并将待推送消息向消息服务器进行推送。

其中，消息服务器可以分别多个内部服务器，每一个内部服务器可连接不同的SDK服务端。并且，多个内部服务器整合一个外网地址。因此，推送网关向整合的消息服务器的外网地址发送待推送消息。

可选地，推送网关接收待推送消息之后，还可以识别接收的待推送消息中的车机信息，将车机信息进行验证，在车机信息验证通过后，再将待推送消息向消息服务器推送。

S103、消息服务器将待推送消息推送到软件开发工具包的服务端。

其中，软件开发工具包SDK分为服务端和客户端，客户端可以理解成集成于每一个车机应用程序；服务端被多个车机应用程序共用，且可与消息服务器进行连接。多个车机应用程序会对服务端与消息服务器的连接结果进行监听，如果连接成功，车机应用程序通知服务端以车机应用程序API key、和车机应用程序API key+车机设备的名称两种形式，分别进行绑定。这样，车机应用程序就能接收到服务器根据上述两种形式发送的消息。

因此，消息服务器要将待推送消息推送到软件开发工具包的服务端。

需要说明的是，消息服务器接收待推送消息之后，自动识别SDK服务端连接的内部服务器，并通过识别出的内部服务器向连接的SDK服务端发送待推送消息。当然，消息服务器识别SDK服务端连接的内部服务器的过程中，SDK服务端是指车机消息中的应用程序的名称所指代的应用程序所对应的SDK服务端。

还需要说明的是，消息服务器接收到待推送消息，在待推送消息中携带有车机信息，则需要将删除车机信息，并组合删除车机信息后的待推送消息和应用程序的包名，得到新的待推送消息。之后，消息服务器将新的待推送消息向软件开发工具包的服务端。

由此可以得到：消息服务器推送给软件开发工具包的服务端的待推送消息，携带有车机应用程序的包名。

S104、软件开发工具包的服务端接收待推送消息，并确定车机应用程序的包名对应的应用程序，再向车机应用程序的包名对应的应用程序推送待推送消息。

其中，软件开发工具包的服务端与车机系统的多个车机应用程序，建立有连接关系，软件开发工具包的服务端可以通过一个通信链路，与多个车机应用程序进行通信。

因此，在SDK服务端接收到消息服务器推送的待推送消息后，先根据待推送消息中附带的应用程序包名信息来确定需要被推送的应用程序，再通过通信链路，将待推送消息向确定出的应用程序推送，这样就可以让待推送消息更准确的推送到需要接收它的应用程序，保证了消息推送的准确率。

本实施例提供的车机消息推送的方法中，通过SDK服务端与车机系统的多个应用程序进行通信。由SDK服务端接收消息服务器发送的待推送消息，其中，待推送消息中携带有应用程序的包名。然后就利用应用程序的包名，从车机系统的多个应用程序中，筛选出与待推送消息对应的应用程序并向筛选出的应用程序推送待推送消息。由于SDK服务端与所有的车机应用程序，建立一条共用的消息通道，所有的应用程序只需要在该消息通道中就可以接收到SDK服务端推送的消息，就不会占用过多的系统资源，可以频繁、并发执行请求的跨进程通信，保证了车机系统消息推送的消息到达率。

可选的，在本申请的另一实施例中，在执行步骤S104中的向车机应用程序的包名对应的应用程序推送待推送消息之前，还可以包括：

软件开发工具包的服务端对待推送消息进行校验。

若校验出待推送消息不符合标准格式要求，则停止发送待推送消息。

需要说明的是，SDK服务端在待推送消息推送到与车机应用程序的包名对应的车机应用程序之前，先对待推送消息进行校验。

校验的标准是待推送消息必须以json格式发送，并且，消息内容必须带有消息ID、消息标题、消息类别(普通消息或者通知消息)、消息内容、消息对应的应用程序包名。如果校验出哪一条消息不符合上述的标准，则停止向应用程序发送该消息。这样可以减少将有问题的消息推送到车机应用程序上，提升推送的消息质量。

可选的，在本申请的另一实施例中，上述车机消息推送的方法的过程中，还可以包括：

当应用程序启动时，软件开发工具包的服务端向消息服务器发送获取请求；该获取请求用于获取消息服务器中保存的应用程序的包名所对应的所有车机应用程序的接口密钥。

若应用程序存在多个车机应用程序的接口密钥，则对车机应用程序的接口密钥进行筛选，得到不属于当前车机系统的车机应用程序的接口密钥。

将不属于当前车机系统的车机应用程序的接口密钥与应用程序的包名解除绑定。

其中，本实施例的方案，可以在对应图1的实施例中，软件开发工具包的服务端在执行步骤S104的过程中并行执行，与步骤S104的执行过程互相不干扰。

需要说明的是，在同一台车机设备上如果使用过多个版本的车机系统的话，比如测试版和正式版。那么在使用测试版的时候，一个应用程序申请了一个测试版本的APIkey。直到后面使用正式版的时候，之前申请的测试版API key并没用在emq服务器上解除绑定，然后该应用程序又申请的一个正式版的API key，这样就导致了一个应用程序会存在一个包名对应两个API key的情况。这样，当SDK服务端根据应用程序的包名向应用程序推送消息时，就会同时将两个API key对应的信息都发送到该应用程序上，导致重复接收消息。

因此，当一个应用程序启动时，则向emq服务器获取应用程序的包名所对应的所有API key。如果该应用程序存在多个API key，则对API key进行筛选，得到不属于当前车机系统的API key。然后，将不属于当前车机系统的API key与该应用程序的包名解除绑定。这样，就能保证该应用程序的包名是与该应用程序的API key是唯一对应的，就可以解决可能接收消息重复的问题。

可选的，在本申请的另一实施例中，上述车机消息推送的方法，还可以包括：

软件开发工具包的服务端对车机系统进行监听。

若监听到车机系统处于启动状态，软件开发工具包的服务端则唤醒车机系统中所有的应用程序。

本实施例的方案，一般会在软件开发工具包的服务端在执行上述实施例中步骤S104之前来执行。当然，在步骤S104的执行过程中，也可以继续执行本实施例的方案。

需要说明的是，当车机中应用程序不是出于运行的状态时，比如系统刚启动而应用程序没有被主动唤醒时，消息服务器推送的消息就无法推送到应用程序上，这就降低了消息的到达率。由于车机系统大部分采用安卓系统，安卓系统通过应用程序自行在系统中登记注册事件来响应系统产生的各类消息，因此，SDK服务端可以对车机系统进行广播监听，当监听到系统开机的响应后，则唤醒所有的应用程序，以提高消息推送的到达率。

可选的，在本申请的另一实施例中，上述车机消息推送的方法，还可以包括：

软件开发工具包的服务端对车机系统中所有的应用程序进行监听。

若监听到任何一个应用程序被唤醒，软件开发工具包的服务端则唤醒车机系统其他所有的应用程序。

同样，本实施例的方案，也可以在软件开发工具包的服务端在执行上述实施例中步骤S104之前来执行。当然，在步骤S104的执行过程中，也可以继续执行本实施例的方案。

需要说明的是，现在大部分车机系统都是基于安卓系统进行开发，但是随着安卓版本的更新(比如安卓8.0版本以上)，安卓系统对后台的管理机制更为严格，如果一个应用程序长时间没有被使用，就会被系统结束该应用的运行，这样服务器推送的消息就无法推送到应用程序上，这就降低了消息的到达率。因此，SDK服务端可以对车机系统中所有的应用程序进行监听，如果监听到任何一个应用程序被唤醒，则唤醒其他所有的应用程序。这样只要有一个程序还在运行，就可以将其他被结束运行的或者还没有被唤醒的应用程序全部唤醒，以提高消息推送的到达率。

本发明另一实施例还提供了一种车机消息推送的装置，如图2所示，具体包括：

接收单元201，用于接收消息服务器发送的待推送消息；其中，待推送消息中携带有应用程序的包名。

第一筛选单元202，用于利用应用程序的包名，从车机系统的多个应用程序中，筛选出与待推送消息对应的应用程序。

推送单元203，用于向筛选出的应用程序推送待推送消息。

本申请提供的车机消息推送的装置中，通过SDK服务端与车机系统的多个应用程序进行通信。由接收单元201接收消息服务器发送的待推送消息，其中，待推送消息中携带有应用程序的包名。然后第一筛选单元202就利用应用程序的包名，从车机系统的多个应用程序中，筛选出与待推送消息对应的应用程序，最后推送单元203向筛选出的应用程序推送待推送消息。由于SDK服务端与所有的车机应用程序，建立一条共用的消息通道，所有的应用程序只需要在该消息通道中就可以接收到SDK服务端推送的消息，就不会占用过多的系统资源，可以频繁、并发执行请求的跨进程通信，保证了车机系统消息推送的消息到达率。

本实施例中，接收单元201、第一筛选单元202以及推送单元203的具体执行过程，可参见上述方法实施例内容，此处不再赘述。

可选的，在本发明的另一实施例中，上述车机消息推送的装置，还可以包括：

检验单元，用于对待推送消息进行校验；

停止单元，用于若校验出待推送消息不符合标准格式要求，则停止发送待推送消息。

本实施例中，检验单元以及停止单元的具体执行过程，可参见上述方法实施例内容，此处不再赘述。

可选的，在本发明的另一实施例中，上述车机消息推送的装置，还可以包括：

获取单元，用于当应用程序启动时，则获取消息服务器中保存的应用程序的包名所对应的所有车机应用程序的接口密钥；

第二筛选单元，用于若应用程序存在多个车机应用程序的接口密钥，则对获取的多个车机应用程序的接口密钥进行筛选，得到不属于当前车机系统的车机应用程序的接口密钥；

解绑单元，用于将不属于当前车机系统的车机应用程序接口密钥与应用程序的包名解除绑定。

本实施例中，获取单元、第二筛选单元以及解绑单元的具体执行过程，可参见上述方法实施例内容，此处不再赘述。

可选的，在本发明的另一实施例中，上述车机消息推送的装置，还可以包括：

第一监听单元，用于对车机系统进行监听；

第一唤醒单元，用于若监听到车机系统处于启动状态，则唤醒车机系统的每一个应用程序。

本实施例中，第一监听单元以及第一唤醒单元的具体执行过程，可参见上述方法实施例内容，此处不再赘述。

可选的，在本发明的另一实施例中，上述车机消息推送的装置，还可以包括：

第二监听单元，用于对车机系统的每一个应用程序进行监听；

第二唤醒单元，用于若监听到任何一个应用程序被唤醒，则唤醒车机系统中的其他应用程序。

本实施例中，第二监听单元以及第二唤醒单元的具体执行过程，可参见上述方法实施例内容，此处不再赘述。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种车机消息推送的方法，其特征在于，应用于软件开发工具包的服务端，所述服务端与车机系统的多个应用程序进行通信；其中，所述车机消息推送的方法，包括：

接收消息服务器发送的待推送消息；其中，所述待推送消息中携带有应用程序的包名；

利用所述应用程序的包名，从所述车机系统的多个应用程序中，筛选出与所述待推送消息对应的应用程序；

向所述筛选出的应用程序推送所述待推送消息。

2.根据权利要求1所述的方法，其特征在于，所述向所述筛选出的应用程序推送所述待推送消息之前，还包括：

对所述待推送消息进行校验；

若校验出所述待推送消息不符合标准格式要求，则停止发送所述待推送消息。

3.根据权利要求1所述的方法，其特征在于，还包括：

当所述应用程序启动时，则获取所述消息服务器中保存的所述应用程序的包名所对应的所有车机应用程序的接口密钥；

若所述应用程序存在多个所述车机应用程序的接口密钥，则对获取的多个所述车机应用程序的接口密钥进行筛选，得到不属于当前车机系统的车机应用程序的接口密钥；

将不属于当前车机系统的车机应用程序接口密钥与所述应用程序的包名解除绑定。

4.根据权利要求1所述的方法，其特征在于，还包括：

对车机系统进行监听；

若监听到所述车机系统处于启动状态，则唤醒所述车机系统的每一个所述应用程序。

5.根据权利要求1所述的方法，其特征在于，还包括：

对所述车机系统的每一个所述应用程序进行监听；

若监听到任何一个所述应用程序被唤醒，则唤醒所述车机系统中的其他应用程序。

6.一种车机消息推送的装置，其特征在于，应用于软件开发工具包的服务端，所述服务端与车机系统的多个应用程序进行通信；其中，所述车机消息推送的装置，包括：

接收单元，用于接收消息服务器发送的待推送消息；其中，所述待推送消息中携带有应用程序的包名；

第一筛选单元，用于利用所述应用程序的包名，从所述车机系统的多个应用程序中，筛选出与所述待推送消息对应的应用程序；

推送单元，用于向所述筛选出的应用程序推送所述待推送消息。

7.根据权利要求6所述的装置，其特征在于，还包括：

检验单元，用于对所述待推送消息进行校验；

停止单元，用于若校验出所述待推送消息不符合标准格式要求，则停止发送所述待推送消息。

8.根据权利要求6所述的装置，其特征在于，还包括：

获取单元，用于当所述应用程序启动时，则获取所述消息服务器中保存的所述应用程序的包名所对应的所有车机应用程序的接口密钥；

第二筛选单元，用于若所述应用程序存在多个所述车机应用程序的接口密钥，则对获取的多个所述车机应用程序的接口密钥进行筛选，得到不属于当前车机系统的车机应用程序的接口密钥；

解绑单元，用于将不属于当前车机系统的车机应用程序接口密钥与所述应用程序的包名解除绑定。

9.根据权利要求6所述的装置，其特征在于，还包括：

第一监听单元，用于对车机系统进行监听；

第一唤醒单元，用于若监听到所述车机系统处于启动状态，则唤醒所述车机系统的每一个所述应用程序。

10.根据权利要求6所述的装置，其特征在于，还包括：

第二监听单元，用于对所述车机系统的每一个所述应用程序进行监听；

第二唤醒单元，用于若监听到任何一个所述应用程序被唤醒，则唤醒所述车机系统中的其他应用程序。

Images